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 - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen _______________________________________________ Guile-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/guile-devel
