[Fwd: [matplotlib-devel] Re: bugfix for dataLim problem (Chris Barker)]

[matplotlib-devel] Re: bugfix for dataLim problem (Chris Barker) (4.98 KB)

I guess it may be time for me to join matplotlib-devel.

Eric Firing wrote:

    > If this strategy sounds reasonable to you,

What was that strategy?

From: John Hunter <jdhunter@...4...>

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.

I suspected as much. Could we add an optional flag, so that the user could ask that the datalim to be updated?

    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)

I had figured I might need to do that, but it seems a shame to have to have a bunch of people writing that code all over the place.

Another option might be to make code like this a method of the LineCollection class, and then you could do:


A question, though. The segments are in different data units, rather that axes units. In fact they are then shifter by the "offsets", so the above code wouldn't do it. That might be a good argument for making this calculation be a method of the LineCollection class. That method could be overridden, as appropriate, for a subclass. Then the axes.add_collection code could call that method to update the datalim. For performance purposes, you could make it no-op by default.

One more thought:

I suspect that in many cases a LineCollection will hold a set of segments that are all the same size. In my example, every segment is 5 points long, so I could store it in a NX5X2 array, and make the above calculation much faster.

As for how the datalim handling works, the syntax is

Thanks for the overview.

My last question:

Is there a reason that axes.cla() doesn't reset datalim?


Christopher Barker wrote:

I guess it may be time for me to join matplotlib-devel.


I should have copied the message to you and/or left it on matplotlib-users instead of switching it to devel--but I thought I would try to keep down the traffic on users. My mistake, in this case; I'm sorry. But yes, there are advantages in joining devel, too, so I encourage it.

Eric Firing wrote:

    > If this strategy sounds reasonable to you,

What was that strategy?

The remainder of this message is what I sent to John and mpl-devel:

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.