How could I make a discrete-distribution input element?

Assume for a minute that I want to define a discrete distribution of N parts as a user input.

If N = 2, I can use a slider, and the second part of the partition can simply subtract the first value from 1. Similarly when N=3. However, as N increases this is unfortunate. Additionally, if I want to let the user vary N, or have N be the output of some other computation, it’s even more irritating.

Ideally, I’d love to have something like a bar chart where I could “pull bars up and down” to define their value (which would be displayed). I also need the output of this selection to be accessible in some variable for use elsewhere in the notebook.

1 Like

You can precompute a list of values and have the slider refer to their indices:

like this?

2 Likes

If there’s a reasonable order you could also plot the CDF as a some monotonically increasing step chart and let people mouse around to set the steps.

1 Like

@Fil Yes! that’s exactly what I had in mind, but with a slightly different behavior on how it “redistributed” values. I think I can modify what you’ve shown here to what I had in mind. Thank you so much!

Here’s what I was able to cook up(a few things that aren’t quite right):

1 Like

Ok @Fil I iterated on it a little so that it always constrained “downstream” of the bar you’re working on. The idea being you adjust it left to right. It’s a little glitchy especially when you first start adjusting and there’s a little bit of strangeness in it just disappearing if you drag too high.

Any suggestions for cleaning this up further:

Hehe, I think I agree that in some cases this would actually be better, but for the case I’m thinking of I worry this will be even more abstract for the reader! I’m glad you mentioned it though because I think there’s another use for this comment elsewhere in my notebook.

Hey I forked Fil’s and put on a log scale. I think log scales are more natural for probabilities (nearly all math works in the log probability space) and prevents the unstableness of. the user input (https://observablehq.com/d/62bd15306ca4c12c) and small values disappearing.

Some external validation on why log-probabilities have nice properties and intuitiveness https://en.wikipedia.org/wiki/Log_probability and that its not an arbitrary hack to fix the UX.

Very clever, Tom. It really does smooth the interaction, and you’re surely right about the utility of log prob mathematically also.

Did you happen to see my response to @Fil above? I changed it to make the bars only effect “downstream” probabilities when normalizing. This is because the effect of moving all other bars make it hard for the user to set a distribution they want (it’s a constantly moving target).

I was curious if you had thoughts on that one? This might be able to solve the jumpiness in mine as well which is even more pronounced.

Thanks for your ideas!

@tomlarkworthy Just checking, is this the intended behavior?

Yes. Log scale so small changes near the top are “worth more”. I like the clamping values to the left as you can set it to a target easier

Hi @tomlarkworthy I can’t seem to find your version now.

Sorry I had trashed it thinking we had finished with it. I jst recovered it.

Thanks, Tom. I wanted to take a closer look.

Thanks, everyone. I think I’ve settled on an implementation that serves my purpose for now. I appreciate the feedback and discussion!

1 Like