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

[etpinard]

Is this a bug?

This is #2970 - I'd recommend setting hovermode: 'closest' for graphs on the likes.

[antoinerg]

This is #2970 - I'd recommend setting hovermode: 'closest' for graphs on the likes.

I updated the Codepen to use hovermode: 'closest': https://codepen.io/antoinerg/pen/jJoroZ . It is now much better.

I will let @nicolaskruchten close this issue if he thinks this is satisfactory.

[nicolaskruchten]

OK, well, px uses closest hover mode by default so #2970 isn't at play there.

I wouldn't say I consider this outcome "satisfactory" as this is quite magical and totally undocumented behaviour, so let's leave this open until the scalegroup docs are updated to explain this auto behaviour and the fact that you cannot turn it off unless you explicitly set scalegroup to something non-empty... right now they just say:

scalegroup (string) 
default: "" 
If there are multiple violins that should be sized according to to some metric (see `scalemode`), link them by providing a non-empty group id here shared by every trace in the same group.

[antoinerg]

@nicolaskruchten I completely missed the fact that the doc is lacking. We should probably document the auto-grouping behavior in both scalegroup AND name to make sure it's well advertised to the user.

Thanks for pointing that out 👍

[antoinerg]

I wouldn't say I consider this outcome "satisfactory" as this is quite magical and totally undocumented behaviour, so let's leave this open until the scalegroup docs are updated to explain this auto behaviour

@nicolaskruchten thanks again for pointing that out: we updated the documentation in PR #3687

[nicolaskruchten]

Excellent, thanks for the great follow-through :) 🎉