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

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

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?

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

is slow

plot(x,y)

is fast.

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.

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

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

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?

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.

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

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

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

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!

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.