Violin kde all 0 in marginal subplot

[nicolaskruchten]

Compare the following plots, which differ only in that one has a second violin on the right: https://plot.ly/~nicolaskruchten/290 and https://plot.ly/~nicolaskruchten/292

Why is it that when there is a second marginal violin on the right, the top one has KDE=0 everywhere?

[etpinard]

Might have been fixed during @antoinerg 's #3626

@antoinerg wanna check?

[antoinerg]

Thank you @nicolaskruchten for reporting this issue.

The following figure https://plot.ly/~nicolaskruchten/290 is indeed not rendering properly.
Here it is in a Codepen: https://codepen.io/antoinerg/pen/vPzxzL

[antoinerg]

I forgot to mention this: the above Codepen uses a recent plotly.js build that includes #3626. Therefore the issue is still present and will require a new fix!

[antoinerg]

Although the violins are rendered differently in the two figures produced by @nicolaskruchten, the calcData is the same (ie. same bandwidth and same density/kde). The problem is probably related to how the axis range is computed. To be followed.

[antoinerg]

The problem reported occurs because both violins have the same trace name (which is a whitespace see JSON). Because of this, by default, they end up in the same scalegroup with a default scalemode of width. Rescaling their width together makes no sense since they represent two very different quantities (ie. the density of lifeExp and gdpPercap respectively).

Question: is the default behavior of grouping traces in the same scalegroup if they have the same trace name a good default? I lean towards yes.

Unfortunately for @nicolaskruchten, he's not out of the woods just yet: there is also the issue of hover labels being empty for the top violin 😞

Codepen with violins having different names:
https://codepen.io/antoinerg/pen/jJoroZ

[nicolaskruchten]

I don't think we should do any kind of automatic grouping based on the trace name, as a gut reaction. Seems far too brittle.

[etpinard]

I don't think we should do any kind of automatic grouping based on the trace name,

Hmm, I'd call that "removing automatic grouping" request

plotly.js/src/traces/violin/defaults.js

Line 33 in 7b2946a

coerce('scalegroup', traceOut.name);

a breaking change.

[antoinerg]

I don't think we should do any kind of automatic grouping based on the trace name, as a gut reaction. Seems far too brittle.

I do understand your concern @nicolaskruchten: automagically doing things can be both a blessing and a curse.

However, one may argue that traces representing different quantities should be named differently and they won't get grouped automatically. Also, note that if no names is specified, they won't be grouped.

[antoinerg]

Instead of having a trace.name that is made of a whitespace, one can completely remove the trace.name and the violin won't get automatically grouped:
https://codepen.io/antoinerg/pen/jJoroZ

The reason for having one whitespace for trace.name was to avoid #3478. Since it got fixed by PR #3480, I will close this issue.

[antoinerg]

Hmm, I'd call that "removing automatic grouping" request

plotly.js/src/traces/violin/defaults.js

Line 33 in 7b2946a

coerce('scalegroup', traceOut.name);
a breaking change.

Indeed, it would break the following mock

[antoinerg]

@etpinard The top violin does not show hover labels displaying the statistics. Why is that? Because the axis range is too narrow? Is this a bug?

https://codepen.io/antoinerg/pen/jJoroZ