plot_date should not use markers by default #1308

Activity

1. dmcdougall commented on Sep 25, 2012

   

   dmcdougall

   on Sep 25, 2012

   Member

   More actions

   @jklymak Would you mind providing a short and self-contained example demonstrating the problem? Which backend are you using?
2. jklymak commented on Sep 25, 2012

   

   jklymak

   on Sep 25, 2012

   MemberAuthor

   More actions

   Using the mac backend. The first elapsed time is about 0.4 s, the second 33s.

   Thanks, Jody

   from pylab import *
   import datetime as dt
   import time
   
   close('all')
   # three years of 1-minute data...
   t = add(arange(0,3.*365.,1./24./60.),matplotlib.dates.datestr2num('2010-01-01'))
   x = cumsum(randn(shape(t)[0]))
   figure(1)
   clf()
   tt = time.time()
   plot_date(t,x,'-')
   show()
   elapsed = time.time() - tt
   print elapsed
   
   figure(2)
   clf()
   tt = time.time()
   plot_date(t,x)
   show()
   elapsed = time.time() - tt
   print elapsed
3. dmcdougall commented on Sep 25, 2012

   

   dmcdougall

   on Sep 25, 2012

   Member

   More actions

   Wow. That is unreasonably slow. However, the size of your data vector is about 1.5e6. That is rather large. If you do:

   x = arange(1.5e6)
   y = sin(x)
   plot(x, y)
   show()

   is that just as slow as your plot_date script?
4. jklymak commented on Sep 25, 2012

   

   jklymak

   on Sep 25, 2012

   MemberAuthor

   More actions

   x = arange(1.5e6)
   y = sin(x)
   plot(x,y,'d')

   is slow

   plot(x,y)

   is fast.
5. dmcdougall commented on Sep 25, 2012

   

   dmcdougall

   on Sep 25, 2012

   Member

   More actions

   Ok, so it really is the markers. Thanks. Is the workaround of specifying fmt='-' unreasonable? I'm not sure that changing the default plot_date behaviour (an api change) is warranted in this case.

   Then again, it seems that the functionality of plot_date should mimic exactly that of plot, except with dates as data.
6. jklymak commented on Sep 25, 2012

   

   jklymak

   on Sep 25, 2012

   MemberAuthor

   More actions

   Right, I don't see why it has a different default from plot
7. dmcdougall commented on Sep 25, 2012

   

   dmcdougall

   on Sep 25, 2012

   Member

   More actions

   I think that's a fair comment. Let's wait and see what others think about this.
8. efiring commented on Sep 25, 2012

   

   efiring

   on Sep 25, 2012

   Member

   More actions

   On 2012/09/25 10:45 AM, Damon McDougall wrote:

   I think that's a fair comment. Let's wait and see what others think
   about this.

   It's probably a matter of history and typical usage; plot_date was
   probably written from the standpoint of users in finance, say, who deal
   with things like daily stock prices, which are better represented with
   markers for moderate time intervals.

   I agree that it would be more logical to have it obey it's docstring,
   which indicates it is merely plot with dates. Maybe this can be an API
   change for 1.3?
9. tacaswell commented on Jan 16, 2014

   

   tacaswell

   on Jan 16, 2014

   Member

   More actions

   I am going to close this as I don't think we want to change default arguments with out very good reason. If anyone disagrees please re-open.
10. tacaswell

    closed this as completedon Jan 16, 2014
11. tacaswell commented on Jan 16, 2014

    

    tacaswell

    on Jan 16, 2014

    Member

    More actions

    This was also addressed in #2641 where it was declined to change the default more than removing the color.
12. jklymak commented on Jan 16, 2014

    

    jklymak

    on Jan 16, 2014

    MemberAuthor

    More actions

    I'll stick up for re-opening this. I've really enjoyed matplotlib, but a huge frustration is inconsistent arguments across routines. This is a pretty classic case of inconsistency: "plot" has fmt='-' and "plot_date" has fmt='o'.
13. tacaswell commented on Jan 16, 2014

    

    tacaswell

    on Jan 16, 2014

    Member

    More actions

    I am sympathetic to that concern (and so is @WeatherGod ), but doing that would require a bump to 2.0.
14. pelson commented on Jan 17, 2014

    

    pelson

    on Jan 17, 2014

    Member

    More actions

    but doing that would require a bump to 2.0.

    I don't entirely agree. If a user can maintain backwards compatibility by adding fmt='o' and it works for all versions of mpl from v1.1 onwards then I'd consider it, if the argument was compelling (and I think it is) I'd probably support it. That said, I'd want @tacaswell and/or @WeatherGod to back it too, so I leave it to their discretion if they don't want to take it on.

    @jklymak - an alternative here might be to add an rcParam (I have a history of disliking rcParams, so I don't say this lightly 😄). At least that way we could give the ability to change the default, or even better, the ability to revert to the old, less sensible, default, if a user opted in.

    Anyway, I wont re-open this, as I think the discussion has served its purpose - at this point I think it is code that talks.

    Cheers!
15. tacaswell commented on Jan 17, 2014

    

    tacaswell

    on Jan 17, 2014

    Member

    More actions

    This sort of thing will be easy to do with the new way of doing rcparam (#2637).

    The concern I have is not that people can't reproduce their plots, but that we will be breaking code that used to work in pipelines.