I played a bit with bisect about this issue, using this test script. The bisect results are:

f8b1a9af53e1ad47adcd6215e54e4f0b8259ee39 is the first bad commit
commit f8b1a9af53e1ad47adcd6215e54e4f0b8259ee39
Author: Antony Lee <anntzer.lee@gmail.com>
Date:   Tue Sep 20 00:28:58 2016 -0700

    Cleanup of style.<>Transforms; catch nan warning.

and indeed, with commit f8b1a9a the test script produces:

while it seems quite OK with the previous commit (684861b)

Attn: @anntzer

Thanks for the bisect, that really simplies the process.

I apologize, I forgot to mention one more thing in my previous post. Something may still be wrong, even with the commit 684861b , but I am not convinced it is the same issue : if some of the data values are “too small”, some weird artefacts appear in log scale. For example, this is the image produced when eps = 0.12 (eps being the minimal data value) in the test script (previously eps = 0.15):

Something I do not understand between 684861b and f8b1a9a as it does not really seem related to the latter commit changes is the fact that ax.get_ylim() after ax.set_ylim(a, b) returns (as expected) (a, b) but nothing changes in the figure, while it is correctly applied with 684861b. I did not figure out how to change the “visible” y_lim of the radar plot (that seems to be more or less equal to 10 times the vanilla results from ax.get_ylim()), from which the data points are obviously out when looking at their “r” value…

Here's a script that demonstrates a difference introduced in commit f8b1a9a:

import numpy as np
from matplotlib.scale import Log10Transform

t = Log10Transform('mask')
d = np.array([1., 5., 10., 50., 100.])
print(t.transform_non_affine(d))

Before the commit I get

[ 1.       1.69897  2.       2.69897  3.     ]

and after the commit

[ 0.       0.69897  1.       1.69897  2.     ]

The old version multiplies the input data by the base before taking the logarithm, effectively adding one to the result.

The following change seems to fix this test case, didn't test anything else:

diff --git a/lib/matplotlib/scale.py b/lib/matplotlib/scale.py
index 17bc4e8..3bdc78f 100644
--- a/lib/matplotlib/scale.py
+++ b/lib/matplotlib/scale.py
@@ -99,7 +99,7 @@ class LogTransformBase(Transform):
 
     def transform_non_affine(self, a):
         with np.errstate(invalid="ignore"):
-            a = np.where(a <= 0, self._fill_value, a)
+            a = np.where(a <= 0, self._fill_value, a * self.base)
         return np.divide(np.log(a, out=a), np.log(self.base), out=a)
 
 
@@ -110,7 +110,7 @@ class InvertedLogTransformBase(Transform):
     has_inverse = True
 
     def transform_non_affine(self, a):
-        return ma.power(self.base, a)
+        return ma.power(self.base, a-1)
 
 
 class Log10Transform(LogTransformBase):

Also, this is probably unrelated but in the same file LogitTransform replaces values >=1 with 1-1e-300, which is just the same as 1.0 since you don't get 300 decimals of precision near 1.0.

This +/-1 was noted in #7144 with a "Why do we do this?" and subsequent removal. Given that this does not preserve backward compatibility and this has been around for 10 years (according to that PR), we should definitely revert that part of the change.

Even as of 1.5.3 the MWE provided by @afvincent fails if one multiplies the data by 0.1 (and adding or removing the +/-1 doesn't change anything to it). Thus, I believe the change applied in #7144 simply modified the range of values for which the radar chart works correctly, but there is a deeper issue that needs to be fixed.

The 1e-300 is related to #7413. Basically minpos is a hack around the problems mentioned in that issue (autoscaling should take place after applying the transforms) specifically designed for logarithmic scales.

I think this script shows the root of the issue:

import matplotlib.pyplot as plt

ax = plt.subplot(211, projection='polar')
ax.scatter([0, 1, 2], [2, 5, 10])
ax.set_yscale('log')

ax = plt.subplot(212, projection='polar')
ax.scatter([0, 1, 2], [1, 5, 10])
ax.set_yscale('log')

plt.show()

Any values <= 1 drop off a polar plot when it's yscale is set to 'log'.

And thinking about this a bit more, I think the problem is that after the log transform, some of the transformed values are negative, which a polar plot simply doesn't plot at the moment.

Perhaps see #2133, also it looks like negative radial values work with a ax.autoscale_view(True,True,True) for ax.plot, but not for ax.scatter (see #1730).

But it worked before. I have created many polar charts with log transformed values < 1.

@EvanZ can you check whether you were able to use values <=0.1? Some quick tests suggest that even as of 1.5.3, values <=0.1 are silently dropped (then the effect of #7144 would make sense, we just shifted the boundary of the problem by a factor of 10).

(If I am correct, a slightly horrible hack would be to replace the +/-1 that #7144 removed by +/-log([minimum-positive-float128]) (in the relevant base), which would handle all possibly relevant values :-))

I am very hazy on how the scale/projection system works and in particular how log scale interacts with the polar plots (and which unit systems all of these things are moving between).

If these numbers never escape our internals, shifting to be strictly positive may be a reasonable path forward.

@anntzer I'm pretty sure small values aren't showing up even in 1.5.3. You can see that if you run the example in the OP with a log scale.

Actually it seems that very large values also get cropped out (replace 10 by 100 in your example), and adding an offset only shifts the working window instead of fixing the issue, so that's not going to be as simple.

I don't mind having the +/-1 restored (with a pointer to this thread) so that the working range stays the same in 2.0 as in 1.5 :-) but the problem is obviously deeper...

@tacaswell, @efiring, and myself discussed this and our consensus is:

1. This worked by chance in before 2.0, so it's not a 2.0 regression--therefore it should not hold up the 2.0 release.
2. @tacaswell thinks this is a bad interaction between log scaling and polar plot and is hoping to find a work-around
3. This should be noted as a known bug in 2.0 release notes--try to fix in 2.0.x/2.1.

Still an issue, I would say. Any updates?

Still having issue here.

This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!

This example is now at https://matplotlib.org/stable/gallery/specialty_plots/radar_chart.html and the MWE example above fails in really weird ways (did not chase through why).

Modifying the current example in a similar way (add minimum to data + setting logscale) works as does the log polar example above

It does not look great, but I think that is because these data sets are not good for log data.

I suspect that this was fixed by #24825 for mpl3.7 but have not bisected to test.

This function creates a RadarAxes projection and registers it.

Parameters
----------
num_vars : int
    Number of variables for radar chart.
frame : {'circle', 'polygon'}
    Shape of frame surrounding axes.

"""
# calculate evenly-spaced axis angles
theta = np.linspace(0, 2*np.pi, num_vars, endpoint=False)

class RadarTransform(PolarAxes.PolarTransform):

    def transform_path_non_affine(self, path):
        # Paths with non-unit interpolation steps correspond to gridlines,
        # in which case we force interpolation (to defeat PolarTransform's
        # autoconversion to circular arcs).
        if path._interpolation_steps > 1:
            path = path.interpolated(num_vars)
        return Path(self.transform(path.vertices), path.codes)

class RadarAxes(PolarAxes):

    name = 'radar'
    PolarTransform = RadarTransform

    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)
        # rotate plot such that the first axis is at the top
        self.set_theta_zero_location('N')

    def fill(self, *args, closed=True, **kwargs):
        """Override fill so that line is closed by default"""
        return super().fill(closed=closed, *args, **kwargs)

    def plot(self, *args, **kwargs):
        """Override plot so that line is closed by default"""
        lines = super().plot(*args, **kwargs)
        for line in lines:
            self._close_line(line)

    def _close_line(self, line):
        x, y = line.get_data()
        # FIXME: markers at x[0], y[0] get doubled-up
        if x[0] != x[-1]:
            x = np.append(x, x[0])
            y = np.append(y, y[0])
            line.set_data(x, y)

    def set_varlabels(self, labels):
        self.set_thetagrids(np.degrees(theta), labels)

    def _gen_axes_patch(self):
        # The Axes patch must be centered at (0.5, 0.5) and of radius 0.5
        # in axes coordinates.
        if frame == 'circle':
            return Circle((0.5, 0.5), 0.5)
        elif frame == 'polygon':
            return RegularPolygon((0.5, 0.5), num_vars,
                                  radius=.5, edgecolor="k")
        else:
            raise ValueError("Unknown value for 'frame': %s" % frame)

    def _gen_axes_spines(self):
        if frame == 'circle':
            return super()._gen_axes_spines()
        elif frame == 'polygon':
            # spine_type must be 'left'/'right'/'top'/'bottom'/'circle'.
            spine = Spine(axes=self,
                          spine_type='circle',
                          path=Path.unit_regular_polygon(num_vars))
            # unit_regular_polygon gives a polygon of radius 1 centered at
            # (0, 0) but we want a polygon of radius 0.5 centered at (0.5,
            # 0.5) in axes coordinates.
            spine.set_transform(Affine2D().scale(.5).translate(.5, .5)
                                + self.transAxes)
            return {'polar': spine}
        else:
            raise ValueError("Unknown value for 'frame': %s" % frame)

register_projection(RadarAxes)
return theta

data = example_data()
spoke_labels = data.pop(0)

fig, axs = plt.subplots(figsize=(9, 9), nrows=2, ncols=2,
                        subplot_kw=dict(projection='radar'))
fig.subplots_adjust(wspace=0.25, hspace=0.20, top=0.85, bottom=0.05)

colors = ['b', 'r', 'g', 'm', 'y']
# Plot the four cases from the example data on separate axes
for ax, (title, case_data) in zip(axs.flat, data):
    ax.set_rgrids([0.2, 0.4, 0.6, 0.8])
    ax.set_title(title, weight='bold', size='medium', position=(0.5, 1.1),
                 horizontalalignment='center', verticalalignment='center')
    for d, color in zip(case_data, colors):
        ax.plot(theta, np.array(d)+0.15, color=color)
        ax.fill(theta, np.array(d)+0.15, facecolor=color, alpha=0.25, label='_nolegend_')
    ax.set_varlabels(spoke_labels)
    ax.set_rscale('log')
# add legend relative to top-left plot
labels = ('Factor 1', 'Factor 2', 'Factor 3', 'Factor 4', 'Factor 5')
legend = axs[0, 0].legend(labels, loc=(0.9, .95),
                          labelspacing=0.1, fontsize='small')

fig.text(0.5, 0.965, '5-Factor Solution Profiles Across Four Scenarios',
         horizontalalignment='center', color='black', weight='bold',
         size='large')

plt.show()

</details>