Re: Serious bug in GUILE rational handling.

[Han-Wen Nienhuys]

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 - http://www.xs4all.nl/~hanwen