Re: [matplotlib-devel] attempting to enable buildbot
Andrew Straw wrote: > Hi all, > > I am attempting to get a collective.buildbot service working on the > Matplotlib trunk (branches could be enabled in the future) and James > Evans' test suite. Right there are errors that prevent the test suite > from even being run. I'll attempt to work through these, and you can > check progress on the nascent buildbot display here: > > http://mpl-buildbot.code.astraw.com OK, the tests are now actually running, although most of the tests are failing, which is worse than when I run the tests manually. :( If anyone wants to attempt to get the tests passing, the buildmaster should be configured to trigger a build on an svn commit (it is supposed to poll the svn server every 10 minutes). You can also trigger a build attempt by clicking the "Force Build" button after following the builder link in the Web GUI (I may have to disable this if the load gets too high.) Let's see if we can get all the tests passing and if this buildbot approach looks sustainable -- if so, I'd like to get some more build slaves into the mix and make MPL a good continuous integration citizen. I don't think the buildbot master will take many resources on my server, so I'm happy to host it there. I could put it under a different domain name, too -- that may be desirable for marketing reasons. -Andrew -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] attempting to enable buildbot
On Wed, May 20, 2009 at 3:48 AM, Andrew Straw wrote: > Let's see if we can get all the tests passing and if this buildbot > approach looks sustainable -- if so, I'd like to get some more build > slaves into the mix and make MPL a good continuous integration citizen. > I don't think the buildbot master will take many resources on my server, The sage project has given us access to a network accessible persistent OSX box, so I will try and get that setup with the buildbot infrastructure. I'm not yet familiar with the buildbot project or approach, so I have some learning to do, so if you have a cheatsheet or docs thaty you think are particularly handy, send them along (otherwise I'll just make my way through the site docs) > so I'm happy to host it there. I could put it under a different domain > name, too -- that may be desirable for marketing reasons. we can worry about marketing it once we have it doing something useful :-) Thanks for pushing ahead on this. JDH -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] attempting to enable buildbot
On Wed, May 20, 2009 at 3:48 AM, Andrew Straw wrote: > Andrew Straw wrote: > > Hi all, > > > > I am attempting to get a collective.buildbot service working on the > > Matplotlib trunk (branches could be enabled in the future) and James > > Evans' test suite. Right there are errors that prevent the test suite > > from even being run. I'll attempt to work through these, and you can > > check progress on the nascent buildbot display here: > > > > http://mpl-buildbot.code.astraw.com > > OK, the tests are now actually running, although most of the tests are > failing, which is worse than when I run the tests manually. :( > > If anyone wants to attempt to get the tests passing, the buildmaster > should be configured to trigger a build on an svn commit (it is supposed > to poll the svn server every 10 minutes). You can also trigger a build > attempt by clicking the "Force Build" button after following the builder > link in the Web GUI (I may have to disable this if the load gets too high.) > > Let's see if we can get all the tests passing and if this buildbot > approach looks sustainable -- if so, I'd like to get some more build > slaves into the mix and make MPL a good continuous integration citizen. > I don't think the buildbot master will take many resources on my server, > so I'm happy to host it there. I could put it under a different domain > name, too -- that may be desirable for marketing reasons. I'll see if I can get the buildbot running on my gentoo AMD64 box. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma Sent from Norman, Oklahoma, United States -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Tests and matplotlibrc
Hi, Is there any way to make the tests force a certain default set of rcparams? When I first ran the test suite just now, I got a lot of image comparison failures because I have my default font set to 10 in my matplotlibrc. Changing this eliminated 13 of my 16 failures. I really don't feel like having to edit my matplotlibrc every time I want to run the test suite. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma Sent from Norman, Oklahoma, United States -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Units issue
Ryan May wrote: > use the units in basic_units.py (in the examples/units directory). This looks like pretty cool stuff. However, I can't seem to find matplotlib.units or basic_units.py in the online Sphinx docs. Is this a doc bug, or intentional? There are units examples in the docs. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Units issue
On Wed, May 20, 2009 at 11:55 AM, Ryan May wrote: > On Wed, May 20, 2009 at 11:38 AM, Ryan May wrote: >> >> Hi, >> >> In looking over a test failure, I'm seeing some behavior that doesn't make >> sense to me. It looks like data passed to a line object is being improperly >> converted when units are involved. Here's a version of the code in the test >> script, but modified to use the units in basic_units.py (in the >> examples/units directory). You should be able to just drop this script into >> the examples/units directory and run it: > > It looks like revision 7020 broke this in the process of adding units > support for fill(). > > If I change the following lines (in the _xy_from_xy() function): > > if bx: > x = self.axes.convert_xunits(x) > if by: > y = self.axes.convert_yunits(y) > > back to: > > if bx or by: return x, y, False > > the example I posted works and the test failure I was seeing is gone. Of > course, this breaks fill() with unit-ed quantities. I'm getting a little > over my head here in terms of tracing the flow of units, so I'd love to hear > opinions on how to actually fix this. IMHO, we *really* need to standardize > on how units are handled. In some cases the axes method handles converting > units, but in this case, the Line2D object also registers for changes to > axis units so it can update itself. The fundamental problem here is that some artists (Line2D) have support for storing original unitized data (_xorig, _yorig) and handling the conversion on unit change internally with the callback, and some artists (eg Patches) do not . axes._process_plot_var_arg subserves both plot (Line2D) and fill (Polygon), one of which is expecting possibly unitized data and one which is only capable of handling already converted data. Hence the fix one problem, create another bind we are now in. So yes, we need a standard. I think the resolution might be in having intermediate higher level container plot item objects (an ErrorBar, LintPlot, FilledRegion) which store the original data, manage the units, and pass converted data back to the primitives. This is obviously a major refactoring, and would require some thought, but may be the best way to go. Handling the conversions in the plotting functions (eg fill, errorbar) is probably not the right way because there is no obvious way to support unit changes (eg inches to cm) since the data is already converted, the artists already created. Having the artist primitives store the original, possibly unitized data, and register callbacks for unit changes can work, but the problem is how to create the artist primitives in such a way the unit data is passed through correctly. The problem here is that some operations don't make sense for certain unit types -- think addition with datetimes. Some functions, eg bar or errorbar, which need to do a lot of arithmetic on the input arrays, may want to do: xmid = 0.5*(x[1:] + x[:-1]) which would not work for x if x is datetime (can't add two dates). distance and scaling should always be well defined, so one should be able to do: xmid = x[1:] + 0.5*(x[1:]-x[:-1]) So one solution is to require all plotting functions to respect the "no addition" rule, ie define the set of operations that are allowed for plotting functions, and all artists to handle original unitized data with internal conversion. This is a fair amount of work at the plotting function layer, is invasive to the artist primitives, and requires the extra storage at the artist layer, but could work. The other solution, what I referred to as the intermediate plot item container, is to have a class ErrorBar, eg, which is like the errorbar method, but has an API like class ErrorBar: def __init__(self, all the errorbar args, possibly unitized): self.store_all_original_data_here() self.store_all_primitives_from_converted_data_here() def callback(): self.update_all_stored_primitives_newly_converted_original_data() self.connect_callback_to_unit_change(callback) This has the advantage that the plot item container class can always work with arrays of floats (removing the onerous restriction on what kind of binary relations are allowed) and removes the restrictions on creating artists which are unit aware. It also makes for a nicer API: eb = ErrorBar(something) eb.draw() # hmm, the cap widths are too small eb.capwidth = 12 eb.draw() ie, instead of getting back a bunch of artist primitives from errorbar which may be difficult to manipulate, you get back an ErrorBar object that knows how to update and plot itself. With traits or properties so that the eb.capwidth attr setting triggers a unitized updating of primitives, then everything is fairly transparent to the user. It would also make it easier support containers of artists for logical groupings during animation, zorder buffering/blitting, etc. JDH
Re: [matplotlib-devel] Units issue
On Wed, May 20, 2009 at 1:10 PM, Christopher Barker wrote: > > Darren Dale was working on a full-fledged package for adding units to > > numpy arrays called quantities > > (http://packages.python.org/quantities/user/tutorial.html), > > thanks for the reminder -- that does look like a really nice package. It > would be great to have a semi-standard for this stuff in the SciPy world > -- and certainly MPL compatible! > > > last I saw it stalled a little due to issues with subclassing ndarray. > > Darn. I hope I'll get a chance to delve into it soon. That's not to say that it's not currently functional, I just believe that some ufuncs don't work properly and that there are some corner cases that don't work, which I think is why Darren hasn't made an official release/announcement. Last time I played with it however, it was quite useful. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma Sent from Norman, Oklahoma, United States -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Tests and matplotlibrc
On Wed, May 20, 2009 at 10:12 AM, Ryan May wrote: > Hi, > > Is there any way to make the tests force a certain default set of rcparams? > When I first ran the test suite just now, I got a lot of image comparison > failures because I have my default font set to 10 in my matplotlibrc. > Changing this eliminated 13 of my 16 failures. I really don't feel like > having to edit my matplotlibrc every time I want to run the test suite. > the config system will pick up a matplotlibrc file in the current dir if there is one, so perhaps we should drop the rc file assumed by the tests into the dir from which they are run http://matplotlib.sourceforge.net/users/customizing.html -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Units issue
On Wed, May 20, 2009 at 11:38 AM, Ryan May wrote: > Hi, > > In looking over a test failure, I'm seeing some behavior that doesn't make > sense to me. It looks like data passed to a line object is being improperly > converted when units are involved. Here's a version of the code in the test > script, but modified to use the units in basic_units.py (in the > examples/units directory). You should be able to just drop this script into > the examples/units directory and run it: It looks like revision 7020 broke this in the process of adding units support for fill(). If I change the following lines (in the _xy_from_xy() function): if bx: x = self.axes.convert_xunits(x) if by: y = self.axes.convert_yunits(y) back to: if bx or by: return x, y, False the example I posted works and the test failure I was seeing is gone. Of course, this breaks fill() with unit-ed quantities. I'm getting a little over my head here in terms of tracing the flow of units, so I'd love to hear opinions on how to actually fix this. IMHO, we *really* need to standardize on how units are handled. In some cases the axes method handles converting units, but in this case, the Line2D object also registers for changes to axis units so it can update itself. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma Sent from Norman, Oklahoma, United States -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Tests and matplotlibrc
On Wed, May 20, 2009 at 10:20 AM, John Hunter wrote: > On Wed, May 20, 2009 at 10:12 AM, Ryan May wrote: > > Hi, > > > > Is there any way to make the tests force a certain default set of > rcparams? > > When I first ran the test suite just now, I got a lot of image comparison > > failures because I have my default font set to 10 in my matplotlibrc. > > Changing this eliminated 13 of my 16 failures. I really don't feel like > > having to edit my matplotlibrc every time I want to run the test suite. > > > > the config system will pick up a matplotlibrc file in the current dir > if there is one, so perhaps we should drop the rc file assumed by the > tests into the dir from which they are run > > http://matplotlib.sourceforge.net/users/customizing.html > Thanks, I wasn't aware of that. It seems that if I just put an empty matplotlibrc file in that directory, it serves the same purpose. Can I just check that in (perhaps containing only a clarifying comment) so that it stays in sync with the current matplotlib defaults? Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Units issue
On Wed, May 20, 2009 at 11:54 AM, Christopher Barker wrote: > Ryan May wrote: > > use the units in basic_units.py (in the examples/units directory). > > This looks like pretty cool stuff. However, I can't seem to find > matplotlib.units or basic_units.py in the online Sphinx docs. Is this a > doc bug, or intentional? > > There are units examples in the docs. matplotlib.units maintains the api for registering unit-ed quantities and various other nuts and bolts. It's another one of those modules whose docs hasn't been converted to sphinx yet, but it does have doc strings. However, it does not provide any units itself. basic_units.py is an example with just a few basic quantities to show off how support in matplotlib works, but is not itself all that useful. Darren Dale was working on a full-fledged package for adding units to numpy arrays called quantities ( http://packages.python.org/quantities/user/tutorial.html), that would (I think) work with some of this, but last I saw it stalled a little due to issues with subclassing ndarray. I haven't seen any other simple packages/modules that suppors general units for the simple goal of doing conversions for plotting. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma Sent from Norman, Oklahoma, United States -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Units issue
Hi, In looking over a test failure, I'm seeing some behavior that doesn't make sense to me. It looks like data passed to a line object is being improperly converted when units are involved. Here's a version of the code in the test script, but modified to use the units in basic_units.py (in the examples/units directory). You should be able to just drop this script into the examples/units directory and run it: from basic_units import secs, minutes, cm import matplotlib.pyplot as plt xdata = [ x*secs for x in range(10) ] ydata1 = [ (1.5*y - 0.5)*cm for y in range(10) ] ydata2 = [ (1.75*y - 1.0)*cm for y in range(10) ] fig = plt.figure() ax = plt.subplot( 111 ) l1, = ax.plot( xdata, ydata1, color='blue', xunits=secs ) l2, = ax.plot( xdata, ydata2, color='green', xunits=minutes ) print l1._xorig print l2._xorig print ax.lines plt.show() Based on the original test, it seems like this behavior should work (just rescale the x-axis without actually changing the plot). Am I missing something, or is this a real bug? Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma Sent from Norman, Oklahoma, United States -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Units issue
Ryan May wrote: > It's another one of those modules > whose docs hasn't been converted to sphinx yet, but it does have doc > strings. Couldn't/shouldn't sphinx just use the docs strings so that there is SOMETHING there? I really love the sphinx docs, but it is frustrating got have a module simply not listed at all. > Darren Dale was working on a full-fledged package for adding units to > numpy arrays called quantities > (http://packages.python.org/quantities/user/tutorial.html), thanks for the reminder -- that does look like a really nice package. It would be great to have a semi-standard for this stuff in the SciPy world -- and certainly MPL compatible! > last I saw it stalled a little due to issues with subclassing ndarray. Darn. I hope I'll get a chance to delve into it soon. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Tests and matplotlibrc
On Wed, May 20, 2009 at 10:27 AM, Ryan May wrote: > Thanks, I wasn't aware of that. It seems that if I just put an empty > matplotlibrc file in that directory, it serves the same purpose. Can I just > check that in (perhaps containing only a clarifying comment) so that it > stays in sync with the current matplotlib defaults? Not sure what is the best way here -- one is to put in an rc w/ everything uncommented for the tests, so that even if the mpl defaults change the regression suite won't break. The other is to assume the defaults in the test suite (empty rc) and if someone changes an rc default it breaks the test suite. Perhaps James or Ted have a view/preference? JDH -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Units issue
John Hunter wrote: > The fundamental problem here is that some artists (Line2D) have > support for storing original unitized data (_xorig, _yorig) and > handling the conversion on unit change internally with the callback, > and some artists (eg Patches) do not . axes._process_plot_var_arg > subserves both plot (Line2D) and fill (Polygon), one of which is > expecting possibly unitized data and one which is only capable of > handling already converted data. Hence the fix one problem, create > another bind we are now in. > > So yes, we need a standard. John, As you know, I agree. This has been a frustrating problem for a long time. > > I think the resolution might be in having intermediate higher level > container plot item objects (an ErrorBar, LintPlot, FilledRegion) > which store the original data, manage the units, and pass converted > data back to the primitives. This is obviously a major refactoring, > and would require some thought, but may be the best way to go. > Handling the conversions in the plotting functions (eg fill, errorbar) > is probably not the right way because there is no obvious way to > support unit changes (eg inches to cm) since the data is already > converted, the artists already created. I'm not sure I understand the use case for unit *changes*, as opposed to initial unit specification. > > Having the artist primitives store the original, possibly unitized > data, and register callbacks for unit changes can work, but the > problem is how to create the artist primitives in such a way the unit > data is passed through correctly. The problem here is that some > operations don't make sense for certain unit types -- think addition > with datetimes. Some functions, eg bar or errorbar, which need to do > a lot of arithmetic on the input arrays, may want to do: > > xmid = 0.5*(x[1:] + x[:-1]) > > which would not work for x if x is datetime (can't add two dates). > distance and scaling should always be well defined, so one should be > able to do: > > xmid = x[1:] + 0.5*(x[1:]-x[:-1]) > > So one solution is to require all plotting functions to respect the > "no addition" rule, ie define the set of operations that are allowed > for plotting functions, and all artists to handle original unitized > data with internal conversion. This is a fair amount of work at the > plotting function layer, is invasive to the artist primitives, and > requires the extra storage at the artist layer, but could work. Sounds horrible to me. I would really like to see clear stratification, with all complicated and flexible argument handling restricted to some not-too-low level. > > The other solution, what I referred to as the intermediate plot item > container, is to have a class ErrorBar, eg, which is like the errorbar > method, but has an API like > > class ErrorBar: > def __init__(self, all the errorbar args, possibly unitized): > self.store_all_original_data_here() > self.store_all_primitives_from_converted_data_here() > > def callback(): > self.update_all_stored_primitives_newly_converted_original_data() > self.connect_callback_to_unit_change(callback) > > > This has the advantage that the plot item container class can always > work with arrays of floats (removing the onerous restriction on what > kind of binary relations are allowed) and removes the restrictions on > creating artists which are unit aware. I think something like this is the way to go. Even without the problem with units, I would like to see things like the bar family, errorbar, and boxplot moved out into their own classes; and there is no reason not to do the same for simple line plots (which are anything but simple in their input argument handling). Then the Axes class can concentrate on Axes creation and manipulation. I think there are also opportunities for factoring out common operations involving input parameter handling--not just units conversion, but validation, checking dimensions, generating X and Y with meshgrid when needed, etc. Some of these things are already partly factored out, but helpers are scattered around, and I suspect there is some unproductive duplication. Of course, the big question is how to get all this done... Fortunately, unless I am missing a key point, this sort of refactoring can be done incrementally; it is not as drastic as the transforms refactoring was. Eric > > It also makes for a nicer API: > > eb = ErrorBar(something) > eb.draw() > > # hmm, the cap widths are too small > eb.capwidth = 12 > eb.draw() > > ie, instead of getting back a bunch of artist primitives from errorbar > which may be difficult to manipulate, you get back an ErrorBar object > that knows how to update and plot itself. > > With traits or properties so that the eb.capwidth attr setting > triggers a unitized updating of primitives, then everything is fairly > transparent to the user. > > It would also make it easier support conta
Re: [matplotlib-devel] Units issue
On Wed, May 20, 2009 at 2:36 PM, Eric Firing wrote: > I'm not sure I understand the use case for unit *changes*, as opposed to > initial unit specification. The use case (and we can debate whether this is worth the extra overhead) ax.plot(inches) ax.set_xlim(cms) And the plot will automagically update with the new units. This worked in the original implementation, but due to some code rot has breakage somewhere. This was a feature requested by the JPL when I did the original implementation. Alternatively if you did ax.plot(inches) and later ax.plot(cms) the first line would be updated to cm and both would be plotted in cm. But if you did ax.plot(seconds) you would get an error since the inches and cms lines would not be able to convert. In the scheme I proposed (plot items with updates on unit change), if you had a line object contained in a PlotItem class, and the original units were in inches, the line's xdata would be simple float array in inches. If you changed the axis units to cm, the line's xdata would automatically be updated to floats but now in cm. JDH -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Tests and matplotlibrc
When I wrote the test stuff I had forgotten all about the matplotlibrc stuff. I think it would make sense to just use a default (empty) matplotlibrc for the tests, this way we are always testing against the defaults. If the defaults ever change it would also allow us to more easily catch those changes to note if there is any negative consequences of the change. Do the defaults ever differ based upon platform? Backend? Phase of the moon? --James Evans > Date: Wed, 20 May 2009 10:32:12 -0500 > From: John Hunter > Subject: Re: [matplotlib-devel] Tests and matplotlibrc > To: Ryan May > Cc: Ted Drain , "Evans, James R" > , Matplotlib Devel > > Message-ID: > <88e473830905200832u4331f78fq21523b4099df6...@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > On Wed, May 20, 2009 at 10:27 AM, Ryan May wrote: > > > Thanks, I wasn't aware of that. It seems that if I just put an empty > > matplotlibrc file in that directory, it serves the same purpose. Can I just > > check that in (perhaps containing only a clarifying comment) so that it > > stays in sync with the current matplotlib defaults? > > Not sure what is the best way here -- one is to put in an rc w/ > everything uncommented for the tests, so that even if the mpl defaults > change the regression suite won't break. The other is to assume the > defaults in the test suite (empty rc) and if someone changes an rc > default it breaks the test suite. Perhaps James or Ted have a > view/preference? > > JDH -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Tests and matplotlibrc
On Wed, May 20, 2009 at 3:30 PM, James Evans wrote: > When I wrote the test stuff I had forgotten all about the matplotlibrc stuff. > I think it would make sense to just use a default > (empty) matplotlibrc for the tests, this way we are always testing against > the defaults. If the defaults ever change it would also > allow us to more easily catch those changes to note if there is any negative > consequences of the change. OK, Ryan, go ahead with this. > Do the defaults ever differ based upon platform? Backend? Phase of the moon? no, just sunspot count JDH -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Tests and matplotlibrc
On Wed, May 20, 2009 at 3:37 PM, John Hunter wrote: > On Wed, May 20, 2009 at 3:30 PM, James Evans > wrote: > > When I wrote the test stuff I had forgotten all about the matplotlibrc > stuff. I think it would make sense to just use a default > > (empty) matplotlibrc for the tests, this way we are always testing > against the defaults. If the defaults ever change it would also > > allow us to more easily catch those changes to note if there is any > negative consequences of the change. > > > OK, Ryan, go ahead with this. > Done. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Units issue
John Hunter wrote:
> The use case (and we can debate whether this is worth the extra overhead)
>
> ax.plot(inches)
> ax.set_xlim(cms)
I'll put my two cents into that debate:
My first thought is: wow! that is putting WAY too much into a plotting
routine!
My second thought is: on the other hand, that is very cool.
If it's going to be done, I think it really shouldn't be too MPL
specific -- it should be built on a good (and hopefully eventually
widely used) unit-array system, perhaps like Darren Dale's Quantities
package (there are quite a few other that should be looked at also).
What that means is that the first step is to get that package complete
and robust. Using it for this kind of MPL functionality may be a good
way to put it to the test.
In between, with a good Quantities package, it's not that big a deal to
put the unit conversion in the hands of user code. The user code would
simple need to be something like:
ax.plot(values.rescale('cm')
ax.set_xlim(limits.rescale('cm'))
a bit klunkier, but very clear. Explicit is better than implicit...
> ax.plot(cms)
>
> the first line would be updated to cm and both would be plotted in cm.
this is a little two implicit for me -- I'd rather specify the units
explicitly, rather than have the last data added determine it for me.
ax.set_xunit('cm')
I'd probably have it default to the first unit used.
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
chris.bar...@noaa.gov
--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables
unlimited royalty-free distribution of the report engine
for externally facing server and web deployment.
http://p.sf.net/sfu/businessobjects
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Units issue
On Wed, May 20, 2009 at 4:02 PM, Christopher Barker
wrote:
> John Hunter wrote:
>> The use case (and we can debate whether this is worth the extra overhead)
>>
>> ax.plot(inches)
>> ax.set_xlim(cms)
>
> I'll put my two cents into that debate:
>
> My first thought is: wow! that is putting WAY too much into a plotting
> routine!
>
> My second thought is: on the other hand, that is very cool.
>
> If it's going to be done, I think it really shouldn't be too MPL
> specific -- it should be built on a good (and hopefully eventually
> widely used) unit-array system, perhaps like Darren Dale's Quantities
> package (there are quite a few other that should be looked at also).
This is not how it works -- we will not be assuming any units package.
Rather, we provide an interface where any units package can be used
with mpl. The original use case is that the JPL has an internal units
package and they want to pass their objects directly to mpl -- they
get handed these objects by custom internal C++ libs with python
wrappers over which they have no control maintained by another group.
So they cannot modify that package. What they can do is access the
matplotlib units registry and register an entry there that maps type
-> a converter class that exposes a certain interface we require. The
converter class not only knows how to convert the units to floats, but
also how to set tick locators, formatters and labels. When we get
passed in a type, eg a datetime, a Quantiles instance, or whatever, we
ask the registry if there is a converter, and if so act appropriately
(though not always, hence the current thread).
One nice thing about this is we were able to extend support to native
datetime objects (which we cannot modify obviously) to mpl, so this
facility works with both proper unit types as well as arbitrary types.
This feature was not part of the original design spec, but fell
naturally out of it, which suggests to me that we are onto something.
So Darren's or anyone else package can be made to work with mpl with
little work (the harder part is getting all of mpl to respect the unit
conversion interface everywhere, which is what we are discussing). To
give you a better idea what this looks like, the *entire* support in
mpl for handling native datetime objects looks like this::
class DateConverter(units.ConversionInterface):
"""The units are equivalent to the timezone."""
@staticmethod
def axisinfo(unit, axis):
'return the unit AxisInfo'
# make sure that the axis does not start at 0
if axis:
ax = axis.axes
if axis is ax.get_xaxis():
xmin, xmax = ax.dataLim.intervalx
if xmin==0.:
# no data has been added - let's set the
default datalim.
# We should probably use a better proxy for the datalim
# have been updated than the ignore setting
dmax = today = datetime.date.today()
dmin = today-datetime.timedelta(days=10)
ax._process_unit_info(xdata=(dmin, dmax))
dmin, dmax = ax.convert_xunits([dmin, dmax])
ax.viewLim.intervalx = dmin, dmax
ax.dataLim.intervalx = dmin, dmax
elif axis is ax.get_yaxis():
ymin, ymax = ax.dataLim.intervaly
if ymin==0.:
# no data has been added - let's set the
default datalim.
# We should probably use a better proxy for the datalim
# have been updated than the ignore setting
dmax = today = datetime.date.today()
dmin = today-datetime.timedelta(days=10)
ax._process_unit_info(ydata=(dmin, dmax))
dmin, dmax = ax.convert_yunits([dmin, dmax])
ax.viewLim.intervaly = dmin, dmax
ax.dataLim.intervaly = dmin, dmax
majloc = AutoDateLocator(tz=unit)
majfmt = AutoDateFormatter(majloc, tz=unit)
return units.AxisInfo( majloc=majloc, majfmt=majfmt, label='' )
@staticmethod
def convert(value, unit, axis):
if units.ConversionInterface.is_numlike(value): return value
return date2num(value)
@staticmethod
def default_units(x, axis):
'Return the default unit for *x* or None'
return None
units.registry[datetime.date] = DateConverter()
units.registry[datetime.datetime] = DateConverter()
See the matplotlib.units module for more info.
> ax.plot(values.rescale('cm')
> ax.set_xlim(limits.rescale('cm'))
>
> a bit klunkier, but very clear. Explicit is better than implicit...
I'm open to the idea of not supporting post-facto conversions after
data is added, but am mostly minus
Re: [matplotlib-devel] attempting to enable buildbot
Andrew Straw wrote:
>> I am attempting to get a collective.buildbot service working on the
>> Matplotlib trunk (branches could be enabled in the future) and James
>> Evans' test suite. Right there are errors that prevent the test suite
>> from even being run.
I believe I have enabled the unit test to properly run on the buildbot,
but it requires a patch to the buildout recipe (pbp.recipe.noserunner)
that runs the tests. I sent the patch to the author of
pbp.recipe.noserunner, so hopefully a new release will appear shortly
and I can take Ryan on John up on their offers of buildslaves, which
I'll coordinate off-list when the time is right.
In the meantime, the essential part of the pbp.recipe.noserunner patch is:
diff -r 8e8141beee8d
packages/pbp.recipe.noserunner/pbp/recipe/noserunner/__init__.py
--- a/packages/pbp.recipe.noserunner/pbp/recipe/noserunner/__init__.py
Wed May 13 12:03:55 2009 +0200
+++ b/packages/pbp.recipe.noserunner/pbp/recipe/noserunner/__init__.py
Wed May 20 15:08:27 2009 -0700
@@ -61,6 +61,13 @@
if initialization_section:
initialization += initialization_section
+plugins = options.get('plugins', '')
+plugins = [plugin.strip() for plugin in plugins.split('\n') if
plugin.strip() != '']
+
+if len(plugins):
+plugin_str = ','.join( plugins )
+defaults += ", plugins=[%s]"%plugin_str
+
dest.extend(zc.buildout.easy_install.scripts(
[(options['script'], 'nose', 'main')],
ws, options['executable'],
If you've applied that, you'll have to add to the "develop" section of
the buildout file the line "/path/to/pbp.recipe.noserunner" (in addition
to the "."). From there, it's standard zc.buildout recipes in the MPL dir:
python bootstrap.py # create bin/buildout
bin/buildout # build MPL and create bin/test
bin/test # run the unit tests
Since these are the steps that the buildbot follows, this should also
work on the build slaves once we no longer need the custom
pbp.recipe.noserunner. If it looks like it'll be a while before a new
pbp.recipe.noserunner is released, I think we could temporarily host a
patched version and direct buildout to it with the find-links option.
-Andrew
--
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://www.creativitycat.com
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Units issue
On Wed, May 20, 2009 at 1:01 PM, Ryan May wrote: > On Wed, May 20, 2009 at 11:54 AM, Christopher Barker < > chris.bar...@noaa.gov> wrote: > >> Ryan May wrote: >> > use the units in basic_units.py (in the examples/units directory). >> >> This looks like pretty cool stuff. However, I can't seem to find >> matplotlib.units or basic_units.py in the online Sphinx docs. Is this a >> doc bug, or intentional? >> >> There are units examples in the docs. > > > matplotlib.units maintains the api for registering unit-ed quantities and > various other nuts and bolts. It's another one of those modules whose docs > hasn't been converted to sphinx yet, but it does have doc strings. However, > it does not provide any units itself. basic_units.py is an example with > just a few basic quantities to show off how support in matplotlib works, but > is not itself all that useful. > > Darren Dale was working on a full-fledged package for adding units to numpy > arrays called quantities ( > http://packages.python.org/quantities/user/tutorial.html), that would (I > think) work with some of this, but last I saw it stalled a little due to > issues with subclassing ndarray. I haven't seen any other simple > packages/modules that suppors general units for the simple goal of doing > conversions for plotting. > Thanks for the mention, Ryan. The package hasn't really stalled due to limitation with numpy (although there are some that I would like to address), its just that I have been too busy with other things to work on it. I am planning to continue again in June. Darren -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://www.creativitycat.com ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Units issue
On Wed, May 20, 2009 at 2:11 PM, Ryan May wrote: > > > On Wed, May 20, 2009 at 1:10 PM, Christopher Barker > wrote: > >> > Darren Dale was working on a full-fledged package for adding units to >> > numpy arrays called quantities >> > (http://packages.python.org/quantities/user/tutorial.html), >> >> thanks for the reminder -- that does look like a really nice package. It >> would be great to have a semi-standard for this stuff in the SciPy world >> -- and certainly MPL compatible! >> >> > last I saw it stalled a little due to issues with subclassing ndarray. >> >> Darn. I hope I'll get a chance to delve into it soon. > > > That's not to say that it's not currently functional, I just believe that > some ufuncs don't work properly and that there are some corner cases that > don't work, which I think is why Darren hasn't made an official > release/announcement. Last time I played with it however, it was quite > useful. > I have been waiting to make an announcement because I am in the middle of overhauling the unit tests, I want them to be more robust and cleaner than they are at present. I also wanted to see whether it would be possible to make an addition to numpy's ufunc mechanism so existing ufuncs can perform a units operation on the way in (so an error can be raised in case of an illegal operation before data is changed in place, for example), rather than on the way out (currently done using ndarray.__array_wrap__). Aside from this corner case, I think all of the common arithmetic ufuncs already just work, and Quantities should already useable. It needs a couple easy tweaks to make some operations easier, and I need input from the community about how much magic is appropriate (right now inches + feet raises an error, since its not clear what units are desired for the result). It would probably not take much work to implement missing features and ufuncs, especially if a few others were interested in helping out ;) Darren -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://www.creativitycat.com ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
