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 <ted.drain@...179...> 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 ted.drain@...179...
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 (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
···
at this over the weekend. The problems may well be in code I wrote
Ted
At 08:05 AM 10/4/2007, John Hunter wrote:
On 10/4/07, Ted Drain <ted.drain@...179...> 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 ted.drain@...179...
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.
The fundamental object containing the relevant information is the Interval instance. Instead of having a proliferation of flags and functions at the python level, I am thinking about adding a few very simple methods to the Interval object. Maybe
swap() to reverse the order of the bounds
increasing() to yield True if val2 >= val1
Your xbound and set_xbound functionality could also be done this way, as Interval methods.
Mike, how would this fit in with your reworking of transforms?
Eric
···
- 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
Sounds fine - I don't think we care too much about the "how". I talked w/ James and as far as we know, the aspect code is the only area that's having a problem right now (James is going to submit a patch to that to handle x1>x2 today).
Since we do these plots all the time, we've just seen a number of problems come up as new features get added and people forget that x1 > x2 is a possibility. We were just trying to think of ways of "future proofing" the new system by making it more obvious that this case does show up. It might be able to be handled by some extra comments in the existing code so that people who are looking for examples would get a reminder that this case has to be handled.
Ted
···
At 02:11 PM 10/4/2007, Eric Firing wrote:
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.
The fundamental object containing the relevant information is the
Interval instance. Instead of having a proliferation of flags and
functions at the python level, I am thinking about adding a few very
simple methods to the Interval object. Maybe
swap() to reverse the order of the bounds
increasing() to yield True if val2 >= val1
Your xbound and set_xbound functionality could also be done this way, as
Interval methods.
Mike, how would this fit in with your reworking of transforms?
Eric
>
> - 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
-------------------------------------------------------------------------
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
matplotlib-devel List Signup and Options
Ted Drain Jet Propulsion Laboratory ted.drain@...179...
All,
Based on what everyone has been saying I have submitted an update to axes.py that reverts the get/set xlim/ylim methods to their
original state with their original interface. I have removed the state flag that keeps track of inverted axes.
Currently I have added the method get/set xbound/ybound that handles getting and setting of the upper and lower bounds and will
handle inverted axes. I have made a couple of changes within the Axes class to now call the xbound/ybound methods so that the
handling of inversion is automatic. This at least solves the immediate problems and provides some level of protection by giving a
"safe" method to call when writing methods that deal with axes limits.
Let me know what you think.
--James Evans
···
-----Original Message-----
From: Ted Drain [mailto:ted.drain@…179…]
Sent: Thursday, October 04, 2007 2:34 PM
To: Eric Firing
Cc: James Evans; John Hunter; matplotlib development list
Subject: Re: [matplotlib-devel] API additions
Sounds fine - I don't think we care too much about the "how". I
talked w/ James and as far as we know, the aspect code is the only
area that's having a problem right now (James is going to submit a
patch to that to handle x1>x2 today).
Since we do these plots all the time, we've just seen a number of
problems come up as new features get added and people forget that
x1 > x2 is a possibility. We were just trying to think of ways of
"future proofing" the new system by making it more obvious that this
case does show up. It might be able to be handled by some extra
comments in the existing code so that people who are looking for
examples would get a reminder that this case has to be handled.
Ted
At 02:11 PM 10/4/2007, Eric Firing wrote:
>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.
>
>The fundamental object containing the relevant information is the
>Interval instance. Instead of having a proliferation of flags and
>functions at the python level, I am thinking about adding a few very
>simple methods to the Interval object. Maybe
>
>swap() to reverse the order of the bounds
>increasing() to yield True if val2 >= val1
>
>Your xbound and set_xbound functionality could also be done this way, as
>Interval methods.
>
>
>Mike, how would this fit in with your reworking of transforms?
>
>Eric
>
> >
> > - 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
>
>-------------------------------------------------------------------------
>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
>matplotlib-devel List Signup and Options
Ted Drain Jet Propulsion Laboratory ted.drain@...179...
Eric Firing wrote:
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.
The fundamental object containing the relevant information is the Interval instance. Instead of having a proliferation of flags and functions at the python level, I am thinking about adding a few very simple methods to the Interval object. Maybe
swap() to reverse the order of the bounds
increasing() to yield True if val2 >= val1
Your xbound and set_xbound functionality could also be done this way, as Interval methods.
Mike, how would this fit in with your reworking of transforms?
I don't anticipate any problems with that approach.
Cheers,
Mike
···
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA