be factored out. Resizing and repositioning are more
> generally useful; for example, they are used in the colorbar
> function. I would like to take a look at this broader
> question before finalizing the axes aspect ratio handling.
Eric, what is the status of the aspect code w/ respect to the presence
of colorbars, or more generally, multiple axes?
JDH
John Hunter wrote:
"Eric" == Eric Firing <efiring@...229...> writes:
> be factored out. Resizing and repositioning are more
> generally useful; for example, they are used in the colorbar
> function. I would like to take a look at this broader
> question before finalizing the axes aspect ratio handling.Eric, what is the status of the aspect code w/ respect to the presence
of colorbars, or more generally, multiple axes?
John,
Broken! I assumed it would be OK, but now I see that is not the case. I know why, and I can fix it easily on my next pass. But this does highlight the question of more complex positioning situations.
Eric
Eric Firing wrote:
John Hunter wrote:
Eric, what is the status of the aspect code w/ respect to the presence
of colorbars, or more generally, multiple axes?John,
Broken! I assumed it would be OK, but now I see that is not the case.
I know why, and I can fix it easily on my next pass. But this does
highlight the question of more complex positioning situations.
Hi Eric,
I don't know if you're aware of this, but Axes.set_position() seems to
have broken in the last day or two, also.
Cheers!
Andrew
Andrew Straw wrote:
Eric Firing wrote:
John Hunter wrote:
Eric, what is the status of the aspect code w/ respect to the presence
of colorbars, or more generally, multiple axes?John,
Broken! I assumed it would be OK, but now I see that is not the case.
I know why, and I can fix it easily on my next pass. But this does
highlight the question of more complex positioning situations.Hi Eric,
I don't know if you're aware of this, but Axes.set_position() seems to
have broken in the last day or two, also.Cheers!
Andrew
Andrew,
Thanks--it makes sense that it would (and it is the reason for the colorbar problem), but I am embarrassed that I didn't spot it myself before committing changes.
Eric
Andrew,
I did not get as far as I would have liked this evening, but Axes.set_position() is now working again in svn, as is the colorbar.
I'm sorry for the disruption. This turned out to be more complicated than I thought.
To be continued...
Eric
Andrew Straw wrote:
Eric Firing wrote:
John Hunter wrote:
Eric, what is the status of the aspect code w/ respect to the presence
of colorbars, or more generally, multiple axes?John,
Broken! I assumed it would be OK, but now I see that is not the case.
I know why, and I can fix it easily on my next pass. But this does
highlight the question of more complex positioning situations.Hi Eric,
I don't know if you're aware of this, but Axes.set_position() seems to
have broken in the last day or two, also.Cheers!
Andrew
All,
I think that aspect ratio handling in svn is now usable; I have checked simple uses of the pylab axis() function, together with interactive resizing, pan, and zoom of images, simple plots, and ganged plots. I have tried to keep the pylab interface pretty much unchanged for now; but if people have ideas as to how it could be improved, I would be happy to consider them. Personally, I find some of the options unintuitive. Maybe we could find better names than 'equal' and 'scaled', for example. Even with the docstrings, I have a hard time keeping track of which is supposed to do what.
Jeff, I haven't forgotten your patch to add anchoring options, but I still want to think about it in a slightly larger context; one way or another it will be done soon.
Eric
Hi,
I think it would be nice if pylab "semantics" were kept close to matlab.
Maybe for instance axis('scaled') could be renamed to axis('image'), and
use similar wording as mathworks documentation in the docstrings?
Helge
On 3/22/06, Eric Firing <efiring@...229...> wrote:
unintuitive. Maybe we could find better names than 'equal' and
'scaled', for example. Even with the docstrings, I have a hard time
keeping track of which is supposed to do what.
Helge Avlesen wrote:
unintuitive. Maybe we could find better names than 'equal' and
'scaled', for example. Even with the docstrings, I have a hard time
keeping track of which is supposed to do what.Hi,
I think it would be nice if pylab "semantics" were kept close to matlab.
Maybe for instance axis('scaled') could be renamed to axis('image'), and
use similar wording as mathworks documentation in the docstrings?http://www.mathworks.com/access/helpdesk/help/techdoc/ref/axis.html
Helge
Helge,
I understand the sentiment, but I don't always agree with it; while I don't want to do things differently from Matlab just for the sake of being different (except insofar is it may be necessary to avoid violating copyright), neither do I want to slavishly follow Matlab. Pylab/matplotlib can and should be better than Matlab. (And is in many respects.)
In the case of Matlab's axis command, the Matlab documentation makes my head spin, and the whole command strikes me as too complicated for anyone's good. I don't think every possible capability should go into the pylab interface; past a certain point, it is better to simply call axis methods, etc.
For now, I have added an axis('image') mode, which is not quite the same as 'scaled', and I have tried to improve the descriptions of the options. Please try out the various axis modes, and see if you think both the behavior and the descriptions make sense.
Eric
On 3/22/06, Eric Firing <efiring@...229...> wrote:
Hi,
from what I see, the axis command now works really well, excellent work!
the descriptions also look fine - I am not a native English speaker/writer
so I fail to see how to make them more precise without beeing much more verbose.
thanks,
Helge
On 3/31/06, Eric Firing <efiring@...229...> wrote:
For now, I have added an axis('image') mode, which is not quite the same
as 'scaled', and I have tried to improve the descriptions of the
options. Please try out the various axis modes, and see if you think
both the behavior and the descriptions make sense.