Hi John,
> oops, I just noticed a bug, the first script I posted wont
> run. This updated script worked for me with a fresh 0.72.1
> installation. Sorry about the error.
Hi Darren, this is very nice work. Sorry for the delay in getting
back but I've been tied up for the last week or so.
Thanks.
One comment I have is that I think we might choose the default offset
label differently. Visually
1e-5+12e-10
10
8
6
4
2
is hard to read because the two 10s line up when you should be
comparing the 12 with the 10. I wonder if this is better
1e-5+1e-10*12
10
8
6
4
2
Still an eyeful but at least the significant part of the ticks are
co-registered. What so you think?
I originally did it the way you suggest, and changed it to make it more
compact....
[...]
Another comment is that these labels take up a lot of space, and will
pretty much break any default subplot which doesn't leave enough room
for them.
Although I like the idea of using one of the tick labels
itself to handle the offset formatting, I wonder if we might be better
off using a special axis.set_offset command, so that for example, the
yaxis could place the offset above the ticks and thus take up less
horizontal space. Just a thought.
Yeah, my intention this weekend was just to get the information into the plot,
so it was clear what I was trying to accomplish. I would really like to get
the scientific notation out of that last ticklabel, and put it above the axis
as you suggest.
Can we do proper exponential formatting, like with the logscale? I know there
are scholarly journals out there that will complain about using the 'e'
notation.
Also, I'm inclined to make this the default formatter --
I am glad to hear that.
do you see
any problems with this? What troubles did you run into when you tried
to add these changes to the ScalarFormatter class and then rolled them
back because of clashes with derived classes?
I originally hijacked ScalarFormatter, then noticed that the LogFormatter*
classes inherited the pprint_val method from ScalarFormatter. That is really
not a problem, we could just copy the old ScalarFormatter.pprint_val method
to LogFormatter, then it will override the new ScalarFormatter method.
Questions/problems before making this the default formatter:
1) Will the gui windows still report the appropriate coordinates? I noticed in
the script I posted that the y coordinate was only reported as an integer.
2) in the script, near the bottom, try changing
figure(2,figsize=(6,6))
ax1 = axes([.225,.74,.75,.2])
ax1.plot(arange(11)*1e-4)
to read
figure(2,figsize=(6,6))
ax1 = axes([.225,.74,.75,.2])
ax1.plot(arange(11)*1e-15) #<--- changed order of magnitude
The resulting plot does not render the last ticklabel. I checked my script,
and the string is generated by pprint_val, but it is not rendered. I dont
understand why. Several orders of magnitude wont render. For example, 1e-107
doesnt render, nor does 1e-60, but 1e-61 does. I didnt see a problem with
scientific notation containing positive exponents. Maybe this odd bug will
not be reproducible once the information is rendered in its own space, I dont
know.
3) (Almost not worth mentioning) I could run the same script 10 times and once
it would yield an unsubscriptable object error message. When this happened,
self.locs was set to None, and pprint_val was choking on this line:
if x==self.locs[-1] and (self.orderOfMagnitude or self.offset):
This problem will not exist when we stop rendering the offset/sci.not. in the
ticklabel. I hesitate to even bring this nonexistent problem up, but if
somebody notices this behavior, they should know it will not exist in the
final product.
···
On Monday 28 February 2005 12:11 pm, John Hunter wrote:
--
Darren