matplotlib-devel Mailing List for matplotlib (Page 3)

> but as I look through patches, I notice there are a number of places
> (eg RegularPolygon) where hidden methods w/o docstrings are used.  I
> assume Michael wrote most of these in the transforms refactorring.
> Was this a conscious decision to hide them from the doc proprty
> introspection mechanism?
>   
I don't think so.  IIRC, most of what are now properties were raw 
attributes at one time, and the hidden methods was just to avoid adding 
more things to the public namespace.  But I don't see any compelling 
reason they couldn't be public.

Mike

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

John Hunter wrote:
> On Thu, May 21, 2009 at 10:08 PM, Jae-Joon Lee <lee...@gm...> wrote:
>
>   
>> 2) Axes.frame
>>  Is it okay to simply  drop this attribute? Any code that access this
>> attribute will raise an exception. For example, some of my code in
>> mpl_toolkits.axes_grid access this attribute, although a fix would be
>> very trivial.
>>     
>
> We can drop it - there never was a documented reference to it, no
> public method, etc, so it is safely considered mostly  "internal
> code", and in the global scheme is comparatively new code (and on a
> quick grepping did not see any examples using it in the pylab_examples
> or api dirs).  I don't think it will impact many users, and anyone who
> was trying to manipulate the frame directly can easily update their
> code.  We should just have a little transition cheatsheet in the
> API_CHANGES section describing the removal.
>
> We *could* override getattr and raise a suitable warning pointing to
> the spine docs, if people think that is needed, but overriding getattr
> often leads to unintentional bugs.
>   
Based on Jae-Joon's comment, I was thinking of making .frame a property
that raised an Error describing to get .spines instead... That avoids
the getattr issues, but I think depends on Artist being a new style class.

(Thanks to all for the responses... I'm acting on them and will
incorporate most or all of the suggestions.)

-Andrew

On Thu, May 21, 2009 at 12:35 PM, Tony S Yu <to...@mi...> wrote:
> 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.


Thanks Tony -- I committed this with a change.  The mpl getters and
setters, as well as the ACCEPTS line,  are used in the object
introspection and doc building, so the way to add a property like
radius is:


    def set_radius(self, radius):
        """
        Set the radius of the circle

        ACCEPTS: float
        """
        self.width = self.height = 2 * radius

    def get_radius(self):
        'return the radius of the circle'
        return self.width / 2.

    radius = property(get_radius, set_radius)

but as I look through patches, I notice there are a number of places
(eg RegularPolygon) where hidden methods w/o docstrings are used.  I
assume Michael wrote most of these in the transforms refactorring.
Was this a conscious decision to hide them from the doc proprty
introspection mechanism?

That's right, Eric.  I think having resolution be an attribute of the 
artist (and not the projection) is the "path" of least resistance here.  
To clarify, however, the interpolation (more specifically, whether to 
interpolate) should remain a function of the projection, not the path.  
That's the important point that lead to it ending up in the wrong place 
in the first place.  If we aim to keep the generalization that all grid 
lines are the same kind of object regardless of the projection, and 
therefore set a high resolution parameter on all the grid lines, we 
wouldn't want this to slow down the standard rectilinear axes.  As long 
as the standard axes don't obey the parameter, then would should be 
fine.  It's somewhat confusing, but I also am seeing this the resolution 
parameter on artists as more of an implementation detail than a public 
API.  If someone wants to interpolate their data, IMHO that should be 
the user's responsibility, since they know the best way to do it.  This 
functionality isn't really about data points, IMHO.

The more difficult change seems to be being backward compatible about 
the Polar plot accepting a resolution argument.  I'm not even certain 
that it's worth keeping, since as you suggest, it makes more sense for 
it to be a property of the artist.  I'd almost prefer to raise a warning 
if the user provides a resolution argument (other than 1) to Polar 
rather than trying to make it work.  Is anyone actually using it, other 
than to set it to 1 on 0.98.x versions?

I should have some time to work on this today.

Mike

Eric Firing wrote:
> Eric Firing wrote:
>> Jae-Joon Lee wrote:
>>> The default resolution (which is used to interpolate a path in polar
>>> coordinate) has change to 1 at some point. And because of this, a
>>> radial grid becomes a 0-length line. Increasing the resolution will
>>> bring back your gridlines.
>>
>> This is not the right solution, though.  There was a reason for the 
>> change in default resolution to 1--it gives the expected behavior for 
>> plotting a line between two points in polar coordinates--and it is 
>> not going back.  The inability to set resolution on a per-artist 
>> basis is a serious problem that doesn't seem to have a simple 
>> solution.  Until one can be found, some sort of special case handling 
>> will be needed for the radial grid lines.
>>
>> Eric
>
>
> Expanding on this: it looks like a possible solution is to attach a 
> new "resolution" attribute to the Path object.  This would ordinarily 
> be None, but could be set to another value when the Path is created 
> (or later).  Then the PolarTransform.transform_path method (and the 
> same in other curvilinear projections) could use that value, if not 
> None, to control interpolation.  Some additional changes would be 
> needed to apply this to the radial gridlines.
>
> Now it is not clear to me that resolution should be an attribute of 
> the PolarAxes at all--the interpolation is done by a path method, so 
> that method doesn't need a resolution parameter at all if resolution 
> is a Path attribute.  Except for backwards compatibility.  Comments, 
> Mike?
>
> I can't implement it right now, but if no one comes up with a better 
> solution, or wants to implement something like this one, then I can do 
> it in a day or two.
>
> (Of course, I may not be seeing a stumbling block.)
>
> Eric

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Thu, May 21, 2009 at 10:08 PM, Jae-Joon Lee <lee...@gm...> wrote:

> 2) Axes.frame
>  Is it okay to simply  drop this attribute? Any code that access this
> attribute will raise an exception. For example, some of my code in
> mpl_toolkits.axes_grid access this attribute, although a fix would be
> very trivial.

We can drop it - there never was a documented reference to it, no
public method, etc, so it is safely considered mostly  "internal
code", and in the global scheme is comparatively new code (and on a
quick grepping did not see any examples using it in the pylab_examples
or api dirs).  I don't think it will impact many users, and anyone who
was trying to manipulate the frame directly can easily update their
code.  We should just have a little transition cheatsheet in the
API_CHANGES section describing the removal.

We *could* override getattr and raise a suitable warning pointing to
the spine docs, if people think that is needed, but overriding getattr
often leads to unintentional bugs.

JDH

Eric Firing wrote:
> Jae-Joon Lee wrote:
>> The default resolution (which is used to interpolate a path in polar
>> coordinate) has change to 1 at some point. And because of this, a
>> radial grid becomes a 0-length line. Increasing the resolution will
>> bring back your gridlines.
> 
> This is not the right solution, though.  There was a reason for the 
> change in default resolution to 1--it gives the expected behavior for 
> plotting a line between two points in polar coordinates--and it is not 
> going back.  The inability to set resolution on a per-artist basis is a 
> serious problem that doesn't seem to have a simple solution.  Until one 
> can be found, some sort of special case handling will be needed for the 
> radial grid lines.
> 
> Eric


Expanding on this: it looks like a possible solution is to attach a new 
"resolution" attribute to the Path object.  This would ordinarily be 
None, but could be set to another value when the Path is created (or 
later).  Then the PolarTransform.transform_path method (and the same in 
other curvilinear projections) could use that value, if not None, to 
control interpolation.  Some additional changes would be needed to apply 
this to the radial gridlines.

Now it is not clear to me that resolution should be an attribute of the 
PolarAxes at all--the interpolation is done by a path method, so that 
method doesn't need a resolution parameter at all if resolution is a 
Path attribute.  Except for backwards compatibility.  Comments, Mike?

I can't implement it right now, but if no one comes up with a better 
solution, or wants to implement something like this one, then I can do 
it in a day or two.

(Of course, I may not be seeing a stumbling block.)

Eric

Jae-Joon Lee wrote:
> The default resolution (which is used to interpolate a path in polar
> coordinate) has change to 1 at some point. And because of this, a
> radial grid becomes a 0-length line. Increasing the resolution will
> bring back your gridlines.

This is not the right solution, though.  There was a reason for the 
change in default resolution to 1--it gives the expected behavior for 
plotting a line between two points in polar coordinates--and it is not 
going back.  The inability to set resolution on a per-artist basis is a 
serious problem that doesn't seem to have a simple solution.  Until one 
can be found, some sort of special case handling will be needed for the 
radial grid lines.

Eric

> 
> ax = fig.add_axes([0.1, 0.1, 0.8, 0.8], polar=True, axisbg='#d5de9c',
> resolution=100)
> 
> -JJ
> 
> 
> 
> On Thu, May 21, 2009 at 10:13 PM, John Hunter <jd...@gm...> wrote:
>> When plotting the polar demo, I am not getting radial grids on the
>> trunk (but I am getting them on the branch).  Any ideas?
>>
>> import matplotlib
>> import numpy as np
>> from matplotlib.pyplot import figure, show, rc, grid
>>
>> # radar green, solid grid lines
>> rc('grid', color='#316931', linewidth=1, linestyle='-')
>> rc('xtick', labelsize=15)
>> rc('ytick', labelsize=15)
>>
>> # force square figure and square axes looks better for polar, IMO
>> width, height = matplotlib.rcParams['figure.figsize']
>> size = min(width, height)
>> # make a square figure
>> fig = figure(figsize=(size, size))
>> ax = fig.add_axes([0.1, 0.1, 0.8, 0.8], polar=True, axisbg='#d5de9c')
>>
>> r = np.arange(0, 3.0, 0.01)
>> theta = 2*np.pi*r
>> ax.plot(theta, r, color='#ee8d18', lw=3)
>> ax.set_rmax(2.0)
>>
>> ax.set_rgrids(np.arange(0.5, 2.0, 0.5))
>> ax.grid(True)
>>
>> ax.set_title("And there was much rejoicing!", fontsize=20)
>> show()
>>
>> ------------------------------------------------------------------------------
>> 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
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
> 
> ------------------------------------------------------------------------------
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

The default resolution (which is used to interpolate a path in polar
coordinate) has change to 1 at some point. And because of this, a
radial grid becomes a 0-length line. Increasing the resolution will
bring back your gridlines.

ax = fig.add_axes([0.1, 0.1, 0.8, 0.8], polar=True, axisbg='#d5de9c',
resolution=100)

-JJ



On Thu, May 21, 2009 at 10:13 PM, John Hunter <jd...@gm...> wrote:
> When plotting the polar demo, I am not getting radial grids on the
> trunk (but I am getting them on the branch).  Any ideas?
>
> import matplotlib
> import numpy as np
> from matplotlib.pyplot import figure, show, rc, grid
>
> # radar green, solid grid lines
> rc('grid', color='#316931', linewidth=1, linestyle='-')
> rc('xtick', labelsize=15)
> rc('ytick', labelsize=15)
>
> # force square figure and square axes looks better for polar, IMO
> width, height = matplotlib.rcParams['figure.figsize']
> size = min(width, height)
> # make a square figure
> fig = figure(figsize=(size, size))
> ax = fig.add_axes([0.1, 0.1, 0.8, 0.8], polar=True, axisbg='#d5de9c')
>
> r = np.arange(0, 3.0, 0.01)
> theta = 2*np.pi*r
> ax.plot(theta, r, color='#ee8d18', lw=3)
> ax.set_rmax(2.0)
>
> ax.set_rgrids(np.arange(0.5, 2.0, 0.5))
> ax.grid(True)
>
> ax.set_title("And there was much rejoicing!", fontsize=20)
> show()
>
> ------------------------------------------------------------------------------
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

I just had a quick at the patch and it looks good.
I have two minor issues.

1) API change in Axes.get_xaxis_transform & get_yaxis_transform.
  The default keyword argument which=None raises an exception. Maybe
you meant which="grid"?

2) Axes.frame
  Is it okay to simply  drop this attribute? Any code that access this
attribute will raise an exception. For example, some of my code in
mpl_toolkits.axes_grid access this attribute, although a fix would be
very trivial.

Regards,

-JJ




On Thu, May 21, 2009 at 8:06 PM, Andrew Straw <str...@as...> wrote:
> I've implemented initial support for "dropped spines". This is motivated
> by the ability to draw figures that look like
> http://jeb.biologists.org/cgi/content/full/211/3/341/FIG7 . I'm
> attaching the patches and an image created by the new example.
>
> This is a somewhat invasive change into the core of the axis rendering
> code, so I'm hereby requesting a review before committing it into the
> code base. In particular, I dropped the idea of using Traits in MPL not
> because I think it's a bad idea, but because that would involve more
> substantial changes.
>
> Anyhow, I'm attaching the proposed implementation as a series of
> patches. If the general form of this looks OK, I'd write up doc strings
> and a CHANGELOG entry and commit it. Should I wait until after the trunk
> release?
>
> Please let me know what you think. All the examples run with
> exaples/tests/backend_driver.py still seem to give OK results, and the
> test suite raises a few more failures, but these appear due to
> (sub)pixel shifts in text rendering rather than anything more severe.
>
> -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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

Andrew Straw wrote:
> John Hunter wrote:
>> When plotting the polar demo, I am not getting radial grids on the
>> trunk (but I am getting them on the branch).  Any ideas?
> 
> git bisect let me narrow it down to r7100 in a few minutes. (I'm back to
> using git to interact with MPL svn again.  Just don't ask me to deal
> with the svn branches! :)

Hmm, it seems my git mirror of the svn repo is bad... For some reason
git thinks r7100 comes after r6550, so there are a few commits in there
that seem to have been lumped with r7100!

Oh, wait, now I remember doing "git svn fetch -r 7100:HEAD" at some
point. I'll have to remedy this...

John Hunter wrote:
> When plotting the polar demo, I am not getting radial grids on the
> trunk (but I am getting them on the branch).  Any ideas?

git bisect let me narrow it down to r7100 in a few minutes. (I'm back to
using git to interact with MPL svn again.  Just don't ask me to deal
with the svn branches! :)

Author: efiring <efiring@f61c4167-ca0d-0410-bb4a-bb21726e55ed>
Date:   Wed May 13 19:59:16 2009 +0000

    Experimental clipping of Line _transformed_path to speed zoom and pan.

    This can be modified to work with x monotonically decreasing, but
    for a first try it works only with x monotonically increasing.
    The intention is to greatly speed up zooming and panning into
    a small segment of a very long time series (e.g., 10^6 points)
    without incurring any significant speed penalty in other situations.

git bisect start
# bad: [e4c9c46ab1909c05323da28c057c8d64fc6d44a8] add example of dropped
spines
git bisect bad e4c9c46ab1909c05323da28c057c8d64fc6d44a8
# good: [bdf5bb3116a6d58d49b0d7a98e8dab5d9dacd1da] removed extraneous
savefig calls from examples
git bisect good bdf5bb3116a6d58d49b0d7a98e8dab5d9dacd1da
# bad: [f36409e021d030fa22515d4d9362a2c657e3df3e] applied Michiel's sf
patch 2792742 to speed up Cairo and macosx collections
git bisect bad f36409e021d030fa22515d4d9362a2c657e3df3e
# good: [6d21b5b655f045d9edf759037e3a67ca51f89d08] updates to doc
git bisect good 6d21b5b655f045d9edf759037e3a67ca51f89d08
# bad: [d7a5aecdbf274227e98ad4ac4257435d2e37156d] Fixed bugs in quiver
affecting angles passed in as a sequence
git bisect bad d7a5aecdbf274227e98ad4ac4257435d2e37156d
# bad: [736a4f9804e01d0d5b738f869444709496e34c56] psfrag in backend_ps
now uses baseline-alignment when preview.sty is used
git bisect bad 736a4f9804e01d0d5b738f869444709496e34c56
# bad: [86e1487f9718db26c86867a2711aac5410bd828d] Experimental clipping
of Line _transformed_path to speed zoom and pan.
git bisect bad 86e1487f9718db26c86867a2711aac5410bd828d

On Thu, May 21, 2009 at 7:47 PM, Eric Firing <ef...@ha...> wrote:
> Andrew Straw wrote:
>> I've implemented initial support for "dropped spines". This is motivated
>> by the ability to draw figures that look like
>> http://jeb.biologists.org/cgi/content/full/211/3/341/FIG7 . I'm
>> attaching the patches and an image created by the new example.

> It looks like that nicely addresses a frequent request.  Great! I
> haven't looked closely enough yet to see how it all works, but one
> immediate suggestion is that the adjust_spines function in your example
> looks like something that should be modified a bit and turned into an
> axes method with the usual pyplot wrapper.  That is a fine point, of
> course, that can be deferred.
>
> It looks like the offset is defined as positive outward from center of
> the plot.  Are negative values allowed, so the spine goes through the
> middle of the plot, for example?


Hey Andrew -- this is really excellent.  The lack of support for spine
placement is one of the things that has been mentally holding me back
from releasing mpl as 1.0, so by all means commit it.  I did read
through the patch, and it looks like a clean implementation so I don't
have any specific suggestions.  I would like to see a 'xcenter'or
'ycenter' (or whatver name works best) option in addition to the
'left', 'right', 'top' and 'bottom' so we can easily support things
like Mathematica/Sage style spines

  http://webscripts.softpedia.com/scriptScreenshots/SAGE-Screenshots-27855.html

Do you think you could add this fairly easily?  Also, it would be nice
to have some simple configuration options, perhaps a few default
themes, so one could easily switch between them, and probably rc
support for a default theme. The theme might specify both the spine
placement as well as the tick in/out/center placement.   None of this
needs to go in ahead of the initial commit though.

Thanks!
JDH

When plotting the polar demo, I am not getting radial grids on the
trunk (but I am getting them on the branch).  Any ideas?

import matplotlib
import numpy as np
from matplotlib.pyplot import figure, show, rc, grid

# radar green, solid grid lines
rc('grid', color='#316931', linewidth=1, linestyle='-')
rc('xtick', labelsize=15)
rc('ytick', labelsize=15)

# force square figure and square axes looks better for polar, IMO
width, height = matplotlib.rcParams['figure.figsize']
size = min(width, height)
# make a square figure
fig = figure(figsize=(size, size))
ax = fig.add_axes([0.1, 0.1, 0.8, 0.8], polar=True, axisbg='#d5de9c')

r = np.arange(0, 3.0, 0.01)
theta = 2*np.pi*r
ax.plot(theta, r, color='#ee8d18', lw=3)
ax.set_rmax(2.0)

ax.set_rgrids(np.arange(0.5, 2.0, 0.5))
ax.grid(True)

ax.set_title("And there was much rejoicing!", fontsize=20)
show()

Andrew Straw wrote:
> I've implemented initial support for "dropped spines". This is motivated
> by the ability to draw figures that look like
> http://jeb.biologists.org/cgi/content/full/211/3/341/FIG7 . I'm
> attaching the patches and an image created by the new example.
> 
> This is a somewhat invasive change into the core of the axis rendering
> code, so I'm hereby requesting a review before committing it into the
> code base. In particular, I dropped the idea of using Traits in MPL not
> because I think it's a bad idea, but because that would involve more
> substantial changes.
> 
> Anyhow, I'm attaching the proposed implementation as a series of
> patches. If the general form of this looks OK, I'd write up doc strings
> and a CHANGELOG entry and commit it. Should I wait until after the trunk
> release?
> 
> Please let me know what you think. All the examples run with
> exaples/tests/backend_driver.py still seem to give OK results, and the
> test suite raises a few more failures, but these appear due to
> (sub)pixel shifts in text rendering rather than anything more severe.
> 
> -Andrew

Andrew,

It looks like that nicely addresses a frequent request.  Great! I 
haven't looked closely enough yet to see how it all works, but one 
immediate suggestion is that the adjust_spines function in your example 
looks like something that should be modified a bit and turned into an 
axes method with the usual pyplot wrapper.  That is a fine point, of 
course, that can be deferred.

It looks like the offset is defined as positive outward from center of 
the plot.  Are negative values allowed, so the spine goes through the 
middle of the plot, for example?

The name "spine" threw me off for a while; but I guess that is a 
reasonable description for a line with ticks. "Axis" and "Scale" are 
already taken, so maybe "spine" is as good as we can find.  "Dropped 
spine" sounds like a painful medical condition... Oh, well...

Eric

I've implemented initial support for "dropped spines". This is motivated
by the ability to draw figures that look like
http://jeb.biologists.org/cgi/content/full/211/3/341/FIG7 . I'm
attaching the patches and an image created by the new example.

This is a somewhat invasive change into the core of the axis rendering
code, so I'm hereby requesting a review before committing it into the
code base. In particular, I dropped the idea of using Traits in MPL not
because I think it's a bad idea, but because that would involve more
substantial changes.

Anyhow, I'm attaching the proposed implementation as a series of
patches. If the general form of this looks OK, I'd write up doc strings
and a CHANGELOG entry and commit it. Should I wait until after the trunk
release?

Please let me know what you think. All the examples run with
exaples/tests/backend_driver.py still seem to give OK results, and the
test suite raises a few more failures, but these appear due to
(sub)pixel shifts in text rendering rather than anything more severe.

-Andrew

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

On Wed, May 20, 2009 at 2:11 PM, Ryan May <rm...@gm...> wrote:

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

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

On Wed, May 20, 2009 at 1:01 PM, Ryan May <rm...@gm...> wrote:

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

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