[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Serious bug in GUILE rational handling.

From: Han-Wen Nienhuys
Subject: Re: Serious bug in GUILE rational handling.
Date: Sun, 24 Dec 2006 01:59:07 +0100
User-agent: Thunderbird (X11/20061107)

Kevin Ryde escreveu:
>> Suppose another thread triggers scm_i_fraction_reduce at the same
>> time, and reads the partial result of the first scm_i_fraction_reduce.
>> This is really insidious, as the corruption would happen upon reading
>> the data, and will show up somewhere completely different.
> Yep.  I think I might have raised that when fractions were introduced,
> then promptly never did anything about it.  My best idea at the time
> was if fractions are stored unreduced then gc would be a good
> thread-safe place to look for reductions to save space.
> I don't know if reduced or unreduced is a better representation.  My
> guess would be that gcds are so horrendously expensive that unreduced
> is often what you want, if it's do-able.  Reducing lazily sounds like
> the best of both worlds, but as you point out would need multithread
> protection.

Is there any data to back this up?  Once the numbers get beyond the
size of fixnum (and that can happen in just a couple of additions), we
have extra allocation overhead of 2 double cells per fraction (for
mpz), and from then on each addition will double the memory use.

Without reduction, doing a significant loop in fractional arithmetic
would make GUILE go trashing.  Have a look at the memory footprint of 

  (apply + (map (lambda (x)  1/10000) (iota 10000)))

At the least, a reduction should happen before trying to make a fraction 
that exceeds fixnum for numerator and/or denominator.  

 Han-Wen Nienhuys - address@hidden -

reply via email to

[Prev in Thread] Current Thread [Next in Thread]