Hi, I'm redirecting the number printing conversation to bug-guile, so that we can track it. Thanks for the debugging!
On Tue 19 Feb 2013 00:12, Mark H Weaver <m...@netris.org> writes: > Andy Wingo <wi...@pobox.com> writes: > >> On Wed 23 Jan 2013 13:20, Daniel Llorens <daniel.llor...@bluewin.ch> 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 -- http://wingolog.org/
