What does R7RS rule when you use a number literal of unsupported precision?

John Cowan <xxxxxx@ccil.org> schrieb am Sa., 31. Okt. 2020, 20:00:
Kawa actually distinguishes between 1.0e0 and 1.0d0, though they both are wrappers for doubles: the former is a gnu.math.DFlonum instances, whereas the latter is a standard java.lang.Double (which means it interface with Java code better, which knows how to unbox it, but does not fit into the gnu.math.Numeric class hierarchy).  Consequently, the two numbers are not eqv?.  1.0s0 and 1.0f0 are eqv?, however, both being java.lang.Float instances.

I guess the true issue is not "what name?" but "what should happen if you call "make-fnan" on a Scheme without binary32 values?  Should you get a binary64 value, as I have been assuming?  Or is an error better?



On Sat, Oct 31, 2020 at 4:20 AM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
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
>