René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"`Normalize` should not need to define an `inverse()` method","articleBody":"The `colors.Normalize` class currently defines an `inverse()` method (http://matplotlib.org/devdocs/api/colors_api.html#matplotlib.colors.Normalize -- by the way it is not documented), which maps the normalized value (i.e., index into the colormap) back to image data value.\n\nIn practice this method is only used in one place: the colorbar is drawn by taking uniformly spaced points in normalized space, transform back into data space (at the end of `Colorbar._process_values()`), then later drawn by calling `pcolormesh` on such data values (applying the normalization back into normalized space).  I guess the reason for this is that one may want to draw the colorbar using user-specified data values instead.\n\nHowever, this could just as easily be done by always working internally in normalized values: by default, just plot uniformly spaced normalized values; if the user specifies the values to use, just normalize them first.\n\nThe advantage of making such a change was highlighted to me by #7294, a PR which proposes supporting arbitrary normalization functions.  While there are a number of other points I make in that PR, one issue is that this PR requires the user to specify both the normalization function and the inverse normalization function (in order to provide `inverse`).  But, as mentioned above, with a fix to the way colorbars are drawn, there wouldn't be a requirement for the user to specify the inverse normalization (which may be nontrivial to compute).\n","author":{"url":"https://github.com/anntzer","@type":"Person","name":"anntzer"},"datePublished":"2016-10-21T07:40:49.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":18},"url":"https://github.com/7320/matplotlib/issues/7320"}