Request for comment: a few extensions to the standard prelude, for real numbers

[Paul Leyland]

> Message: 1
> Date: Wed, 10 Dec 2025 20:32:46 -0800
> From: chris hermansen<clhermansen@gmail.com>
> To:algol68@gcc.gnu.org
> Subject: Request for comment: a few extensions to the standard prelude
> 	for real numbers
> Message-ID:
> 	<CACc2_6-G7M+jmxAokXbvbfSRdbkVbgdt10hYZAw-idbUPcDZyg@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hello all,
>
> In another email thread, I commented that it would be useful to have
> something like BIN defined for real to bits conversion and ABS for bits to
> real.  Jose kindly suggested that I prepare a proposal to include this as a
> GNU extension to the standard prelude.
>
> After some thought, I decided to propose two mechanisms that have the same
> objective, which is to facilitate converting binary real numbers to string
> representations of decimal fixed or floating point and vice versa.
>
> Note below I'm using ? (capital L with caron) for SIZETY and # for the
> comment symbol.
>
> The first mechanism is a set of three "getter" operators:
>
> op sign = (? real a) int: (a > ? 0 | 1 |: a < ? 0 | -1 | 0) # this is
> defined similarly to sign for integers #;
> op significand = (? real a) ? int: # return the significand of the ? real
> value a as an integer #;
> op exponent = (? real a) int: # return the significand of the ? real value
> a as an integer #;
>
> and three "setter" operators: op sign = (? real a, int s) ? real: # return an ? real 
> value the same as a but with the sign set to positive if s is greater 
> than or equal to 0, negative if s is less than 0 #; op significand = 
> (? real a, ? int s) ? int: # return an ? real value the same as a but 
> with the significand set to ? int s #; op exponent = (? real a, int e) 
> ? int: # return an ? real value the same as a but with the exponent 
> set to int e #; These three "setter" operators could of course be combined into one
> procedure, something like:
>
> proc to real = (int sign, int exponent, ? int significand) ? real: # return
> a ? real given int sign, int exponent and ? int significand #;
>
> and of course the "getter" operators could be combined into one procedure,
> something like:
>
> proc from real = (ref int sign, ref int exponent, ref ? real significand, ?
> real a) void: # extract sign, exponent and significand from ? real a #;
>
> I can see pros and cons to each approach above, but in both cases I think
> the mechanism provides clarity of intent and leaves the knowledge of the
> hardware representation details to the writer of the operators or
> procedures, and would therefore encourage portability among floating point
> representations.  It lacks obvious means to deal with edge cases such as
> not-a-number, infinity and subnormal numbers; however these could be
> provided as a separate set of operators such as:
>
> op is infinite (? real a) bool: # return true if the value of ? real a
> corresponds to hardware infinity #;
> op is nan (? real a) bool: # return true if the value of ? real a
> corresponds to hardware not-a-number #;
> op is subnormal (? real a) bool: # return true if the value of ? real a
> corresponds to hardware subnormal #;
I would suggest two NAN more operators: "is signalling nan" with a 
meaning obvious to anyone familiar with IEEE 754, and "nan bits" which 
returns an integer with the same bit pattern as the significand. Each 
would have their uses, albeit in rather specialised circumstances. For 
instance, exception handlers may well find them useful to determine what 
subsequent action to take if an exception occurs.

FWIW back in the early 1980s I implemented an entire IEEE 754 
instruction set for a 32-bit for the AMD 2901/2910 bit slice minicomputer.
> Another lacking is knowing the maximum sizes of the exponent and
> significand; this could be dealt with via environment queries in the
> standard prelude, indicating for example the number of bits in exponent and
> significand.
>
> The second mechanism surfaces knowledge of the representation and structure
> of floating point numbers, most probably following the IEEE 754 standard.
>
> In this case, we would define the operators:
>
> op bin = (? real a) ? bits: # return the ? bit pattern of the ? real number
> a #;
> op abs = (? bits a) ? real: # put the ? real number corresponding to the ?
> bits pattern a #;
>
> which are analogous to those defined for ? int values (I believe we would
> have to choose a name other than "abs" for the bits to real transformation
> in order not to conflict with the abs that takes ? bits and returns ? int).
>
> This allows (forces) us to confront the hardware representation directly in
> the use of the conversion routines.  I see this as less desirable than the
> first mechanism because we could end up with hardware representation
> details scattered around other bits of code, meaning the likely first thing
> that would be done with this new conversion pair would be to wrap them in
> the operators (or procedures) described in the first mechanism.
>
> Therefore, my preference would be to implement the first mechanism as a way
> to have efficient conversion from external to internal representation and
> vice versa.
>
> Any and all comments welcomed!

I also prefer the first mechanism. That does not preclude the option of 
providing both. Indeed having both could be very useful. It pre-wraps 
the second set for general use and yet allows low-level bit mangling for 
those who believe they really need that facility.

Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://gcc.gnu.org/pipermail/algol68/attachments/20251211/47ff465e/attachment.htm>