set offset threshold to 4

[story645]

Using the code from #7084, ax.set_xlim(1990, 2020) yields

Tried this for some other values and it seems broken for everything except values that follow the form %d*10^n so 10, 20, 300, etc.

Eta this also yields weirdness: ax.plot(range(1990,2020), range(1990,2020))

[efiring]

Please put in exactly the code snippets that yield the two example images, and elaborate on what it is that looks wrong. I can't tell from what you have here so far.

[story645]

Sorry about that:

fig, ax = plt.subplots()
ax.plot(range(1990,2020), range(1990,2020))

and it's not a range bug, 'cause the following yields the same figure:

fig, ax = plt.subplots()
ax.plot(list(range(1990,2020)), list(range(1990, 2020)))

This is version 2.0.0b3.post2245+g4f559a9

The issue is that the xticks and xlims aren't mapping to the datavalues, which are between 1990 and 2020. It should look something like this (which I got by manually setting the labels):

[efiring]

I don't see anything wrong, except in your manually-adjusted example. The Formatter is using an offset of 2000, so the tick labels are from 2000 - 10 to 2000 + 20. In many cases like this one doesn't actually want an offset. It can be turned off with rcParams['axes.formatter.useoffset'] = False, or ax.ticklabel_format(useOffset) = False.

[LindyBalboa]

As efiring stated, this is relatively standard behavior, albeit rather counterintuitive. I don't know the source code well enough without looking; could there be room for improvement in the default behavior of deciding when to turn on offsetting?

[story645]

I fully fully support changing the default 'cause that offset seems so incredibly arbitrary and like you said, way counterintuitive. I think it looks at base 10 for defaults somehow, since something like ax.plot(range(200,400)) yields ticks between 200 and 400.

Also, @efiring how come calling ax.set_xlim((1990,2020)) doesn't overwrite the offset?

[efiring]

On 2016/09/13 9:15 AM, hannah wrote:

Also, @efiring https://github.com/efiring how come calling
ax.set_xlim((1990,2020)) doesn't overwrite the offset?

Setting the view limits is independent of the Formatter; the offset
comes from the Formatter.

[story645]

@efiring I just realized that half my issue is that I didn't read the notation correctly. Why is the default to pitch it to scientific notation for 4 numbers? (What is the cut off?)

[efiring]

On 2016/09/13 9:27 AM, hannah wrote:

Why is the default to pitch it to scientific notation for 4 numbers?
(What is the cut off?)

A non-zero offset is used if it saves at least 2 significant digits in
the tick labels, according to the comment in
ScalarFormatter._compute_offset(). There is no API for changing that
threshold when offsets are used.

It looks like the offset is always being forced into scientific
notation. This does seem like a misfeature. Maybe the offset should be
formatted using the same powerlimits criterion as is used for the tick
labels.

[story645]

Maybe the offset should be formatted using the same powerlimits criterion as is used for the tick labels.

I'm 👍 on that.

[tacaswell]

@anntzer was doing some work on this, but I do not remember if it got merged (sorry).

There is also #6086 which is still waiting for a review (sorry again @VincentVandalon)

[anntzer]

The choice of the offset value (not its formatting) was changed by myself in #5785.

The formatting of the offset value is addressed by #5804 (so that the offset displays enough significant digits to match the ticks themselves, and so that the cursor values are also displayed in a useful manner), but this PR also lumps in a large amount of breaking API changes to the formatter class (which I still think seriously need some API cleanup). TBH I have lost interest in making this backwards compatible, I think it's too difficult to be worth it and now simply disable any use of offsets from my matplotlibrc. (I can update my PR if we agree to break backcompat but will probably not add a complete backcompat layer.)

[VincentVandalon]

No problem @tacaswell we are all doing this on a voluntary basis (I think).

In #6086 i tried to implement the desired behavior with as few as possible changes/refactoring. When you reviewed the pull request, you (rightly so) commented that it was not clear from the code if the desired behavior was achieved. The code was not transparent to begin with, and it did not improve with my changes.

I started refactoring to make the code clear, but that overlapped with #5804 and #5785. So #6068 ended up in limbo.

If the ticker.py code has undergone refactoring in the mean time, we could close #6086

[efiring]

@story645 do you see a way out of the impasse here? If not, I think this needs to be booted down the road to v2.1.

[anntzer]

There's a relevant discussion of the formatting of the offset value in the first three messages of #5804, FWIW.

[tacaswell]

Lets bump the threshold up to 3 or 4 digits to make years behave better.

There are enough questions on SO specifically related to this issue with years (and I have seen it go wrong for my co workers) is worth fixing.

[anntzer]

Ah, I didn't think about that use case. Seems reasonable to me.

[story645]

@efiring I'm for whatever solution is easy and more user friendly. I support @tacaswell's suggestion of making a hard minimum of 4 digits since years are very common use case, so much so that it's the usecase that triggered my opening this issue.

[tacaswell]

https://github.com/matplotlib/matplotlib/blob/v2.x/lib/matplotlib/ticker.py#L693 is the expression that needs to change, someone just needs to understand it enough to make the threshold 4 instead of 2....

[efiring]

In the line below that, I would try changing to this:

 if abs_max // 10 ** oom >= 1000

[dopplershift]

Fixed by #7365.