Ted Drain wrote: > John, > I think keeping the existing API is probably a good idea. What about > something like this: > > - Keep xlim and viewlim as they are. > > - Add xbound() (or maybe a better name) that returns (x1,x2) where x1 < x2. > > - Add set_xbound(x1,x2) that takes x1<x2, checks the inversion flag, and > then calls set_xlim() w/ the args in the proper order. > > - Change the existing axis code that messes w/ bounds (autoscale, aspect > ratio, etc) to use xbound. These algorithm can then be written so > they're independent of the order of x1 and x2 and they won't flip the > bounds back if the inversion flag is set.
I'm not sure whether additional flags and functions are even needed to clean up the problems, but they might make it easier. I can take a look at this over the weekend. The problems may well be in code I wrote (like aspect ratio handling). I would be inclined to try to clean up the naming--if what is really meant in the code is "left", not "xmin", then that is what it should be called. I don't think fixing that will be too big a deal. Ted, if you can supply some simple examples that illustrate the bugs, that would be most helpful. (Apologies if you have already done so and I missed it.) Changing the API is still on the table, but I would rather see first whether we can come up with a clean solution using the existing API. Eric > > Ted > > > At 08:05 AM 10/4/2007, John Hunter wrote: >> On 10/4/07, Ted Drain <[EMAIL PROTECTED]> wrote: >> > John, >> > I think that the problem isn't doing the inversion - it's keeping >> > it. Calling set_xlim() to invert is fine - but it never seems to >> > stay that way. There is a lot of code (resizing, autoscaling, >> > labelling, etc) that has a tendency to flip the axis back to it's >> > 'un-inverted' state. The idea behind having a flag on the axis >> > itself is so that other code can check that easily to see what the >> > state of the axis is. >> > >> >> > We do a lot of plots that require an inverted axis and we've had tons >> > of problems keeping the axis inverted (which is where the idea for >> > the flag came from). It seems like people forget that this is >> > possible and add code that assumes that xmin < xmax which then ends >> > up flipping the axis back to it's "normal" state (this happens in the >> > aspect ratio code for example). >> >> I see -- I missed James' original email describing the motivation for >> this flag because it was in spam quarantine (I think he posted from a >> non-subscribed address). As I was just clearing out the spam, I >> noticed it, and now better understand what you are trying to do. It >> seems like a reasonable use case. >> >> If I am reading this right, there is no way to support this kind of >> behavior *and* not break existing code. If we want to go this route, >> I don't mind breaking existing code as long as we do it cleanly. Eg, >> I think xmin and xmax should always be in order (calls to >> set_xlim(xmax, xmin) would raise a helpful exception like "call >> ax.invert_xaxis instead") and we would need to make sure that the >> viewlim are still reversed per Michael's request. And we would need a >> clean way to toggle back. In this view: >> >> ax.xaxis_invert() # turns inversion on and off >> ax.get_xlim() # always returns xmin, xmax >> ax.set_xlim(blah) # requires xmin<xmax >> >> and viewlim behave as before. >> >> This would also satisfy Eric's point that xmin and xmax are poorly named. >> >> The one thing I find potentially confusing about Jame's original post >> is that set_xlim can be out of order (xmin>xmax) while get_xlim always >> returns ordered values. >> >> For the record, I almost never use inverted axes so we should hear >> more from those who do.... >> >> JDH > > Ted Drain Jet Propulsion Laboratory [EMAIL PROTECTED] > ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
