[matplotlib-devel] clippedline example status
Hello,
I was playing a bit with the clippedline example
(http://matplotlib.org/examples/pylab_examples/clippedline.html) and I
feel it is not working anymore.
From what I understand of the traceback I got, there may be something
evil happening after setting
>>> self._marker = 's'
in the draw method. Maybe using the self.set_marker('s') is safer
Also, by reading some archived emails from this mailing list, it seems
that the purpose of this example became pointless because line clipping
is now implemented directly in matplotlib. Am I right ?
For what it's worth, I modified the clippeline.py example to make it
just serve the purpose of dynamically changing the appearance of the
line when zoom level is changing. I called t "zoom_adaptive_line.py" :
https://gist.github.com/3607993
Would this script be an appropriate replacement for the clippedline
example ?
Best,
Pierre
signature.asc
Description: OpenPGP digital signature
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] slowdown with big invisible lines
Hello, This may be a silly question, but I'm wondering what happens in Matplotlib rendering when there is a "big" Line2D object (say 10**7 points) added to an Axes, with *visibility set to false*. Here is an tiny script meant to be run interactively (say with Python in pylab mode) step by step : https://gist.github.com/3638471 I'm experiencing a strange slowdown of Axes rendering when such a "big line" is added to the Axes, despite the fact it is invisible. So I'm wondering if this is an expected behavior or a some kind of bug. Or maybe it's a well known fact, already fixed in the upcoming 1.2 release and in that case sorry for the duplicate. Best, Pierre PS: I'm using Matplotlib version 1.1.1rc2, from Debian Testing. Today TkAgg backend, but the other day same problem happened with Qt. signature.asc Description: OpenPGP digital signature -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] slowdown with big invisible lines
Le 10/09/2012 19:19, Pierre Haessig a écrit : > Hello, > > This may be a silly question, but I'm wondering what happens in > Matplotlib rendering when there is a "big" Line2D object (say 10**7 > points) added to an Axes, with *visibility set to false*. > > [...] Hello, I was just wondering if I should preferably post such messages about a possible bug report on matplotlib-users mailing list instead of the devel ml. I'm not familiar with the community convention of how to spit topics between those two. Or is it better if I just report directly an issue on GitHub and start discussion from there ? Best, Pierre PS : an unrelated question about mailing list : I noticed that the matplotlib-users ml archive on sourceforge seems to stop from recording starting around July 16th 2012 http://sourceforge.net/mailarchive/forum.php?forum_name=matplotlib-users (on the other hand, the devel archive seems fine). No messages appear for August and September signature.asc Description: OpenPGP digital signature -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] slowdown with big invisible lines
Hi Phil, Le 13/09/2012 16:50, Phil Elson a écrit : > Your issue looks legit, I have looked through the axes.py Axes.draw > method, and there is no filtering based on the visibility toggle for > anything but images. Seems like it could be a very easy fix, would you > be willing to open an issue on the github tracker? > https://github.com/matplotlib/matplotlib/issues/new Thank your very much for your feedback. I've opened the issue (https://github.com/matplotlib/matplotlib/issues/1256) and started to investigate a bit. It's the first time I'm browsing matplotlib code but fortunately I have this part of the API quite well in mind. I guess the next step is git-cloning and compiling the code... I need to take a look at the Developper's Guide first ! Best, Pierre signature.asc Description: OpenPGP digital signature -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Bug in pyplot.hist when using histtype="step"
Hi, Le 16/04/2013 12:14, Detlef Maurel (IKP) a écrit : > there seems to be a bug in in pyplot.hist when using histtype="step". > > I am plotting the attached data to a histogram (see 1.png). In this > case I set the limits on the y axis manually. > > When I don't do this (let the hist function choose the limits), I get > the picture in the file 2.png. Only the highest bin is drawn. To be > exact, ymin=second highest value, ymax=highest value. Can you also send a minimal code that reproduces the bug. I just tried a hist(x, histtype='step') command, with x being a random vector and it works fine. best, Pierre -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Bug in pyplot.hist when using histtype="step"
Hi,
Le 16/04/2013 15:41, Detlef Maurel (IKP) a écrit :
> this works for me, too. Strange... I get the problem with the attached
> dataset using the command
>
> hist(loadtxt("data.txt"),bins=300,histtype="step")
Indeed, I could reproduce your problem using your specific dataset.
The automated selection of ylim is not working as expected, and I don't
know why !
best,
Pierre
signature.asc
Description: OpenPGP digital signature
--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Pull request
Hi, Le 20/10/2013 09:45, Todd a écrit : > I submitted a pull request #2522 [1]. It includes support for more > basic spectrum plots like magnitude and phase spectrums. These are > extremely commonly used in signal processing, acoustics, and many > other fields, but are also very important for educational usage since > pretty much anyone going through one of several engineering degrees > like electrical engineering has to learn these types of plots. I have > heard a number of colleagues complaining about the lack of these plots > in matlab. Having specific signal processing functions is indeed important. I hust have a question about "phase" vs. "angle" spectrum. From browsing quickly through you doc, it seems that the difference is just about *unwrapping the phase*. If that's indeed the case, I've two questions/remarks: 1) is the terminology "phase" vs. "angle" spectrum standardized ? I must say I've never heard of one meaning "wrapped" and the other "unwrapped". I didn't find similar terms in Matlab docs, but I didn't search that thoroughly. 2) Should there be two separate functions for these two, or just one function, with a switch argument `unwrap` ? (I guess it would be True by default) best, Pierre signature.asc Description: OpenPGP digital signature -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Pull request
Hi, Le 22/10/2013 12:31, Todd a écrit : > Currently, both axes.psd and axes.csd return the same thing as > mlab.psd and mlab.csd, namely the spectrum and frequency points. They > do NOT return the line object that was plotted. This is different > than specgram, which returns the AxesImage object that was plotted in > addition to the mlab.specgram return values. > > I think having access to the line object is important, so > axes.magnitude_spectrum, axes.angle_spectrum, and axes.phase_spectrum > do return the line object. I know this is inconsistent, but I think > it is very important and would strongly objefct to removing this. > > The question, then, is whether this would be a good opportunity to add > the line object to the returned values for axes.psd and axes.csd. > This would be an API break, but would be very easy to fix, and it may > be beneficial enough to warrant it. What does everyone think? I agree that it may be nice to have plt.psd/csd to return lines just like plt.plot for increased consistency. I guess that returning the values comes from Matlab style inspiration. Maybe breaking the API is too strong. In that case, adding a transitional keyword (for example `return_line=False`) to psd/csd may help introduce your new proposed behavior in a softer manner. What do you think ? Of course, for your new functions, there is no API breakage problem. best, Pierre signature.asc Description: OpenPGP digital signature -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Pull request
Hi, Le 21/10/2013 15:58, Todd a écrit : > On Mon, Oct 21, 2013 at 3:13 PM, Pierre Haessig > mailto:[email protected]>> wrote: > > 1) is the terminology "phase" vs. "angle" spectrum standardized ? > I must > say I've never heard of one meaning "wrapped" and the other > "unwrapped". > I didn't find similar terms in Matlab docs, but I didn't search that > thoroughly. > > > The "angle" function in numpy returns the wrapped angle, while the > "unwrap" function documentation talks about phase, so it is consistent > with the usage in numpy. Further, in signal processing, phases can > have any value, while "angle" often refers to the angle between two > lines, which must be wrapped. > > There may be some ambiguity, but I made sure to explain it in the > documentation and provide links between the two functions so people > know what they should do if they want to use the other approach. > > > 2) Should there be two separate functions for these two, or just one > function, with a switch argument `unwrap` ? (I guess it would be > True by > default) > > > I originally was going to do that, but decided against it. The > problem is with specgram. Here, I thought it would be needlessly > complicated to add an "unwrap" parameter that is only useful for one > "mode". To make it obvious to users, I wanted to keep specgram as > similar as possible to the other plot types, and that involved keeping > the parameter. > > Further, this approach is simpler to code and easier to maintain. > Having to deal with the "unwrap" parameter would have been more > difficult to program. Dealing with both an "unwrap" parameter in some > cases and a separate "mode" in others would have been even more > complicated. > > Further, _spectral_helper and specgram already have a huge number of > arguments. This way I was able to get away with just adding one new > argument rather than two. > Thanks for the feedback. I agree that your documentation does make clear the distinction between "phase" and "angle" and that it has a consistency. I just feel that this distinction does not exist "outside" ... But beyond this question of phase vs. angle, I must say I don't see that big a use case for phase/angle spectrums[*] (as opposed to magnitude which are much used). Also, in many cases, "spectrum" is synonymous with spectral density, which implies "magnitude". In the end I wonder whether the notion of phase even makes sense for a spectrogram ? That's the reason why I'm a bit skeptical with the many new "mode switches" in the spec helper, along with the new phase/angle_* functions. best, Pierre [*] On the other hand I do see a usecase of magnitude and phase for plotting transfer functions (i.e. Bode diagrams). Those are not fft based plots, so it's a different topic I guess. Bode/Nyquist/Black diagrams could be nice to have. signature.asc Description: OpenPGP digital signature -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Pull request
Hi, Le 22/10/2013 19:14, Todd a écrit : > > Thanks for the feedback. I agree that your documentation does make > clear the distinction between "phase" and "angle" and that it has > a consistency. I just feel that this distinction does not exist > "outside" ... > > But beyond this question of phase vs. angle, I must say I don't > see that big a use case for phase/angle spectrums[*] (as opposed > to magnitude which are much used). > > > I personally use phase and angle spectrums a huge amount. In signal > processing it is extremely important. It is a critical component in > acoustics. It is also used a lot to separate out signals that have > been mixed together. Knowing the phases of signals can also be very > important in certain optics applications and for radio signals and > RADAR. Changes in the phase spectrum over time (like you would get > from a phase spectrogram) is important for doppler analysis both with > optical and acoustic signals. > > Also, from an educational perspective, anyone taking a digital signal > processing course will need to produce magnitude/phase plots, probably > both with and without wrapping (since any decent digital signal > processing course will teach you about the pitfalls that occur due to > phase wrapping). So this will make matplotlib much more useful for > such courses. > > > Also, in many cases, "spectrum" is synonymous with spectral > density, which implies "magnitude". In the end I wonder whether > the notion of phase even makes sense for a spectrogram ? > > > Yes, particularly electrical engineering. But there are many other > fields where spectral density is rarely used, and where more > "ordinary" magnitude and phase plots are the norm, as I explained in > the previous paragraphs. Thanks for dealing with my ignorance. It's true that I have a biased view on these frequency functions, because I mostly deal with random signals these days. In fact I'd like to understand a bit more how phase spectorgram works. Since the signal must be cut into chunks to make the plot along time, how is the phase computations "synchronised", that is, how does it use a common time reference. (because I would imagine that otherwise the phase would make "jumps" between each window frame). Do you have a pointer for how this is solved ? (or is this problem just non-existing?). best, Pierre signature.asc Description: OpenPGP digital signature -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Pull request
Hello, Now that that PR #2522 is merged, I don't know how much futher commenting is useful, but I think there are two API details that I feel could be better : 1) API dissymetry The new pyplot/axes API is now: * 1 function *spectgram* now uses a mode argument to tune this behavior : *mode*: [ 'default' | 'psd' | 'magnitude' | 'angle' | 'phase' ] What sort of spectrum to use. Default is 'psd'. which takes the power spectral density. 'complex' returns the complex-valued frequency spectrum. 'magnitude' returns the magnitude spectrum. 'angle' returns the phase spectrum without unwrapping. 'phase' returns the phase spectrum with unwrapping. * 3 new functions *phase_spectrum, angle_spectrum, magnitude_spectrum* which complement the exising psd/csd -> I think this contributes to overcrowding axes/pyplot API. I like much better what is done with specgram so I would propose to add just one new function, for example *spectrum*(...mode='magnitude/angle/phase'). Using the same /mode /keyword as for specgram would increase the coherence of the API. 2) default NFFT value being hidden from views used to be def specgram(x, NFFT=256, Fs=2, ... now is def specgram(x, NFFT=None, Fs=None I think that NFFT is an important parameter of the spectrum computation. It should not be /hidden from the immediate view of the user/. The fact it is set to 256 is an arbitrary choice and I think it even teaches something to the user (if he doesn't know what it is). Such a fixed value is an "invitation to change it". Now with NFFT=None, it is more likely to imply "a good choice was made for you", which is not true (because there is no such good choice for all datasets). best, Pierre signature.asc Description: OpenPGP digital signature -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Pull request
Hi, Le 21/10/2013 15:58, Todd a écrit : > > 2) Should there be two separate functions for these two, or just one > function, with a switch argument `unwrap` ? (I guess it would be > True by > default) > > > I originally was going to do that, but decided against it. The > problem is with specgram. Here, I thought it would be needlessly > complicated to add an "unwrap" parameter that is only useful for one > "mode". To make it obvious to users, I wanted to keep specgram as > similar as possible to the other plot types, and that involved keeping > the parameter. > > Further, this approach is simpler to code and easier to maintain. > Having to deal with the "unwrap" parameter would have been more > difficult to program. Dealing with both an "unwrap" parameter in some > cases and a separate "mode" in others would have been even more > complicated. > > Further, _spectral_helper and specgram already have a huge number of > arguments. This way I was able to get away with just adding one new > argument rather than two. You've convinced me. I didn't have the big picture of your PR when writing my previous messages. I like the approach you took for specgram, which put "magnitude", "phase", "angle" on the same level. This indeed reduce the number of keywords. Coming back to the readability, what do you think of replacing "phase", "angle" by "unwrapped phase", "phase". Beyond readability, it also emphasizes for the reader the idea of "postprocessing" to get the unwrapped phase, i.e. a something that can have it's issue. best, Pierre signature.asc Description: OpenPGP digital signature -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Pull request
Le 25/10/2013 14:57, Pierre Haessig a écrit : > 2) default NFFT value being hidden from views > > used to be def specgram(x, NFFT=256, Fs=2, ... > now is def specgram(x, NFFT=None, Fs=None > > I think that NFFT is an important parameter of the spectrum > computation. It should not be /hidden from the immediate view of the > user/. The fact it is set to 256 is an arbitrary choice and I think it > even teaches something to the user (if he doesn't know what it is). > Such a fixed value is an "invitation to change it". Now with > NFFT=None, it is more likely to imply "a good choice was made for > you", which is not true (because there is no such good choice for all > datasets). My, mistake, this 2nd point is pointless! I got confused because I'm not familiar with the docstring convention which make signatures are hard-written in the docstring. Thanks Todd for pointing me this. best, Pierre signature.asc Description: OpenPGP digital signature -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] "Examples" section misaligned
Hi, On the main doc page http://matplotlib.org/contents.html the "Examples" section is misaligned (because it gets surrounded by a blockquote tag). I guess it relates to the special treatment it gets in content.rst (https://raw2.github.com/matplotlib/matplotlib/master/doc/contents.rst). I don't know what magic is required to put it right (I always make alignment errors myself with Sphinx...). Maybe just add or remove one space ? best, Pierre (beyond this alignment issue, I feel like this small Examples link is a bit lost. It may deserve a stronger visual presence) <> signature.asc Description: OpenPGP digital signature -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Review for new feature, shade_color
Hi David, Le 19/01/2014 18:31, David Reed a écrit : > I've implemented a new feature called shade_color which will either > brighten or darken a color based on a certain percentage. Compare URL > is here: > > https://github.com/dvreed77/matplotlib/compare/master...shade_color > A nice helper function. Ideally, I feel it would be great to have L a b color support in matplotlib, but that's far beyond this discussion. Two small remarks: * I feel it unnecessary to rename your colorsys imports: "from colorsys import rgb_to_hls as rgb2hls, hls_to_rgb as hls2rgb" -> only few characters less at the cost of a loss in readability (I mean in case someone want to google "colorsys rgb2hls"...) * instead of a "percent" argument (centered around 100), I feel like a float centered around 1.0 would be nicer. The same way rgb values are expressed in [0,1] best, Pierre <>-- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Please consider Html Help
Just as a side note, it is indeed possible to view the html docs offline by having a copy of the directory Ben mentioned, and depending on which Unix system you are using, it is possible that this doc is already packaged. I'm thinking of Debian : https://packages.debian.org/jessie/python-matplotlib-doc (python and bumpy docs are also packaged the same way and I use them a lot.) Best, Pierre On 28 juillet 2014 18:11:18 UTC, Gary Setter wrote: >Monday, July 28, >2014 08:16 AM >Dear Sirs, >Please consider >including Html Help as a third format for MatPlotLib documentation. I >was first >introduced to MatPlotLib at an online class in programming which used >Python >and MatPlotLib. I was impressed by MatPlotLib but believed that the >help system >could be better for someone like me. > >At the time, only >PDF was available, which has these problems: >- The index page >is difficult to navigate >- You cannot move >backwards and forwards as you follow hyperlinks >- Being page >oriented, text that spans pages has a distracting page break >- In some places, >text spills off the page and is not visible. > >You added Html >support online, which is was a great improvement. However it has a >fatal flaw >for someone like me: >- It is >unavailable to people without an internet connection when then they are >working. > >Of the help >documents that I used or written, (plain text, UNIX man pages, LaTex, >WinHelp >and Html Help), Html Help is by far the best system. Html help is: >- Self contained >- Available off >line >- Easy to >navigate >- Easy to use >index >- Easy to use >table of contents > >There is only one >problem that I know of concerning using Html Help for MatPlotLib >documentation, >support for it on UNIX systems. Rather than rejecting Html Help, why >not work >on supporting it on UNIX systems? > >To see what I'm >talking about, please take a look at the Html Help version of >MatPlotLib 1.3.0 >which I converted from the PDF file. It is a sourceforge project which >you can >access here: >https://sourceforge.net/projects/matplotlibashtmlhelp/?source=directory > > >What do you >think? Is Html Help a format for offline documentation that you are >willing to >support or at least accept? Please reply here or to >[email protected]. > >Gary Setter > > > > >-- >Infragistics Professional >Build stunning WinForms apps today! >Reboot your WinForms applications with our WinForms controls. >Build a bridge from your legacy apps to the future. >http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk > >-------- > >___ >Matplotlib-devel mailing list >[email protected] >https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Pierre Haessig-- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] 'LogLocator' object has no attribute 'set_params'
Hello,
I was wondering if the following behavior is a bug of LogLocator class
or just a known limitation:
(mpl 1.3.1)
Input:
plt_scale = 'log'
#plt_scale = 'linear'
fig, (ax1) = plt.subplots(1, 1)
ax1.set(yscale=plt_scale)
# works for linear scale, not for log:
ax1.axes.locator_params('y', nbins=5)
Result:
AttributeErrorTraceback (most recent
call last)
in ()
7
8 # works for linear scale, not for log:
> 9 ax1.axes.locator_params('y', nbins=5)
/home/pierre/anaconda/lib/python2.7/site-packages/matplotlib/axes.pyc in
locator_params(self, axis, tight, **kwargs)
2305 self.xaxis.get_major_locator().set_params(**kwargs)
2306 if _y:
-> 2307 self.yaxis.get_major_locator().set_params(**kwargs)
2308 self.autoscale_view(tight=tight, scalex=_x, scaley=_y)
2309
AttributeError: 'LogLocator' object has no attribute 'set_params'
What I get from the traceback is that `locator_params` method forwards
the locator attributes (in my case `nbins`) to the actual locator object
via its `set_params` method. And this method is missing from LogLocator
So my question is: shouldn't all Locator subclasses have a `set_params`
method ?
best,
Pierre
(set_params is indeed defined in
MaxNLocatorhttps://github.com/matplotlib/matplotlib/blob/master/lib/matplotlib/ticker.py#L1297)
--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] 'LogLocator' object has no attribute 'set_params'
Hi, Le 08/10/2014 15:04, Pierre Haessig a écrit : [...] AttributeError: 'LogLocator' object has no attribute 'set_params' [...] Should I put an issue on Github ? best, Pierre -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] 1.4.1rc1 feedback
Hi, Le 17/10/2014 15:38, Thomas Caswell a écrit : > I have heard no complaints about the release candidate. Unless I hear > otherwise I plan to tag and release 1.4.1 tomorrow. I just got hit by https://github.com/matplotlib/matplotlib/issues/3553 today and I didn't see a definite feedback that the problem is fixed in 1.4.1rc1. Should I try to test it ? (as a side note: is there an easy way to build a conda package for 1.4.1 ?) best, Pierre -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Matlab parula colormap
Hi, Matlab is now shipping with a new default colormap, named "parula" [1,2]. It is meant to overcome the many issues of the current default "jet". It seems that the RGB values of this new colormap are already onnline [3]. So my question is: * is it worth adding this parula in the Matplotlib colormap collection ? (I think it is) * is there any copyright issue with that ? (I have no idea how copyrightable a list of numbers is !) (I'm not speeking of changing the *default* colormap since this is already discussed here https://github.com/matplotlib/matplotlib/issues/875) best, Pierre 1 http://blogs.mathworks.com/steve/2014/10/13/a-new-colormap-for-matlab-part-1-introduction/ 2 http://blogs.mathworks.com/steve/2014/10/20/a-new-colormap-for-matlab-part-2-troubles-with-rainbows/ 3 http://www.mathworks.com/matlabcentral/answers/158575-values-fo-colormap-parula -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Matlab parula colormap
Le 21/10/2014 10:09, Eric Firing a écrit : That's the big question: what is the IP status? So Nathaniel and I asked, and the blog post author, Steve Eddins, took the time to answer : Nathaniel and Pierre—Thanks for your interest in the new parula colormap. /Parula is the end result of a creative design effort over an extended period of time. I am pleased that you find it so appealing. The colormap is, however, MathWorks intellectual property, and it would not be appropriate or acceptable to copy or re-use it in non-MathWorks plotting tools./ You might look at other sources of high-quality colormaps. I have listed some in my technical paper on rainbow colormaps, published earlier this month on mathworks.com. http://blogs.mathworks.com/steve/2014/10/20/a-new-colormap-for-matlab-part-2-troubles-with-rainbows/#comment-27702 So they claim the IP. Next question is: is this claim valid, and I'm not a lawyer to answer it. I suspect that the answer could be country specific. The only things that bother me in this IP claim, is the status of all the plots produced with this colormap. They are in a sense a /derivative/ work, am I right ? So the question becomes : does Mathworks owns IP right for all these plots ?! Pierre -- ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] logit scale for frequencies
Hi Fabio, Le 03/11/2014 11:41, Fabio Zanini a écrit : > I've been using matplotlib with great satisfaction for a few years, but > one feature I've been missing is a "logit" scale. This is essentially a > nonlinear scale that is log both towards 0+ and log towards 1-. Nice coincidence, I was also playing with this idea back in April. http://nbviewer.ipython.org/gist/pierre-haessig/7e3e6a818edeb6819708 I was actually wondering whether this could interest other people in other fields... best, Pierre > It is > useful when one has frequencies in a population (i.e. floats between 0 > and 1) and both rare events and very common ones are interesting. > > For instance, say you ask about the fraction of people with blue eyes in > various world populations, you want to spot even tiny deviations from > zero or one. > > I have coded a scale according to matplotlib's documentation and it > works well, so I was wondering whether you are interested into merging > it into the the main repository. I think it'd be useful because lots of > people have such frequency data, especially now that matplotlib is > becoming popular in the biology/social sciences research communities. > > If there is interest, I'll just start a pull request on github and try > to adapt the code to your coding style. It's already PEP8 and similia. > > Thanks. Cheers, > Fabio > > -- ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] release strategy and the color revolution
Hi, Le 16/02/2015 23:01, Eric Firing a écrit : > For a long time there has been discussion of replacing the matplotlib > default color map [...] I've started building a small interactive Lab point editor to build a sequential colormap. https://github.com/pierre-haessig/lab-colormap-creator The main interest of it is the ability to quickly check that the points stay in the sRGB gamut. There are some colormap results I just got this afternoon with it in the companion notebook (http://nbviewer.ipython.org/github/pierre-haessig/lab-colormap-creator/blob/master/test_plots.ipynb) It feels there are indeed only two routes: the Blue-Green-Yellow and the Blue-Red-Yellow one. Maybe it is possible to squeeze in a more "snaky" path, but it might look weird. best, Pierre signature.asc Description: OpenPGP digital signature -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] release strategy and the color revolution
Hi, Le 01/03/2015 23:27, jni a écrit : > As someone working with images, I think for displaying images you want a > colormap that spans as much as possible of the luminance range. The colormap > suggested by Michael Waskom would be quite perfect as-is. (recap: middle > colormap here: > http://earthobservatory.nasa.gov/blogs/elegantfigures/files/2013/08/three_perceptual_palettes_618.png) > Thanks for this feedback. Could you please elaborate a bit on this usecase. I was thinking, naively, that when plotting a grayscale image, one would simply used a gray colormap. Do you have some examples to illustrate what kind of results you are expecting ? best, Pierre -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] build problem with current doc (about colormap) ?
Hi, I'm a bit confused with the colormap doc http://matplotlib.org/users/colormaps.html I often get to this page to select my colormaps and today I see no more images of the colormaps, only text ! And when I look at the raw code https://raw.githubusercontent.com/matplotlib/matplotlib/master/doc/users/colormaps.rst I feel that some plot command are missing. Was there any error in the build process of the documentation ? best, Pierre -- ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] build problem with current doc (about colormap) ?
Le 24/07/2015 15:10, Jens Nielsen a écrit : > In the mean time you can use the development version of the docs up > here: http://matplotlib.org/devdocs/users/colormaps.html that contains > the plots. thanks ! -- Pierre -- ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
