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 inn GUILE rational handling Date: Sun, 24 Dec 2006 12:45:45 +0100 Message-ID: <458E6869.1060402@xs4all.nl> References: <20061224112539.M19482@ccrma.Stanford.EDU> 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 1166960791 30837 80.91.229.10 (24 Dec 2006 11:46:31 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 24 Dec 2006 11:46:31 +0000 (UTC) Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun Dec 24 12:46: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 1GyRo4-0004lZ-KH for guile-devel@m.gmane.org; Sun, 24 Dec 2006 12:46:20 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GyRo4-0003rm-80 for guile-devel@m.gmane.org; Sun, 24 Dec 2006 06:46:20 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GyRny-0003rI-Ou for guile-devel@gnu.org; Sun, 24 Dec 2006 06:46:14 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GyRnw-0003os-TV for guile-devel@gnu.org; Sun, 24 Dec 2006 06:46:14 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GyRnw-0003op-Pp for guile-devel@gnu.org; Sun, 24 Dec 2006 06:46:12 -0500 Original-Received: from [80.91.229.2] (helo=ciao.gmane.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1GyRnw-0000mf-D0 for guile-devel@gnu.org; Sun, 24 Dec 2006 06:46:12 -0500 Original-Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GyRnj-0005dd-O4 for guile-devel@gnu.org; Sun, 24 Dec 2006 12:46:00 +0100 Original-Received: from muurbloem.xs4all.nl ([213.84.26.127]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 24 Dec 2006 12:45:59 +0100 Original-Received: from hanwen by muurbloem.xs4all.nl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 24 Dec 2006 12:45:59 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-To: guile-devel@gnu.org Original-Lines: 42 Original-X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: muurbloem.xs4all.nl User-Agent: Thunderbird 1.5.0.8 (X11/20061107) In-Reply-To: <20061224112539.M19482@ccrma.Stanford.EDU> 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:6364 Archived-At: Bill Schottstaedt escreveu: >> I have removed support for the reduced bit, and put the reduction in >> make_fraction. > > I think it was intended that equal? would use scm_i_fraction_equalp > which reduces both arguments before checking equality. So the > simplest fix would be to mask off the reduced bit in the cell type > in the check for cell type equality in scm_equalp. I would hesitate > to remove support for this bit because it will mean you get gcd > on every integer divide! The current system already slows Guile I think thes best quick fix would be to put the bit into the 4th double cell word. > down by about 10%. On the race condition, my vage recollection > is that the "is this safe?" question was mine, and I hoped at that > time that someone who knew about such things would check it > out -- I believe (it's been a long time since I looked at this stuff) > that if that line is not safe, there are a lot more like it scattered > around Guile, so it's scarcely reason to jettison the entire thing. In that case, we need to fix the more-like-it stuff. Can you point out some of those cases? I'm hesitant to put stuff like this in because 1. it _is_ a race condition 2. if it is triggered, it will be next to impossible to reproduce. In effect this would lead to a once in a million inexplicable corruption. And that's really bad. The correct solution would be a to use a lock-free instruction to swap the old and reduced forms, but I'm not sure if we have those in GUILE. As I explained earlier, the logic for doing reduces or not needs to be more refined. Any program that does serious arithmetic in fractions will likely have exploding memory requirements. -- 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