matplotlib-devel Mailing List for matplotlib (Page 4)

bu...@gm..., on 2011-04-04 05:15,  wrote:
> Hi,
> 
> Does matplotlib keep track of the last object added to the plot axes
> or its nature (line, text, collection, patch, etc.) ?
> If not, would it be feasible to implement something like this in
> matplotlib ?
> 
> This could be useful for interactive plotting, as it would allow a
> simple undo feature based on commands such as del ax.lines[-1].

Hi there,

I think this functionality already exists exactly as you
describe. ax.plot appends new lines to ax.lines, ax.scatter
appends new collection to ax.collections (via the
ax.add_collection method).

try this, and you'll see the cyan line is removed:

plt.plot([1,2,3],'r')
plt.plot([1,2,1],'c')
ax = plt.gca()
del(ax.lines[-1])
plt.draw()

-- 
Paul Ivanov
314 address only used for lists,  off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7 

Hi,

Does matplotlib keep track of the last object added to the plot axes or its  
nature (line, text, collection, patch, etc.) ?
If not, would it be feasible to implement something like this in  
matplotlib ?

This could be useful for interactive plotting, as it would allow a simple  
undo feature based on commands such as del ax.lines[-1].

On 04/02/2011 02:48 PM, bdb112 wrote:
>
> Cannot pick markers '+','x' or others with zero area in plots made by
> pyplot.scatter
>
> The example below
> http://old.nabble.com/file/p31305303/picker_example_scatter.py
> picker_example_scatter.py  is from the matplotlib docs, but modified to use
> scatter instead of plot (which works fine).
> http://matplotlib.sourceforge.net/users/event_handling.html#picking-exercise
>
> run picker_example_scatter.py
> <will not respond to any picks>
> edit code replace 'x' with 'o'
> <Works, but only if click is inside marker - i.e. ignores picker value.>
>
> See also
> http://old.nabble.com/Can't-pick-on-various-scatter-markers-tp19140977p19140977.html
> which describes the same problem.
>
> Ububtu 10.04 LTS
> matplotlib 0.99.1.1
> Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56)
>
>

See https://github.com/matplotlib/matplotlib/pull/72 for a possible 
solution.

Eric

On 04/02/2011 02:48 PM, bdb112 wrote:
>
> Cannot pick markers '+','x' or others with zero area in plots made by
> pyplot.scatter
>
> The example below
> http://old.nabble.com/file/p31305303/picker_example_scatter.py
> picker_example_scatter.py  is from the matplotlib docs, but modified to use
> scatter instead of plot (which works fine).
> http://matplotlib.sourceforge.net/users/event_handling.html#picking-exercise
>
> run picker_example_scatter.py
> <will not respond to any picks>
> edit code replace 'x' with 'o'
> <Works, but only if click is inside marker - i.e. ignores picker value.>
>
> See also
> http://old.nabble.com/Can't-pick-on-various-scatter-markers-tp19140977p19140977.html
> which describes the same problem.

The bug is verified in 1.0.x.  I have looked around, but haven't figured 
it out yet.

Eric

>
> Ububtu 10.04 LTS
> matplotlib 0.99.1.1
> Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56)
>
>

Cannot pick markers '+','x' or others with zero area in plots made by
pyplot.scatter

The example below 
http://old.nabble.com/file/p31305303/picker_example_scatter.py
picker_example_scatter.py  is from the matplotlib docs, but modified to use
scatter instead of plot (which works fine).
http://matplotlib.sourceforge.net/users/event_handling.html#picking-exercise

run picker_example_scatter.py
<will not respond to any picks>
edit code replace 'x' with 'o'
<Works, but only if click is inside marker - i.e. ignores picker value.>

See also
http://old.nabble.com/Can't-pick-on-various-scatter-markers-tp19140977p19140977.html
which describes the same problem.

Ububtu 10.04 LTS
matplotlib 0.99.1.1 
Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56) 


-- 
View this message in context: http://old.nabble.com/picker-inpoerative-on-scatter-markers-x%2C-%2B-%28those-with-zero-area%29-tp31305303p31305303.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

Hello dev people,

I had an app where I needed the radar chart (aka Kiviat diagrams) source
code out of matplotlib. Turns out the example source code is very limited
the way it is currently written. Not good.

I re-wrote parts of the source code to make it much more flexible and easier
to include in an app. For example, if run in stand-alone mode, the user can
specify upto 25 different radar charts in one window. Titles and labels are
much more general as well. The legend can have multiple columns, etc.

If anyone is interested, I will be happy to send you my source code, hoping
you might consider replacing the current version in the docs with the one
I'll send.

Just reply and I'll send the code. You can decide from there whether to use
it to replace current version.

I did not want to attach the code if no one is interested.

Daniel Barnette

On Fri, Apr 1, 2011 at 4:46 PM, Eric Firing <ef...@ha...> wrote:

> On 04/01/2011 10:47 AM, Benjamin Root wrote:
> > Just had a thought and I am curious about what others think.
> >
> > Now that we have agreed that calling a plotting function with empty data
> > should always be considered valid, should it also automatically advance
> > the colorcycle?  I think it should.
>
> I agree.  Fortunately, that is the present behavior, at least with this
> simple test:
>
> plot([1,2,3])
> plot([], [])
> plot([3,2,1])
>
> Eric
>
>
Ok, good to know that someone else agrees.  Enforcing this would probably
best be done through tests that explicitly tests for this in a variety of
different kinds of plots.  Looks like yet another thing to add to my todo
list when I finish my current "distraction".

Ben Root

On 04/01/2011 10:47 AM, Benjamin Root wrote:
> Just had a thought and I am curious about what others think.
>
> Now that we have agreed that calling a plotting function with empty data
> should always be considered valid, should it also automatically advance
> the colorcycle?  I think it should.

I agree.  Fortunately, that is the present behavior, at least with this 
simple test:

plot([1,2,3])
plot([], [])
plot([3,2,1])

Eric


>
> Here is a use-case: consider a user who is plotting temperature in three
> regions over time in one subplot, and surface pressure over time for
> those same three regions.  Let's say the thermometer in second region
> started reporting only NaNs.  If empty data did not advance the color
> cycle, then the line for the temperature plot of the third region will
> be same as the line for the pressure plot for the second region, leading
> to mis-leading interpretation that the thermometer in the third region
> was the one that broke.
>
> This is a really simple example, but I can see this being harder to
> ensure for more complicated plots the depend on the automatic color cycling.
>
> Ben Root
>
>
>
> ------------------------------------------------------------------------------
> Create and publish websites with WebMatrix
> Use the most popular FREE web apps or write code yourself;
> WebMatrix provides all the features you need to develop and
> publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
>
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Just had a thought and I am curious about what others think.

Now that we have agreed that calling a plotting function with empty data
should always be considered valid, should it also automatically advance the
colorcycle?  I think it should.

Here is a use-case: consider a user who is plotting temperature in three
regions over time in one subplot, and surface pressure over time for those
same three regions.  Let's say the thermometer in second region started
reporting only NaNs.  If empty data did not advance the color cycle, then
the line for the temperature plot of the third region will be same as the
line for the pressure plot for the second region, leading to mis-leading
interpretation that the thermometer in the third region was the one that
broke.

This is a really simple example, but I can see this being harder to ensure
for more complicated plots the depend on the automatic color cycling.

Ben Root

On 04/01/2011 05:01 AM, Michael Droettboom wrote:
> I'm going through and removing old and deprecated information from the
> source tree.
>
> I'm noticing that there are two makefiles for OS-X, one at ./make.osx
> and one in release/osx/Makefile.  The former was updated in Sep 2010,
> the latter in Mar 2010.  Our installation (installing.rst) recommends
> using the one in release/osx.
>
> Also, the README.txt at the root of the source tree seems to be related
> to the Mac OS-X binary installer.  We should probably move this
> elsewhere and put generic information in this file.
>
> I'm not actually trying to build on OS-X, I haven't in many years, and I
> haven't really followed any of the mailing list threads on this topic --
> so maybe that makes me a good example of a user coming to this blind and
> saying: "hey, there's two ways to do it, which is the right one?"
>
> Mike
>

I think they can and should be consolidated, or at least their core 
functionality should be consolidated.  release/osx/Makefile was for 
official releases, so it includes an "upload" target; ./make.osx was for 
users to use in building from the repo, so it has gotten most of the 
updating attention.

If the developers with the most OS-X expertise (and that does not 
include me) could pool that expertise and come up with a more solid 
framework and documentation for building under OS-X, it might relieve a 
lot of the frustration that has been expressed on the mailing lists.

Eric

I'm going through and removing old and deprecated information from the 
source tree.

I'm noticing that there are two makefiles for OS-X, one at ./make.osx 
and one in release/osx/Makefile.  The former was updated in Sep 2010, 
the latter in Mar 2010.  Our installation (installing.rst) recommends 
using the one in release/osx.

Also, the README.txt at the root of the source tree seems to be related 
to the Mac OS-X binary installer.  We should probably move this 
elsewhere and put generic information in this file.

I'm not actually trying to build on OS-X, I haven't in many years, and I 
haven't really followed any of the mailing list threads on this topic -- 
so maybe that makes me a good example of a user coming to this blind and 
saying: "hey, there's two ways to do it, which is the right one?"

Mike

-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA