matplotlib-devel Mailing List for matplotlib (Page 4)

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

On Wed, May 20, 2009 at 4:02 PM, Christopher Barker
<Chr...@no...> 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 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 think having proper units
support kind of implies that you should be able to handle conversion
between compatible units seamlessly. Else we are basically in the
date2num world -- just make all the users convert to floats before
working with mpl, since 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.
JDH

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
Chr...@no...

On Wed, May 20, 2009 at 3:37 PM, John Hunter <jd...@gm...> wrote:
> On Wed, May 20, 2009 at 3:30 PM, James Evans <jre...@ea...>
> 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

On Wed, May 20, 2009 at 3:30 PM, James Evans <jre...@ea...> 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 <wink>
JDH

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: 2009年5月20日 10:32:12 -0500
> From: John Hunter <jd...@gm...>
> Subject: Re: [matplotlib-devel] Tests and matplotlibrc
> To: Ryan May <rm...@gm...>
> Cc: Ted Drain <ted...@jp...>, "Evans,	James R"
> 	<jam...@jp...>, Matplotlib Devel????
> 	<mat...@li...>
> Message-ID:
> 	<88e...@ma...>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> On Wed, May 20, 2009 at 10:27 AM, Ryan May <rm...@gm...> 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

On Wed, May 20, 2009 at 2:36 PM, Eric Firing <ef...@ha...> 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

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 containers of artists for logical
> groupings during animation, zorder buffering/blitting, etc.
> 
> 
> 
> JDH

On Wed, May 20, 2009 at 1:10 PM, Christopher Barker
<Chr...@no...>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

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
Chr...@no...

On Wed, May 20, 2009 at 11:55 AM, Ryan May <rm...@gm...> wrote:
> On Wed, May 20, 2009 at 11:38 AM, Ryan May <rm...@gm...> 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

On Wed, May 20, 2009 at 11:54 AM, Christopher Barker
<Chr...@no...>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

On Wed, May 20, 2009 at 11:38 AM, Ryan May <rm...@gm...> 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

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
Chr...@no...

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

On Wed, May 20, 2009 at 10:27 AM, Ryan May <rm...@gm...> 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

On Wed, May 20, 2009 at 10:20 AM, John Hunter <jd...@gm...> wrote:
> On Wed, May 20, 2009 at 10:12 AM, Ryan May <rm...@gm...> 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

On Wed, May 20, 2009 at 10:12 AM, Ryan May <rm...@gm...> 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

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

On Wed, May 20, 2009 at 3:48 AM, Andrew Straw <str...@as...> 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

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)
> 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

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

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
(If the DNS update hasn't propagated to your DNS server yet, you can go
directly to http://code.astraw.com:8092/ )
In the meantime, please forgive a couple extra files I committed
(bootstrap.py and buildout.cfg) that are designed to get matplotlib to
adhere to buildout package standards.
Assuming I can get this working, I'll attempt to recruit further
buildslaves. In the interest of piquing your interest in running a
buildslave on your favorite platform(s), here is the contents of my
buildout.cfg file containing all of the configuration necessary. It's
pretty simple:
[buildout]
parts = ubuntu-hardy-amd64
[ubuntu-hardy-amd64]
recipe = collective.buildbot:slave
host = mpl-buildbot.code.astraw.com
port = 8090
password = <secret>

On Mon, May 18, 2009 at 10:41:22PM -0400, Darren Dale wrote:
> I had tried to work things out so mpl would only install traits if traits
> wasn't already installed, or if the installed version had also been
> provided by mpl. That turned out to be insufficient to avoid the problems
> [...]
> To make a long story short, it won't happen again.
Excellent. 
I do agree with both of you that shipping Traits with matplotlib is very
likely to get all of us in trouble.
If there are issue with having Traits as a dependency, they must be
adressed in the Traits codebase.
Gaël

On Mon, May 18, 2009 at 9:37 PM, Robert Kern <rob...@gm...> wrote:
> On 2009年05月18日 20:05, Darren Dale wrote:
> > On Mon, May 18, 2009 at 8:41 PM, Robert Kern <rob...@gm...
> > <mailto:rob...@gm...>> wrote:
> >
> > On 2009年05月18日 19:07, Andrew Straw wrote:
> > > I've been hacking away at adding support for "dropped spines" to
> MPL
> > > (e.g. http://jeb.biologists.org/cgi/content/full/211/3/341/FIG7 )
> and
> > > have come to the conclusion that there is a fundamental issue in
> the
> > > code base that the traits package has solved -- many values that
> > depend
> > > on other values with complicated stuff that happens when one of
> the
> > > parent values changes. For example, the location of the text from
> the
> > > xaxis depends on the padding value in addition to the xaxis
> location.
> > > Now I'm trying to add another element to the mix -- namely an
> > axis spine
> > > that can change location -- and things are going to spiral into a
> > > (further) collection of special-cased updates unless there's some
> > > reworking of the infrastructure.
> > >
> > > So, the question is, should I attempt to use traits for this? I
> guess
> > > that I won't have the time to re-write the entire code base to use
> > > traits, but I'd like make a stab a stab at dropped spine support
> with
> > > the knowledge that, should I be successful, there's at least a
> > chance we
> > > would again ship traits with MPL. I imagine we could
> > incrementally move
> > > more and more to traits if I'm successful, particularly now that
> > we have
> > > the beginnings of a unit test infrastructure (thanks James!).
> >
> > If you do, *please* either depend on Traits or, if you must include
> > the code in
> > matplotlib itself, stick it under matplotlib's namespace.
> >
> >
> > We stopped shipping traits with mpl a long time ago, when that issue was
> > identified.
>
> But part of that calculation was that Traits wasn't being used for anything
> non-experimental. Since that is being revisited, and since you still do
> distribute other packages like dateutils and pytz (which also cause similar
> installation headaches) the same way, I would like this to be kept in mind.
>
> > I really don't want to
> > go back to having to fix people's broken installations again.
> >
> >
> > Was that comment really necessary?
>
> Was it really offensive?
The whole situation was just really embarrassing for me. Who would want to
go back to having to fix people's broken installations? It just opened an
old wound.
> People would install matplotlib, then they would try to
> install other parts of ETS, the ETS stuff wouldn't work, thus they had a
> broken
> installation. I do not want to go back to having to fix their broken
> installations. This isn't a jab at the matplotlib team.
>
I had tried to work things out so mpl would only install traits if traits
wasn't already installed, or if the installed version had also been provided
by mpl. That turned out to be insufficient to avoid the problems you and
Gael had to deal with, because if setup.py was ever run when Traits was not
installed, distutils would copy traits into the build/ directory. Once it
ended up in build/, "setup.py install" would install it regardless of what
checks were in place in setup.py, thus overwriting existing Traits and
breaking environments.
To make a long story short, it won't happen again.
Darren