bug#13757: Problems with Guile's number printer

bug#13757: Problems with Guile's number printer

[Andy Wingo]

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 <mhw@netris.org> writes:

> Andy Wingo <wingo@pobox.com> writes:
>
>> On Wed 23 Jan 2013 13:20, Daniel Llorens <daniel.llorens@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/

bug#12216: Problems with Guile's number printer

[Mark H Weaver]

I've pushed 1ea37620c2c1794f7685b312d2530676a078ada7 to stable-2.0,
which fixes our number printer.  Closing this bug.

   Thanks,
     Mark

bug#12216: Problems with Guile's number printer

[Mark H Weaver]

I wrote:
> I've pushed 1ea37620c2c1794f7685b312d2530676a078ada7 to stable-2.0,
> which fixes our number printer.  Closing this bug.

Sorry, I sent this to the wrong bug.  Oops :)

    Mark

bug#13757: Problems with Guile's number printer

[Mark H Weaver]

I've pushed 1ea37620c2c1794f7685b312d2530676a078ada7 to stable-2.0,
which fixes our number printer.  Closing this bug.

   Thanks,
     Mark

bug#14047: more aggressive inlining

[Daniel Llorens]

On Mar 1, 2013, at 10:44, Andy Wingo wrote:

> On Fri 01 Mar 2013 10:01, Daniel Llorens <daniel.llorens@bluewin.ch> writes:
> 
>> scheme@(guile-user)> ,optimize (vector-ref #(1 2 3) 0)
>> $1 = 1
>> scheme@(guile-user)> ,optimize (array-ref #(1 2 3) 0)
>> $2 = (array-ref '#(1 2 3) 0)
> 
> File a bug for this case, this sort of thing is totally fixable :)

So I think this use of array-ref should be inlined.

Same for other simple functions such as e.g.

scheme@(guile-user)> ,optimize (real-part 1+1i)
$1 = (real-part 1.0+1.0i)
scheme@(guile-user)> 

imag-part, magnitude, and so on.

bug#14047: more aggressive inlining

[Andy Wingo]

On Mon 25 Mar 2013 10:42, Daniel Llorens <daniel.llorens@bluewin.ch> writes:

>> On Fri 01 Mar 2013 10:01, Daniel Llorens <daniel.llorens@bluewin.ch> writes:
>> 
>>> scheme@(guile-user)> ,optimize (vector-ref #(1 2 3) 0)
>>> $1 = 1
>>> scheme@(guile-user)> ,optimize (array-ref #(1 2 3) 0)
>>> $2 = (array-ref '#(1 2 3) 0)
>> 
>> File a bug for this case, this sort of thing is totally fixable :)
>
> So I think this use of array-ref should be inlined.
>
> Same for other simple functions such as e.g.
>
> scheme@(guile-user)> ,optimize (real-part 1+1i)
> $1 = (real-part 1.0+1.0i)
> scheme@(guile-user)> 
>
> imag-part, magnitude, and so on.

If you would like to make a precise list, that would be helpful.

Cheers,

A
-- 
http://wingolog.org/

bug#14047: more aggressive inlining

[Daniel Llorens]

On Mar 27, 2013, at 20:31, Andy Wingo wrote:

> If you would like to make a precise list, that would be helpful.


At least everything from §6.6.2.7 to §6.6.2.13 in http://www.gnu.org/software/guile/manual/html_node/

I've noticed that a few of these are already reduced, it seems quite random. For example everything in §6.6.2.8 is reduced, then logand is reduced but logior is not.

odd? *
even? *
quotient
modulo
remainder
gcd
lcm
modulo-expt
exact-integer-sqrt
make-rectangular
make-polar
real-part
imag-part
magnitude
angle
abs
min
max
truncate
round
floor
ceiling
euclidean/, -quotient, -remainder
floor/, -quotient, -remainder
ceiling/, -quotient, -remainder
truncate/, -quotient, -remainder
centered/, -quotient, -remainder
round/, -quotient, -remainder
sqrt
expt
sin
cos
tan
asin
acos
atan
exp
log
log10
sinh
cosh
tanh
asinh
acosh
atanh
logand *
logior
lognot *
logtest
ash *
logcount
integer-length
integer-expt
bit-extract