Hi, I am happily using matplotlib-0.50e. I tried eps
> output and it worked very nicely. The problem with plot
> lines not being clipped by a manual axis in the PS
> backend also seems to have been fixed.
Good to hear ..
> I have some feedback on the default tick
> behaviour. matplotlib seems to pick a number of ticks,
> and then divides through to get the tick values. This
> results in some ugly long tick labels, making it hard to
> quickly gauge the range between two points on a graph.
> E.g. if the y range of a plot is 1.927 to 1.948, then
> matplotlib puts ticks at (1.927, 1.931, 1.935, ...,
I agree this is an important issue. It's also a difficult one. If
matplotlib just had to make a good choice for the axis limits and tick
values for a single plot, it wouldn't be too hard. What becomes
harder is to do this in the presence of interactivity. Once you allow
the user to pan and zoom, you have some other considerations. For
example, if the tick locations or the number of ticks/grids on the
axis move while you pan or zoom, that is visually disturbing. The
easiest way to optimize the tick locations is to have some flexibility
in choosing the number of ticks, but after the initial plot, this
number is set for the rest of the interactive session which makes it
So enough excuses! I agree that the current implementation is
suboptimal and will give it some more thought. Out of curiosity: do
the undersirable tick locs appear more frequently for you on an
initial plot or after interacting with the plot.
> Another slight niggle. If I set the axis range manually,
> then if a data point is exactly equal to the end of the
> axis range then it won't be plotted.
This is a consequence of the way python and Numeric do ranges, and
doesn't really have anything to do with matplotlib. eg, the Numeric
>>> from Numeric import *
>>> arange(0.0, 1.0, 0.2)
array([ 0. , 0.2, 0.4, 0.6, 0.8])
[0, 1, 2, 3, 4]
Ie, ignore the end point is the default behavior of python.