Add support for negative color

[Willian-Zhang]

This PR adds support for negative number range support and extends color spaces to negative range

[AndreasMadsen]

@Willian-Zhang Thanks. I didn't look careful at the hex colors, but wouldn't it be better if this was a configuration option? I could imagine cases where values could be negative, but there are no negative values. But you still would want the color range to be consistent.

Also, could you include a screenshot and describe the problem you are solving a bit more. I don't fully understand what you are solving.

[Willian-Zhang]

It does not need to be configured upfront as it does not change current behavior on positive value range. And, yes, color range will remain consistent as is with this PR:

• the value range extends from 0 ~ 1 to -1 ~ 1
• color range extends accordingly with different subset of color space (red-ish) as oppose to current (green-ish) range on positive values

[Willian-Zhang]

data = [[
    {'token': 'cat',
     'heat': [1, 0, -1]},
    {'token': ' loves',
     'heat': [1, 0, 0]},
    {'token': ' dog',
     'heat': [-1, 0, 1]},
]]

heatmap = TextualHeatmap(facet_titles = ['Favors'])
heatmap.set_data(data)

[AndreasMadsen]

@Willian-Zhang It is not good API design to have the color range be inferred automatically from the data and for there to be no other way of changing it. It could be inferred incorrectly.

Could you clarify what is unsatisfying with mapping the data from [-1, 1] to [0, 1] in the input.

data = [[
    {'token': 'cat',
     'heat': [1, 0, -1]},
    {'token': ' loves',
     'heat': [1, 0, 0]},
    {'token': ' dog',
     'heat': [-1, 0, 1]},
]]
data = [{'token': obs['token'], 'heat': [(h + 1)/2 for h in obs['heat']]} for obs in data]

I can understand if you would want a different colormap. But then I think a better solution is to make the colormap and background color configurable.

[Willian-Zhang]

It is not good API design to have the color range be inferred automatically from the data and for there to be no other way of changing it. It could be inferred incorrectly.

Yes, I agree with that. Upon start using this package, I used input value range from [-any, +any] and hoped the library would automagically find whatever the number ranges in and scale for me if it found suite. (which it does not)

However, extending the input range to -1 is a different story. My case is, values from my custom model represents different nature of a specific attribute. positive for positive "voting", negative for against that same voting. In your example ideal usage for keeping value range [0, 1], I, as a user, would have to manually provide a two-stage color-map also a two-stage normalization range aligned with that color map for my values, just to represent that [-1, 0] + [0, 1] range as what I have described as voting.

Hence I do think extending the value range to -1 make a sense, as they semantically extends meaning for that value attribute.

[Willian-Zhang]

Think of a display monitor that absorbs light besides emitting them. I would say extending single color [0, 255] range to [-255, 255] be a great start for that display.

[AndreasMadsen]

@Willian-Zhang I completely understand the value in having a colormap for [-1, 1]. However, I don't think you have considered all the edge-cases with your current implementation.

You may have inputs which could be [-1, 1], but for a specific case are only [0, 1]. They would then be shown with the [0, 1] colormap, but you would actually want them to be shown with the [-1, 1] colormap. That is why the colormap should not be inferred automatically, it is inherently a bug to do so.

[Willian-Zhang]

@AndreasMadsen I don't get it. I cannot see a case where anyone would want their value range in (0,1) yet mapped to a (-1,1) color-map range, as they serve different semantic meaning.
If by any chance the color map could be customized, I do think (-1,0)and (0, 1) should be handled differently, as they serve a diff semantic meaning.

To elaborate on what I mean by semantic meaning, think of two pair of value in those two ranges: (-0.5 -0.4) and (0.4, 0.5)
Apparently -0.4 > -0.5, 0.5>0.4.
On Neg color range, -0.5 should be more dense color than -0.4, contrary to their value comparison. In other words, they should not be treated same. Proving single configurable mapping just wouldn't solve this.

Nevertheless, I think this PR should be considered separated to what a user configuration should be done.

(Excuse me for my formatting, I'm typing on a phone)

[AndreasMadsen]

I don't get it. I cannot see a case where anyone would want their value range in (0,1) yet mapped to a (-1,1) color-map range, as they serve different semantic meaning.

An explanation could provide importance score in the range (-1,1) but for a given observation only provide values in the range (0,1). Just because the potential output range is (-1,1), it does not guarantee that it will happen. Inferring the colormap from the input is therefore a bug.