Re: [Matplotlib-users] 'bug' in labelling axes for data with small variation?

[Darren D. <dd...@co...>]

Hi John,

On Monday 28 February 2005 12:11 pm, John Hunter wrote:
> >>>>> "Darren" == Darren Dale <dd...@co...> writes:
>
>     Darren> oops, I just noticed a bug, the first script I posted wont
>     Darren> run. This updated script worked for me with a fresh 0.72.1
>     Darren> 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.

-- 

Darren