Closed Ranges and Range Interface

[thomasnield]

This issue is for conversation regarding the proposal for Exclusive Ranges and a Range Interface.

Pull Requestion: #137

[Wasabi375]

I think there are a few things that should change:

1. The Range interface should contain properties describing whether start and end are inclusive.
2. I think the definition of open and closed ranges also needs to be refined. As far as my understanding of maths goes I would expect an open range to not include either endpoint, yet your example for an OpenRange contains the start value.
3. This means that we need 4 different ranges: open, closed, IncludingStart, IncludingEnd. For the later 2 we would need a better name.

[LouisCAD]

From the Contracts section:

For the OpenRange implementations, the lowerBound/start must be less than the upperBound/endExclusive. Otherwise the range should be empty.

0 downTo -10 is a valid range in Kotlin which doesn't follows this statement. I think this contract could be changed or dropped.

[thomasnield]

@Wasabi375 Well by that standard, ClosedRange should not be inclusive then either, and it is already an incumbent range type in Kotlin. I personally think my proposed names are fine and practical: ClosedRange, OpenRange, and later ExclusiveRange. Also, I can't think of many use cases for a fully ExclusiveRange anyway, although I'm sure they are out there.

I think indicators on Range for inclusivity/exclusivity on each point can be added later. For now, I recommend keeping it simple and don't make the Range do too much. If someone needs it that badly they can do a type check.

@LouisCAD Fair enough, but aren't those Progressions? That might be a separate KEEP but useful nonetheless.

10.0 downTo 1.0 step .5

I could have used that in my temperature schedule for the TSP.

That needs to be planned carefully though. For instance, how do we handle a DoubleProgression without a step? How do we control inclusivity/exclusivity?

[Wasabi375]

@thomasnield No, following the standard terminology used in mathematics an open interval does not include either of its end points while a closed interval includes both of them. Than there is a half open interval which only includes one endpoint.
I know in kotlin they are called rang, but it is the same thing.
The names I would suggest would be: OpenRange, ClosedRange, LeftExclusiveRange, RightExclusiveRange.

[Wasabi375]

As to the inclusivity indicators: I think adding will be no cost at all. They will just be a readonly property which all implementations override to either return true or false. This is safer than to assume, that no user would create their own custom range type (maybe for BigDecimal or some complex number type).

[thomasnield]

@Wasabi375 Or StartExclusiveRange and EndExclusiveRange 🤔, I guess I'm not opposed to calling my proposed need EndExclusiveRange. But if we are going to go that route, there's a larger issue with the start not being called startInclusive in the incumbent ClosedRange. If we really are going to consider ranges with start exclusivity, we need to address that.

I'd like to see use cases for StartExclusiveRange or a fully exclusive OpenRange. If start-exclusive ranges are never used, what's the point of killing ourselves over that start property? Can we kick that can down the road?

And let's keep in mind, just because supporting start exclusivity is mathematically correct, it does not mean it will have use cases in a generalized programming language.

I'm not sure what to do with the inclusivity indicators. I feel they add clutter and I can't think of use cases for them. Whenever you implement your own Range in my opinion, the onus of not screwing up the implementation is solely on the developer, and I don't see how the indicators enforce any behavior.

[Wasabi375]

I think with adding lowerBound and upperBound we should think about deprecating start and endInclusive anyways.

I'd like to see use cases for StartExclusiveRange or a fully exclusive OpenRange. If start-exclusive ranges are never used, what's the point of killing ourselves over that start property? Can we kick that can down the road?

When dealing with pricing models I had to use both start and end inclusive ranges. As far as I remember startInclusive was more common than endInclusive but it was more equal than you might expect. I guess open ranges can be useful in validation and testing of calculations.

---

As for the inclusivity indicator, I was thinking about a custom range, where the inclusivity could be changed by the user, but I think this goes beyond this KEEP, so let's forget about it.

[thomasnield]

With your pricing model example, you mean exclusive start ranges right?

Also, I posted this on MathExchange.

https://math.stackexchange.com/questions/2851657/what-are-real-world-use-cases-for-start-exclusive-ranges-intervals

[Wasabi375]

Yes, I mean I had to use both ranges, which included the start and not the end, and ranges, which included the end and not the start. Imagine your histogram example just with the lower bound excluded and the upper bound included.

[thomasnield]

I'll update the proposal and present all the approaches we discussed. I think we need to support start exclusivity after your input. Good talk.

[thomasnield]

Proposal has been updated. The new types I documented are:

• Range
• OpenRange
• OpenStartRange
• OpenEndRange

@Wasabi375 I added you as a contributor, thanks for your helpful considerations and advisement.

[HaasJona]

Please consider taking some inspiration from Guava's Range class: https://github.com/google/guava/wiki/RangesExplained

It has worked very nicely in my projects so far.

[thomasnield]

@HaasJona I think we are pretty aligned with Guava, other than Kotlin-izing it a little.

I think I'm going to create a separate KEEP for continous progressions, like 12..0 downTo 0 step 0.5

[voddan]

@thomasnield I think this proposal needs a similar API review analyses of other languages and frameworks. For example, how Python and other "math" languages handle this, what are the pros and cons of their implementations. Also, Guava seems to have similar APIs, why not include their analyses, as well as their usages and possibly discovered pain points.