Problems with 'number->string' (was Re: propose deprecation of generalized-vector-*)

[Mark H Weaver]

Andy Wingo <address@hidden> writes:

> On Wed 23 Jan 2013 13:20, Daniel Llorens <address@hidden> writes:
>
>> scheme@(guile-user)> (f64vector-ref #s64(1 2 3) 0)
>> $1 = #.#
>
> Here you are interpreting an int64 as a double, which should work, but
> this printed result is really bizarre and looks like a bug in our number
> printer.  Mark? :)

Yes, our number printer is seriously flawed and needs a rewrite.  It
prints subnormal[1] floats as "#.#", and even in typical cases often
fails to print enough digits to get the same number back when you read
it back in.

Note that this also affects compiled code involving numbers, because the
compiler serializes numbers using 'number->string'.  For example,
(* 1e-155 1e-155) returns #f at the REPL, because peval turns this into
a constant which happens to be a subnormal.  During assembly it serializes
this to "#.#", and then 'string->number' returns #f.

Also, 3.14159265358979323846264338327950288419716939937510582097494, if
compiled, fails to produce the float closest to pi.  (acos -1) works
properly, but only because this expression is not currently folded to a
constant by the compiler.

I've already started work on this (based on "Printing Floating-Point
Numbers Quickly and Accurately" by Burger and Dybvig) but got
distracted.

     Mark

[1] http://en.wikipedia.org/wiki/Subnormal_number