IndexFormatter doesn't round to the nearest integer

[Wlodarski]

Bug report

Bug summary

Because IndexFormatter.__call__ doesn't round to the nearest integer but truncates/round up to the next integer, x ticks labels are duplicated when user pans plot to left, displaying values below minimum.

Code for reproduction

import matplotlib.pyplot as plt
from matplotlib.ticker import IndexFormatter

x = [1, 2, 3, 4, 5]
y = [1, 3, 5, 6, 0]
x_labels = ['under', 'a', 'b', 'c', 'd', 'e', 'over']

fig, ax = plt.subplots()
print(x[1])
ax.xaxis.set_major_formatter(IndexFormatter(x_labels))
ax.plot(x, y, '-o')
plt.show()

Actual outcome

class IndexFormatter(Formatter):

[...]

    def __call__(self, x, pos=None):
        """
        Return the format for tick value `x` at position pos.

        The position is ignored and the value is rounded to the nearest
        integer ******** NOT TRUE *********, which is used to look up the label.
        """
        i = int(x + 0.5)
        if i < 0 or i >= self.n:
            return ''
        else:
            return self.labels[i]

IndexFormatter returns self.labels[0] for x = -1 instead of an empty string

Expected outcome

Proposed solution to correct [IndexFormatter] (https://matplotlib.org/3.1.3/_modules/matplotlib/ticker.html#IndexFormatter)

def __call__(self, x, pos=None):
        """
        Return the format for tick value `x` at position pos.

        The position is ignored and the value is rounded to the nearest
        integer, which is used to look up the label.
        """
        i = int(round(x))
        if i < 0 or i >= self.n:
            return ''
        else:
            return self.labels[i]

Matplotlib version

• Matplotlib version: 3.1.3

[jklymak]

I think you are correct that this is a bug, and we should use round rather than int(i+0.5). Would you care to make a PR?

[tacaswell]

The issue is that int always goes towards 0 (as it is truncation not rounding).

[ImportanceOfBeingErnest]

IndexFormatter is deprecated in #16170. Before trying to fix anything here, maybe one can identify if it is worth keeping or not?

[Wlodarski]

IndexFormatter could have literally been fixed in less than 5 minutes. It's a tiny, tiny, extremely evident correction : a int(x + 0.5) replaced by int(round(x)). Now you are discussing deprecating the entire formatter along some others, which implies:

• No backward compatibility. Beginners like me who are using this easy to understand function will lose it because users familiar with all the intricacies of matplotlib, those who wrote the examples, prefer a more complex way of achieving the same effect.
  • According the precepts of semantic versioning, deprecation is major version change since every single user of this function will have to replace it with another one. You are now talking of v4.xx.yy, not v3.3.0
    • You will have to update the documentation and teach all users like me that use IndexFormatter how to replace it with another function.

I am amazed how cascading and tedious is your process. No wonder why there are more than 1200 issues pending resolution. At the end of who knows how many days, maybe even weeks if not months, of deliberations, I won't be able to use IndexFormatter anymore, a function I was modestly trying to help fix... so I could continue use it without that annoying, tiny, tiny little bug. I was extremely naive. I regret submitting this easy fix. I learned my lesson. Life is too short to wasting it caught up in this procedural wrangles.

[ImportanceOfBeingErnest]

Welcome to reality. ;-)
On a more serious note, though: We really appreaciate you taking the time to file a bug report here and to fix the problem. It is however not unusual that what seems like an easy fix will unroll to a major problem (programmers often call it a "rabbit hole"). There are two main points here:

• The fix that you proposed lets the test suite fail. The tests are there to keep matplotlib stable and make sure we won't break it with seemingly obvious changes such as this one here. Of course there is always the possibility that the tests themselves are wrong as well. So any help in finding out if that test is simply incorrect, would be appreciated.
• Totally independent of this issue at hand, IndexFormatter was deprecated in Deprecate old and little used formatters. #16170 already a month ago, scheduled for version 3.3.0. Such deprecations are common also to do in minor versions (see point 7 of the semantic versioning guide you link to). Note that deprecation means that the feature stays in the API, but releases a warning of it being removed in the future. The reason for the deprecation of IndexFormatter was that none of the developpers did know of a common use case for this formatter. If, however, you do have a good usecase, it is helpful to us to learn about it, instead of reading a rant about it going away. The more convincing this usecase is, the more likely the decision to remove it would be taken back.

[anntzer]

Some more points:

• Matplotlib does not follow semver in a strict sense: we will remove deprecated APIs in minor releases. FWIW Python doesn't strictly follow semver either: there has been APIs removed in minor Python releases too.

• I deprecated IndexFormatter in Deprecate old and little used formatters. #16170 because @efiring suggested it in Deprecate old and little used formatters. #16170 (comment) (pushing the blame to someone else :-)) but in fact looking at it again it is super brittle (so I don't feel too bad about the deprecation); for example it will "break" if the ticker decides to also put ticks at half-integers:

from matplotlib import pyplot as plt
from matplotlib.ticker import IndexFormatter

x = [1, 2, 3, 4, 5]
y = [1, 3, 5, 6, 0]
x_labels = ['under', 'a', 'b', 'c', 'd', 'e', 'over']

fig, ax = plt.subplots()
ax.xaxis.set_major_formatter(IndexFormatter(x_labels))
ax.plot(x, y, '-o')

plt.show()

The correct fix is to use FuncFormatter, for which you can literally arrange to use whatever logic you want; for example:

from matplotlib import pyplot as plt
from matplotlib.ticker import FuncFormatter

x = [1, 2, 3, 4, 5]
y = [1, 3, 5, 6, 0]
x_labels = ['under', 'a', 'b', 'c', 'd', 'e', 'over']

fig, ax = plt.subplots()
ax.xaxis.set_major_formatter(FuncFormatter(
    lambda x, _: dict(zip(range(len(x_labels)), x_labels)).get(x, "")))
ax.plot(x, y, '-o')

plt.show()

[Wlodarski]

If the inner workings of FuncFormatter are superior to those of IndexFormatter, why don't you update IndexFormatter(x_labels) to become synonymous with FuncFormatter(lambda x, _: dict(zip(range(len(x_labels)), x_labels)).get(x, "")) ?

This way you would conserve backward compatibility.

[Wlodarski]

• The fix that you proposed lets the test suite fail.

It fails because the test requires the bug to be present. It expects the label for index -1 to display the label for index 0 instead of being empty as it should be.

[jklymak]

As you can see, everything we include (or keep) in the library comes at a maintenance cost. In this case the value of the formatter was deemed to not be worth the cost in maintaining it. However, as said above, if there is a good use case for it, we can reconsider.

I hope you will have patience with us. This library is used by many thousand people, so there are indeed procedures to follow. Part of getting a "simple fix" into the code base is proving it doesn't break anything.

[anntzer]

Any code needs to be maintained, documented, tested, generates bug reports and questions from the user that need to be fielded, etc.; meanwhile, developer time is finite. Hence it makes sense to remove little-used functionality, especially when reasonably simple alternatives exist.
The fact that two basic bugs (yours and mine) in IndexFormatter had never been reported before in more than 10 years(!) (the implementation dates back to 2009), even though they should be readily triggered (I found "my" bug completely accidentally while trying to understand yours...), strongly suggests to me that IndexFormatter is very rarely used and therefore does not warrant being part of Matplotlib itself.

[ImportanceOfBeingErnest]

It obviously doesn't make sense to use an IndexFormatter without setting the ticks somehow (that is true for FixedFormatter as well).
Probably IndexFormatter was only ever meant to be used in conjunction with an IndexLocator. An example could be

import numpy as np
import matplotlib.pyplot as plt
from matplotlib.ticker import IndexLocator, IndexFormatter

n = 2**np.arange(0, 10)
y = np.linspace(3, 7, 10)

fig, ax = plt.subplots()
ax.plot(y, "o-.")

ax.xaxis.set_major_locator(IndexLocator(1,0))
ax.xaxis.set_major_formatter(IndexFormatter(n))

plt.show()