Setting logarithmic yscale in Radar chart broken · Issue #7751 · matplotlib/matplotlib · GitHub

I have been using the API example for creating radar charts: http://matplotlib.org/examples/api/radar_chart.html

In the previous version you could make the radial grid logarithmic simply by adding ax.set_yscale('log') here:

        ax = fig.add_subplot(2, 2, n + 1, projection='radar')
        ax.set_yscale('log')
        plt.rgrids([0.1, 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, d, color=color)
            ax.fill(theta, d, facecolor=color, alpha=0.25)
        ax.set_varlabels(spoke_labels)

This seems to be broken in rc2, with no data being plotted.

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).

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.

Details ```python import matplotlib.pyplot as plt import numpy as np

from matplotlib.patches import Circle, RegularPolygon
from matplotlib.path import Path
from matplotlib.projections import register_projection
from matplotlib.projections.polar import PolarAxes
from matplotlib.spines import Spine
from matplotlib.transforms import Affine2D

def radar_factory(num_vars, frame='circle'):
"""
Create a radar chart with num_vars axes.

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

def example_data():
# The following data is from the Denver Aerosol Sources and Health study.
# See doi:10.1016/j.atmosenv.2008.12.017
#
# The data are pollution source profile estimates for five modeled
# pollution sources (e.g., cars, wood-burning, etc) that emit 7-9 chemical
# species. The radar charts are experimented with here to see if we can
# nicely visualize how the modeled source profiles change across four
# scenarios:
# 1) No gas-phase species present, just seven particulate counts on
# Sulfate
# Nitrate
# Elemental Carbon (EC)
# Organic Carbon fraction 1 (OC)
# Organic Carbon fraction 2 (OC2)
# Organic Carbon fraction 3 (OC3)
# Pyrolyzed Organic Carbon (OP)
# 2)Inclusion of gas-phase specie carbon monoxide (CO)
# 3)Inclusion of gas-phase specie ozone (O3).
# 4)Inclusion of both gas-phase species is present...
data = [
['Sulfate', 'Nitrate', 'EC', 'OC1', 'OC2', 'OC3', 'OP', 'CO', 'O3'],
('Basecase', [
[0.88, 0.01, 0.03, 0.03, 0.00, 0.06, 0.01, 0.00, 0.00],
[0.07, 0.95, 0.04, 0.05, 0.00, 0.02, 0.01, 0.00, 0.00],
[0.01, 0.02, 0.85, 0.19, 0.05, 0.10, 0.00, 0.00, 0.00],
[0.02, 0.01, 0.07, 0.01, 0.21, 0.12, 0.98, 0.00, 0.00],
[0.01, 0.01, 0.02, 0.71, 0.74, 0.70, 0.00, 0.00, 0.00]]),
('With CO', [
[0.88, 0.02, 0.02, 0.02, 0.00, 0.05, 0.00, 0.05, 0.00],
[0.08, 0.94, 0.04, 0.02, 0.00, 0.01, 0.12, 0.04, 0.00],
[0.01, 0.01, 0.79, 0.10, 0.00, 0.05, 0.00, 0.31, 0.00],
[0.00, 0.02, 0.03, 0.38, 0.31, 0.31, 0.00, 0.59, 0.00],
[0.02, 0.02, 0.11, 0.47, 0.69, 0.58, 0.88, 0.00, 0.00]]),
('With O3', [
[0.89, 0.01, 0.07, 0.00, 0.00, 0.05, 0.00, 0.00, 0.03],
[0.07, 0.95, 0.05, 0.04, 0.00, 0.02, 0.12, 0.00, 0.00],
[0.01, 0.02, 0.86, 0.27, 0.16, 0.19, 0.00, 0.00, 0.00],
[0.01, 0.03, 0.00, 0.32, 0.29, 0.27, 0.00, 0.00, 0.95],
[0.02, 0.00, 0.03, 0.37, 0.56, 0.47, 0.87, 0.00, 0.00]]),
('CO & O3', [
[0.87, 0.01, 0.08, 0.00, 0.00, 0.04, 0.00, 0.00, 0.01],
[0.09, 0.95, 0.02, 0.03, 0.00, 0.01, 0.13, 0.06, 0.00],
[0.01, 0.02, 0.71, 0.24, 0.13, 0.16, 0.00, 0.50, 0.00],
[0.01, 0.03, 0.00, 0.28, 0.24, 0.23, 0.00, 0.44, 0.88],
[0.02, 0.00, 0.18, 0.45, 0.64, 0.55, 0.86, 0.00, 0.16]])
]
return data

if name == 'main':
N = 9
theta = radar_factory(N, frame='polygon')

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>

Setting logarithmic yscale in Radar chart broken · Issue #7751 · matplotlib/matplotlib · GitHub

Repository navigation

Setting logarithmic yscale in Radar chart broken #7751

7 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Setting logarithmic yscale in Radar chart broken · Issue #7751 · matplotlib/matplotlib · GitHub

Repository navigation

Setting logarithmic yscale in Radar chart broken #7751

Description

Activity

afvincent commented on Jan 6, 2017

dopplershift commented on Jan 6, 2017

dopplershift commented on Jan 6, 2017

afvincent commented on Jan 6, 2017

afvincent commented on Jan 6, 2017

jkseppan commented on Jan 6, 2017

jkseppan commented on Jan 6, 2017

jkseppan commented on Jan 6, 2017

QuLogic commented on Jan 6, 2017

anntzer commented on Jan 7, 2017

dstansby commented on Jan 8, 2017

dstansby commented on Jan 8, 2017

EvanZ commented on Jan 8, 2017

anntzer commented on Jan 8, 2017

7 remaining items

gtancev commented on Mar 6, 2020

freddiebarrsmith commented on Dec 2, 2020

github-actions commented on Jan 1, 2024

tacaswell commented on Jan 3, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions