f8 representation Alex Shinn (17 Feb 2021 10:24 UTC)
Re: f8 representation Bradley Lucier (17 Feb 2021 18:55 UTC)
Re: f8 representation John Cowan (17 Feb 2021 21:33 UTC)
Re: f8 representation Alex Shinn (18 Feb 2021 12:21 UTC)
Re: f8 representation John Cowan (18 Feb 2021 15:29 UTC)
Re: f8 representation Alex Shinn (19 Feb 2021 01:15 UTC)
Re: f8 representation Lucier, Bradley J (19 Feb 2021 01:29 UTC)
Re: f8 representation Alex Shinn (21 Feb 2021 01:16 UTC)

Re: f8 representation Alex Shinn 19 Feb 2021 01:14 UTC

On Fri, Feb 19, 2021 at 12:29 AM John Cowan <xxxxxx@ccil.org> wrote:
>
> On Thu, Feb 18, 2021 at 7:21 AM Alex Shinn <xxxxxx@gmail.com> wrote:
>
>> Yes, that's a sensible implementation, but my question was what are
>> those 256 values?
>
> The user decides on a particular value set and binds the parameter to it, according to the needs of the application.  This could be your 1.5.2 or WP's 1.4.3 (the first table) or 1.4.3.-2 (the second, integer-only, table with an exponent bias of -2).  Even 0.4.4 is practical when all values are known to be nonpositive, in which case (- 2.0t0 3.0t0) => 0.0t0, (using "t" as the ad hoc exponent marker for "tiny") as it is the smallest value in the table.

There is no such parameter in the SRFI, and I think this would be a bad idea.
f8 vectors generated with different values of that parameter would be
incompatible,
despite having the same storage class.  Better to have a separate storage class
for each variant.

And whether using parameters or separate variants, f8-storage-class still needs
a default specification.  I think you want to make it implementation
defined, but
then I wonder if it is of any use.  Regardless, as an implementor I
would like to
have agreement with other implementors on a sensible default.

--
Alex