autoinfer norms from scale names in the "norm" kwarg of imshow() and friends. #20746
Comments
|
I don't think there will be confusion w/ norms where the string version doesn't exist 'cause it's not a scale (like boundarynorm) but I'm like kinda wondering what this looks like in documentation since it let's the kwarg take as input the object and a strict subset of strings. |
|
We already do that for I think this could work. I'm a little leery about doing it because making folks aware of the underlying Norm class is quite useful. But it is awkward to grab. Another alternative is we add the norms to pyplot so folks can do |
|
I would document this exactly in the same way as we document set_scale, as norms can (mostly) be thought of as setting the scale on the colorbar axis. (And even though (as noted above) I like exposing the underlying objects, here there's strong precedent for using strings for scales.) |
👎 on such an API. This is not discoverable, has no editor support (completion/checking), and it's not readable (a common realistic case would be explicit numbers
ok. |
|
Agreed, I went for the second solution in #20752. |
|
Closed by #20752. |
Problem
Now that Norms are auto-derived from Scales (see
make_norm_from_scale), it may be nice to reuse the scale-name machinery to allow using strings to specify norms, e.g.and perhaps
or just allow
(#15769 deprecated
norm=LogNorm(), vmin=vmin, vmax=vmaxbut that was because in that case it was unclear whether the passed-in norm should be mutated, whereas here it's always a new norm instance which can thus always be mutated). (I'm not always particularly fond of using strings when objects would be more featureful, but here the machinery for scales is already present and well established so...)This would seem relatively easy to implement, except for one detail: LogScale currently defaults to
nonpositive="clip"(see #9477 and the long tree of linked issues for the reason), whereas norms usenonpositive="mask"(which is more or less implied by the existence of APIs likeColormap.set_bad). While this can be resolved in an ad-hoc manner (e.g. by making sure that such scales have anonpositiveparameter/attribute and setting it accordingly), I wonder whether a more general solution is possible.Proposed Solution
As described above.
Additional context and prior art
AFAICT, proplot uses a hard-coded mapping of norm names (https://proplot.readthedocs.io/en/latest/api/proplot.constructor.Norm.html).
The text was updated successfully, but these errors were encountered: