Make base of bars configurable

[etpinard]

so that positive and negative values can be stacked on each side of the zero line.

See current behavior of the each barmode here: http://codepen.io/etpinard/pen/mPGLrY?

[mdtusz]

To clarify, do you mean so that all negative values stack below and all positive values stack above?

[etpinard]

To clarify, do you mean so that all negative values stack below and all positive values stack above?

Yes. That's what I'm thinking.

[etpinard]

Maybe we should also generalize the base level of the bars. Right now, positive values span above the zero line and negative values below it, but what if a user wants to plot bars on each side of y=20 ?

[mdtusz]

Maybe barmode: 'relative' with some specification for the base value?

{
  barmode: 'relative',
  barbase: 42
}

I don't like barbase though. @cldougl ?

[mdtusz]

And we could use barbase for the other modes too now that I think of it.

[keeganmccallum]

#517, didn't setup a 'barbase' type functionality, but properly provides a 'relative' barmode that behaves as described.

[etpinard]

'relative' bar mode added in #517

Issue title changed to reflect barbase feature.

[programflex]

[http://codepen.io/etpinard/pen/mPGLrY] It seems 'relative' does not work if the first index of y in trace2 is a negative value and the first index of y in trace1 is a positive value.
Like this:
var trace1 = {
x: ['giraffes', 'orangutans', 'monkeys'],
y: [20, 14, -23],
name: 'SF Zoo',
type: 'bar'
};
var trace2 = {
x: ['giraffes', 'orangutans', 'monkeys'],
y: [-12, -18, 29],
name: 'LA Zoo',
type: 'bar'
};

[etpinard]

@programflex thanks for reporting ➡️ #639

[kk45991]

Hello,
I am using plotly with R and I do not see any difference between:
barmode = "relative"
and
barmode = "group".

So with the first options values are not stacked like in the example: http://codepen.io/etpinard/pen/mPGLrY

Like this:
require(plotly)
require(dplyr)
set.seed(1)
test_data <- data.frame(x = rep(1:10, 3), y = rnorm(30), z = rep(c("A", "B", "C"), 10))
plot_ly(data = test_data,
x = x,
y = y,
color = z,
type = "bar") %>% layout(barmode = "relative")

plot_ly(data = test_data,
x = x,
y = y,
color = z,
type = "bar") %>% layout(barmode = "group")

[n-riesco]

@etpinard @alexcjohnson I wanted to check with you a question about the current behaviour of bar charts when a trace contains very close bars. I've edited Étienne's codepen with an example. In this example the positions are x: [1, 2, 1e5].

If the barmode:

• is stack or relative, then the bars at x:1 and x:2 will be combined into one bar.
• is group or overlay, then the bar at x:2 will hide the bar at x:1.

Is this the desired behaviour?

[alexcjohnson]

@n-riesco that's a good question. This behavior comes from Lib.distinctVals:

find distinct values in an array, lumping together ones that appear to
just be off by a rounding error

Where the criterion for a rounding error is a difference less than (max - min) / ((length-1) * 10000)

So 1 and 2 in your example are right over the edge of that criterion. It's definitely an unintuitive result, though the plot is pretty darn useless just on the other side of that boundary (put in 1e4 for example), with a bunch of sub-pixel bars. But I guess when you zoom in it could become useful. We could change that cutoff to be smarter - tighter and/or with an explicit lower bound so integers never get marked the same? Mostly this cutoff is meant to match between different traces, in case their x values have slight rounding differences due to different calculation methods or something.

[n-riesco]

@alexcjohnson I think we're looking at different issues:

• the issue you describe with subpixel bars, that you can see here when x: [1, 2, 1e3]. As you said, this can be fixed by improving Lib.distinctVals.
• and the issue with very close bars within the same trace. See here in group mode (the size of the first bar is 20) and here in relative mode (the size of the first bar is 34).

In relative mode, the size of the first bar is 34, because the x:1 and x:2 have been combined into a single bar. I think all the barmodes should follow this behaviour.

[alexcjohnson]

I see - thanks for clarifying. In fact the same thing happens with x:[1, 1, 2]. Yes, it does seem like all modes should work the same way in this regard, though I'm not sure if adding them up is really the right way, vs. just taking the first, or the biggest... is there a real use case for this or is it a mistake? I guess perhaps if it is a mistake, totaling the values may give the user the best clue as to what is going on.

FYI what's actually happening in group mode currently is it's showing all the bars. Try x:[1, 1, 2], y: [20, -14, -23] for example. And changing that to stack mode gives really screwy results depending on the relative signs of the coincident bars: bars of the same sign as the first add to it, but bars of the opposite sign get discarded. Relative mode at least seems self-consistent, both the positive and negative totals get shown.

[etpinard]

done in #1075