Bug summary

In some edge cases, colorbars end up with 0 ticks.

Code for reproduction

import numpy as np
import matplotlib.pyplot as plt
from matplotlib.colors import SymLogNorm

prng = np.random.RandomState(0)
data = prng.randint(0, 2, size=100).reshape(10, 10)

fig, ax = plt.subplots()
im = ax.imshow(data, norm=SymLogNorm(linthresh=1))
fig.colorbar(im)

sfile = "/tmp/symlog_no_ticks.png"
print(f"saving to {sfile}")
fig.savefig(sfile)

Actual outcome

Expected outcome

Additional information

I find this can be solved with the following patch

diff --git a/lib/matplotlib/ticker.py b/lib/matplotlib/ticker.py
index a29343029f..17ab354dce 100644
--- a/lib/matplotlib/ticker.py
+++ b/lib/matplotlib/ticker.py
@@ -2503,9 +2503,9 @@ class SymmetricalLogLocator(Locator):
             return [vmin, vmax]

         # Lower log range is present
-        has_a = (vmin < -linthresh)
+        has_a = (vmin <= -linthresh)
         # Upper log range is present
-        has_c = (vmax > linthresh)
+        has_c = (vmax >= linthresh)

         # Check if linear range is present
         has_b = (has_a and vmax > -linthresh) or (has_c and vmin < linthresh)

I don't anticipate this patch to have undesirable side effects. Would it be acceptable as a fix ?

For context, this is part of an effort to upstream some subtly different rules regarding symlog normed colorbars that are implemented in yt. A rather obvious observation is that there is no actual need for the example here to use SymLogNorm, but yt auto-selects a norm depending on the value range to be plotted and is "log by default", so symlog is the default scale used for data that isn't strictly positive, as in the simple example above.

Operating system

No response

Matplotlib Version

3.7.1

Matplotlib Backend

MacOSX

Python version

Python 3.11.2

Jupyter version

No response

Installation

pip