whathecode / kotlinx.interval Goto Github PK

Now that upper and lower bound accessors have been added (#30), there is an opportunity to generalize this concept.

IntervalUnion also has an upper and lower bound, even though it isn't an Interval itself.

This should likely be extracted as an interface.

Types with negative numbers can represent a - larger interval size than can be represented by the type itself

Once generic size parameters are introduced for intervals (#1), this can likely be fixed by using the unsigned matching type as the size parameter.

end does not always need to lie after start. When start lies after end, an interval is called "reversed".

When operating and comparing intervals, however, it is useful to normalize them. Part of this is to make sure start always lies before end.

Can isStartIncluded and isEndIncluded also be normalized for discrete types? E.g. for integers ]0, 1] can be normalized to [1, 1].

Currently, I added an inner normalize function to intersects solely dealing with start/end reversal as part of ongoing IntervalUnion work: #22

DateTime intervals will need this, since the size between two dates is not a date itself.

Similarly, the size between two chars is probably better expressed as a byte

Common operations on intervals are to:

• add/remove a value or interval
• get complementary interval

These may result not in a single interval, but in what can be called an interval union. This can be stored as a sorted list of non-overlapping intervals. Operations which may result in interval unions should return IntervalUnion, others can continue to return a normal Interval.

To remove redundancy in setting up unit tests for each concrete Interval type (e.g. IntInterval implementing Interval<Int, UInt>), BasicTypeIntervalsTest.kt uses an inline function to retrieve the type operations for the type parameters (using getBasicTypeOperationsFor()).

This manually needs to be kept in sync if the operations ever change.

Is there a way to directly retrieve the matching TypeOperations from the concrete types? Maybe through a common factory interface on the companion objects?

Instead of using nonReversed(), another option could to be to provide accessors like upperBound and lowerBound, which always return the highest (upper bound) or lowest (lower bound) of the two values (of start and end). And similar for the matching isIncluded properties.

It may convey the concept a bit better, and in addition prevent an additional object from needing to be initialized (the return of nonReversed().

jsBrowserTest and nativeTest show up twice when running check in IntelliJ. Once with only the tests in kotlinx-interval, and a second time with tests of both kotlinx-interval and kotlinx-interval-datetime.

They appear not necessarily to run twice, but it is unclear why they show up twice.

Add/remove intervals from interval unions.

To write tests for this, it will become useful to first implement #36.

When debugging, it is useful to see a quick summary of an interval.

Some examples:

• a closed interval: [0, 10]
• a half-open interval: [0, 10)
• a reversed open interval: (10, 0)

If these implementations can be assumed tested in separate unit tests, they can probably be used to simplify the implementation of IntervalTest.

E.g. use subtract to calculate a size, rather than passing it, and zero could be included in TypeOperators.

Compare whether two interval unions represent the same set, regardless of the structural equality of the intervals to represent them.

E.g., [0,10] and [10, 0] represent the same set.

In the case of types representing natural numbers, this raises some added complexity which most likely needs to be dealt with. Since the set of values represented by (0, 3] should be equal to [1, 3].

A common operation is to reverse intervals: swapping start and isStartIncluded with end and isEndIncluded.

Currently, I added an inner fun to assertIntersects in IntervalTest as part of ongoing IntervalUnion work. #22

Include Interval<Instant, Duration>.

Since this depends on the kotlinx datetime library, implement it as a separate module: kotlinx.interval.datetime.

With the addition of TSize as a type parameter for Interval, overflows for almost all types are prevented by relying on TSize operations to prevent T values from overflowing.

However, as commented when closing this issue:

DoubleInterval can still overflow since there is no suitable type that can be specified to cover Double.MAX_VALUE - Double.MIN_VALUE. This is probably okay as an edge case, but this should probably throw an exception when accessing size rather than it being ignored.

Currently, the IntervalTest.size_can_be_greater_than_max_value for DoubleIntervalTest succeeds since Double.Infinity is returned for both the expected and calculated value. This should not succeed for Double and probably give a runtime exception instead.

Rather than initializing a new object each time an empty result is returned, it should be possible to return a statically defined Empty. Similar to how kotlin has EmptyList.

However, are there common scenarios in which this would actually expect to reduce the memory footprint, or can be more performant? This is probably premature before any performance metrics are added to measure average operation runtime.

This operator should return an IntervalUnion, similar to minus.

With the introduction of kotlinx-interval-datetime as a submodule, build-logic is used to apply a conventions plugin.

But, this can be cleaned up a bit:

• Central definition of versions. It is spread out between buildSrc/build.gradle.kts and build.gradle.kts at the moment, since the Nexus Gradle Plugin has to be applied to the main project.
• Double loading of publish.properties in buildSrc/build.gradle.kts and the interval.library-conventions.gradle.kts plugin.
• Add a test dependency on kotlinx.interval.testcases. But, this will require kotlinx.interval.testcases not to apply the convention plugin itself, perhaps only a subset defined in a new separate convention plugin.

Publish to Maven from main. CI checks for PRs on develop.