matplotlib-devel Mailing List for matplotlib

John Hunter wrote:
> def add_collection(self, coll, autolim=False) 
> 
> ...or something to that effect.

> If offsets are defined, one could, as Chris suggested, just use the
> offsets to compute the limits.  This would be "close enough" to get
> most of the data into the axes, and the user could then tweak to their
> heart's content.

  it would give something useful to most users.My vote would be to make 
this the default, rather than nothing. It wouldn't be any more expensive 
than for the other plotting commands, and  Having struggled with this, I 
know it would have taken me a while to find an autolim keyword, even if 
it had been there. Of course, It would have been a lot simpler if cla() 
had worked right, which Eric has fixed.

Perhaps I'm too focused on my use case, however. Any way you do it is 
quite usable.

-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,

OK, I will put in a kwarg and support as many cases as reasonably 
possible.  I was part-way there this weekend, but pulled back after 
running into the problem.

Eric

John Hunter wrote:
>>>>>>"Eric" == Eric Firing <ef...@ha...> writes:
> 
>     Eric> Because collections have verts and offsets, which may have
>     Eric> separate transformations, it is not possible, in general, to
>     Eric> convert the plotted points to data units (which is what we
>     Eric> would need) until the viewLim is set; but that defeats the
>     Eric> purpose, which is to update the dataLim so that it can be
>     Eric> used to calculate viewLim.
> 
> Hey Eric, thanks for laying out the problem so clearly.  The only way
> for different transforms (eg the vert and offset transform) to
> coordinate is to first convert to the common space (display/pixels)
> and then invert back to their respective coordinates.  And this isn't
> possible if the viewlim aren't set, as you note.  It's been a while
> since I mucked around with the get_verts method in the collections
> module, but I had the feeling that I had left it incomplete and your
> post clarifies that.
> 
>     Eric> The related bug is that the collection get_verts() methods
>     Eric> all simply add the offset to the verts and return the sums,
>     Eric> which are quite meaningless unless transform and transOffset
>     Eric> are identical; and even if they are identical, the units of
>     Eric> get_verts() will depend on the transform.
> 
>     Eric> Options for adding some automatic dataLim updating option to
>     Eric> add_collection include:
> 
>     Eric> 1) Don't even try.  Simply require it to be done manually.
>     Eric> Make notes in docstrings and/or elsewhere.
> 
>     Eric> 3) Do a partial job of it also in the case where transData
> 
> I think we can support auto-limits for collections reasonably
> coherently.  I'm inclined to leave the default behavior unchanged for
> efficiency (no auto-limits) but to support a kwarg that does
> auto-scaling
> 
> def add_collection(self, coll, autolim=False) 
> 
> ...or something to that effect.
> 
> If autolim is True, even given the problems you pointed out above, we
> can support it in many common use cases.
> 
> There are two cases with no ambiguity that we could definitely support
> 
>  * if no offsets are specified just use the verts
> 
>  * if offsets are specified and the vert and offset transforms are
>    the same it is straightforward to calculate the limits
> 
> If offsets are defined, one could, as Chris suggested, just use the
> offsets to compute the limits.  This would be "close enough" to get
> most of the data into the axes, and the user could then tweak to their
> heart's content.  In this case we might want to warn.
> 
> JDH
> 
> 
> 
> 

>>>>> "Eric" == Eric Firing <ef...@ha...> writes:
    Eric> Because collections have verts and offsets, which may have
    Eric> separate transformations, it is not possible, in general, to
    Eric> convert the plotted points to data units (which is what we
    Eric> would need) until the viewLim is set; but that defeats the
    Eric> purpose, which is to update the dataLim so that it can be
    Eric> used to calculate viewLim.

Hey Eric, thanks for laying out the problem so clearly.  The only way
for different transforms (eg the vert and offset transform) to
coordinate is to first convert to the common space (display/pixels)
and then invert back to their respective coordinates.  And this isn't
possible if the viewlim aren't set, as you note.  It's been a while
since I mucked around with the get_verts method in the collections
module, but I had the feeling that I had left it incomplete and your
post clarifies that.

    Eric> The related bug is that the collection get_verts() methods
    Eric> all simply add the offset to the verts and return the sums,
    Eric> which are quite meaningless unless transform and transOffset
    Eric> are identical; and even if they are identical, the units of
    Eric> get_verts() will depend on the transform.

    Eric> Options for adding some automatic dataLim updating option to
    Eric> add_collection include:

    Eric> 1) Don't even try.  Simply require it to be done manually.
    Eric> Make notes in docstrings and/or elsewhere.

    Eric> 3) Do a partial job of it also in the case where transData

I think we can support auto-limits for collections reasonably
coherently.  I'm inclined to leave the default behavior unchanged for
efficiency (no auto-limits) but to support a kwarg that does
auto-scaling

def add_collection(self, coll, autolim=False) 

...or something to that effect.

If autolim is True, even given the problems you pointed out above, we
can support it in many common use cases.

There are two cases with no ambiguity that we could definitely support

 * if no offsets are specified just use the verts

 * if offsets are specified and the vert and offset transforms are
   the same it is straightforward to calculate the limits

If offsets are defined, one could, as Chris suggested, just use the
offsets to compute the limits.  This would be "close enough" to get
most of the data into the axes, and the user could then tweak to their
heart's content.  In this case we might want to warn.

JDH