Re: [Matplotlib-users] Novice question: Am I using pyplot.rgrids correctly?
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 -- 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 Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] Novice question: Am I using pyplot.rgrids correctly?
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 -- 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 Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] Novice question: Am I using pyplot.rgrids correctly?
>> 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 -- 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 Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] Novice question: Am I using pyplot.rgrids correctly?
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 -- 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 Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] uniqueness of polar coordinates (meaningfulness of r<0)
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 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
> Matplotlib-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>
--
Daniel Hyams
dhy...@gmail.com
--
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
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] Undocumented transform API change between 1.1 and 1.2?
On Mon, Dec 10, 2012 at 6:27 PM, Joe Kington wrote: > On Mon, Dec 10, 2012 at 2:45 AM, Phil Elson 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 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 >>> Matplotlib-users@lists.sourceforge.net >>> 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 Inst
Re: [Matplotlib-users] uniqueness of polar coordinates (meaningfulness of r<0)
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 Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] Novice question: Am I using pyplot.rgrids correctly?
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. At the very least, I think matplotlib should raise a NOISY warning. (I just checked that it does not). I would advocate for a change however. I suggest that given negative values of "r", pyplot.polar raises an error and exits. One could add a kwarg that allows you to override this default behavior, "neg_r=False" unless the user specifies otherwise. In general, when I code things that don't make sense mathematically, I like it when the code tells me I made a dumb mistake. If the code is defaulting to "fixing" the dumb mistake for me without any explicit warnings, that is more likely to raise a more serious error in my code, and a much harder bug to track down. My two cents (well, it looks like a bit more than two). Regards, 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 Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] Novice question: Am I using pyplot.rgrids correctly?
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. Best, Pierre -- 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 Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] Novice question: Am I using pyplot.rgrids correctly?
Hi Bob, Le 17/12/2012 19:09, Bob Dowling a écrit : > > I am plotting a polar graph with some negative values of r. > Everything goes well until I try to use rgrids(). Am I doing > something wrong? I just noticed that calling rgrids *after* plotting works nicely for me: subplot(111, polar=True) polar(t, r) rgrids([2,4,6]) However, calling rgrids before plotting indeed leads to a weird situation where only half of the curve is plotted. After digging in the source code, this may relate to the `use_rmin` parameter in the PolarTransform class init (in matplotlib.projections.polar) In the tranform_non_affine method I see # line 40-42: if self._axis is not None: if self._use_rmin: rmin = self._axis.viewLim.ymin # [...] if rmin != 0: r = r - rmin mask = r < 0 x[:] = np.where(mask, np.nan, r * np.cos(t)) y[:] = np.where(mask, np.nan, r * np.sin(t)) else: x[:] = r * np.cos(t) y[:] = r * np.sin(t) Maybe this the code behind the masking of half your curve, but I don't know more. Best, Pierre -- 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 Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] Novice question: Am I using pyplot.rgrids correctly?
> I am a matplotlib.pyplot novice, but I have looked through various FAQs to no > avail. > > I am plotting a polar graph with some negative values of r. Everything goes > well until I try to use rgrids(). Am I doing something wrong? > > I attach some demo scripts and their outputs. > > version1.py uses rgrid() but only has positive values of r. Everything works > the way I expect it to (see version1.png). > > version2.py has negative values of r and the same call to rgrid() and > misbehaves (see version2.png). > > version3.py is the same as version2.py, but without the call to rgrids() (but > with negative values of r). Again everything is as expected. > > What am I doing wrong in version2.py? and only because it (sadly) took me a few minutes to figure out (even though it seemed so obvious), to create the plot of your version 3, with only positively defined values for "r", you can do t = numpy.linspace(0,2*numpy.pi,61) r = t t2 = numpy.linspace(-numpy.pi,numpy.pi,61) r2 = numpy.pi - t2 plt.polar(t,r) plt.polar(t2,r2) 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 Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] Novice question: Am I using pyplot.rgrids correctly?
Hi Bob, > I am a matplotlib.pyplot novice, but I have looked through various FAQs to no > avail. > > I am plotting a polar graph with some negative values of r. Everything goes > well until I try to use rgrids(). Am I doing something wrong? > > I attach some demo scripts and their outputs. > > version1.py uses rgrid() but only has positive values of r. Everything works > the way I expect it to (see version1.png). > > version2.py has negative values of r and the same call to rgrid() and > misbehaves (see version2.png). > > version3.py is the same as version2.py, but without the call to rgrids() (but > with negative values of r). Again everything is as expected. > > What am I doing wrong in version2.py? I am not sure why things work in version 3 and do not work in version 2. A guess would be how matplotlib is covering up illegal values of your "r" coordinate. Here I am only speaking from the math point of view, and not what is actually happening in matplotlib. I tired finding info in the docs, but did not succeed in getting The coordinates "t" and "r" are angle and radius. In polar coordinates, negative values of the radial coordinate "r" are not well defined, since in this coordinate system, you can not have negative values of a radius. So my **guess** is that your problems are related to this ill definition of the radial coordinate. And that sometimes matplotlib can cover it up for you, and other times it complains more loudly. Regards, 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 Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] clabel3D, is it possible?
On Sun, Dec 16, 2012 at 8:22 PM, Diego Avesani wrote: > dear all, > I have plot a 3D picture, I would like to have xy projection with contours > levels and labels. > The contours works but I do not get the labels. > > This is my code: > > import matplotlib.pyplot as plt > > from mpl_toolkits.mplot3d import axes3d, Axes3D > > fig = plt.figure() > > ax = Axes3D(fig) #<-- Note the difference from your original code... > > > X, Y, Z = axes3d.get_test_data(0.05) > > > cset = ax.contour(X, Y, Z,100,zdir='z',offset=-100) > > ax.clabel(cset, fontsize=9, inline=1) > > > plt.show()import matplotlib.pyplot as plt > > from mpl_toolkits.mplot3d import axes3d, Axes3D #<-- Note the > capitalization! > > fig = plt.figure() > > > ax = Axes3D(fig) #<-- Note the difference from your original code... > > > X, Y, Z = axes3d.get_test_data(0.05) > > > cset = ax.contour(X, Y, Z,100,zdir='z',offset=-100) > > ax.clabel(cset, fontsize=9, inline=1) > > > plt.show() > > > Is it possible to have also the labels? > > Thanks > > > Diego > > Theoretically, yes. I have just never thought about that sort of feature before, and it would not be trivial to implement. In the meantime, you can take a look at this example for a way to manually label things in a 3d plot. http://matplotlib.org/examples/mplot3d/text3d_demo.html Ben Root -- 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 Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
