Re: [Matplotlib-users] Undocumented transform API change between 1.1 and 1.2?
On Mon, Dec 10, 2012 at 3:45 AM, Phil Elson 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 -- 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] 3d performance question
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 -- 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] 3d performance question
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 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 >>> Matplotlib-users@lists.sourceforge.net >>> 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 >> Matplotlib-users@lists.sourceforge.net >> 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 > Matplotlib-users@lists.sourceforge.net > 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 Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] uniqueness of polar coordinates (meaningfulness of r<0)
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 > Matplotlib-users@lists.sourceforge.net > 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 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 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 -- 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)
>> 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 -- 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)
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 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?
> 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 -- 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)
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 > Matplotlib-users@lists.sourceforge.net > 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 Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] 3d performance question
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 -- 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] 3d performance question
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 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 >> Matplotlib-users@lists.sourceforge.net >> 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 > Matplotlib-users@lists.sourceforge.net > 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 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 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 signature.asc Description: OpenPGP digital signature -- 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?
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. -- 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 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 -- 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
