I've been thinking about the meaning of your proposal.

I think you're saying that

(a) there should be no f8-storage-class in the SRFI because there's no
IEEE standard format for 8-bit floating-point numbers;

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

That brings up the larger issue of what f32-storage-class and
f64-storage-class mean.

The term "IEEE" appears only once in the document, in the discussion of
an example, and not in the context of f{32|64}-storage-class.

I'll ask some questions:

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?

2.  If a Scheme supports non-IEEE formats natively (an unlikely
possibility at this point, I know), should f{32|64}-storage-class refer
to the native formats, or should classes for the native formats be
required to have another name?

Perhaps the SRFI needs a Post-Finalization Note clarifying the
floating-point storage classes.

Brad

On 3/14/23 12:13 PM, John Cowan wrote:
>
>
> On Mon, Mar 13, 2023 at 4:36 PM Bradley Lucier <xxxxxx@math.purdue.edu
> <mailto:xxxxxx@math.purdue.edu>> wrote:
>
>     https://ieeexplore.ieee.org/abstract/document/9515082
>     <https://ieeexplore.ieee.org/abstract/document/9515082>
>
>
> I'm not an IEEE member and this paper isn't in You-Know-Where either, so
> I have no access to it.
>
>     and another paper, 8-bit Numerical Formats for Deep Neural Networks,
>     that investigates one of the issues you mentions, various ways of
>     interpreting the bit patterns of 8-bit floating point and how useful
>     each variation may be:
>
>     https://deepai.org/publication/8-bit-numerical-formats-for-deep-neural-networks <https://deepai.org/publication/8-bit-numerical-formats-for-deep-neural-networks>
>
>
> This paper definitely implies that standardizing on an f8 format is not
> only premature but may be the Wrong Thing.  In addition, squeezing out a
> little bit more range is more important to them than supporting the full
> IEEE range of ±inf.0 and +nan.0.
>
> Matters may have shaken out more by ~2030 when the next revision of IEEE
> 754 can be expected, but I doubt it.  But perhaps you know better than I
> do, being closer to where the rubber meets the road.
>
>     As long as you didn't specifically call an array's getter or setter
>     (explicitly, or implicitly through array-ref, array-set!, etc.) then
>     all
>     the Bawden-style transformations of slicing and dicing and rearranging
>     arrays would work just fine.
>
>
> That's quite true.  You would need to make sure that the relevant
> procedures in the f8-storage-class returned an error.  By the same
> token, the SRFI should specify the array procedures that don't work on
> f8-arrays.  That would be satisfactory.
>
> But I have a more radical proposal.  Remove the f8-storage-class unless
> and until there is a corresponding standard, at which time a new SRFI
> can add it back.  Instead, provide a simple (make-f8-storage-class
> getter-converter setter-converter) that provides a wrapped version of a
> u8 storage class.  The idea is that the getter-converter translates a u8
> Scheme value into whatever floating-point Scheme value would be the
> Right Thing, and the setter-converter is the inverse transformation.
> That allows full use of f8-arrays given a little bit of specialized code
> that understands the particular f8 format in use.
>
> What do you think of this?