matplotlib-devel Mailing List for matplotlib

John,
Thanks very much. I had missed the fact that the ignore argument can 
take three values, not two, so I will take that into account. As usual, 
I might not finish the changes until the weekend.
Eric
John Hunter wrote:
>>>>>>"Eric" == Eric Firing <ef...@ha...> writes:
> 
> 
> Eric> If this strategy sounds reasonable to you, I can go ahead
> Eric> and implement it.
> 
> This looks fine; FYI I'll include a post I started in response to your
> earlier email but failed to push send; this provides a little context
> 
> To: Eric Firing <ef...@ha...>
> Cc: Christopher Barker <Chr...@no...>,
> 	 mat...@li...
> Subject: Re: [Matplotlib-users] Apparent bug in Data limits with LineCollections
> From: John Hunter <jdh...@ac...>
> 
> Eric> I would like to make a genuine bugfix, but I do not yet
> Eric> understand all this well enough to do so right now. Maybe
> Eric> John will chime in with a good solution.
> 
> Just a comment for now. If you look at ax.add_collection, it does not
> update the datalim. This is by design but it should be documented.
> The reason I didn't add it was collecitons were meant to be fast
> (they've failed a little bit on that front but they aren't
> mind-numbingly slow) and so I left it to the user to set the datalim
> manually since this is potentially expensive and the user often knows
> the lim for one reason or another. See the finance.py module for
> several instances on how to set the data lim with collections. Eg,
> 
> 
> minx, maxx = (0, len(rangeSegments))
> miny = min([low for low in lows if low !=-1])
> maxy = max([high for high in highs if high != -1])
> 
> corners = (minx, miny), (maxx, maxy)
> ax.update_datalim(corners)
> ax.autoscale_view()
> 
> 
> As for how the datalim handling works, the syntax is
> 
> self.dataLim.update(xys, ignore)
> 
> Note this is different than the ax.update_datalim method, which calls
> it. datalim is a bbox which has an ignore state variable (boolean).
> 
> The ignore argument to update datalim can take on three values
> 
> 0: do not ignore the current limits and update them with the xys
> 1: ignore the current datalim limits and override with xys
> -1: use the datalim ignore state to determine the ignore settings
> 
> This seems a bit complex but arose from experience. Basically a lot
> of different objects want to add their data to the datalim. In most
> use cases, you want the first object to add data to ignore the current
> limits (which are just default values) and subsequent objects to add
> to the datalim taking into account the previous limits. The default
> behavior of datalim is to set ignore to 1, and after the first call
> with -1 set ignore to 0. Thus everyone can call with -1 and have the
> desired default behavior . I hope you are all confused now.
> 
> One can manually set the ignore state var with
> 
> datalim.ignore(1)
> 
> Cheers,
> JDH
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

>>>>> "Eric" == Eric Firing <ef...@ha...> writes:
 Eric> If this strategy sounds reasonable to you, I can go ahead
 Eric> and implement it.
This looks fine; FYI I'll include a post I started in response to your
earlier email but failed to push send; this provides a little context
To: Eric Firing <ef...@ha...>
Cc: Christopher Barker <Chr...@no...>,
	 mat...@li...
Subject: Re: [Matplotlib-users] Apparent bug in Data limits with LineCollections
From: John Hunter <jdh...@ac...>
 Eric> I would like to make a genuine bugfix, but I do not yet
 Eric> understand all this well enough to do so right now. Maybe
 Eric> John will chime in with a good solution.
Just a comment for now. If you look at ax.add_collection, it does not
update the datalim. This is by design but it should be documented.
The reason I didn't add it was collecitons were meant to be fast
(they've failed a little bit on that front but they aren't
mind-numbingly slow) and so I left it to the user to set the datalim
manually since this is potentially expensive and the user often knows
the lim for one reason or another. See the finance.py module for
several instances on how to set the data lim with collections. Eg,
 minx, maxx = (0, len(rangeSegments))
 miny = min([low for low in lows if low !=-1])
 maxy = max([high for high in highs if high != -1])
 corners = (minx, miny), (maxx, maxy)
 ax.update_datalim(corners)
 ax.autoscale_view()
As for how the datalim handling works, the syntax is
 self.dataLim.update(xys, ignore)
Note this is different than the ax.update_datalim method, which calls
it. datalim is a bbox which has an ignore state variable (boolean).
The ignore argument to update datalim can take on three values
 0: do not ignore the current limits and update them with the xys
 1: ignore the current datalim limits and override with xys
 -1: use the datalim ignore state to determine the ignore settings
This seems a bit complex but arose from experience. Basically a lot
of different objects want to add their data to the datalim. In most
use cases, you want the first object to add data to ignore the current
limits (which are just default values) and subsequent objects to add
to the datalim taking into account the previous limits. The default
behavior of datalim is to set ignore to 1, and after the first call
with -1 set ignore to 0. Thus everyone can call with -1 and have the
desired default behavior . I hope you are all confused now.
One can manually set the ignore state var with
 datalim.ignore(1)
Cheers,
JDH

John,
Chris Barker found a problem: plotting in an axes, then calling 
axes.cla, then adding a collection, then calling axes.plot, results in 
the original plot's dataLim being used as the starting point for the 
update. I think the problems are:
1) axes.add_line updates the data limits, but add_collection does not;
2) axes.has_data is simply looking to see whether a line or collection 
has been added, but is using that as an indication of whether the data 
limits have been set; this is invalid because add_collection does not 
set the limits.
I suggest two changes to address the problem:
1) Use a flag instead of the have_data() method to keep track of whether 
data limit updating needs to start from scratch. Then axes.cla() can 
set the flag, and the update_datalim* functions can clear it.
2) Add an optional flag to add_collection, telling it to call the 
collection's get_verts method and use the result to update the data 
limits. This would make it easier to use collections in user-level 
code, without imposing any performance penalty for functions like 
contour that handle the data limit updating in a more efficient way.
If this strategy sounds reasonable to you, I can go ahead and implement it.
Eric

On 2006年1月31日, Robert Kern wrote:
> Andrew Straw wrote:
>
> > Now, mostly jokingly, how 'bout a MPL-like VTK interface?? Somehow the
> > idea of "borrowing" the MPL interface has playful allure, no? ;)
>
> *Which* MPL interface? The OO API or the pylab API? Does Prabhu's work with tvtk
> strike any chords? E.g.
>
> http://svn.enthought.com/svn/enthought/trunk/src/lib/enthought/tvtk/tools/mlab.py
Also have a look at the screenshot at
 http://www.enthought.com/enthought/wiki/TVTK
(and http://www.enthought.com/enthought/wiki/MayaVi)
IMHO: before starting to think about how to
incorporate 3D in MPL one should spend some time with the
excellent tvtk and MayaVi2 (which is in very good shape already).
In case someone wants to try out tvtk and MayaVi2,
 http://www.scipy.org/ArndBaecker/MayaVi2
might be helpful.
Best, Arnd