Splitting make-nan John Cowan (30 Oct 2020 22:18 UTC)
Re: Splitting make-nan Marc Nieper-Wißkirchen (31 Oct 2020 08:21 UTC)
Re: Splitting make-nan John Cowan (31 Oct 2020 19:00 UTC)
Re: Splitting make-nan Marc Nieper-Wißkirchen (31 Oct 2020 19:08 UTC)
Re: Splitting make-nan John Cowan (01 Nov 2020 23:48 UTC)

Re: Splitting make-nan Marc Nieper-Wißkirchen 31 Oct 2020 08:20 UTC

R7RS-small defines the characters s, f, d, and l (to be used instead
of the exponent-"e") to write floating-point numbers of varying
precision. This could be reflected by the names chosen for SRFI 208
because there are, potentially, nans for each of these precisions.

make-nan would then correspond to make-nan-e (defaulting to make-nan-d
or make-nan-l, depending on the underlying default floating-point
format).

Marc

Am Fr., 30. Okt. 2020 um 23:18 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>
> I've added `make-nan` to my local copy of SRFI 208, but I haven't published it yet, because there is a problem.
>
> We need two make-nan functions: one returns the Scheme equivalent of a C double, and the other returns the Scheme equivalent of a C float (which is typically exactly the same).  I thought about specifying an extra argument, but it seemed very artificial.
>
> The question is: what should the float32 version be called?  It shouldn't be make-float32-nan, because typically it returns the same as make-nan; that is, not a float32 at all.  make-possibly-reduced-precision-nan seems absurdly verbose even for a Lisp identifier.
>
> The nearest thing to prior art is CL's `float` function, which takes two arguments, a real number x and an optional float y, and returns a float whose value is x but whose precision is the same as y (y defaults to a single-float, as always in CL).  I don't think this is a particularly good design, but it does get the job done.
>
> Any ideas?
>
>
>
> John Cowan          http://vrici.lojban.org/~cowan        xxxxxx@ccil.org
> All "isms" should be "wasms".   --Abbie
>