matplotlib-devel Mailing List for matplotlib

Eric Firing wrote:
>> Which is what we have now, yes?
> 
> Yes, except for the "notes in docstrings and/or elsewhere".
Yes. Notes are always good.
>>> 2) Do it only if the transforms and offsets are such that it does not 
>>> depend on the viewLim; otherwise raise an exception.
>>>
>>> 3) Do a partial job of it also in the case where transData is the 
>>> transform for either of verts of offsets, and simply ignore the 
>>> effect of whichever of these is not using transData.
>>
>> I'd be happy if dataLim was calculated from just the offsets. Is that 
>> option 3? adding option 2 would be fine too, but wouldn't help me any.
> 
> Option 3 includes and extends option 2, and does cover your use case. 
> What it does *not* do is ensure that the result of autoscaling is that 
> you can see everything you are trying to plot. To some extent this is a 
> problem even now; a line marker that happens to land in a corner (such 
> as the origin) doesn't show up very well, because only 1/4 of it is in 
> the plotted domain.
Exactly, and I think that's fine.
> To get around this problem, one could put in yet another rc param that 
> would ensure a margin is added to the viewLim as calculated from the 
> dataLim. So, for example, plot([0,1], [0,1]) would have axis limits 
> from -0.2 to 1.2 (or something like that) instead of 0 to 1, and a big 
> red marker at each point would still be fully within the plotted domain.
I think an rc param is a bad idea. there really is no way to do this in 
the general case, as you have NO idea how big people's markers, etc are 
going to be in data units. I also think it's no big deal to have part of 
a marker chopped off.
> A strategy question, of course, is how much of this sort of 
> sophistication should be built in to the automatic plotting, versus 
> simply available, as is the case now, with manual commands. This 
> concern with excessive complexity is the reason I am not enthusiastic 
> about option 3 (or 2);
I agree. I still vote for my option: just calculate the dataLim from the 
offsets. That's it. It's easy, and it covers the basics.
> getting the right result manually is pretty easy 
> once one knows how to do it. And, chances are, for a final product one 
> would end up using the manual methods anyway so as to have full control.
True, but it would be nice if the defaults gave you dataLims that were 
at least in the ballpark for your data, rather than arbitrary. It'd be 
easier for people to see the plot and think: "I need to tweak the axis 
limits"
Thanks for you work on this.
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
 		
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

Chris,
Christopher Barker wrote:
> Eric Firing wrote:
> 
>> I fixed the bug in which ax.cla() was not actually causing the 
>> existing dataLim to be ignored. It did not require an extra flag; it 
>> only required taking advantage of the ignore=-1 option of 
>> dataLim.update. The fixed version is in CVS.
> 
> 
> Wonderful. Thanks.
> 
>> Because collections have verts and offsets, which may have separate 
>> transformations, it is not possible, in general, to convert the 
>> plotted points to data units (which is what we would need) until the 
>> viewLim is set; but that defeats the purpose, which is to update the 
>> dataLim so that it can be used to calculate viewLim.
> 
> 
> 
>> 1) Don't even try. Simply require it to be done manually. Make notes 
>> in docstrings and/or elsewhere.
> 
> 
> Which is what we have now, yes?
Yes, except for the "notes in docstrings and/or elsewhere".
> 
>> 2) Do it only if the transforms and offsets are such that it does not 
>> depend on the viewLim; otherwise raise an exception.
>>
>> 3) Do a partial job of it also in the case where transData is the 
>> transform for either of verts of offsets, and simply ignore the effect 
>> of whichever of these is not using transData.
> 
> 
> I'd be happy if dataLim was calculated from just the offsets. Is that 
> option 3? adding option 2 would be fine too, but wouldn't help me any.
Option 3 includes and extends option 2, and does cover your use case. 
What it does *not* do is ensure that the result of autoscaling is that 
you can see everything you are trying to plot. To some extent this is a 
problem even now; a line marker that happens to land in a corner (such 
as the origin) doesn't show up very well, because only 1/4 of it is in 
the plotted domain.
To get around this problem, one could put in yet another rc param that 
would ensure a margin is added to the viewLim as calculated from the 
dataLim. So, for example, plot([0,1], [0,1]) would have axis limits 
from -0.2 to 1.2 (or something like that) instead of 0 to 1, and a big 
red marker at each point would still be fully within the plotted domain.
A strategy question, of course, is how much of this sort of 
sophistication should be built in to the automatic plotting, versus 
simply available, as is the case now, with manual commands. This 
concern with excessive complexity is the reason I am not enthusiastic 
about option 3 (or 2); getting the right result manually is pretty easy 
once one knows how to do it. And, chances are, for a final product one 
would end up using the manual methods anyway so as to have full control.
> 
> That's because in my case, I'm using a LineCollection to create 
> something kind of like a marker, so the offsets really do define the 
> dataLim. Perhaps that's not universal enough to include, however. It 
> would be easy.
> 
> -Chris
> 
> 
Eric

Eric Firing wrote:
> I fixed the bug in which ax.cla() was not actually causing the existing 
> dataLim to be ignored. It did not require an extra flag; it only 
> required taking advantage of the ignore=-1 option of dataLim.update. The 
> fixed version is in CVS.
Wonderful. Thanks.
> Because collections have verts and offsets, which may have separate 
> transformations, it is not possible, in general, to convert the plotted 
> points to data units (which is what we would need) until the viewLim is 
> set; but that defeats the purpose, which is to update the dataLim so 
> that it can be used to calculate viewLim.
> 1) Don't even try. Simply require it to be done manually. Make notes 
> in docstrings and/or elsewhere.
Which is what we have now, yes?
> 2) Do it only if the transforms and offsets are such that it does not 
> depend on the viewLim; otherwise raise an exception.
> 
> 3) Do a partial job of it also in the case where transData is the 
> transform for either of verts of offsets, and simply ignore the effect 
> of whichever of these is not using transData.
I'd be happy if dataLim was calculated from just the offsets. Is that 
option 3? adding option 2 would be fine too, but wouldn't help me any.
That's because in my case, I'm using a LineCollection to create 
something kind of like a marker, so the offsets really do define the 
dataLim. Perhaps that's not universal enough to include, however. It 
would be easy.
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
 		
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

John and Chris,
In reference to my suggestion:
> 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.
I fixed the bug in which ax.cla() was not actually causing the existing 
dataLim to be ignored. It did not require an extra flag; it only 
required taking advantage of the ignore=-1 option of dataLim.update. The 
fixed version is in CVS.
I was not able to implement the second part of the strategy, however, 
which was to put an optional flag into axes.add_collection telling it to 
update the dataLim. The reason is quite fundamental, and I think it 
reveals some additional bugs.
Because collections have verts and offsets, which may have separate 
transformations, it is not possible, in general, to convert the plotted 
points to data units (which is what we would need) until the viewLim is 
set; but that defeats the purpose, which is to update the dataLim so 
that it can be used to calculate viewLim.
The related bug is that the collection get_verts() methods all simply 
add the offset to the verts and return the sums, which are quite 
meaningless unless transform and transOffset are identical; and even if 
they are identical, the units of get_verts() will depend on the transform.
Options for adding some automatic dataLim updating option to 
add_collection include:
1) Don't even try. Simply require it to be done manually. Make notes 
in docstrings and/or elsewhere.
2) Do it only if the transforms and offsets are such that it does not 
depend on the viewLim; otherwise raise an exception.
3) Do a partial job of it also in the case where transData is the 
transform for either of verts of offsets, and simply ignore the effect 
of whichever of these is not using transData.
I am leaning towards (1); it is not clear to me that the effort involved 
in the other options would be justified by the convenience gained.
Regarding the bug in get_verts(), the options include:
1) Add bug warnings to the docstrings.
2) Raise an exception if it is not possible to unambiguously determine 
the plotted points in data coordinates.
3) Remove the functions entirely on the grounds that they are 
dangerously misleading.
Most likely I have missed something important in all this.
Eric