Working with numeric intervals

[alpine]

What I do not understand is why you did not use class operators for sets? You use functions. That is possibly more descriptive for beginners but for the average Pascal programmer it is counter-intuitive.
If your design for functions is about clear description, then please at least add the operators too, because to me those are way more clear and natural, if only because the notation is shorter.

IMHO the operators are some sugar, but that isn't a reason to not have them, though.

here are a couple of further suggestions: (Temp EDIT! Oops, sign contains an error, will fix. FIXED)
1. Removes the dependency on math. Here a stand-alone sign<> function that operates on ordinals, but you can also integrate it in the records:

Code: Pascal  [Select][+][-]

1. { Utility function, works for ordinals }
2. generic function sign<T>(const value:T):T;inline;
3. begin
4.   Result:=T(Value > 0) - T(Value < 0);
5. end;

2. You can use the generic ifthen<T> from sysutils, which was also a dependency on math.
*snip*

Actually Sign() isn't needed in the way Compare() was used. Same with the IfThen() - see the updated snippet.

At that point I'm concerned more about the correctness than the completeness. Adding the operators is just a piece of detail.

Feedback appreciated.

[Thaddy]

IMHO the operators are some sugar, but that isn't a reason to not have them, though.

In the case of sets, they are certainly not sugar: is is actually a prime example of when operators are not sugar!
In set-like constructs it is a very good thing to also have set notation. Feels more natural.

here are a couple of further suggestions: (Temp EDIT! Oops, sign contains an error, will fix. FIXED)
1. Removes the dependency on math. Here a stand-alone sign<> function that operates on ordinals, but you can also integrate it in the records:

Code: Pascal  [Select][+][-]

1. { Utility function, works for ordinals }
2. generic function sign<T>(const value:T):T;inline;
3. begin
4.   Result:=T(Value > 0) - T(Value < 0);
5. end;

2. You can use the generic ifthen<T> from sysutils, which was also a dependency on math.
*snip*

Actually Sign() isn't needed in the way Compare() was used. Same with the IfThen() - see the updated snippet.

At that point I'm concerned more about the correctness than the completeness. Adding the operators is just a piece of detail.

Well, if I find something I let you know.

[Kays]

[…] Definitely a candidate for the standard rtl. […]

I dissent.

• When mathematicians/engineers say interval they usually mean (continuous) subsets of ℂ or at least ℝ. This unit works for with ordinal data types only. Hence it’s essentially a “big set” unit that economizes on space provided large continuous chunks are member of it. For Alpine’s application this is ideal, but it addresses a fairly specific problem.
• When I say interval arithmetic I understand arithmetic operations are performed with an external rounding mode, i. e. the operation uses round toward +∞ for the upper bound, round toward −∞ for the lower bound.
• The source code is a little light on source code comments. (This is acceptable during the development phase.)

[jamie]

This whole thread reminds me of working with Low/High limits within a polynomial table.

whereas the limits get changed as new data comes in and old limits expires.

Also reminds me of doing RMS conversions from what would appear to be random noise.

[Thaddy]

@kays
1. I concur that the code looks more like a set than intervals but that does not mean his intend is not good, I have commented as such.
2. This is not relevant in the context of ordinals, and he has specified the code is explicitly for ordinals
3. The code is pretty much self-documenting, it took me just five minutes to understand all of it. That needs KUDOS

It is not very difficult - as is this code - to add a unit for mathematical intervals too.

Naming is another question.

[alpine]

• When mathematicians/engineers say interval they usually mean (continuous) subsets of ℂ or at least ℝ. This unit works for with ordinal data types only. Hence it’s essentially a “big set” unit that economizes on space provided large continuous chunks are member of it. For Alpine’s application this is ideal, but it addresses a fairly specific problem.

Besides the immediate problem that I have, I decided to implement such a unit to be able to address another set of tasks I have mentioned also - the timing intervals (or spans).

In my daily work, and I believe in many other peoples work as well, I need to handle (split, intersect, etc.) a time span again a set of predefined schedules, e.g. to split somebody's stay at some premises to work-time, overtime, weekend time, etc. Similar is to check if one have an access to a resource in a daily, weekly, or monthly basis, or to calculate a fee based on a tiered prices.
That way, specializing those generics with unix times (Int64) will give a convenient instrumentation for the job. I have already implemented similar templates in C++. Now I'm writing the FPC library with the same purpose in mind. That is a true intervals (or time spans) and in a no way another "big-set" implementation.
 

• When I say interval arithmetic I understand arithmetic operations are performed with an external rounding mode, i. e. the operation uses round toward +∞ for the upper bound, round toward −∞ for the lower bound.

I should note that I have a pretty strong mathematical background and I'll admit those have nothing to do with the "intervals" in the common mathematical sense, but OTOH, the "arithmetic" is definable on an any properly defined structure as long the operations obey the needed properties. But since it will be best if the identifiers were obvious for everybody - I am eagerly accepting suggestions for renaming.

• The source code is a little light on source code comments. (This is acceptable during the development phase.)

Of course it should have a proper comments together with some documentation article. But first it needs to get its proper shape.

Thanks for the input,

[Thaddy]

Your code is so clearly written that @Kays comment is considered by me to be out of order.
Keep up the good work. 

[alpine]

Here is the updated unit with operators added: https://gitlab.com/-/snippets/2509282
I'm a bit concerned about the double finalization bug but I haven't seen it to show yet.

I'll appreciate further comments and suggestions.

[alpine]

@Kays, @Thaddy
Wouldn't it be better if I renamed them to TRanges or TSubranges in accordance with the Pascal language tradition, e.g. set of [0..15], array[1..100] of ... ? Will this make their purpose more clear?