Violin span fix

[etpinard]

Fixes #2631 and supersedes #2552

This PR uses @joshua-gould's 9329a4d where the set bandwidth value is used to determine the number of pts in the kde estimate (as opposed to the min of the set bandwidth and the Silverman's rule of thumb).

Moreover, this PR uses Scott's rule of thumb when the Silverman value yields too many kde points. This happens when the IQR is not a very good estimate of the distribution's spread like in the data of #2552 (comment).

cc @alexcjohnson

[alexcjohnson]

I still have two concerns about this:

• The user can still lock things up with a custom bandwidth that's sufficiently small (and potentially even automatically, say you provide a million zeros and one one? That might still be OK though...) - we need some absolute limit.
• A sharp transition from Silverman to Scott means that some distributions that are actually narrower will end up looking wider. In your example say you tweaked it to be just on the Silverman side of the limit: you'd get 1e5 bandwidths in the span, then narrow it a little and it would pop out to essentially what's in your test image, looks like ~50 bandwidths in the span. I guess I don't mind if we reach a point where distribution width stops affecting bandwidth, but not if the dependence goes the wrong direction.

What if the automatic bandwidth just used Silverman but limited it to > (max - min)/100 or something? Maybe /100 is too wide still? /1000? I think a narrower result would do a better job showing the shape of this particular distribution anyhow, don't worry about matching Seaborn. And then the 1e5 limit would constrain all cases, manual or automatic. That's far narrower than one pixel, until you've zoomed waaaay in.

[etpinard]

What if the automatic bandwidth just used Silverman but limited it to > (max - min)/100 or something?

Going with /100 in -> 36cc37d

[alexcjohnson]

wait, that's still going to jump from 1/1e5 up to 1/100. I had in mind something like:

if(trace.bandwidth) {
    return Math.max(trace.bandwidth, span / 1e5);
}
else {
    return Math.max(silvermanValue, span / 100);
}

[etpinard]

Oops. My bad -> c554070

[alexcjohnson]

From slack, for the record:

@etpinard: limiting custom bandwidth at (span / 1e5) is still pretty slow. ok if I increase it to span / 1e4 ?

Me: sure, that’s still more than 1 bw/px. I’m not quite so worried about it though, at that point the user has asked for something explicitly ridiculous… but I guess we don’t want our mock to take forever to render!

[alexcjohnson]

Looks great! 💃