BlackBox Component Builder Forums

adimetrius wrote: What does 'contained' mean? Is it ∈?

I probably agree with you!

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.)

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?

Again, slightly confused by your comment, but think I agree with it.

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 $.)

Yes, under ∈ I meant 'interval' rather that set membership, I agree with your pedantical wording.

Thank you very much! My request is exhausted. I am relieved to know that SHORT is not required in short := SHORT(0.3); even more so - that the Language Report is coherent. I have implemented the REAL type rules we had discussed in Herschel.