You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I went through the ultraplot document, but failed to find a clear explanation on how to set the default color cycle to a custom color sequence.
The configuration page mentioned rc['cycle'].
The Color cycles page mentioned how to define a cycle with uplt. Cycle, but this cycle can not be passed to rc actually.
These are all relevant info that I found.
I don't know what's the recommended practice with ultraplot.
I found a workaround using a mixture of uplt and mpl.
frommatplotlibimportpyplotaspltimportmatplotlibasmplimportultraplotasupltimportnumpyasnpctab= ["#5790fc", "#f89c20", "#e42536", "#964a8b", "#9c9ca1", "#7a21dd"]
uplt.rc['axes.prop_cycle'] =mpl.cycler(color=ctab)
# uplt.rc['cycle'] = mpl.cycler(color=ctab) # does not workforiinrange(6):
plt.plot(np.arange(10) +i)
The rc file is getting on my radar the last couple of days. It currently is not checked for internal validity (that is it lacks tests). I see that the cycle is listed but if what you are saying it correct it is not correctly passing this on. axes.prop_cycle is how it is named under matplotlib. To construct the cycler please us uplt.Cycle
Ok I found the issue. The issue is that the docs state that rc["cycle"] maps to "axes.prop_cycle", however, in the code it reads it as a colormap not necessarily a cycler object. I will fix this such that both are possible.
This requires a bit more tooling than I thought. The issue is that the docs are implying that we can set any cycler -- whereas the code only allows colormaps and in particular it allows only to set strings for this property. There is also something funky going on with the colormap names being copied with a different name -- which I have been aware of for a while. A fix for this would also require to fix that. For now I will keep this open and suggest to use "axes.prop_cycle" directly. Apologies for the inconvenience :(
I confirm that uplt.rc["axes.prop_cycle"] = uplt.Cycle(color=ctab) works.
A naive question: if rc["cycle"] is simply supposed to map to "axes.prop_cycle" (though not exactly implemented this way yet), why do we need rc["cycle"] in the first place? Because the item name is shorter?
I think that Luke did it for two reasons; one, like you mentioned the name is shorter, but second the name is more intuitive. The implementation is a bit odd however. For example you can use it like this currently:
uplt.rc["cycle"] ="qual1"
This works perfectly fine. I believe even passing a colormap object works, just not the actual object its name implies its designed for (a cycler).
Activity
cvanelteren commentedon Apr 30, 2025
The rc file is getting on my radar the last couple of days. It currently is not checked for internal validity (that is it lacks tests). I see that the cycle is listed but if what you are saying it correct it is not correctly passing this on.
axes.prop_cycleis how it is named under matplotlib. To construct the cycler please usuplt.Cyclecvanelteren commentedon Apr 30, 2025
The correct code would be
which currently errors for
cyclebut works fine foraxes.prop_cycle.cvanelteren commentedon May 17, 2025
So I looked at this again and it seems to automagically work now. Can you confirm this?cvanelteren commentedon May 17, 2025
Ok I found the issue. The issue is that the docs state that
rc["cycle"]maps to "axes.prop_cycle", however, in the code it reads it as a colormap not necessarily a cycler object. I will fix this such that both are possible.cvanelteren commentedon May 17, 2025
This requires a bit more tooling than I thought. The issue is that the docs are implying that we can set any cycler -- whereas the code only allows colormaps and in particular it allows only to set strings for this property. There is also something funky going on with the colormap names being copied with a different name -- which I have been aware of for a while. A fix for this would also require to fix that. For now I will keep this open and suggest to use "axes.prop_cycle" directly. Apologies for the inconvenience :(
syrte commentedon May 17, 2025
I confirm that
uplt.rc["axes.prop_cycle"] = uplt.Cycle(color=ctab)works.A naive question: if
rc["cycle"]is simply supposed to map to"axes.prop_cycle"(though not exactly implemented this way yet), why do we needrc["cycle"]in the first place? Because the item name is shorter?cvanelteren commentedon May 18, 2025
I think that Luke did it for two reasons; one, like you mentioned the name is shorter, but second the name is more intuitive. The implementation is a bit odd however. For example you can use it like this currently:
This works perfectly fine. I believe even passing a colormap object works, just not the actual object its name implies its designed for (a cycler).
cvanelteren commentedon Oct 25, 2025
Fixed on main!