I probably agree with you!adimetrius wrote: What does 'contained' mean? Is it ∈?
If by "e" you mean set membership I might, rather pedantically, word it differently by saying the value (say x) must lie in the interval or range MIN(SHORTREAL) ≤ x ≤ MAX(SHORTREAL) rather than saying x is contained in some set.
But if you want to say x is a member of the set of numbers in the interval MIN(SHORTREAL) to MAX(SHORTREAL) inclusive that is fine by me.
Of course ± INF are also allowed.
(Note that Appendix C does not include -INF or NaN. -INF is an omission, and NaN is also assumed by the important library Math.)
Again, slightly confused by your comment, but think I agree with it.byte := 1;
byte: BYTE; 1: INTEGER (according to 3.2); 1 ∈ [0..255] => byte and 1 are assignment compatible according to (5).
short := 1. / 3.
short: SHORTREAL; 1./3.: REAL (according to 3.2); 1./3. ∈ [MIN(SHORTREAL)..MAX(SHORTREAL)] => short and 1./3. are assignment compatible according to (5).
Is this how you also interpret 'contained'? And are you saying this should be regarded as correct despite the precision loss?
Take a simpler example: the constant 0.3. It is in the range of SHORTREAL numbers (and REAL numbers).
It is not exactly representable by either a SHORTREAL or REAL variable.
But we can assign this constant to either a SHORTREAL or REAL variable, and in either case we have to accept a precision loss.
If only exactly representable numbers were permitted we would have to write
x := 0.299999999999999988897769753748434595763683319091796875 - if x is REAL
or
x := 0.300000011920928955078125 - if x is SHORTREAL,
and this would be completely impractical.
Most computer arithmetic involves approximations, and users of types like REAL or SHORTREAL accept that. Exact results, like in the previous sentance, require specialist and expensive software. (Expensive means run-time & memory, not $.)