On Wed, Mar 22, 2023 at 5:18 PM Bradley Lucier <[email protected]>
wrote:
(a) there should be no f8-storage-class in the SRFI because there's no
> IEEE standard format for 8-bit floating-point numbers;
>
Yes. More broadly, there is not even a single default format.
> (b) unless and until that happens, even if an implementation supports an
> 8-bit format, it shouldn't be called "*the* f8-storage-class" but given
> a different name; and
>
> (c) if the IEEE ever settles on a single standard for 8-bit
> floating-point format, then the name "f8-storage-class" should be
> reserved for a storage-class (if any) supporting that format.
>
I now think these should follow whatever you decide to do about question 1.
1. Should the document say that if a Scheme supports 32- and 64-bit
> IEEE floating-point numbers, then the storage classes
> f{32|64}-storage-class should be reserved for those format?
>
Historically we haven't done that, mostly because Schemes that translate to
C or use C formats often use floats and doubles for f32vectors and
f64vectors respectively, and therefore don't know what format they are
going to get from the C compiler.
>
> 2. If a Scheme supports non-IEEE formats natively (an unlikely
> possibility at this point, I know),
IBM mainframes still use their native formats (where the exponent base is
not 2 but 16) by default, though they also supply IEEE, and this is the
meaning of C float and double on those machines.
In addition, formats that are not IEEE-ish are not uncommon in f8. For
example, an extra magnitude bit may be more important than the sign, and
extending the magnitude range by eliminating the 8 positions used for
infinity and NaN (clamping infinite results and using some conventional
value instead of NaN) may also make sense.
should f{32|64}-storage-class refer
> to the native formats, or should classes for the native formats be
> required to have another name?
>
It's a tradeoff between portability and performance, especially if IEEE has
to be done in software. I am not a numerical programmer, but I'd go for
allowing non-IEEE formats.
Perhaps the SRFI needs a Post-Finalization Note clarifying the
> floating-point storage classes.
>
My current view is that all we need to do is to remove the reference to
f8-storage-class, which will have the effect of making the sample
implementation correct, given that it now supports f16-storage-class.
However, you haven't yet discussed the merits (if any) of my idea to have a
`make-f8-storage-class` procedure that accepts two converters and returns a
new storage class layered on u8-storage-class . It could be generalized to
a constructor that accepts a storage class argument as well as the
converters, perhaps to be called `make-storage-subclass`. This is only a
convenience function, and if you don't like it I'll drop it.
