[r6rs-discuss] Confusion over |p

From: Alan Watson <alan>
Date: Fri, 29 Jun 2007 10:24:28 -0500

I am not sure what problem the editors are trying to solve with |p, but
despite this ignorance I am willing, nay, eager to put money on |p not
being the solution.

Here is the problem I want to solve. I want to be able to read IEEE
singles and doubles and have them represented by the nearest inexact
real. I want to be able to write the IEEE single and double that is
nearest to a given inexact real. I am prepared to accept a solution that
works on many but not all implementations and I am prepared to do some
of the work myself.

I can see a number of solutions. First, the input problem:

(a) We keep |p but give is some kind of sane semantics. This is beyond
my ability.

(b) Throw out |p and return to the R5RS syntax for inexact numbers.
Actually, we're a bit better than the R5RS, as I can generate IEEE
single-precision and double-precision values using byte vectors literals
and procedures. Someone smarter than I might be able to wrap this in a
nice macro, which would work well for programs. Data will be a bit
messy, as I will have to process it an convert byte vectors to inexacts
as appropriate.

(c) We throw out |p and return to the R5RS syntax for inexact numbers,
but we encourage (with "should" or "may") implementations to convert
literals with f exponents to IEEE single-precision numbers using IEEE
rounding and then to an internal representation that can accommodate all
IEEE single-precision numbers. Ditto with d and double-precision
numbers. I would leave s and l unspecified, at least in part because
there are no standard IEEE short and long formats (double-extended is
only partially specified).

(d) This is (c), but with *native* singles and doubles and native
rounding rather than IEEE format and rounding. It makes no difference to
me; I've not seen a VAX since 1994 and IBM big iron now has IEEE
support. YMMV.

(e) We throw out |p, but accept that x|p is a perverse notation for a
binary mantissa and, here's an odd concept, *allow* binary, octal, and
hexadecimal mantissas. We keep the exponents in decimal. We remove the
ambiguity in the syntax by requiring a point at the end of the number or
immediately before the exponent (so, #x0e0 is an exact integer not an
inexact zero whereas #x0. and #x0.e0 are inexact zeros).

My favoured option is (e), but some of these options can be combined. In
particular, (c) or (d) and (e) might work nicely together.

Now the output problem. First, we should accept that inexact arithmetic
is ... inexact. Therefore we do the best we can:

(a) We leave |p and do something sane with the precision argument to
number->string. This is beyond my ability.

(b) We throw out |p and the third argument to number->string. I will
have to write IEEE singles and doubles using byte vectors, which won't
work so well for data but I can live with that.

(c) We throw out |p but have some means by which we signal to
number->string that we would like the argument converted to an IEEE
single first and the converted to a string using IEEE rounding. Ditto
for double. If you use this mode, you might lose write-read invariance.

(d) This is (c) with *native* rather than IEEE formats and rounding.

(e) We throw out |p and the third argument to number->string, but allow
2, 8, and 16 as second arguments to number->string for inexact numbers.
We treat conversion to truncated mantissas elsewhere (e.g., we use
things like (number->string (real->single 1.1) 16) when we want to write
the single-precision representation of 1.1 in hexadecimal) and accept
that we will have to write our own versions of things like real->single
and that this might not mesh especially well with all implementations of
inexact arithmetic.

I favor (e) here. Again, it might be combined with (c) or (d).

Regards,

Alan
Received on Fri Jun 29 2007 - 11:24:28 UTC