From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Han-Wen Nienhuys Newsgroups: gmane.lisp.guile.devel Subject: Re: Serious bug in GUILE rational handling. Date: Sun, 24 Dec 2006 01:59:07 +0100 Message-ID: <458DD0DB.10302@xs4all.nl> References: <458D900F.1020108@xs4all.nl> <87slf66vw6.fsf@zip.com.au> Reply-To: hanwen@xs4all.nl NNTP-Posting-Host: dough.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1166921970 27429 80.91.229.10 (24 Dec 2006 00:59:30 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 24 Dec 2006 00:59:30 +0000 (UTC) Cc: schottstaedt@ccrma.stanford.edu, guile-devel@gnu.org, Jan Nieuwenhuizen Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun Dec 24 01:59:29 2006 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by dough.gmane.org with esmtp (Exim 4.50) id 1GyHi2-00059K-Vh for guile-devel@m.gmane.org; Sun, 24 Dec 2006 01:59:27 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GyHi2-00063F-5I for guile-devel@m.gmane.org; Sat, 23 Dec 2006 19:59:26 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GyHhw-00062T-US for guile-devel@gnu.org; Sat, 23 Dec 2006 19:59:21 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GyHhr-00060Y-EC for guile-devel@gnu.org; Sat, 23 Dec 2006 19:59:18 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GyHhr-00060U-6R for guile-devel@gnu.org; Sat, 23 Dec 2006 19:59:15 -0500 Original-Received: from [194.109.24.29] (helo=smtp-vbr9.xs4all.nl) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GyHhn-0000hg-J5; Sat, 23 Dec 2006 19:59:11 -0500 Original-Received: from [192.168.123.187] (muurbloem.xs4all.nl [213.84.26.127]) (authenticated bits=0) by smtp-vbr9.xs4all.nl (8.13.8/8.13.8) with ESMTP id kBO0x7l4023238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 24 Dec 2006 01:59:08 +0100 (CET) (envelope-from hanwen@xs4all.nl) User-Agent: Thunderbird 1.5.0.8 (X11/20061107) Original-Newsgroups: gmane.lisp.guile.devel Original-To: Kevin Ryde In-Reply-To: <87slf66vw6.fsf@zip.com.au> X-Virus-Scanned: by XS4ALL Virus Scanner X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:6360 Archived-At: 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 - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel