Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

plot_date should not use markers by default #1308

Closed
jklymak opened this issue Sep 25, 2012 · 14 comments
Closed

plot_date should not use markers by default #1308

jklymak opened this issue Sep 25, 2012 · 14 comments

Comments

@jklymak
Copy link
Member

jklymak commented Sep 25, 2012

Hi - for some reason plot_date uses markers by default, which is extremely slow (on my backend) if you have a lot of data (say 200k data points). Suggest changing default to be the same as plot - i.e. just use a line.
Thanks, Jody

@dmcdougall
Copy link
Member

@jklymak Would you mind providing a short and self-contained example demonstrating the problem? Which backend are you using?

@jklymak
Copy link
Member Author

jklymak commented Sep 25, 2012

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

@dmcdougall
Copy link
Member

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?

@jklymak
Copy link
Member Author

jklymak commented Sep 25, 2012

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

is slow

plot(x,y)

is fast.

@dmcdougall
Copy link
Member

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.

@jklymak
Copy link
Member Author

jklymak commented Sep 25, 2012

Right, I don't see why it has a different default from plot

@dmcdougall
Copy link
Member

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

@efiring
Copy link
Member

efiring commented Sep 25, 2012

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?

@tacaswell
Copy link
Member

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.

@tacaswell
Copy link
Member

This was also addressed in #2641 where it was declined to change the default more than removing the color.

@jklymak
Copy link
Member Author

jklymak commented Jan 16, 2014

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'.

@tacaswell
Copy link
Member

I am sympathetic to that concern (and so is @WeatherGod ), but doing that would require a bump to 2.0.

@pelson
Copy link
Member

pelson commented Jan 17, 2014

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!

@tacaswell
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants