axvspan musings

axvspan is useful with plot_date. Two thoughts addressing

    > only convenience not functionality.

    > 1. Might it make sense for the first argument to be a list?
    > This would be interpreted as [xmin1,xmax1,xmin2,xmax2,...]
    > allowing multiple shadings in one go. If breaking the
    > interface is too costly, perhaps allowing matched lists for
    > the xmin and xmax arguments would be an alternative.

I wouldn't want to break the existing interface. Is it really that
It's pretty trivial to iterate over your list and call axvspan
repeatedly. Now if you have a long list of min/max values, you'll get
into performance issues since axvspan creates a new rectangle for each
min/max pair. To handle this case, we would need to use a
PolygonCollection (axvspans?) I would suggest [ (xmin1, xmax2),
(xmin1, xmin2), ...] as a more natural data structure for the
argument. Is this a common need?

    > 2. If I wish to shade date ranges, am I right that I now
    > should produce date objects and then use date2num to get
    > xmin and xmax? Would it be useful for axvspan to directly
    > accept the tuples that would be fed to date (or datetime)
    > for xmin and xmax?

Well plotdate takes datenums (as you say, dates converted with
date2num). I think it would add, not reduce, confusion if axvspan did
anything different in the case. To make your code read better, just
add a little helper function converting whatever form of date
representation you use to a datetime and then call it

  axvspan( todatenum(xmin), todatenum(xmax) )

JDH

JDH

It's pretty trivial to iterate over your list and call axvspan
repeatedly.

Absolutely.
I saw this purely as a nice user convenience.
I was not even thinking about the performance
aspect, which you mention.

Now if you have a long list of min/max values, you'll get
into performance issues since axvspan creates a new
rectangle for each min/max pair. To handle this case, we
would need to use a PolygonCollection (axvspans?) I would
suggest [ (xmin1, xmax2), (xmin1, xmin2), ...] as a more
natural data structure for the argument.

Yes, I considered that because of its naturalness
but went for conciseness. (I also had in the back
of my mind that you might one day accept datetime.date
compatible tuples as arguments, and typing tuples of tuples
seemed error prone.) Either is great.

Is this a common need?

Pretty common in macroeconomics.
E.g., highlight the recession periods for some time series.

However, given what you have said, I should add that
I cannot think of an example with a *long* list of values.

Cheers,
Alan

···

On Sat, 09 Jul 2005, John Hunter apparently wrote: