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