'm
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.
...
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, ..., 1.948)
I think it would be better (and closer to the plotting behaviour of
other software) if matplotlib picked ticks that were "round", even if that
means the endpoints of the axes are slightly outside the range of the
data.
So the ticks for the example above would become:
(1.925, 1.930, 1.935, ..., 1.950)
I guess this would be more complicated to implement than the current
algorithm, but it would make life easier when interpreting graphs from
matplotlib!
...
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. Making the axis range slightly longer is clumsy. This also
violates the principle of least surprise, because automatic axis ranges do
not have this behaviour. A simple way to see the problem is to compare the
output of the two plots below:
>>> xvals = arange(0.0, 1.0, 0.1)
>>> plot(xvals, [sin(x) for x in xvals])
[<matplotlib.lines.Line2D instance at 0x93fa844>]
>>> show()
>>> plot(xvals, [sin(x) for x in xvals])
[<matplotlib.lines.Line2D instance at 0x9249d2c>]
>>> autoaxis = axis()
>>> autoaxis
[0.0, 0.90000000000000002, 0.0, 0.80000000000000004]
>>> axis(autoaxis)
>>> show()
Presumably the logic for picking the datapoints to plot should use <= not
<.
Cheers,
Matthew.
>>>>> "matthew" == matthew arnison <maffew@...> writes:
matthew> Hi again, I'm having more trouble with matplotlib ticks
matthew> today. I wrote a little demo script that illustrates some
matthew> of the problems:
Hi Matthew,
Thanks for sending me these example scripts - it really helps to have
complete examples when working on these problems. I've made a few
changes to the tickval formatter. The relevant function is
matplotlib.axis.format_tickval and is pretty simple conceptually.
Try replacing the default format_tickval with this one. The d
variable gives the max-min distance of the view limits. I use
different format strings depending on the size of the distance.
def format_tickval(self, x):
'Format the number x as a string'
d = self.viewlim.interval()
if self._scale == 'log':
# only label the decades
fx = self.transData.func(x)
isdecade = abs(fx-int(fx))<1e-10
if self._ticklabelStrings is None and not isdecade: return ''
#if the number is not too big and it's an int, format it as an
#int
if abs(x)<1e4 and x==int(x): return '%d' % x
# if the value is just a fraction off an int, use the int
if abs(x-int(x))<0.0001*d: return '%d' % int(x)
# use exponential formatting for really big or small numbers,
# else use float
if d < 1e-2 : fmt = '%1.2e'
elif d < 1e-1 : fmt = '%1.2f'
elif d > 1e5 : fmt = '%1.3e'
elif d > 10 : fmt = '%1.1f'
elif d > 1 : fmt = '%1.2f'
else : fmt = '%1.3f'
s = fmt % x
#print d, fmt, x, s
# strip trailing zeros, remove '+', and handle exponential formatting
m = self._zerorgx.match(s)
if m:
s = m.group(1)
if m.group(2) is not None: s += m.group(2)
s = s.replace('+', '')
return s
And then feed it some more of your sadistic examples <wink>. If you
don't like what you see, try tweaking the formats and the distance
values until you get sensible results. Or feel free to provide more
JDH
>>>>> "matthew" == matthew arnison <maffew@...> writes:
matthew> Hi, I am happily using matplotlib-0.50e. I tried eps
matthew> output and it worked very nicely. The problem with plot
matthew> lines not being clipped by a manual axis in the PS
matthew> backend also seems to have been fixed.
Good to hear ..
matthew> I have some feedback on the default tick
matthew> behaviour. matplotlib seems to pick a number of ticks,
matthew> and then divides through to get the tick values. This
matthew> results in some ugly long tick labels, making it hard to
matthew> quickly gauge the range between two points on a graph.
matthew> E.g. if the y range of a plot is 1.927 to 1.948, then
matthew> matplotlib puts ticks at (1.927, 1.931, 1.935, ...,
matthew> 1.948)
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
harder.
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.
matthew> Another slight niggle. If I set the axis range manually,
matthew> then if a data point is exactly equal to the end of the
matthew> axis range then it won't be plotted..
JDH
On Tue, 3 Feb 2004, John Hunter wrote:
> 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.
I haven't been using the pan and zoom stuff very much, the issues I
described this week are all from initial plots. If I had been doing more
zooming then I would have noticed your very good point about jumping
ticks being distracting. It's fiddly stuff, but getting it right helps a
lot when interpreting results from plots!
>.
I guessed as much. But I think in this case the python behaviour needs to
be over-ridden. Python range logic is generally about integers, arange
stretches it, and using this [) style range for plots over-stretches the
principle beyond usefulness. There are also a couple of contradictions in
matplotlib's behaviour:
* the axis and tick ranges are inclusive, but the data point range is
exclusive of the higher end point only
* the auto data range (axis()) is inclusive, but setting it manually is
exclusive of the higher end point only
Some of this may be alleviated by chooing better tick points. But I think
it would also be helpful to make whichever behaviour is chosen more
consistent.
Cheers,
Matthew.
>>>>> 
I agree to receive quotes, newsletters and other information from sourceforge.net and its partners regarding IT services and products. I understand that I can withdraw my consent at any time. Please refer to our Privacy Policy or Contact Us for more details