Algol 68 real vs IEEE 754 vs x86 extended precision

[Jose E. Marchesi]

Hi Chris.

> Hello everyone,
>
> Back with more questions... I hope not too irritating.
>
> Awhile ago, I asked whether we could implement a "real to bits" conversion
> operator similar to BIN which currently converts int to bits; and of course
> the reverse, "bits to real", which is implemented as ABS in the case of
> bits to int.
>
> I've been looking into this and related topics in the context of the IEEE
> 754 that we seem to deal with as a matter of course in today's computing,
> and I see a few sticky points that stem from the x86 extended precision (80
> bit floating point) type:
>
>    1. given that long long int is 128 bits and long long bits is therefore
>    also 128 bits, the concept of op BIN = (L real r) L bits would of needs
>    convert an 80 bit long long real to a 128 bit long long bits value
>    2. can we even define op ABS = (L bits b) L real? or should we rather
>    chose a name like REAL_BIN and BIN_REAL for this pair?
>    3. and whether it's ABS b or BIN_REAL b presumably we would convert a
>    128 bit long long bits value to an 80 bit long long real value

I don't think we can rely on any relationship between reals and bits "of
the same size" the same way we do between ints and bits "of the same
size".

In most targets long long bits will be 64-bit long, not 128.

Widening only works on the int to real direction, for ints and reals "of
the same size".

The BIN operator applied to reals would work in the opposite direction,
but as you observe, a long long real is 80 bits, which will not fit in a
64-bit long long bits.

> Worth mentioning here is that the 80 bit extended form is not just the 128
> bit quad precision form with the rightmost 49 bits chopped off; the 80 bit
> extended form also has a bit for the integral part, which is "assumed" in
> the 128 bit form.
>
> Starting from this confusion (on my part), I've begun to wonder about how
> constants like max_real should be defined in an Algol 68 standard prelude.
> I am tempted to think of them as
>
> real max_real = BIN_REAL 2r0111111111111111;
> long real long_max_real = BIN_REAL 2r0111111111111111111111111111;
> long long real long_max_real = BIN_REAL
> 2r0111111111111111111111111111111111111111111111;
>
> Similarly, and harking back to the discussion over twos-complement and -
> max_int, I feel as though we should define min_real, long_min_real and
> long_long_min_real as the negative minima.
>
> Further, the concept of small_real (and long_small_real,
> long_long_small_real) throws me off given that we have these subnormal
> numbers in IEEE 754.  Should the "small" values be the minimum normal or
> minimum subnormal values, and in either case, what should the other small
> values be called?
>
> We could for instance decide that small_real, long_small_real and
> long_long_small_real refer to the subnormal numbers following the RR
> definition:
>
> L real L small_real= { the smallest L real value such that both
>    L 1 + L small real > L 1 and
>    L 1 - L small real < L 1 (2.2.2.b} };
>
> Yet it seems that it might be better to encourage programmers to work with
> normal values and leave subnormal values for "special occasions".

Would both options be conformant with the RR?

>
> Final preoccupation - it seems to me that we should also directly support
> NaN and infinity, at least with standard prelude constants or operators.

Yes definitely, these identifiers would go in the extended standard
prelude.

> Any thoughts on all of this?