matplotlib-devel Mailing List for matplotlib

The tests now seem to be running OK. There are some failures due to
image comparison mismatch, but I think we should attempt to track these
down as a team -- hopefully running on more computers than just mine and
with James' input. To see the latest test results, click on the "stdio"
link for each run of the "test" box in the waterfall display
http://mpl-buildbot.code.astraw.com/waterfall .
It would be nice if the buildbot web GUI would easily let us see, for
failed image-based tests, the baseline, output, and difference image,
but that's not implemented (as far as I know). It would probably be
possible to add something like this to the MplNosePlugin to do this with
relatively little pain, although the display would be easiest via a
pastebin or something rather than hooking back into a patched buildbot
framework that supported test images.
John Hunter wrote:
> On Wed, May 20, 2009 at 3:48 AM, Andrew Straw <str...@as...> 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)
OK, here's what you do::
 # (Make a username you want to run this buildslave as.
 # Become that user. Change into a new directory e.g. $HOME/builbot)
 curl http://astraw.com/mpl/bootstrap-py.txt > bootstrap.py
 curl http://astraw.com/mpl/buildout-example.cfg > buildout.cfg
 # Edit buildout.cfg according the instructions in the file. Send me
 # the values you added.
 # python bootstrap.py
 # bin/buildout
Once you've been added to the build master:
 # bin/<slave-identifier-string> start
And that should be it.
For now we can start/stop builds by clicking the "force build" button in
the buildmaster web GUI. SVN polling doesn't seem to be working yet...
I'll look into that when I have time. Ditto for building binaries and
uploading them somewhere.
-Andrew

There seems to be some confusion as to how the mpl unit system works, I hope the following will help to clarify that and keep this
thread focused on the issue.
Currently mpl provides an API via the 'ConversionInterface' class in 'matplotlb.units' that allows a user to define how to translate
their data into something meaningful for mpl to process (i.e. floats). If you are already passing around floats, then this
interface is not for you. This interface is for typed data that is to be plotted (i.e. it needs to be "manipulated" to convert it
to a float).
This manipulation is handled via the user-defined and registered ConversionInterface sub-class.
The idea is not that a user will do the following:
>>> ax.plot( cms )
>>> ax.plot( inches )
As that would imply that the user has already converted their data to floats. But that the user will this intead:
>>> ax.plot( length_data1 )
>>> ax.plot( length_data2 )
Where the length_dataX is some user-defined data type and a user-defined conversion class has been pre-registered. mpl will choose
the default units based upon what the user-defined conversion class says the default should be. But if a more explicit
specification is required, then the user does the following instead:
>>> ax.plot( length_data1, xunits="cm" )
>>> ax.plot( length_data2 )
This would plot the length data in centimeters. If desired then the user can do the following:
>>> ax.xaxis.set_units( "cm" )
And the plot would be updated. The following also currently works:
>>> ax.plot( length_data1, xunits="cm" )
>>> ax.plot( length_data2, xunits="inches" )
And the final plot would be in inches. The current mpl interface for units is quite robust and supports a very generic interface
that is highly user-customizable (should the user want to do so). The interface is so robust that I defined a simple converter
class that will "convert" strings to floats. I use this with bar plots and do something like the following:
>>> ax.bar( ["a", "b', "c"], [1, 2, 3] )
An example can be seen in the matplotlib 'test/mplTest/units/StrConverter.py' file. Additionally other unit example classes can be
found in the 'test/mplTest/units' directory.
The issue is, as John has already stated with the individual plot functions. 'ax.plot' works perfectly fine due to the way the line
data is cached and updated as needed (the updates take into account if units might have changed). Some individual plot functions
strip out the units then manipulate the data, and others keep the unitized data and pass it along to be stripped out later. The
issue is getting a consistent mechanism for dealing with where the conversion is to occur.
I think that John's proposal of having higher level classes that handle this (as well as the caching) might be the way to go. It
would allow the individual plot functions to stay simplistic and true to what they provide and let the data handle itself. This
type of mechanism promises to be faster since the data only needs to be converted once (in the typical use case). Overhead of
re-converting would only occur when the user explicitly changes the units for a specified axis. Additionally this approach looks to
be more appealing when it comes to making plottable data items that are selectable and ultimately manipulatable via a gui interface.
--James Evans

On Thu, May 21, 2009 at 2:20 PM, Christopher Barker
<Chr...@no...> wrote:
> John Hunter wrote:
>> <Chr...@no...> wrote:
>>> 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.
>
> Fair enough, but you still need to require a particular API to a unit-ed
> object, which it no so different.
No, this is incorrect. The object can have any API it wants. The
person who wants to add support for that object registers the object
type with a converter class for that object. The converter class can
be entirely external to the class, as in the datetime example I
posted, so the object's API is not exposed to mpl. This is the
crucial distinction. The converter class at a minimum must know how
to convert the object to a sequence of floats.
JDH
JDH

On 2009年05月21日 14:55, Pierre GM wrote:
> Anyway, the zoom-level dependent ticks we implemented might be a good
> starting point for implementing a "locator/formatter that decides
> whether to display cm or km"...
Well, if we're pushing products, Chaco has a subsystem for doing exactly this in 
a generic fashion for times or anything else:
 https://svn.enthought.com/svn/enthought/Chaco/trunk/enthought/chaco/scales/
It was written to be self-contained so that it could be shared with matplotlib 
or anything else that need it.
-- 
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
 -- Umberto Eco

<push product>
Er... Anybody has tried the plotting capacities of scikits.timeseries 
(pytseries.sourceforge.net)? In short, the package provides some 
extensions to matplotlib to plot timeseries. One of these extensions 
changes the ticks depending on the zoom level: start over a few 
decades and ticks will be every 5 y or so. Select a smaller area and 
the ticks will be every quarter, you get the idea. The series 
associated with the plot (either the first plotted or one given at 
plot creation) sets the units (frequency) of the xaxis. Afterwards, 
other series plotted on the same plot are converted to the plot's 
frequency) with our own conversion routines.
Theses extensions were coded about 18 months ago, at a time where the 
support for units was inexistent (or hidden somewhere I never fund 
it). A couple weeks ago I realized that units converting would 
probably be the way to go (and that in general, our extensions should 
be rewritten).
Anyway, the zoom-level dependent ticks we implemented might be a good 
starting point for implementing a "locator/formatter that decides 
whether to display cm or km"...
I'd be quite happy to get some feedback about these extensions...
Cheers
P.
</push product>

John Hunter wrote:
> <Chr...@no...> wrote:
>> 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.
Fair enough, but you still need to require a particular API to a unit-ed 
object, which it no so different.
One thing that strikes me is that there is a distinctive difference 
between something like Darren's Quantities (and other numpy-based 
packages) and what MPL no supports for DateTimes -- in Quantities, the 
sequence itself has units, whereas with Datetimes, you use a generic 
sequence, and each element has units. I suppose that difference can be 
dealt with in the API, though.
> The original use case is that the JPL has an internal units
> package and they want to pass their objects directly to mpl
But, of course, the rest of us probably don't want to (or can't) use 
JPL's package, so we'll want a more generic package to test with and 
write samples for, etc.
In general, I think it's next to impossible to write a generic API 
without AT LEAST two use cases -- so maybe JPL's and Quantities would be 
a good start.
> 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.
And I have enjoyed the DateTime support (except when it's not there, 
natch!). In thinking about this more, I think the real benefit is in the 
coupling with the units support with nifty things like AutoLocaters and 
AutoFormatters -- these are great for DateTimes, and my first thought 
was "who cares" for simpler units like meters. However, in thinking, I 
realize that I've written a fair bit of code for my data that may be in 
meters, for instance, that goes like:
if max < 1:
 do_stuff_to display_centimeters.
elif max < 1000:
 do_stuff_to display_meters.
else:
 do_stuff_to display_kilometers.
It would be nice to push that stuff into an MPL locater and formatter, 
even if I do need to write them myself. And, ideally between us all, a 
nice collection of generic ones could be written.
I could (and now that I think about it, will) still do that by simply 
assuring my data are always in a particular unit, but it would be nicer 
if the locaters could be unit aware, so that one could pass in any 
length unit, and apply a "SI_length_Formatter" to it. Or just 
SI_Formatter, now that I think about it.
I'm not sure how to resolve one issue:
If I have a locator/formatter that decides whether to display cm or km, 
etc, depending on values, I probably want the axis label to reflect that 
too, but I don't know how one can get all those to communicate.
Also, it sounds like you're talking about converting units to the same 
something -- but, for length, it might be feet, or miles, or cm, or.... 
This is a bit different than what is done for time, where datetimes are 
always converted to the same base -- days since 0001年01月01日 00:00:00. 
Perhaps this convention could be followed with a standard base unit for 
length, etc. though maybe that wouldn't capture the range of precisions 
that may be required -- some data in centuries, some in nanoseconds...
(by the way, there was some work on handling datetimes with numpy arrays 
a while back -- I wonder what came of that?)
> I'm open to the idea of not supporting post-facto conversions after
> data is added, but am mostly minus one on it, and I'd like to hear
> from the JPL who requested the ability initially. I think their users
> are working with complex plots and might have arrays in different
> distance units, and would like to be able to pass in any distance
> units as long as conversion is possible.
I can see that, but suggest that the unit finally displayed by the plot 
be specified by an axis method, or Locators or Formatters, or ??, but in 
any case, not change depending on what order you add data to the plot.
It would be pretty cool to be able to do:
ax.plot(x, data_in_feet)
ax.plot(x, data_in_meters)
and get it all scaled right!
> there is little difference between the code
> you suggest::
> 
> ax.plot(values.rescale('cm'))
> ax.set_xlim(limits.rescale('cm'))
> 
> and::
> 
> ax.plot(values.rescale('cm').tofloat())
> ax.set_xlim(limits.rescale('cm').tofloat())
> 
> where the latter means we have no units or custom type support.
there are a couple differences:
1) with date2num, we still always use float-days- since-epoc for the 
actual numbers. That means that there can be one set of formatters. In 
that example, what units would tofloat() return? If we want formatter to 
work, some info about the units needs to be passed into mpl.
2) in the second version -- every unit-ed data type would have to have a 
tofloat() method (and what units would those floats be in?), or it would be:
 ax.plot(mpl.length2num(values.rescale('cm')) )
 ax.set_xlim(mpl.length2num(limits.rescale('cm')) )
In the end, I think datetimes are easier, not as many options.
I'm not sure all this was very clear, but hopefully it added some signal 
with the noise!
-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
Chr...@no...

I'm animating a Circle patch with a varying center and radius, and I 
noticed that changing the ``radius`` attribute has no effect on the 
patch. Currently, ``radius`` is only used to instantiate an Ellipse 
object, but updating radius has no effect (i.e. redrawing the patch 
doesn't use the new radius).
I've included a patch to add this feature. Also included in the patch 
is a small fix to one of the UI examples (sorry for included a 
completely unrelated patch but the fix seemed to small for a separate 
email).
BTW, I'm using a property idiom from: http://code.activestate.com/recipes/205183/ 
. I thought that this approach was better than polluting the namespace 
with getters and setters, especially since this would differ from the 
way the Ellipse class uses ``width`` and ``height`` attributes.
Cheers,
-Tony
===================================================================
--- lib/matplotlib/patches.py	(revision 7128)
+++ lib/matplotlib/patches.py	(working copy)
@@ -1131,6 +1131,14 @@
 self.radius = radius
 Ellipse.__init__(self, xy, radius*2, radius*2, **kwargs)
 __init__.__doc__ = cbook.dedent(__init__.__doc__) % artist.kwdocd
+
+ def radius():
+ def fget(self):
+ return self.width / 2.
+ def fset(self, radius):
+ self.width = self.height = 2 * radius
+ return locals()
+ radius = property(**radius())
 class Arc(Ellipse):
 """
Index: examples/user_interfaces/embedding_in_wx3.py
===================================================================
--- examples/user_interfaces/embedding_in_wx3.py	(revision 7128)
+++ examples/user_interfaces/embedding_in_wx3.py	(working copy)
@@ -147,7 +147,7 @@
 return True
 def OnBang(self,event):
- bang_count = XRCCTRL(self.frame,"bang_count")
+ bang_count = xrc.XRCCTRL(self.frame,"bang_count")
 bangs = bang_count.GetValue()
 bangs = int(bangs)+1
 bang_count.SetValue(str(bangs))

Now that we (finally!) got the bug fix release out for 0.98.5.3, which
I am hoping will be the last, I'd like to turn our attention to a
trunk release, which is where all the good stuff is, including the new
axes grid and mplot3d toolkits.
In advance of this, I suggest you commit any pending work you'd like
to see in the release, and try to tackle any pending sf bug reports or
patches (and file a bug report if you know of an issue that needs to
be addressed). In a week or so, I'll ask Michael to create a release
branch from HEAD at which point the 98.5 branch will die and the
release branch will become the new stable branch to which we apply
only bugfixes and not new features. We'll do a release candidate from
the branch, and then a release, in perhaps two weeks time.
Thanks,
JDH