On Tuesday, 30 August 2016 18:22:01 UTC+9, Martin Brown wrote:

Having REAL subrange types worries me a bit.

[0..0.1] of REAL will have fence post issues in IEEE FP implementations
since there is no finite representation of 0.1 aka 1/10 in base 2.

There are no fence post issues that wouldn't otherwise exist already without the real number subrange facility.

Consider that ...

[0.0 .. 0.1] OF REAL

internally represents a relational expression

(r >= 0.0 AND r <= 0.1)

and

0.0 .. <0.1] OF REAL

internally represents a relational expression

(r > 0.0 AND r < 0.1)

where r is of type REAL.


Thus when you have ...

TYPE Range = [0.0 .. 0.1] OF REAL;
VAR value : Range; r : REAL;

and subsequently

value := r;

... this will be transformed during compilation into ...

IF r >= 0.0 AND r <= 0.1 THEN
value := r
ELSE
RTS.RaiseRTFault(OutOfRange);
END;

You could write the same already in PIM or ISO M2.

Consequently, if an FP implementation causes fence post issues when encountering a relation of the form (r >= 0.0 AND r <= 0.1), then this would be an issue with that implementation, not an issue caused by the real number subrange facility.


Let's also consider what happens if we use a real number literal in the assignment in place of real variable r.

TYPE Range = [0.0 .. 0.1] OF REAL;
VAR value : Range;

and subsequently

value := 0.0999;

... will be transformed during compilation into ...

IF 0.0999 >= 0.0 AND 0.0999 <= 0.1 THEN
value := 0.0999
ELSE
RTS.RaiseRTFault(OutOfRange);
END;

Here again, you could write the same already in PIM or ISO M2.

It is conceivable that there may be compilers out there (not necessarily M2 compilers) whose FP implementation leads to an incorrect result when evaluating 0.0999 <= 0.1 but that would be an issue with the compiler's FP implementation.

In any event, the real number subrange facility does not by itself introduce fence post issues.


I should like to mention that M2 R10 defines an internal representation for numeric values called scalar exchange format (SXF) which is radix preserving.

Thus in M2 R10, constant folding of an expression of the form

0.0999 >= 0.1

has the semantics

radix10(0.0999) >= radix10(0.1)

and not

radix2(0.0999) >= radix2(0.1)


Many older compilers and languages convert numeric literals during lexing into the internal binary format of a specific type which can then cause rounding issues during constant folding of expressions with decimal literals. It also causes bizarr effects
such as 0 != 0L != 0LL in C.

Over the last 10-20 years there has been a trend to move away from this practise and store numeric literals in internal formats that avoid these undesirable effects. The Go language is one example of this.

Hope this clarifies.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)