matplotlib-devel Mailing List for matplotlib (Page 2)

Another note. I ran into problems when trying to create the build in
a directory that had spaces. (e.g. C:\Documents and Settings\....).
Try running everything in a top level dir.
- Charlie
On Thu, May 28, 2009 at 9:56 AM, Charlie Moad <cw...@gm...> wrote:
> It's strange that I didn't run into spacing issues.
>
> sdist --formats=gztar
>
> - Charlie
>
> On Thu, May 28, 2009 at 9:47 AM, John Hunter <jd...@gm...> wrote:
>> On Wed, May 27, 2009 at 11:08 PM, Charlie Moad <cw...@gm...> wrote:
>>>   I've spent the last couple of days writing the win32 equivalent
>>> of John's osx release scripts for MinGW. It patches distutils at
>>> runtime to exclude the msvcr link, hence we should no longer need to
>>> modify distutils. I have tested it on Python 2.6 and it should work
>>> on 2.4 and 2.5 as well. It's too late for me to test those right now,
>>> but I trust they should work. Instructions can be found in
>>> release/win32/README.txt. It required removing a link to "gw32" in
>>> "setupext.py" so it only works trunk sdists. All interested, please
>>> give it a try.
>>
>> I'm in the process of testing this -- one problem I encountered was
>> some trailing spaces after the version numbers and before the comments
>> which broke the build. nfortunately some of the compiler error
>> messages were fairly cryptic (c compiler cannot create executables)
>> which sent me down some false trails before I figured it out from the
>> libpng config.log. I've committed the fix (first use of tortoisesvn
>> -- woohoo).
>>
>> My sdist command in mingw is creating zip files by default -- any way
>> to force it to make the tar.gz that the build script is expecting ? I
>> can hack around this by creating my own tarball.....
>>
>> JDH
>>
>

It's strange that I didn't run into spacing issues.
sdist --formats=gztar
- Charlie
On Thu, May 28, 2009 at 9:47 AM, John Hunter <jd...@gm...> wrote:
> On Wed, May 27, 2009 at 11:08 PM, Charlie Moad <cw...@gm...> wrote:
>>   I've spent the last couple of days writing the win32 equivalent
>> of John's osx release scripts for MinGW. It patches distutils at
>> runtime to exclude the msvcr link, hence we should no longer need to
>> modify distutils. I have tested it on Python 2.6 and it should work
>> on 2.4 and 2.5 as well. It's too late for me to test those right now,
>> but I trust they should work. Instructions can be found in
>> release/win32/README.txt. It required removing a link to "gw32" in
>> "setupext.py" so it only works trunk sdists. All interested, please
>> give it a try.
>
> I'm in the process of testing this -- one problem I encountered was
> some trailing spaces after the version numbers and before the comments
> which broke the build. nfortunately some of the compiler error
> messages were fairly cryptic (c compiler cannot create executables)
> which sent me down some false trails before I figured it out from the
> libpng config.log. I've committed the fix (first use of tortoisesvn
> -- woohoo).
>
> My sdist command in mingw is creating zip files by default -- any way
> to force it to make the tar.gz that the build script is expecting ? I
> can hack around this by creating my own tarball.....
>
> JDH
>

 I've spent the last couple of days writing the win32 equivalent
of John's osx release scripts for MinGW. It patches distutils at
runtime to exclude the msvcr link, hence we should no longer need to
modify distutils. I have tested it on Python 2.6 and it should work
on 2.4 and 2.5 as well. It's too late for me to test those right now,
but I trust they should work. Instructions can be found in
release/win32/README.txt. It required removing a link to "gw32" in
"setupext.py" so it only works trunk sdists. All interested, please
give it a try.
- Charlie

Thanks a lot Andrew. This looks great.
I'm just reporting some of issues I encountered in a hope that you can
address these (I'll also take a look if have chance).
 * cla() does not reset spines (positions, color, etc). I think it is
better to be reset, since all other things are. For example, cla()
resets visibility of ticks, etc.
* better support for log scale.
ax = subplot(131)
ax.spines["bottom"].set_position("center")
ax.semilogx()
# this works
ax = subplot(132)
ax.semilogx()
ax.spines["bottom"].set_position("center")
# this does NOT
ax = subplot(133)
ax.spines["bottom"].set_position(("data", 1))
ax.loglog()
# this does NOT work regardless the position of loglog.
▶◀
-JJ
On Wed, May 27, 2009 at 12:33 PM, Andrew Straw <str...@as...> wrote:
> I've gone ahead and committed my arbitrary spine location implementation
> to the trunk (svn r7144). I'd appreciate it if you could kick the tires.
> To get you started, try the new demo:
> examples/pylab_examples/spine_placement_demo.py
>
> I believe I addressed all the issues raised with the patch I emailed the
> list last week and I tried to avoid any breakage. Thanks to all who
> commented -- you made this a better implementation.
>
> Note that Axes.frame no longer exists, and I made a note of this in
> api_changes.rst and a hopefully carefully worded AttributeError will be
> raised if you try to access it.
>
> Also, as excercised by the demo, in addition to support for a offset of
> spines specified in points, one may specify spine placement in both axes
> and data coordinates. Here is the docstring for Spine.set_position:
>
> """
> set the position of the spine
>
> Spine position is specified by a 2 tuple of (position type,
> amount). The position types are:
>
> * 'outward' : place the spine out from the data area by the
> specified number of points. (Negative values specify placing the
> spine inward.)
>
> * 'axes' : place the spine at the specified Axes coordinate (from
> 0.0-1.0).
>
> * 'data' : place the spine at the specified data coordinate.
>
> Additionally, shorthand notations define a special positions:
>
> * 'center' -> ('axes',0.5)
> * 'zero' -> ('data', 0.0)
> """
>
> As always, please let me know of any suggestions or comments.
>
> -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 as they present alongside digital heavyweights like Barbarian
> Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On Wed, May 27, 2009 at 12:53 PM, Eric Firing <ef...@ha...> wrote:
> No problem--it can be done later, no rush. Your replacement of the
> frame with spines is a *big* improvement. Thank you for the great work.
Yes, this looks great -- thanks again Andrew.
Something that would be nice would be a Formatter that is aware of the
spines which would drop the label in the places near the spine
intersection (eg the zeros in the centered example). Nothing obvious
comes to mind, but I just wanted to throw it out there in case someone
wants to dig in.
JDH

A review of a book primarily on matplotlib, numpy and scipy has hit the 
front page of Slashdot.
http://books.slashdot.org/article.pl?sid=09/05/27/1327255&from=rss
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Andrew Straw wrote:
> Andrew Straw wrote:
>> I believe I addressed all the issues raised with the patch I emailed the
>> list last week and I tried to avoid any breakage. Thanks to all who
>> commented -- you made this a better implementation.
> 
> Upon further reflection, I realize I didn't add any Axes convenience 
> methods as Eric suggested. This is simply due to a lack of time -- not a 
> lack of enthusiasm.
Andrew,
No problem--it can be done later, no rush. Your replacement of the 
frame with spines is a *big* improvement. Thank you for the great work.
Eric

Andrew Straw wrote:
> I believe I addressed all the issues raised with the patch I emailed the
> list last week and I tried to avoid any breakage. Thanks to all who
> commented -- you made this a better implementation.
Upon further reflection, I realize I didn't add any Axes convenience 
methods as Eric suggested. This is simply due to a lack of time -- not a 
lack of enthusiasm.
-Andrew

I've gone ahead and committed my arbitrary spine location implementation
to the trunk (svn r7144). I'd appreciate it if you could kick the tires.
To get you started, try the new demo:
examples/pylab_examples/spine_placement_demo.py
I believe I addressed all the issues raised with the patch I emailed the
list last week and I tried to avoid any breakage. Thanks to all who
commented -- you made this a better implementation.
Note that Axes.frame no longer exists, and I made a note of this in
api_changes.rst and a hopefully carefully worded AttributeError will be
raised if you try to access it.
Also, as excercised by the demo, in addition to support for a offset of
spines specified in points, one may specify spine placement in both axes
and data coordinates. Here is the docstring for Spine.set_position:
"""
set the position of the spine
Spine position is specified by a 2 tuple of (position type,
amount). The position types are:
* 'outward' : place the spine out from the data area by the
 specified number of points. (Negative values specify placing the
 spine inward.)
* 'axes' : place the spine at the specified Axes coordinate (from
 0.0-1.0).
* 'data' : place the spine at the specified data coordinate.
Additionally, shorthand notations define a special positions:
* 'center' -> ('axes',0.5)
* 'zero' -> ('data', 0.0)
"""
As always, please let me know of any suggestions or comments.
-Andrew

This is off the top of my head. I haven't really been following this 
thread and I wasn't able to determine which was the most current patch 
to apply.
It looks like you don't actually want to apply the axes transform twice 
(which get_xaxis_transform() + mtransforms.ScaledTranslation(0.5, 0, 
self.axes.transAxes) would do). 
What seems to work for me is to transform the input coordinates *before* 
applying the existing axis transform:
 mtransforms.Affine2D().translate(0.0, 0.5) + self.get_xaxis_transform()
I would suggest that you could keep two kinds of spine transforms (those 
relative to the axes and those given in points) separate. Build the 
whole pipeline all the time and then just allow the user to tweak either 
or both, and thus have something like:
 transform_by_axes_units + self.get_xaxis_transform() + 
transform_by_points
Using them in combination may be rare, but isn't completely nonsensical.
Hope that helps,
Mike
Andrew Straw wrote:
> Hi MPL transform gurus (aka Mike),
>
> I'm trying to close on this "dropped spine" thing, and I have a question
> I think you could save me some time on.
>
> I need to get a transform that will be combined with the normal xaxis
> transform to shift the spine and associated ticks and tick labels by
> some amount. For my first incarnation, I used something like
>
> mtransforms.ScaledTranslation(offset_x,offset_y,self.figure.dpi_scale_trans)
>
> This is fine when I new the offset in points directly. However, now I'd
> like to support offsetting the spine to the center of the Axes. So, for
> this case, I'd like to calculate the offset transform required to take
> axes coordinate 0 and translate it to 0.5. Thus, I think I need
> something like
>
> mtransforms.ScaledTranslation(0.5, 0, self.axes.transAxes)
>
> Unfortunately, that's clearly not working. So, is there a quick fix for
> this?
>
> Note that, as I've implemented things, the easiest path is that the new
> transform is a translation combined with the existing xaxis transform
> (using "get_xaxis_transform() + my_new_transform"). Other methods may be
> possible, but I think they'll be a lot more work.
>
> Thanks,
> Andrew
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hi MPL transform gurus (aka Mike),
I'm trying to close on this "dropped spine" thing, and I have a question
I think you could save me some time on.
I need to get a transform that will be combined with the normal xaxis
transform to shift the spine and associated ticks and tick labels by
some amount. For my first incarnation, I used something like
mtransforms.ScaledTranslation(offset_x,offset_y,self.figure.dpi_scale_trans)
This is fine when I new the offset in points directly. However, now I'd
like to support offsetting the spine to the center of the Axes. So, for
this case, I'd like to calculate the offset transform required to take
axes coordinate 0 and translate it to 0.5. Thus, I think I need
something like
mtransforms.ScaledTranslation(0.5, 0, self.axes.transAxes)
Unfortunately, that's clearly not working. So, is there a quick fix for
this?
Note that, as I've implemented things, the easiest path is that the new
transform is a translation combined with the existing xaxis transform
(using "get_xaxis_transform() + my_new_transform"). Other methods may be
possible, but I think they'll be a lot more work.
Thanks,
Andrew

Yes -- that is correct. Arc's are unfillable by design -- such a thing 
might be possible, but it would require some extra work to the code to 
generate rectilinear lines around the edges of the clipped area. 
I think this fix is correct -- the purpose is to warn the user trying to 
fill an Arc that filling is not possible.
Cheers,
Mike
Eric Firing wrote:
> John Hunter wrote:
> 
>> On Sun, May 24, 2009 at 7:20 PM, Eric Firing <ef...@ha...> wrote:
>> 
>>> Tony S Yu wrote:
>>> 
>>>> Currently, Arc in matplotlib.patches requires that it be called with
>>>> kwarg ``fill=False``. Was this behavior intentional? The code suggests
>>>> that a default value was left out of the kwarg lookup.
>>>>
>>>> I've attached a simple patch to fix this (it still fails when fill set
>>>> to True).
>>>> 
>>> Thanks. I committed a slightly different fix. I think this handles all
>>> possibilities.
>>>
>>> 
>> Michael can weigh in on this when he has a chance, but my recollection
>> is that Arc was added to satisfy a JPL reported bug when one zooms
>> into a small region of an ellipse -- in that case our 4 spline
>> approximation code was inadequate, and in a heroic burst Michael
>> provided an 8 spline interpolation limited to the viewport. Ie,
>> instead of getting 4 splines for the entire ellipse, with his Arc
>> class you get 8 for the segment in the viewport. As part of this, he
>> decided it was mostly impossible to fully support filling, or at least
>> too difficult, so he may have intentionally raised this error. So we
>> should be careful here, because it may be that simple arcs, those
>> where everything is in the viewport, work ok with filling, but things
>> break down when his zoom optimizations are triggered.
>> 
>
> John,
>
> Yes, Arc is a very special-purpose class, and not really a patch at all. 
> Actually, according to the docstrings, the Ellipse is calculated with 
> 8 splines, and Arc is calculated with 8 splines for the viewable portion 
> alone.
>
> The change I made merely made it so that Arc works with no fill kwarg at 
> all, or with fill=False, and as before, it raises an error if 
> fill==True. I suspect this is the behavior Mike intended--I doubt he 
> meant to *require* a kwarg that can take only one value without raising 
> an error--but certainly he can correct me if I am mistaken.
>
> Eric
>
> 
>> JDH
>> 
>
>
> ------------------------------------------------------------------------------
> 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
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

FYI: The main reason we needed Arc was related to zooming accuracy and performance. We're drawing ellipses on a planetary scale (1000's of km) and then drawing other items (targeting points, error ellipses, etc) in only a small part of the planetary ellipse (1-10 km). Drawing a complete ellipse and then zooming way in to see everything else meant that the accuracy of the ellipse in the area we were looking at is crucial (and the performance of the agg in this mode is terrible). Arc allows us to draw just the part of the planetary ellipse in the area we care about so we get great accuracy and a huge speed increase.
Ted
> -----Original Message-----
> From: Eric Firing [mailto:ef...@ha...]
> Sent: Sunday, May 24, 2009 9:59 PM
> To: John Hunter
> Cc: Tony S Yu; matplotlib development list
> Subject: Re: [matplotlib-devel] Arc requires explicitly setting
> fill=False?
> 
> John Hunter wrote:
> > On Sun, May 24, 2009 at 7:20 PM, Eric Firing <ef...@ha...>
> wrote:
> >> Tony S Yu wrote:
> >>> Currently, Arc in matplotlib.patches requires that it be called
> with
> >>> kwarg ``fill=False``. Was this behavior intentional? The code
> suggests
> >>> that a default value was left out of the kwarg lookup.
> >>>
> >>> I've attached a simple patch to fix this (it still fails when fill
> set
> >>> to True).
> >> Thanks. I committed a slightly different fix. I think this handles
> all
> >> possibilities.
> >>
> >
> > Michael can weigh in on this when he has a chance, but my
> recollection
> > is that Arc was added to satisfy a JPL reported bug when one zooms
> > into a small region of an ellipse -- in that case our 4 spline
> > approximation code was inadequate, and in a heroic burst Michael
> > provided an 8 spline interpolation limited to the viewport. Ie,
> > instead of getting 4 splines for the entire ellipse, with his Arc
> > class you get 8 for the segment in the viewport. As part of this, he
> > decided it was mostly impossible to fully support filling, or at
> least
> > too difficult, so he may have intentionally raised this error. So we
> > should be careful here, because it may be that simple arcs, those
> > where everything is in the viewport, work ok with filling, but things
> > break down when his zoom optimizations are triggered.
> 
> John,
> 
> Yes, Arc is a very special-purpose class, and not really a patch at
> all.
> Actually, according to the docstrings, the Ellipse is calculated with
> 8 splines, and Arc is calculated with 8 splines for the viewable
> portion
> alone.
> 
> The change I made merely made it so that Arc works with no fill kwarg
> at
> all, or with fill=False, and as before, it raises an error if
> fill==True. I suspect this is the behavior Mike intended--I doubt he
> meant to *require* a kwarg that can take only one value without raising
> an error--but certainly he can correct me if I am mistaken.
> 
> Eric
> 
> >
> > JDH
> 
> 
> -----------------------------------------------------------------------
> -------
> 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
> 
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.5.339 / Virus Database: 270.12.37/2130 - Release Date:
> 05/24/09 07:09:00

John Hunter wrote:
> On Sun, May 24, 2009 at 7:20 PM, Eric Firing <ef...@ha...> wrote:
>> Tony S Yu wrote:
>>> Currently, Arc in matplotlib.patches requires that it be called with
>>> kwarg ``fill=False``. Was this behavior intentional? The code suggests
>>> that a default value was left out of the kwarg lookup.
>>>
>>> I've attached a simple patch to fix this (it still fails when fill set
>>> to True).
>> Thanks. I committed a slightly different fix. I think this handles all
>> possibilities.
>>
> 
> Michael can weigh in on this when he has a chance, but my recollection
> is that Arc was added to satisfy a JPL reported bug when one zooms
> into a small region of an ellipse -- in that case our 4 spline
> approximation code was inadequate, and in a heroic burst Michael
> provided an 8 spline interpolation limited to the viewport. Ie,
> instead of getting 4 splines for the entire ellipse, with his Arc
> class you get 8 for the segment in the viewport. As part of this, he
> decided it was mostly impossible to fully support filling, or at least
> too difficult, so he may have intentionally raised this error. So we
> should be careful here, because it may be that simple arcs, those
> where everything is in the viewport, work ok with filling, but things
> break down when his zoom optimizations are triggered.
John,
Yes, Arc is a very special-purpose class, and not really a patch at all. 
 Actually, according to the docstrings, the Ellipse is calculated with 
8 splines, and Arc is calculated with 8 splines for the viewable portion 
alone.
The change I made merely made it so that Arc works with no fill kwarg at 
all, or with fill=False, and as before, it raises an error if 
fill==True. I suspect this is the behavior Mike intended--I doubt he 
meant to *require* a kwarg that can take only one value without raising 
an error--but certainly he can correct me if I am mistaken.
Eric
> 
> JDH

On Sun, May 24, 2009 at 7:20 PM, Eric Firing <ef...@ha...> wrote:
> Tony S Yu wrote:
>> Currently, Arc in matplotlib.patches requires that it be called with
>> kwarg ``fill=False``. Was this behavior intentional? The code suggests
>> that a default value was left out of the kwarg lookup.
>>
>> I've attached a simple patch to fix this (it still fails when fill set
>> to True).
>
> Thanks. I committed a slightly different fix. I think this handles all
> possibilities.
>
Michael can weigh in on this when he has a chance, but my recollection
is that Arc was added to satisfy a JPL reported bug when one zooms
into a small region of an ellipse -- in that case our 4 spline
approximation code was inadequate, and in a heroic burst Michael
provided an 8 spline interpolation limited to the viewport. Ie,
instead of getting 4 splines for the entire ellipse, with his Arc
class you get 8 for the segment in the viewport. As part of this, he
decided it was mostly impossible to fully support filling, or at least
too difficult, so he may have intentionally raised this error. So we
should be careful here, because it may be that simple arcs, those
where everything is in the viewport, work ok with filling, but things
break down when his zoom optimizations are triggered.
JDH

Tony S Yu wrote:
> Currently, Arc in matplotlib.patches requires that it be called with 
> kwarg ``fill=False``. Was this behavior intentional? The code suggests 
> that a default value was left out of the kwarg lookup.
> 
> I've attached a simple patch to fix this (it still fails when fill set 
> to True).
Thanks. I committed a slightly different fix. I think this handles all 
possibilities.
--- a/matplotlib/lib/matplotlib/patches.py	Mon May 25 00:00:46 2009 +0000
+++ b/matplotlib/lib/matplotlib/patches.py	Mon May 25 00:16:44 2009 +0000
@@ -1189,10 +1189,9 @@
 %(Patch)s
 """
- fill = kwargs.get('fill') # returns None if key is absent
+ fill = kwargs.setdefault('fill', False)
 if fill:
 raise ValueError("Arc objects can not be filled")
- kwargs['fill'] = False
 Ellipse.__init__(self, xy, width, height, angle, **kwargs)
Eric
> 
> Cheers,
> -Tony
> 
> Index: lib/matplotlib/patches.py
> ===================================================================
> --- lib/matplotlib/patches.py	(revision 7137)
> +++ lib/matplotlib/patches.py	(working copy)
> @@ -1189,7 +1189,7 @@
> 
> %(Patch)s
> """
> - fill = kwargs.pop('fill')
> + fill = kwargs.pop('fill', False)
> if fill:
> raise ValueError("Arc objects can not be filled")
> kwargs['fill'] = False
> 
> 
> ------------------------------------------------------------------------------
> 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

Currently, Arc in matplotlib.patches requires that it be called with 
kwarg ``fill=False``. Was this behavior intentional? The code suggests 
that a default value was left out of the kwarg lookup.
I've attached a simple patch to fix this (it still fails when fill set 
to True).
Cheers,
-Tony
Index: lib/matplotlib/patches.py
===================================================================
--- lib/matplotlib/patches.py	(revision 7137)
+++ lib/matplotlib/patches.py	(working copy)
@@ -1189,7 +1189,7 @@
 %(Patch)s
 """
- fill = kwargs.pop('fill')
+ fill = kwargs.pop('fill', False)
 if fill:
 raise ValueError("Arc objects can not be filled")
 kwargs['fill'] = False

On Sat, May 23, 2009 at 9:53 AM, Reinier Heeres <re...@he...> wrote:
> I just committed a few updates to mplot3d:
> - Contourf3d is working again (although I'm not 100% it looks the same
> as in previous versions; I'll have to compare)
> - Drawing bars works
> - Zordering is implemented for collections and patches, necessary to
> get both of the above working properly.
Excellent -- I'll give these a test drive shorty. BTW, have you had a
chance to look at this question:
 http://www.nabble.com/3d-surface-plot-appears-as-black-surface-td23587006.html
Perhaps you could look and see if there is a bug here and respond to the OP.
> I noticed that matplotlib/axes3d.py contains the following code:
>  raise NotImplementedError('axes3d is not supported in
> matplotlib-0.98. You may want to try the 0.91.x maintenance branch')
>
> I think we should either remove this file or just import
> mpl_toolkits.axes3d. Any thoughts?
Let's just remove it. When the release goes out, I will put a
prominent notice on the website news section pointing to the new
toolkits.
> Finally, I'm also trying to write a bit of docs in Sphinx, hope to
> have something interesting soon...
Excellent -- when we have uploaded these, we should edit the scipy
cookbook mplot3d entry to point to these too. Also, if you create an
examples in the examples/mplot3d dir, I'll configure the site docs to
build these examples so they show up in the gallery and examples
pages. Lots of people will find the toolkit this way. While we have
one demo file that makes a lot of plots, and this is fine, I prefer
smaller self contained examples each illustrating one feature: plot3,
bar, scatter, surf, mesh, whatever.
Thanks for all your work on this,
JDH

Hi all,
I just committed a few updates to mplot3d:
- Contourf3d is working again (although I'm not 100% it looks the same
as in previous versions; I'll have to compare)
- Drawing bars works
- Zordering is implemented for collections and patches, necessary to
get both of the above working properly.
I noticed that matplotlib/axes3d.py contains the following code:
 raise NotImplementedError('axes3d is not supported in
matplotlib-0.98. You may want to try the 0.91.x maintenance branch')
I think we should either remove this file or just import
mpl_toolkits.axes3d. Any thoughts?
Finally, I'm also trying to write a bit of docs in Sphinx, hope to
have something interesting soon...
Cheers,
-- 
Reinier Heeres
Bleijenburg 64
2511 VD Den Haag
The Netherlands
Tel: +31 6 10852639

Eric Firing wrote:
> Michael Droettboom wrote:
>> 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.
>
> Mike,
>
> Thanks for taking care of this so quickly.
>
> Although I agree that _interpolation_steps is a low-level, 
> implementation-dependent attribute (which might not be the right 
> specification if interpolation were changed to take advantage of 
> Bezier curves, for example), I think that some sort of 
> "follow_curvilinear_coordinates" public Artist attribute would be 
> desirable. For example, one might want to plot a set of arcs, or 
> arc-shaped patches (warped rectangles) on a polar plot. It would be 
> nice to be able to do this using lines, line collections, rectangle 
> patches, or rectangle collections, by adding a single kwarg to set 
> that attribute. Then it would be up to each Artist to use that 
> attribute to set _interpolation_steps or whatever implementation 
> mechanism is in place. Possibly it does not make sense as a general 
> Artist attribute but should be restricted to a subset, but it is 
> probably simpler to put it at the Artist level and then selectively 
> apply it. 
Agreed with all of the above -- all the infrastructure is now in place 
to do this. I was most concerned with fixing the bug (seeming lack of 
gridlines) first, and then getting this improvement in later (probably 
not till next week).
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Michael Droettboom wrote:
> 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.
Mike,
Thanks for taking care of this so quickly.
Although I agree that _interpolation_steps is a low-level, 
implementation-dependent attribute (which might not be the right 
specification if interpolation were changed to take advantage of Bezier 
curves, for example), I think that some sort of 
"follow_curvilinear_coordinates" public Artist attribute would be 
desirable. For example, one might want to plot a set of arcs, or 
arc-shaped patches (warped rectangles) on a polar plot. It would be 
nice to be able to do this using lines, line collections, rectangle 
patches, or rectangle collections, by adding a single kwarg to set that 
attribute. Then it would be up to each Artist to use that attribute to 
set _interpolation_steps or whatever implementation mechanism is in 
place. Possibly it does not make sense as a general Artist attribute 
but should be restricted to a subset, but it is probably simpler to put 
it at the Artist level and then selectively apply it.
Eric
> 
> 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
> 

Thanks. Should be fixed now in SVN.
Mike
Andrew Straw wrote:
> Hi Mike, I think you introduced a regression in r7131. I picked this up
> using "python backend_driver.py agg":
>
> examples/api$ python custom_projection_example.py
> Traceback (most recent call last):
> File "custom_projection_example.py", line 440, in <module>
> subplot(111, projection="hammer")
> File "/usr/local/lib/python2.6/dist-packages/matplotlib/pyplot.py",
> line 645, in subplot
> a = fig.add_subplot(*args, **kwargs)
> File "/usr/local/lib/python2.6/dist-packages/matplotlib/figure.py",
> line 690, in add_subplot
> a = subplot_class_factory(projection_class)(self, *args, **kwargs)
> File "/usr/local/lib/python2.6/dist-packages/matplotlib/axes.py", line
> 7802, in __init__
> self._axes_class.__init__(self, fig, self.figbox, **kwargs)
> File "custom_projection_example.py", line 35, in __init__
> Axes.__init__(self, *args, **kwargs)
> File "/usr/local/lib/python2.6/dist-packages/matplotlib/axes.py", line
> 525, in __init__
> self.set_figure(fig)
> File "/usr/local/lib/python2.6/dist-packages/matplotlib/axes.py", line
> 597, in set_figure
> self._set_lim_and_transforms()
> File "custom_projection_example.py", line 94, in _set_lim_and_transforms
> self.transProjection = self.HammerTransform(self.RESOLUTION)
> TypeError: __init__() takes exactly 1 argument (2 given)
>
>
> Michael Droettboom wrote:
> 
>> 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

Tony S Yu wrote:
> When running `pyplot.spy` I ran into the following error:
> 
> AttributeError: 'BlendedGenericTransform' object has no attribute 
> '_interpolation_steps'
> 
> Just from pattern matching (I have no idea what's going on in the 
> code), I noticed that _interpolation_steps was usually called from a 
> Path object, not a Transform object, so I tried switching the call 
> (see diff below), which seems to work for me. Since this was a recent 
> addition (r7130), I figure this was just a typo.
Fixed. Thank you.
Eric
> 
> Cheers,
> -Tony
> 
> 
> ===================================================================
> --- lib/matplotlib/transforms.py	(revision 7133)
> +++ lib/matplotlib/transforms.py	(working copy)
> @@ -1145,7 +1145,7 @@
> ``transform_path_affine(transform_path_non_affine(values))``.
> """
> return Path(self.transform_non_affine(path.vertices), 
> path.codes,
> - self._interpolation_steps)
> + path._interpolation_steps)
> 
> def transform_angles(self, angles, pts, radians=False, 
> pushoff=1e-5):
> """
> 
> 
> ------------------------------------------------------------------------------
> 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

When running `pyplot.spy` I ran into the following error:
AttributeError: 'BlendedGenericTransform' object has no attribute 
'_interpolation_steps'
Just from pattern matching (I have no idea what's going on in the 
code), I noticed that _interpolation_steps was usually called from a 
Path object, not a Transform object, so I tried switching the call 
(see diff below), which seems to work for me. Since this was a recent 
addition (r7130), I figure this was just a typo.
Cheers,
-Tony
===================================================================
--- lib/matplotlib/transforms.py	(revision 7133)
+++ lib/matplotlib/transforms.py	(working copy)
@@ -1145,7 +1145,7 @@
 ``transform_path_affine(transform_path_non_affine(values))``.
 """
 return Path(self.transform_non_affine(path.vertices), 
path.codes,
- self._interpolation_steps)
+ path._interpolation_steps)
 def transform_angles(self, angles, pts, radians=False, 
pushoff=1e-5):
 """

On Fri, May 22, 2009 at 9:35 AM, Andrew Straw <str...@as...> wrote:
> 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.
This is a much better solution, one I hadn't thought of, so go with
it. Artist is already a newstyle class, so no problems there.
> (Thanks to all for the responses... I'm acting on them and will
> incorporate most or all of the suggestions.)
Excellent.
JDH