Re: [matplotlib-devel] sampledoc: mark out prompts in ipython sessions?
On Thu, Sep 17, 2009 at 11:02 AM, Fernando Perez wrote: > Thanks :) I'll take care of it later then, I'll try to fix a warning > we're seeing as well because it lacks a setup.py. > Done. I also committed the update to sampledoc, with a note in the log to eventually remove it once it's 'enough' in the wild in mpl. Cheers, f -- 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
[matplotlib-devel] svnmerge strangeness
Some files seem to get a properties modification on them every time someone does an svn merge, eg examples/misc/multiprocess.py which is rarely changed, but frequently has its svnmerge properties change home:~/mpl> svn diff -rPREV:HEAD examples/misc/multiprocess.py Property changes on: examples/misc/multiprocess.py ___ Name: svn:mergeinfo - /branches/v0_91_maint/examples/misc/log.py:5753-5771 /branches/v0_98_5_maint/examples/misc/log.py:6581,6585,6587,6589-6609,6614,6616,6625,6652,6660-6662,6672-6673,6714-6715,6717-6732,6752-6754,6761-6773,6781,6792,6800,6802,6805,6809,6811,6822,6827,6850,6854,6856,6859,6861-6873,6883-6884,6886,6890-6891,6906-6909,6911-6912,6915-6916,6918,6920-6925,6927-6928,6934,6941,6946,6948,6950,6952,6960,6972,6984-6985,6990,6995,6997-7001,7014,7016,7018,7024-7025,7033,7035,7042,7072,7080 /branches/v0_99_maint/examples/misc/multiprocess.py:7338,7393,7395-7404,7407-7424,7428-7433,7442-7444,7446,7475-7482,7484,7486,7489-7523,7567,7569,7582-7584,7616-7618,7633,7638,7703,7727-7734,7740-7741,7745,7751,7756,7762,7770,7772,7774,7776-7778,7780,7784,7788,7790,7792,7794 + /branches/v0_91_maint/examples/misc/log.py:5753-5771 /branches/v0_98_5_maint/examples/misc/log.py:6581,6585,6587,6589-6609,6614,6616,6625,6652,6660-6662,6672-6673,6714-6715,6717-6732,6752-6754,6761-6773,6781,6792,6800,6802,6805,6809,6811,6822,6827,6850,6854,6856,6859,6861-6873,6883-6884,6886,6890-6891,6906-6909,6911-6912,6915-6916,6918,6920-6925,6927-6928,6934,6941,6946,6948,6950,6952,6960,6972,6984-6985,6990,6995,6997-7001,7014,7016,7018,7024-7025,7033,7035,7042,7072,7080 /branches/v0_99_maint/examples/misc/multiprocess.py:7338,7393,7395-7404,7407-7424,7428-7433,7442-7444,7446,7475-7482,7484,7486,7489-7523,7567,7569,7582-7584,7616-7618,7633,7638,7703,7727-7734,7740-7741,7745,7751,7756,7762,7770,7772,7774,7776-7778,7780,7784,7788,7790,7792,7794,7796 home:~/mpl> examples/misc/multiprocess.py Other examples that are frequently subject to properties changes are U doc/sphinxext/gen_gallery.py U doc/sphinxext/gen_rst.py U examples/mplot3d/contourf3d_demo.py U examples/mplot3d/scatter3d_demo.py U examples/mplot3d/polys3d_demo.py U examples/mplot3d/wire3d_demo.py U examples/mplot3d/surface3d_demo.py U examples/mplot3d/contour3d_demo.py Any idea what is special about these files that is causing them to get frequent property changes even when they are not modified apparently? It is a minor nuisance, but it makes it harder to see what has actually changed after a merge. 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
[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 -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 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
Re: [matplotlib-devel] empty date formatter unit tests
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 -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 > > 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 u
Re: [matplotlib-devel] empty date formatter unit tests
On Sun, Sep 20, 2009 at 6:50 PM, Drain, Theodore R (343P)
wrote:
> 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.
I think we have this problem mostly licked. The problem I was writing
about in my email is a 2nd tier problem. For example, in svn HEAD,
you can specify an "empty" date plot as long as you inform mpl of you
intentions.. From the test_date_empty unit test::
fig = plt.figure()
ax = fig.add_subplot(1,1,1)
ax.xaxis_date()
fig.savefig('date_empty')
Here we are fine, because we call ax.axaxis_date, which informs mpl
that you intend to pass in datetime instances. The key piece which
makes this possible, which you allude to in your post, is the default
xlimits, which is new in svn HEAD. In particular, the default
converter provides an AxisInfo which now supports an optional
attribute
default_limits: the default min, max of the axis if no data is present
which is overridden in the DateConverter:
def axisinfo(unit, axis):
'return the unit AxisInfo'
# make sure that the axis does not start at 0
majloc = AutoDateLocator(tz=unit)
majfmt = AutoDateFormatter(majloc, tz=unit)
datemin = datetime.date(2000, 1, 1)
datemax = datetime.date(2010, 1, 1)
return units.AxisInfo( majloc=majloc, majfmt=majfmt, label='',
default_limits=(datemin, datemax))
while the min/max are arbitrary, the important thing is that custom
types can now handle the default min/max limits, so when you present a
new type to mpl, the type can request a certain default view/data lim
if no data are presented. Additionally, because of the
"ignore"setting on the limts argument, we can detect whether the
limits we are applying are defaults or actively set by the user.
The complication that motivated the sf bug
http://sourceforge.net/tracker/?func=detail&aid=2861426&group_id=80706&atid=560720
is a bit more subtle. Here no data type is presented to mpl -- either
through "plot" or "fill" or "set_xlim" or whatever. If the user had
passed any data in, or manually expressed their intent through
"ax.xaxis_date" we would be fine. The difficulty is that they passed
no data in but declared their intention to use a "YearFormatter". My
original inclination, and the one that failed the unit tests, was to
trigger a call to Axis.axis_date (a new method) on a call to
ax.xaxis.set_major_formatter (or locator) where the argument was a
DateLocator or DateFormatter. This seemed to be an imminently
reasonable and helpful thing to do -- if they want a date locator or
formatter presumably they will be passing in dates -- but the unit
tests told me this was wrong.
The locators and formatters work on *converted* units. The
EpochConverter and DateConverter both convert their native types to
floating point days since -00-00. So here are two custom
converter interfaces which both end up with the same floating point
representation. The conc
