matplotlib-users Mailing List for matplotlib

On Mon, Dec 10, 2012 at 3:45 AM, Phil Elson <pel...@gm...> wrote:
> Thanks for bringing this up, it is certainly valuable to highlight this on
> the mailinglist. As you say, the change is hard to spot and, I agree, makes
> library code supporting v1.1.1 and v1.2 harder than one would like.
> Typically, anything which is going to break core APIs (even slightly) should
> be documented under the "API Changes" page here
> http://matplotlib.org/api/api_changes.html#changes-in-1-2-x
I suggest that an API change should have triggered a major version
bump to mpl-2.0.0. It seems a well-established expectation for a
major.minor.bugfix versioning scheme that bugfix releases will not
introduce new features, and minor releases will not introduce API
changes.
Darren

On 12/18/2012 09:21 AM, Jason Grout wrote:
> On 12/18/12 6:53 AM, Sturla Molden wrote:
>> Interactive 2D plots can be sluggish too, if you have enough objects in
>> them. It is not the backend that is sluggish. Replacing the backend does
>> not speed up the frontend.
>>
>> OpenGL is only 'fast' if you have a frontend that exploits it (e.g. uses
>> vertex buffers and vertex shaders). If you just use OpenGL for
>> bitblitting an image or drawing vertices individually (glVertex*), it is
>> not going to help at all.
>>
>> My impression is that whenever Matplotlib is 'too slow', I have to go
>> down to the iron and use OpenGL directly. It tends to happen when there
>> are too many objects to draw, and the drawing has to happen in 'real-time'.
>>
>> Observe that if we let OpenGL render to a frame buffer, we can copy its
>> content into a Matplotlib canvas. Unless we are doing some really heavy
>> real-time graphics, displaying the image is not going to be the speed
>> limiting factor. Even though using OpenGL to swap framebuffers will be
>> 'faster', you will not be able to tell the difference in an interactive
>> Matplotlib plotting.
> I'm curious: how come Chaco is so much faster for real-time plots? What
> are the main technical differences to enable it to plot things much more
> quickly?
>
I think this a great question -- one way to address this might be to 
find certain examples or plot types where the performance has a large 
gap and then drill down from there. There are so many different plot 
types and methods in both matplotlib and Chaco that it's hard to be 
general about performance issues. (And raw drawing performance isn't 
always the same thing as interactive performance, or file size or memory 
performance). I know years ago when I was working on the path 
simplification code in matplotlib it was way ahead of what Chaco was 
doing in that (very narrow and specific) case, but I haven't looked at 
Chaco much since.
Mike

This is a great summary of the issues related to OpenGL, and how it can 
help but is not a universal panacea.
Thanks,
Mike
On 12/18/2012 08:53 AM, Sturla Molden wrote:
> Interactive 2D plots can be sluggish too, if you have enough objects in
> them. It is not the backend that is sluggish. Replacing the backend does
> not speed up the frontend.
>
> OpenGL is only 'fast' if you have a frontend that exploits it (e.g. uses
> vertex buffers and vertex shaders). If you just use OpenGL for
> bitblitting an image or drawing vertices individually (glVertex*), it is
> not going to help at all.
>
> My impression is that whenever Matplotlib is 'too slow', I have to go
> down to the iron and use OpenGL directly. It tends to happen when there
> are too many objects to draw, and the drawing has to happen in 'real-time'.
>
> Observe that if we let OpenGL render to a frame buffer, we can copy its
> content into a Matplotlib canvas. Unless we are doing some really heavy
> real-time graphics, displaying the image is not going to be the speed
> limiting factor. Even though using OpenGL to swap framebuffers will be
> 'faster', you will not be able to tell the difference in an interactive
> Matplotlib plotting.
>
> Sturla
>
>
> On 14.12.2012 15:51, Ethan Gutmann wrote:
>> Hi Neal, my understanding is that matplotlib does not use OpenGL (thus
>> the terrible performance you see). You might want to look into glumpy
>> for mplot3d OpenGL acceleration.
>>
>> Ethan
>>
>>
>> On Dec 14, 2012, at 5:23 AM, Neal Becker<ndb...@gm...> wrote:
>>
>>> I'm using fedora (17) linux. I notice on complicated 3d plot, interactive
>>> performance can get sluggish. I'm using nouveau driver now, but wondering if
>>> installing nvidia driver will improve mpl 3d performance? Does mpl use opengl?
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
>>> Remotely access PCs and mobile devices and provide instant support
>>> Improve your efficiency, and focus on delivering more value-add services
>>> Discover what IT Professionals Know. Rescue delivers
>>> http://p.sf.net/sfu/logmein_12329d2d
>>> _______________________________________________
>>> Matplotlib-users mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>> ------------------------------------------------------------------------------
>> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
>> Remotely access PCs and mobile devices and provide instant support
>> Improve your efficiency, and focus on delivering more value-add services
>> Discover what IT Professionals Know. Rescue delivers
>> http://p.sf.net/sfu/logmein_12329d2d
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Sorry -- I hadn't meant to be terse: I hadn't realised until now that 
this was related to the other thread. I think it's an interesting 
discussion, and we should probably find some way to address it -- 
perhaps that means that `polar` grows an option to affect negative handling.
Mike
On 12/18/2012 10:08 AM, Alan G Isaac wrote:
> On 12/18/2012 9:40 AM, Michael Droettboom wrote:
> > Is this in reference to issue #1603? Are you advocating changing the
> > solution?
>
>
>
> My only point was that the ongoing conversation should
> not accept uncritically the assertion that r<0 is senseless.
> Thus I cited one example of the common acceptance of negative r:
> http://en.wikipedia.org/wiki/Polar_coordinate_system#Uniqueness_of_polar_coordinates
>
> I am not advocating a position on whether Matplotlib should enforce a unique
> representation, although that seems very doubtful to me.
>
> Alan
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Hi Pierre,
>> There is no mention in the docs about the treatment of negative "r". The treatment is contrary to my expectations, and I would wager contrary to many peoples expectations. So at a new minimum, at the very least, the docs should make clear what is happening.
>> 
>> I would further suggest that there are options specified by kwargs what the behavior is. The default could be the current behavior, which sounds like it is standard to some, and another option would be to complain if r < 0, as I think many others would expect.
> I fully agree with the idea of enabling users to specify the behavior
> they want. I'm not sure about raising an error, but it's true that it
> can be pretty helpful to detect computational mistakes.
This (above) sums up why I would like to have the option of matplotlib error raising for negative values of r.
Just to set the scene, I come from a physics background. So for me, and any application I would have, r is interpreted as a radius bounded from [0,inf]. Otherwise, keeping track, for example, of the motion of an object in polar coordinates would be more difficult.
Constructing polar coordinates is not always obvious, and one can make a mistake. Especially with something like matplotlib, where it is easy to experiment, sometimes one just throws the parameterization at the computer and sees what comes out.
From this perspective, it would be nice if I were to get a warning or error message.
I am perfectly happy to have the default behavior remain what it is.
I wish I were in a position to actually contribute to adding this new option. At the moment, I am in the midst of job hunting season, and would not be able to attempt it for a few months. If no one has taken up the task by then, and a developer were willing to look over my shoulder now and then, I would be interested in trying to add such an option. I have not yet contributed in such a way.
Regards,
Andre

>> Is this in reference to issue #1603? Are you advocating changing the
>> solution?
> 
> 
> 
> My only point was that the ongoing conversation should
> not accept uncritically the assertion that r<0 is senseless.
and I finally appreciate that criticism.
From my perspective, I was happy to learn something new.
I think it is clear to all on the list, that at first, this notion railed against my senses.
Cheers,
Andre

On 12/18/2012 9:40 AM, Michael Droettboom wrote:
 > Is this in reference to issue #1603? Are you advocating changing the
 > solution?
My only point was that the ongoing conversation should
not accept uncritically the assertion that r<0 is senseless.
Thus I cited one example of the common acceptance of negative r:
http://en.wikipedia.org/wiki/Polar_coordinate_system#Uniqueness_of_polar_coordinates
I am not advocating a position on whether Matplotlib should enforce a unique
representation, although that seems very doubtful to me.
Alan

> Is there anything we could do to give this important information a
> little more visibility on the webpage? The webpage still indicates
> that 1.2.0 is a development version.
Oops. That's been updated.
> Perhaps we could update it to
> say:
>
> "1.2.0 The most current stable release. Click here to see what's new
> since 1.1.1"
>
> And have "Click here" link to the page Phil mentioned. Thoughts?
>
I think I'm fine with this, but I'll hold off a bit on making this 
change in case there are better ideas raised.
Cheers,
Mike

Is this in reference to issue #1603? Are you advocating changing the 
solution?
Cheers,
Mike
On 12/17/2012 05:50 PM, Alan G Isaac wrote:
> http://en.wikipedia.org/wiki/Polar_coordinate_system#Uniqueness_of_polar_coordinates
>
> fwiw,
> Alan Isaac
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

On 12/18/12 6:53 AM, Sturla Molden wrote:
> Interactive 2D plots can be sluggish too, if you have enough objects in
> them. It is not the backend that is sluggish. Replacing the backend does
> not speed up the frontend.
>
> OpenGL is only 'fast' if you have a frontend that exploits it (e.g. uses
> vertex buffers and vertex shaders). If you just use OpenGL for
> bitblitting an image or drawing vertices individually (glVertex*), it is
> not going to help at all.
>
> My impression is that whenever Matplotlib is 'too slow', I have to go
> down to the iron and use OpenGL directly. It tends to happen when there
> are too many objects to draw, and the drawing has to happen in 'real-time'.
>
> Observe that if we let OpenGL render to a frame buffer, we can copy its
> content into a Matplotlib canvas. Unless we are doing some really heavy
> real-time graphics, displaying the image is not going to be the speed
> limiting factor. Even though using OpenGL to swap framebuffers will be
> 'faster', you will not be able to tell the difference in an interactive
> Matplotlib plotting.
I'm curious: how come Chaco is so much faster for real-time plots? What 
are the main technical differences to enable it to plot things much more 
quickly?
Thanks,
Jason

Interactive 2D plots can be sluggish too, if you have enough objects in 
them. It is not the backend that is sluggish. Replacing the backend does 
not speed up the frontend.
OpenGL is only 'fast' if you have a frontend that exploits it (e.g. uses 
vertex buffers and vertex shaders). If you just use OpenGL for 
bitblitting an image or drawing vertices individually (glVertex*), it is 
not going to help at all.
My impression is that whenever Matplotlib is 'too slow', I have to go 
down to the iron and use OpenGL directly. It tends to happen when there 
are too many objects to draw, and the drawing has to happen in 'real-time'.
Observe that if we let OpenGL render to a frame buffer, we can copy its 
content into a Matplotlib canvas. Unless we are doing some really heavy 
real-time graphics, displaying the image is not going to be the speed 
limiting factor. Even though using OpenGL to swap framebuffers will be 
'faster', you will not be able to tell the difference in an interactive 
Matplotlib plotting.
Sturla
On 14.12.2012 15:51, Ethan Gutmann wrote:
> Hi Neal, my understanding is that matplotlib does not use OpenGL (thus
> the terrible performance you see). You might want to look into glumpy
> for mplot3d OpenGL acceleration.
>
> Ethan
>
>
> On Dec 14, 2012, at 5:23 AM, Neal Becker<ndb...@gm...> wrote:
>
>> I'm using fedora (17) linux. I notice on complicated 3d plot, interactive
>> performance can get sluggish. I'm using nouveau driver now, but wondering if
>> installing nvidia driver will improve mpl 3d performance? Does mpl use opengl?
>>
>>
>> ------------------------------------------------------------------------------
>> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
>> Remotely access PCs and mobile devices and provide instant support
>> Improve your efficiency, and focus on delivering more value-add services
>> Discover what IT Professionals Know. Rescue delivers
>> http://p.sf.net/sfu/logmein_12329d2d
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Le 18/12/2012 11:13, Bob Dowling a écrit :
> Any how, the answer seems to be "yes I'm using rgrids() correctly, but 
> no I'm not using matplotlib-friendly data points". I shall adjust my 
> values of (r,th).
You don't need to change your (r,th) values. The two workarounds I see
to get your "version2" script work are :
1) Either call rgrids *after* plotting :
subplot(111, polar=True)
polar(t, r)
rgrids([2,4,6])
2) or call ylim to change the "rmin" parameter which tunes the radius
offset :
subplot(111, polar=True)
rgrids([2,4,6])
polar(t, r)
ylim(ymin=0) # or ylim(0,8) which looks even better in your specific case
Best,
Pierre

This is causing so much fuss, I'm starting to feel bad about asking the 
question. I'll reply in the "uniqueness" thread about the (r,th) 
coordinate system from a mathematical perspective.
 From a matplotlib.pyplot user perspective, however, I think that if it 
is going to misbehave with negative values of r under certain 
circumstances (rgrids() in this case) then it should produce a noisy 
warning as soon as it sees them in *all* circumstances. So my 
version2.py and version3.py should both produce warnings.
Any how, the answer seems to be "yes I'm using rgrids() correctly, but 
no I'm not using matplotlib-friendly data points". I shall adjust my 
values of (r,th).
Thank you for all your feedback.

Hi Andre,
Le 18/12/2012 06:52, Andre' Walker-Loud a écrit :
> There is no mention in the docs about the treatment of negative "r". The treatment is contrary to my expectations, and I would wager contrary to many peoples expectations. So at a new minimum, at the very least, the docs should make clear what is happening.
>
> I would further suggest that there are options specified by kwargs what the behavior is. The default could be the current behavior, which sounds like it is standard to some, and another option would be to complain if r < 0, as I think many others would expect.
I fully agree with the idea of enabling users to specify the behavior
they want. I'm not sure about raising an error, but it's true that it
can be pretty helpful to detect computational mistakes.
The way polar plots are implemented now seems to be a generalization of
usual polar coordinate mapping. Indeed, we have in [1] the following
mapping (let's call it T) :
T : (r, θ) ⟶ ((r-rmin) cos(θ), (r-rmin) sin(θ) )
which is parametrized by rmin.
Currently this 'rmin' is get from the ymin property of axis.viewLim
which can be set by ax.set_lim(ymin=...)
I see this "radius offsetting" functionality pretty useful in some cases
like drawing antenna diagrams in dB like [2]. For such a usecase, a
radius (ie r-rmin) going negative could raise an error.
In some other usecases like with a polar rose [3], the radius going
negative (and indeed it may not be called radius anymore...) is
perfectly legitimate and is the expected behavior. Also, the mapping T
currently implemented in [1] supports it perfectly.
In conclusion, I think matplotlib in its currently almost perfectly(*)
able to deal with both use cases thanks to this parametrized polar
mapping T. However, the current state of the documentation doesn't
reflects this flexibility. Also, an additional keyword argument could
help to specify the expected behavior, especially in term of error raising.
Best,
Pierre
[1]
https://github.com/matplotlib/matplotlib/blob/master/lib/matplotlib/projections/polar.py#L61
[2] https://hamstudy.org/browse/E4_2012/E9B
[3] http://en.wikipedia.org/wiki/Polar_coordinate_system#Polar_rose
(*) rgrids function raises an error for negative r values (see
polar.py#L537). This could be annoying for radiation patterns in dB

Hi Brendan,
>>>> I reiterate that in polar coordinates, a negative value of "r"
>>>> does not make sense. It is confusing at best.
>>> 
>>> This isn't really true. Many standard introductions to polar
>>> coordinates consider negative r as valid. It's simply treated as
>>> a radius in the opposite direction
>> 
>> In Euclidean space, can you have a negative distance? Would you
>> ever describe a circle as having negative radius (in Euclidean
>> space)? If you take "r" to be the radius, then I suggest you
>> confuse a precise definition of radius with allowing a useful,
>> non-unique interpretation of negative values of "r".
> 
> 	I don't take r to be "the radius", I take it to be a number in an ordered pair with a particular mapping into R^2. It is an extension of the notion of radius, but there's no reason it has to conform with the restrictions on geometrically possible radii.
This was clear from your previous comment - but this is precisely my point. In your original message, you used the word "radius". My point is that mathematics, and computing, are precise languages with hopefully unambiguous definitions. You used the word radius, but had in mind a less rigorous definition, because you were thinking of "r" as just one component of a two-coordinate description of 2D Euclidean space, with a specific definition of how to interpret negative "r". It is the standard you are used to and so not surprising to you. My point is that this expectation is not unique, and in my field, not common, and so not expected by me. Further, looking at the matplotlib doc, there is no indication what is happening - from 
http://matplotlib.org/api/pyplot_api.html
matplotlib.pyplot.polar(*args, **kwargs)
Make a polar plot.
call signature:
polar(theta, r, **kwargs)
Multiple theta, r arguments are supported, with format strings, as in plot().
There is no mention in the docs about the treatment of negative "r". The treatment is contrary to my expectations, and I would wager contrary to many peoples expectations. So at a new minimum, at the very least, the docs should make clear what is happening.
I would further suggest that there are options specified by kwargs what the behavior is. The default could be the current behavior, which sounds like it is standard to some, and another option would be to complain if r < 0, as I think many others would expect.
Maybe I am totally off. Maybe I am the only one who does not expect r to go negative. But at least the behavior should be clear without having to dig into the code.
> 	However, those issues are beside the point. The point is that, regardless of what a radius is, in the context of polar coordinates, a negative *r-coordinate* is a perfectly mathematically respectable notion with a standard interpretation. Moreover, it is actually useful when you want to graph some things, and is supported by other plotting software (see, e.g., http://www.wolframalpha.com/input/?i=polar+plot+r%3Dtheta%2C-pi%3Cr%3C0). Matplotlib should plot r-coordinates according to this standard interpretation,
Again, I would just argue the standard behavior should be clearly stated in the docs.
Regards,
Andre

On 2012年12月17日 20:05, Andre' Walker-Loud wrote:
>>> I reiterate that in polar coordinates, a negative value of "r"
>>> does not make sense. It is confusing at best.
>>
>> This isn't really true. Many standard introductions to polar
>> coordinates consider negative r as valid. It's simply treated as
>> a radius in the opposite direction
>
> In Euclidean space, can you have a negative distance? Would you
> ever describe a circle as having negative radius (in Euclidean
> space)? If you take "r" to be the radius, then I suggest you
> confuse a precise definition of radius with allowing a useful,
> non-unique interpretation of negative values of "r".
	I don't take r to be "the radius", I take it to be a number in an 
ordered pair with a particular mapping into R^2. It is an extension 
of the notion of radius, but there's no reason it has to conform with 
the restrictions on geometrically possible radii.
	However, those issues are beside the point. The point is that, 
regardless of what a radius is, in the context of polar coordinates, a 
negative *r-coordinate* is a perfectly mathematically respectable 
notion with a standard interpretation. Moreover, it is actually 
useful when you want to graph some things, and is supported by other 
plotting software (see, e.g., 
http://www.wolframalpha.com/input/?i=polar+plot+r%3Dtheta%2C-pi%3Cr%3C0). 
 Matplotlib should plot r-coordinates according to this standard 
interpretation,
-- 
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is 
no path, and leave a trail."
 --author unknown

>> I reiterate that in polar coordinates, a negative value of "r" does not make sense. It is confusing at best.
> 
> 	This isn't really true. Many standard introductions to polar 
> coordinates consider negative r as valid. It's simply treated as a 
> radius in the opposite direction
In Euclidean space, can you have a negative distance? Would you ever describe a circle as having negative radius (in Euclidean space)? If you take "r" to be the radius, then I suggest you confuse a precise definition of radius with allowing a useful, non-unique interpretation of negative values of "r".
> (i.e., the point is reflected about 
> the origin). A few examples found by googling: 
> http://tutorial.math.lamar.edu/Classes/CalcII/PolarCoordinates.aspx 
> and 
> http://sites.csn.edu/istewart/mathweb/math127/intro_polar/intro_polar.htm 
> and an MIT Opencourseware document at 
> http://ocw.mit.edu/resources/res-18-001-calculus-online-textbook-spring-2005/study-guide/MITRES_18_001_guide9.pdf. 
The nice MIT notes you linked to state (sec. 9.2, (page 355) listed as 132 on the bottom of page)
"The polar equation r = F(theta) is like y = f(x). For each angle theta the equation tells us the distance r (which is not allowed to be negative)."
> 	Matplotlib shouldn't raise an error on negative r, it should just 
> interpret negative r values correctly.
You assume all people have chosen the same definition of how to interpret negative values of "r". I grant you that it may be useful in some contexts to define what it means to have negative values of "r". But this definition is NOT UNIQUE. However, if you take "r" as a radius, and hence a positive definite quantity, as you would expect in Euclidean geometry for a distance, and you allow
r: [0,inf]
theta: [0,2pi)
then there is a unique and unambiguous representation of the coordinates.
I am not arguing that one can not take a definition of negative "r", only that different users will expect different things, and what matplotlib choses to do is not readily accessible in the documents as far as I can see. I also argue that many users, coming from the scientific background, will naturally interpret "r" as the radius (as I do) and hence expect "r" to be positive definite. And lastly, I argue, that since the definition is not unique, and people have different expectations, at the very least, matplotlib should warn you how it is interpreting negative "r".
Regards,
Andre

On 2012年12月17日 14:36, Andre' Walker-Loud wrote:
> On Dec 17, 2012, at 1:12 PM, Pierre Haessig wrote:
>
>> Le 17/12/2012 21:59, Pierre Haessig a écrit :
>>> Maybe this the code behind the masking of half your curve, but I don't
>>> know more.
>> Looking closer at the plot, the curve is actually not masked !
>>
>> Actually the "rmin functionality' is activated with rmin=-2*pi so that
>> the whole r-axis is offset by +2pi. The plot is therefore pretty
>> consistent only it is not what you want, I guess.
>> I don't know how to disable this radius offset functionality.
>
> Hi Pierre, Bob and all,
>
> I reiterate that in polar coordinates, a negative value of "r" does not make sense. It is confusing at best.
	This isn't really true. Many standard introductions to polar 
coordinates consider negative r as valid. It's simply treated as a 
radius in the opposite direction (i.e., the point is reflected about 
the origin). A few examples found by googling: 
http://tutorial.math.lamar.edu/Classes/CalcII/PolarCoordinates.aspx 
and 
http://sites.csn.edu/istewart/mathweb/math127/intro_polar/intro_polar.htm 
and an MIT Opencourseware document at 
http://ocw.mit.edu/resources/res-18-001-calculus-online-textbook-spring-2005/study-guide/MITRES_18_001_guide9.pdf. 
	Matplotlib shouldn't raise an error on negative r, it should just 
interpret negative r values correctly.
-- 
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is 
no path, and leave a trail."
 --author unknown

Maybe I'm just not seeing it; I don't see how the definition on wikipedia,
your definition, and matplotlib behavior differ.
import numpy as np
import matplotlib
matplotlib.use('WxAgg')
import matplotlib.pyplot as plt
t = np.linspace(0.0,2.0*np.pi, 50)
r = np.linspace(0.0,2.0*np.pi, 50)
plt.polar(t,r,color='blue')
plt.polar(t,-r,color='red')
plt.polar(-t,r,color='green')
plt.polar(-t,-r,color='yellow')
plt.show()
Comparing blue and red, you can see how mpl handles a negative r; each
point is 'opposite' just as described.
Comparing blue and green, you can see how mpl handles a negative angle.
 green curve increases in as you go clockwise, which is correct.
On Mon, Dec 17, 2012 at 6:54 PM, Andre' Walker-Loud <wal...@gm...>wrote:
> >
> http://en.wikipedia.org/wiki/Polar_coordinate_system#Uniqueness_of_polar_coordinates
>
> quoting from the site
>
> '''
> Where a unique representation is needed for any point, it is usual to
> limit r to non-negative numbers (r ≥ 0) and θ to the interval [0, 360°) or
> (−180°, 180°] (in radians, [0, 2π) or (−π, π]).[12] One must also choose a
> unique azimuth for the pole, e.g., θ = 0.
> '''
>
> Of course I don't have anything close to a scientific study of the
> following statement, but I suspect in practice (ie as polar coordinates are
> used in practice by working scientists), they expect to find values of "r"
> consistent with the above definition of unique - however, still wanting
> theta to not be bounded.
>
> Taking another quote form the site
>
> '''
> Also, a negative radial coordinate is best interpreted as the
> corresponding positive distance measured in the opposite direction.
> '''
>
> How does one define opposite in polar coordinates? The natural definition
> for "opposite" direction is presumably theta --> theta + pi, as that
> definition would correspond to the same notion of "opposite" in Cartesian
> coordinates (take whatever direction you were drawing a line, and go in "-"
> that direction. If we agree that this is the sensible definition of
> opposite, then pyplot.polar is not representing this definition of opposite.
>
> Attached are two plots. The first uses
>
> ''' as matplotlib is - neg_r.png '''
> import numpy as np
> import matplotlib.pyplot as plt
>
> t = np.linspace(-np.pi, np.pi, 60)
> r = t
> plt.polar(t,r)
>
> The second produces a curve which I say represents the natural definition
> of "opposite". Note, the tangents of the curves are also opposite as well
>
> ''' as matplotlib "should be" - neg_r_opposite.png '''
> import numpy as np
> import matplotlib.pyplot as plt
>
> t = np.linspace(0, np.pi, 30)
> r = t
> plt.polar(t,r)
> t_opp = np.linspace(np.pi,2*np.pi,30)
> r_opp = t_opp - np.pi
> plt.polar(t_opp,r_opp)
>
>
> I have three points to make with these plots:
> 1) my definition of opposite makes more sense than the default behavior of
> matplotlib
> 2) other people may have different ideas about what is best
> 3) matplotlib should at least raise a NOISY warning about what it is doing.
>
>
> Andre
>
>
>
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>
-- 
Daniel Hyams
dh...@gm...

On Mon, Dec 10, 2012 at 6:27 PM, Joe Kington <jof...@gm...> wrote:
> On Mon, Dec 10, 2012 at 2:45 AM, Phil Elson <pel...@gm...> wrote:
>>
>> Hi Joe,
>>
>> Thanks for bringing this up, it is certainly valuable to highlight this on
>> the mailinglist. As you say, the change is hard to spot and, I agree, makes
>> library code supporting v1.1.1 and v1.2 harder than one would like.
>> Typically, anything which is going to break core APIs (even slightly) should
>> be documented under the "API Changes" page here
>> http://matplotlib.org/api/api_changes.html#changes-in-1-2-x .
>
>
> Thanks! I wasn't aware of that page! (and it does a very nice job of
> documenting the changes!)
>
>>
>> You will find there were quite a few changes made relating to transforms
>> which I think is entirely my doing, so at least we know who the guilty party
>> is :-)
>>
>> Thanks for spotting the example failure - I split these changes over many
>> separate pull requests and did scan the gallery for any noticeable changes,
>> but this one must have slipped the net.
>>
>> If you're still having problems with using the newer transform API, please
>> shout and I'd be happy to have a look for you.
>
>
> Will do, thanks for the offer!
>
>>
>>
>> All the best,
>>
>> Phil
>>
>>
>> On 9 December 2012 22:10, Joe Kington <jof...@gm...> wrote:
>>>
>>> Hi folks,
>>>
>>> At some point transforms.Transform was slightly refactored.
>>> (Particularly, this commit:
>>> https://github.com/matplotlib/matplotlib/commit/8bbe2e55f29b28ba558504b27596b8e36a087c1c
>>> ) This changed what methods need to be overridden when subclassing
>>> Transform.
>>>
>>> All in all, it seems like a very sensible change, but it led to some very
>>> hard-to-find bugs in some of my code that subclasses transforms.Transform. I
>>> thought I would mention it on the mailing list for anyone else that uses
>>> custom projections. Forgive me if it was mentioned earlier and I just didn't
>>> notice.
>>>
>>> With versions 1.1.x and older, one had to directly implement a transform
>>> method when subclassing transforms.Transform, otherwise a NotImplemented
>>> error would be raised.
>>>
>>> With versions 1.2.x and newer, the preferred way appears to be to
>>> implement things in a separate transform_affine or transform_non_affine
>>> method and not explicitly implement a transform method.
>>>
>>> If you implement the non-affine portion directly in the transform method
>>> without overriding transform_non_affine, it leads to strange drawing bugs
>>> with v1.2 that did not occur with older versions. (For example, this broke
>>> one of the examples in the gallery between 1.1. and 1.2:
>>> http://matplotlib.org/1.1.1/examples/api/custom_projection_example.html
>>> http://matplotlib.org/1.2.0/examples/api/custom_projection_example.html . I
>>> just submitted a pull request to update the example, by the way.)
>>>
>>> On the other hand, for compatibility with versions 1.1 and older, you
>>> have to explicitly implement the transform method as well, otherwise you'll
>>> get the NotImplemented error.
>>>
>>> Therefore, now one needs to explicitly implement _both_ the
>>> transform_non_affine and transform methods of a custom non-affine transform
>>> for compatibility with 1.1 and older as well as 1.2 and newer.
>>>
>>> Similarly, one needs to implement _both_ the transform_path_non_affine
>>> and the transform_path methods for compatibility with newer and older
>>> versions of matplotlib.
>>>
>>> Arguably, it should have always been done this way, but based on
>>> examples/api/custom_projection_example.py, I (and I suspect many other
>>> people as well) implemented the transform directly as the transform method
>>> when subclassing Transform, instead of separately in a transform_affine or
>>> transform_non_affine method.
>>>
>>> Is this a large enough change to warrant a mention in the changelog? (On
>>> the other hand, the mailing list probably gets a lot more eyes on it than
>>> the changelog...)
>>>
>>> Thanks!
>>> -Joe
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
>>> Remotely access PCs and mobile devices and provide instant support
>>> Improve your efficiency, and focus on delivering more value-add services
>>> Discover what IT Professionals Know. Rescue delivers
>>> http://p.sf.net/sfu/logmein_12329d2d
>>> _______________________________________________
>>> Matplotlib-users mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>
>>
>
Is there anything we could do to give this important information a
little more visibility on the webpage? The webpage still indicates
that 1.2.0 is a development version. Perhaps we could update it to
say:
"1.2.0 The most current stable release. Click here to see what's new
since 1.1.1"
And have "Click here" link to the page Phil mentioned. Thoughts?
-- 
Damon McDougall
http://www.damon-is-a-geek.com
Institute for Computational Engineering Sciences
201 E. 24th St.
Stop C0200
The University of Texas at Austin
Austin, TX 78712-1229