For cases like using histograms, I imagine we woul...

# stdlib

[thomasnield]

For cases like using histograms, I imagine we would want the last range to be inclusive. But doing so right now results in an List<Any> due to lack of common Range interface.

[karelpeeters]

Would adding a new parent class be a breaking change though?

[thomasnield]

Probably not. I'd have to defer to JB how disruptive that would be to the API, or radically change the intent of it.

[ilya.gorbunov]

I wonder what would be in that parent class?

[karelpeeters]

operator fun contains

[ilya.gorbunov]

Not very useful in that example with histogram

[thomasnield]

But the histogram will be used to retrieve a bin based on the contains for a value, or a randomly selected value.

It's too bad there can't be a start and end
The end can have multiple implementations. The start can arguably too

[karelpeeters]

What implementations? Inclusive and exclusive?

[thomasnield]

Yes

[karelpeeters]

A baseclass with start: Int, startInclusive: Boolean, end: Int, endInclusive: Boolean might also work.

[thomasnield]

I suppose I could just go rogue and make Kotlin-Statistics do it's own thing with it's own types. But this stdlib setup may run into problems the moment you start stacking continuous ranges

[thomasnield]

@karelpeeters I thought about that, or use a different terminology, like upperBound and lowerBound

[thomasnield]

You know what would be helpful too? An exclusive range operator 0.0.<1.0

[karelpeeters]

until?

[thomasnield]

Isn't until discrete? Does that work for continuous Double or Float?

[karelpeeters]

Not yet, but it does produce ranges without the end element. You could overload it for doubles easily.

[thomasnield]

That makes sense actually. I like that.

Here is my most recent use case where I used my own implementation of OpenDoubleRange. I wanted to use a Probability Density Function to create a weighted dice.

https://github.com/thomasnield/kotlin-statistics/blob/master/src/main/kotlin/org/nield/kotlinstatistics/Random.kt#L106:L135

[karelpeeters]

The distinction between open and closed should't really matter for that use case though, right?

[karelpeeters]

The odds of landing exactly on the border are negligibly small.

[thomasnield]

@karelpeeters Ya know, I was thinking about that for several days. Sure, but it doesn't feel kosher.

Also if the user of the API decided to extract the ranges and use them... it's misleading if they behave inclusively.