John, I've run into this problem quite a few times and I'd love to figure out some way to fix it. As an example, here's the kind of scenario this occurs in:
I embed MPL in a few different GUI's that plot data either in real-time or via the user selecting things. There is a saved state which contains preferences like auto-scaling, legend on/off, axis formatting, etc. When the app starts up, I need to create a plot to put on the screen and configure it. What I'd like to do is this: - create widget - apply format (date formatter, etc) - apply settings (autoscale, etc) - wait for data (either via real time feed or user clicking on things) But this is impossible because of this kind of bug. Instead, I have to create a plot with a fake date range and test every operation to see if it's actually setting data before applying the settings like autoscale. In addition, if the user removes data from the plot (via menu or selectable lists), I have to either start over or "unset" the settings back to something safe so this error won't occur. It really makes coding something like this a royal pain. I don't have a suggestion as of yet... Perhaps it could just return "N/A" or something like that. I think part of the problem might be the default ranges used by the autoscaling algorithm when there is no data are invalid for certain formatters and locators. That suggests that possible solutions might be one of: 1) require autoscaling or scaling algorithms to return ranges that will be OK for known scalers/formatters. Perhaps some system that allows different autoscaling algorithms to be set which can configure the default? 2) require scalers/formatters to be robust for any range or engineer the system to allow them to report "errors" in a way that allows the plot do something reasonable and not trigger an exception (perhaps some changeable behavior w/ the default as an exception?). I'll think about this a little this week and see if any other ideas come to mind. Ted > -----Original Message----- > From: John Hunter [mailto:jdh2...@gmail.com] > Sent: Sunday, September 20, 2009 3:26 PM > To: Andrew Straw; matplotlib development list > Subject: [matplotlib-devel] empty date formatter unit tests > > I spent a long time working on > > > https://sourceforge.net/tracker/index.php?func=detail&aid=2861426&group > _id=80706&atid=560720 > > and the associated unit test. I learned a lot and the unit tests > really helped. > > First, I decided that if someone sets the formatter or locator to be a > DateFormatter or DateLocator, then they are expressing their intention > to plot dates, so I triggered the axis unit conversion pipeline on > set_major_formatter(aDateFormatter) to use a DateConverter. This > worked fine, but broke the JPL unit tests, because in their > EpochConverter, they have a *different* class that nonetheless > converts to the "datenum" floats, ie days since 0000-00-00, and thus > they also use the AutoDateFormatter and AutoDateLocator in their > AxisInfo converter info. > > So what was happening is that the unit tests for the Epochs passed in > an Epoch instance, this triggered the unit conversion interface which > set the formatter to be an AutoDateFormatter, which triggered my new > code to use a DateConverter, which in turn broke the Epochs since the > DateConverter doesn't know how to hand;e an Epoch. This is quite > subtle, but what is happening is that two different classes are > converting to the same floating point representation, and so both can > use the same Formatter and Locator, but we can't invert -- just > because we see a Formatter or Locator of a certain type, we can't > infer the class. > > I would have never caught this w/o the unit test, would have happily > committed my "fix" while screwing up all the JPL stuff. > > At the end of the day, after realizing all this, I decided the current > behavior was not a bug at all, and that mpl was doing what it was told > to do. And there is no way to be smart here, since the use of a > DateFormatter does not imply you want a DateConverter. So I simply > modified the DateFormatter code to raise with an intelligible message. > > The question is: what to do with the unit test I wrote to expose the : > test_dates.test_empty_date_with_year_formatter > > I can either leave it as a knownfailure, since that is what it is, or > modify it to set ax.xaxis_date as the traceback advises, and then add > the image comparison. > > What do you think? > > Another win for the unit tests, though they caused me to spend a lot > more time "fixing" this bug than I would have without them <wink> > > JDH > > ----------------------------------------------------------------------- > ------- > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart > your > developing skills, take BlackBerry mobile applications to market and > stay > ahead of the curve. Join us from November 9-12, 2009. Register > now! > http://p.sf.net/sfu/devconf > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 8.5.409 / Virus Database: 270.13.109/2384 - Release Date: > 09/20/09 06:22:00 ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
