I have tested the numpy issue and it looks like it has been like this since at least 1.6.0

1. numpy interp: I think this is to be expected. For the most part, plain numpy doesn't know how to handle masked arrays, which is why the ma module is so big. Here, explicit handling seems to be in order--you need to do the interpolation using only the valid values. The interp docstring says nothing about handling nans, either.
2. I think the idea for "piece-wise-linear" is that it is general, and can be applied with any number of segments. The version here is a special case with two segments. It would be nice to handle the general and special cases from the outset.
3. What about the inverse? The basic linear Normalize norm is just a special case of piece-wise linear; the latter should be just as invertible as the former.

I am a bit nervous that the inverse was removed.

Any update on this?

I will take a look at this tomorrow and see what I can add. Should I make a PR to merge into this branch, or work on top of this in a separate PR?

I added some suggestions on my branch, also submitted as a pull request to @dopplershift's branch.

just looked at it dopplershift#2 but we still lack the generality... I think the API should read:

def __init__(self, stops, clip=False):

We need stops as a kind of dictionary, not too sure on that yet. Whether {<cmap-fraction>: <value>} or {<value>, <cmap-fraction>}, I guess we would want an ordered dictionary, but as we still support python-2.6 that means we should do it as a list of tuples... [(, ), (, )], with this structure we have:

class CenteredLinearNorm(PiecewiseLinearNorm):
  def __init__(self, vmin, vcenter, vmax, clip=False):
    stops = [(0., vmin), (0.5, vcenter), (1., vmax)]
    PiecewiseLinearNorm.__init__(self, stops, clip)

PiecewiseLinearNorm will probably want to do some sort of validation to ensure order, in which case we can accept any kind of dict and build our own sorted dict.

I also started working on this a while ago, but got distracted. I was envisioning an API something like

tacaswell@de5eb53

@tacaswell Any reason why you have them as two separate lists? We have a 1:1 mapping, this would require an extra check that the two lists have equal lengths, and if we have two lists, we can easily put them into ordered dict format with zip(map_points, data_points).

Because they have different units and because there are less ways to input
this wrong.

If we take a list of tuples then we also need to take a 2D arrays, which
means we need to deal with the transpose, etc.

Also, this matches the underlying np.intep API so we can just pass
through to that and let numpy do those checks (we just need to check
monotonic as their docs explicitly say they do not check for that).

On Thu, Sep 3, 2015 at 11:32 AM OceanWolf notifications@github.com wrote:

@tacaswell https://github.com/tacaswell Any reason why you have them as
two separate lists? We have a 1:1 mapping, this would require an extra
check that the two lists have equal lengths, and if we have two lists, we
can easily put them into ordered dict format with zip(map_points,
data_points).

—
Reply to this email directly or view it on GitHub
#4666 (comment)
.

Well I don't see different units as a problem... it underpins the whole definition of a dict {'time': 5}, string, int.

With "more ways to input it wrong" I think I see why you say that, because you think in terms of a list of tuples, but as I say we should think of it instead as passing in an OrderedDict, or anything that stops = OrderedDict(stops) won't error, this approach feels better for the future when we finally drop support for python-2.6 (which you have already considered doing recently).

def __init__(self, stops, clip=False):
  stops = OrderedDict(stops)  # will raise a ValueError on bad data
  stops = OrderedDict(sorted(stops.items(), key=lambda t: t[0]))  # sort keys
  map_points, data_points = stops.keys(), stops.values()  # get data ready for np.interp
  if not np.all(np.diff(data_points) > 0):
    raise ValueError("stops must increase monotonically")

We need far simpler error checking here because we utilize ordered dicts, this also makes the class a lot more useful as we simply duck-type the data input based on its dict-like structure. Anything that can get cast to a dict, we accept. While we don't support OrderedDict yet because of our support for python-2.6 we can for now cast to an ordinary dict and then extract and work internally with a list of tuples, this casting to a dict will mean we can also accept OrederedDicts right now, but internally handle them a bit more clumsily until we drop support for 2.6.

Are you sure there is a use case for a general piecewise linear mapping? Centering a diverging colormap's neutral color on a specific data value makes a lot of sense to me, but I'm not so sure about the more general case.

@jkseppan I thought earlier about this earlier today, and I wondered about our accent colour map (a qualitative one), that might work well with data sources where we want to see the local variation, but the data contains big jumps in the data which would drown out that local variation otherwise...

@dopplershift was very excited about this for meteorology where they have color maps with multiple natural break points. The other canonical use case would be to correctly map gist_earth on to elevation data.

@dopplershift @jkseppan This needs a rebase. If this turns back into just a centered norm for now, that is cool it just needs to be renamed.

It seems that the problem with #3858 was finding a fitting name for the norm, and people liked PiecewiseLinearNorm, but that suggests more generality than implemented here. How about DivergingNorm, since it's likely to get used with a diverging colormap? Then we can later implement the more general case as PiecewiseLinearNorm if needed.

I have just started on the generic version of this, we shall see how far I get...

Sold on diverging norm

On Sun, Sep 13, 2015, 10:08 OceanWolf notifications@github.com wrote:

I have just started on the generic version of this, we shall see how far I
get...

—
Reply to this email directly or view it on GitHub
#4666 (comment)
.

closing in lieu of #5054