Re: [Matplotlib-users] weird behaviour in x axis

[Eric F. <ef...@ha...>]

On 09/15/2010 08:25 AM, Benjamin Root wrote:
> On Wed, Sep 15, 2010 at 12:37 PM, Eric Firing <ef...@ha...
> <mailto:ef...@ha...>> wrote:
>
>     On 09/15/2010 04:55 AM, Benjamin Root wrote:
>      > On Tue, Sep 14, 2010 at 11:12 AM, Jan Skowron
>     <jan...@gm... <mailto:jan...@gm...>
>      > <mailto:jan...@gm... <mailto:jan...@gm...>>> wrote:
>      >
>      >     Hi,
>      >     apropos this offset discussion.
>      >     matplotlib makes offsets not aligned to the full tens or some
>     other
>      >     easy number with small amount of non-zero digits in front?
>      >
>      >     For example having ticks:
>      >     4917, 4918, 4919, 4920, 4921, 4922
>      >
>      >     it will now display:
>      >     1, 2, 3, 4, 5, 6   with offset 4916  (of even +4.916e3)
>      >
>      >     this makes reading values on the axis really really hard as
>     every time
>      >     one have to perform not obvious summations with all digits of
>     length.
>      >     It would be beneficial to have as a default behaviour some
>      >     optimization of offsets to have it as some basic number for easy
>      >     reading instead of current behaviour that tries to minimize
>     the number
>      >     of digits in the ticks and starts from a low number like 1 or
>     0.05 or
>      >     so.
>      >     In our case the best display would be:
>      >
>      >     17, 18, 19, 20, 21, 22  with offset 4900
>      >
>      >     So we minimize the number of non-zero digits in offset and not a
>      >     number of digits in tick labels.
>      >
>      >     Another more ridiculous example (from life) are ticks with
>     values:
>      >
>      >     4916.25, 4916.30, 4916.35, 4916.40, 4916.45
>      >
>      >     are displayed as:
>      >
>      >     0.05, 0.10, 0.15, 0.20, 0.25   with offset +4.9162e3
>      >
>      >     and with good algorithm should be displayed as:
>      >
>      >     0.25, 0.30, 0.35, 0.40, 0.45  with offset 4962  (nottice that not
>      >     +4.962e3 as it usually displays now)
>      >
>      >     and if we would cross the boundary between 4962 and 4963 than
>     ticks
>      >     should look like:
>      >     2.80, 2.85, 2.90, 2.95, 3.00, 3.05   with offset 4960
>      >
>      >
>      >     In my opinion the current behaviour of offsets really hampers the
>      >     usability of these at all, and probably 90% of users spent
>     some time
>      >     on nothing but trying to figure out how to turn this thing
>     off (thanks
>      >     for sending this solutions here).
>      >
>      >     So this is message to signal or show the need for fixing this
>      >     algorithm. For now I think that the title of this post: "weird
>      >     behaviour in x axis", really summarize current offset algorithm
>      >     nicely.
>      >
>      >
>      >     Thanks for your comments,
>      >     Jan
>      >
>      >
>      > I like that idea as it is certainly more intuitive.  Essentially, it
>      > would find the most significant bits that are common to all ticks and
>      > use that for the offset.
>      >
>      > Does anybody know where the current code is?  I would be willing
>     to take
>      > a look at it today and see what I can do.
>
>     In ticker.ScalarFormatter._setOffset (or something like that).  Be
>     careful not to make it too complicated; maybe it can even be made
>     simpler.  I think that as a first shot, something like adding +3 (or
>     maybe it would be -3) to a couple lines of code might be a step in the
>     right direction--and maybe adequate.
>
>     Thank you.
>
>     Eric
>
>
> Here is what I came up with.  In ticker.ScalarFormatter._setOffset, I
> set a variable called "common_oom" to the same value as 'range_oom'.
> This order of magnitude should be the smallest possible magnitude where
> there all the significant digits are the same.  Then, I do:
>
> tickdiff = np.sum(np.diff(np.trunc(locs * 10**-common_oom)))
> while tickdiff >= 1.0 :
>      common_oom += 1.0
>      tickdiff = np.sum(np.diff(np.trunc(locs * 10**-common_oom)))
>
> Essentially, I find increment common_oom until the differences in the
> rounded versions of the locs become significant.  Then, I use common_oom
> instead of range_oom in calculating the offset.
>
> I suspect it could be done better, and I am not certain that there are
> no edge cases regarding the use of trunc.
>
> Thoughts, concerns?
>
> Ben Root


Ben,

I can't look closely right now, so here are only very quick off-the-cuff 
comments:

1) for testing, try to come up with a good selection of cases: negative, 
positive, very close to, but less than 1, very close to, but greater 
than, 1, etc.

2) I'm concerned that the sort of approach you are describing may be 
slow.  The process of generating a plot, and redrawing it upon 
zoom/pan/resize, is already badly slowed down by the ticks and tick 
labels, and I would hate to see this pesky offset make the situation worse.

3) Isn't there a good-enough solution involving a single math calculation?

4) Although I have complained about the ever-expanding set of rcParams, 
*maybe* the useOffset default should be added.  Rather than a boolean, 
it could be a threshold.

Eric

>
>
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
>
>
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users