From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Kevin Ryde Newsgroups: gmane.lisp.guile.devel Subject: Re: scm_i_fraction_reduce thread safety Date: Sat, 13 Dec 2003 09:23:40 +1000 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: <87wu91mxhf.fsf@zip.com.au> References: <3FD85844.3060108@ccrma> <1071170342.1217.60.camel@flare> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1071271712 3011 80.91.224.253 (12 Dec 2003 23:28:32 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 12 Dec 2003 23:28:32 +0000 (UTC) Cc: Bill Schottstaedt , guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sat Dec 13 00:28:23 2003 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AUwhq-0001KV-00 for ; Sat, 13 Dec 2003 00:28:22 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AUxc6-0000XL-7k for guile-devel@m.gmane.org; Fri, 12 Dec 2003 19:26:30 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AUxbe-0000Sa-73 for guile-devel@gnu.org; Fri, 12 Dec 2003 19:26:02 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AUxb0-0008SB-QX for guile-devel@gnu.org; Fri, 12 Dec 2003 19:25:53 -0500 Original-Received: from [61.8.0.36] (helo=snoopy.pacific.net.au) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AUxaz-0008Qz-44 for guile-devel@gnu.org; Fri, 12 Dec 2003 19:25:21 -0500 Original-Received: from mongrel.pacific.net.au (mongrel.pacific.net.au [61.8.0.107]) by snoopy.pacific.net.au (8.12.3/8.12.3/Debian-6.6) with ESMTP id hBCNNpno014055; Sat, 13 Dec 2003 10:23:51 +1100 Original-Received: from localhost (ppp143.dyn11.pacific.net.au [61.8.11.143]) by mongrel.pacific.net.au (8.12.3/8.12.3/Debian-6.6) with ESMTP id hBCNNmxs018636; Sat, 13 Dec 2003 10:23:50 +1100 Original-Received: from gg by localhost with local (Exim 3.35 #1 (Debian)) id 1AUwdI-0000KB-00; Sat, 13 Dec 2003 09:23:40 +1000 Original-To: Carl Witty Mail-Copies-To: never User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3 (gnu/linux) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.lisp.guile.devel:3119 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:3119 Bill Schottstaedt writes: > > I'd vote for a lock, I guess everywhere inspecting the parts of a fraction would need to acquire and release such a lock. Perhaps a macro that did that and delivered out the parts could stop it being too awful when coding. > if it's really an issue. Unfortunately I believe it is, in the new-style free-running concurrent posix threads. It'll be one of those threading things that might almost never actually cause a problem, but alas is not right. > On the need for reduction, I wonder how much of that > notoriety is due to Knuth -- his discussion of this > was in a slightly artificial context, and I've been > intending for a long time to check some "real-world" > situation. I guess +, -, *, / will keep increasing num and/or den (though perhaps with some cancellation in the num for + and -), unless steps are taken at some point. > (I think it's less of a problem than calling gcd all the time). The claim in gmp (without anything actual to cite :-), is that because gcd is O(N^2) it's better to do a couple of smaller one's sooner than to allow a product to accumulate and do a big one later. Of course if one knows or suspects not much cancellation will be possible in a given algorithm, then all theories about automated reductions go out the window. A general purpose fraction type is probably not the tool for the job in that case. Carl Witty writes: > > I think that one way to avoid arbitrarily-bad behavior is to reduce only > if the numerator or denominator is "sufficiently large" (I think this is > at most a constant factor worse than always reducing). mpz_t allocated memory could be counted towards the mtrigger, to provoke a gc when big numbers are using up memory. That's probably a good idea anyway. The gc could nose around and attempt to reduce likely looking big fractions. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel