On Wed, Sep 15, 2010 at 12:37 PM, Eric Firing ~~<efiring@hawaii.ed=
u> wrote:~~

Here is what I came up with.=A0 In ticker.ScalarF= ormatter._setOffset, I set a variable called "common_oom" to the = same value as 'range_oom'.=A0 This order of magnitude should be the= smallest possible magnitude where there all the significant digits are the= same.=A0 Then, I do:

tickdiff =3D np.sum(np.diff(np.trunc(locs * 10**-common_oom)))

while= tickdiff >=3D 1.0 :

=A0=A0=A0 common_oom +=3D 1.0

=A0=A0=A0 tickd= iff =3D np.sum(np.diff(np.trunc(locs * 10**-common_oom)))

Essentiall= y, I find increment common_oom until the differences in the rounded version= s of the locs become significant.=A0 Then, I use common_oom instead of rang= e_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

--002215046dcf835c530490507490--On 09/15/2010 04:55 AM, Benjamin Root wrote:

> On Tue, Sep 14, 2010 at 11:12 AM, Jan Skowron <jan.skowron@gmail.com

In ticker.ScalarFormatter._setOffset (or something like that). = =A0Be> <mailto:jan.skowron@gmail.com>> wrote:

>

> =A0 =A0 Hi,

> =A0 =A0 apropos this offset discussion.

> =A0 =A0 matplotlib makes offsets not aligned to the full tens or some = other

> =A0 =A0 easy number with small amount of non-zero digits in front?

>

> =A0 =A0 For example having ticks:

> =A0 =A0 4917, 4918, 4919, 4920, 4921, 4922

>

> =A0 =A0 it will now display:

> =A0 =A0 1, 2, 3, 4, 5, 6 =A0 with offset 4916 =A0(of even +4.916e3)

>

> =A0 =A0 this makes reading values on the axis really really hard as ev= ery time

> =A0 =A0 one have to perform not obvious summations with all digits of = length.

> =A0 =A0 It would be beneficial to have as a default behaviour some

> =A0 =A0 optimization of offsets to have it as some basic number for ea= sy

> =A0 =A0 reading instead of current behaviour that tries to minimize th= e number

> =A0 =A0 of digits in the ticks and starts from a low number like 1 or = 0.05 or

> =A0 =A0 so.

> =A0 =A0 In our case the best display would be:

>

> =A0 =A0 17, 18, 19, 20, 21, 22 =A0with offset 4900

>

> =A0 =A0 So we minimize the number of non-zero digits in offset and not= a

> =A0 =A0 number of digits in tick labels.

>

> =A0 =A0 Another more ridiculous example (from life) are ticks with val= ues:

>

> =A0 =A0 4916.25, 4916.30, 4916.35, 4916.40, 4916.45

>

> =A0 =A0 are displayed as:

>

> =A0 =A0 0.05, 0.10, 0.15, 0.20, 0.25 =A0 with offset +4.9162e3

>

> =A0 =A0 and with good algorithm should be displayed as:

>

> =A0 =A0 0.25, 0.30, 0.35, 0.40, 0.45 =A0with offset 4962 =A0(nottice t= hat not

> =A0 =A0 +4.962e3 as it usually displays now)

>

> =A0 =A0 and if we would cross the boundary between 4962 and 4963 than = ticks

> =A0 =A0 should look like:

> =A0 =A0 2.80, 2.85, 2.90, 2.95, 3.00, 3.05 =A0 with offset 4960

>

>

> =A0 =A0 In my opinion the current behaviour of offsets really hampers = the

> =A0 =A0 usability of these at all, and probably 90% of users spent som= e time

> =A0 =A0 on nothing but trying to figure out how to turn this thing off= (thanks

> =A0 =A0 for sending this solutions here).

>

> =A0 =A0 So this is message to signal or show the need for fixing this<= br> > =A0 =A0 algorithm. For now I think that the title of this post: "= weird

> =A0 =A0 behaviour in x axis", really summarize current offset alg= orithm

> =A0 =A0 nicely.

>

>

> =A0 =A0 Thanks for your comments,

> =A0 =A0 Jan

>

>

> I like that idea as it is certainly more intuitive. =A0Essentially, it=

> would find the most significant bits that are common to all ticks and<= br> > use that for the offset.

>

> Does anybody know where the current code is? =A0I would be willing to = take

> a look at it today and see what I can do.

careful not to make it too complicated; maybe it can even be made

simpler. =A0I 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.=A0 In ticker.ScalarF= ormatter._setOffset, I set a variable called "common_oom" to the = same value as 'range_oom'.=A0 This order of magnitude should be the= smallest possible magnitude where there all the significant digits are the= same.=A0 Then, I do:

tickdiff =3D np.sum(np.diff(np.trunc(locs * 10**-common_oom)))

while= tickdiff >=3D 1.0 :

=A0=A0=A0 common_oom +=3D 1.0

=A0=A0=A0 tickd= iff =3D np.sum(np.diff(np.trunc(locs * 10**-common_oom)))

Essentiall= y, I find increment common_oom until the differences in the rounded version= s of the locs become significant.=A0 Then, I use common_oom instead of rang= e_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