René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"[ENH]: BoundaryNorm should not need to know colormap length","articleBody":"### Problem\n\nCurrently `BoundaryNorm` requires `ncolors` as an argument, and hence the user needs to know the colormap size to use it.  \r\n\r\nThen we have this comment in the code\r\n```python\r\n    # Mapping to the 0-1 interval could have been done via piece-wise linear\r\n    # interpolation, but using integers seems simpler, and reduces the number\r\n    # of conversions back and forth between int and float.\r\n```\r\n\r\nand this \"note\" in the docstring:\r\n\r\n```python\r\n\"\"\"\r\n        If there are fewer bins (including extensions) than colors, then the\r\n        color index is chosen by linearly interpolating the ``[0, nbins - 1]``\r\n        range onto the ``[0, ncolors - 1]`` range, effectively skipping some\r\n        colors in the middle of the colormap.\r\n\"\"\"\r\n```\r\n\r\nIf we are going to interpolate anyway, we should just map from 0-1 with `len(boundaries)` boundaries like all the other norms.  Then the user doesn't need to specify Ncolors.  In fact, if the user mispecifies the length of the colormap, then the mapping will mysteriously be incorrect.  (Yes there is a fast-path of len(boundaries)-1 == ncolors, but I really don't think `np.digitize` is one of our performance chokepoints)\n\n### Proposed solution\n\nThe problem with changing this is tracking down the special cases, and possible with downstream libraries that do something with the Norm.  The other problem is somehow deprecating the argument. ","author":{"url":"https://github.com/jklymak","@type":"Person","name":"jklymak"},"datePublished":"2021-12-10T09:59:41.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":8},"url":"https://github.com/21911/matplotlib/issues/21911"}