From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Hans Aberg Newsgroups: gmane.lisp.guile.devel Subject: Re: RFC: Arbitrary-precision floats for Guile Date: Tue, 1 Feb 2011 20:20:16 +0100 Message-ID: References: <878vxzx3g3.fsf@yeeloong.netris.org> <87sjw7vg9s.fsf@yeeloong.netris.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (Apple Message framework v936) Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1296588367 2515 80.91.229.12 (1 Feb 2011 19:26:07 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 1 Feb 2011 19:26:07 +0000 (UTC) Cc: guile-devel@gnu.org To: Mark H Weaver Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Feb 01 20:26:03 2011 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PkLrW-0005rY-7g for guile-devel@m.gmane.org; Tue, 01 Feb 2011 20:26:02 +0100 Original-Received: from localhost ([127.0.0.1]:38143 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PkLmG-0006mn-Hm for guile-devel@m.gmane.org; Tue, 01 Feb 2011 14:20:36 -0500 Original-Received: from [140.186.70.92] (port=52067 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PkLm4-0006kZ-Or for guile-devel@gnu.org; Tue, 01 Feb 2011 14:20:26 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PkLm0-0006P6-GA for guile-devel@gnu.org; Tue, 01 Feb 2011 14:20:23 -0500 Original-Received: from smtp-out21.han.skanova.net ([195.67.226.208]:35674) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PkLm0-0006OE-4o for guile-devel@gnu.org; Tue, 01 Feb 2011 14:20:20 -0500 Original-Received: from [192.168.2.5] (217.210.127.13) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u26619196) id 4D0751710108F238; Tue, 1 Feb 2011 20:20:18 +0100 In-Reply-To: <87sjw7vg9s.fsf@yeeloong.netris.org> X-Mailer: Apple Mail (2.936) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 195.67.226.208 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:11487 Archived-At: On 1 Feb 2011, at 18:03, Mark H Weaver wrote: >>> There would be a fluid whose value would determine the minimum >>> precision >>> to use for inexact operators. A value of #f (the default) would >>> mean >>> that normal floats would be used unless one of the operands was a >>> bigfloat. >> >> Only checking takes a lot of time, so it is best to make a new >> type. Same for integral types. So if speed is an issue, Guile ought >> to >> have C99 integral types. >> >> The name 'floating' seems free for such a type. > > I'm not sure I understand. These type checks would only be added as > additional cases to the generic arithmetic operators, which > unfortunately cannot avoid checking the types of their arguments for > each operation. Sadly this is already the case. Currently Guile > supports fixnums (small integers), arbitrary-precision integers, > arbitrary-precision rationals, IEEE 64-bit floats, and complex numbers > composed of IEEE 64-bit floats. All of these cases must be considered > on each operation. To make matters worse, all of these types except > small integers must be allocated on on the heap. Therefore every > floating point operation involves heap allocation, and additionally > pays > the amortized cost of garbage collecting the number later on. Right. I'm told that overflow checks on integral types typically add the order of ten cycles per arithmetic operation. So that would already be a bottleneck in Guile. > The only additional overhead added to existing floating point > operations > would be to check the value of the fluid. Admittedly this is not > entirely trivial, but I think it will be lost in the noise compared > with > the overheads already present. All those overheads are really going to bog it down, I suspect, if you need something fast. >>> One complication is that we'd have to implement the transcendental >>> functions. However, I already have code to do that, as part of a >>> bigfloat library I wrote a while back. >> >> There is already MPFR, which is a package of top of GMP (see the >> manual of the latter). > > Excellent, thanks for the pointer! MPFR seems to contain all of the > functionality I need, so this will make my job much easier. Why reinventing the wheel? There is a group of maintainers of this package, hard focusing on getting the numerics right. >>> I'd also like to add another more general representation of complex >>> numbers whose real and imaginary parts are each of type SCM, like >>> the >>> way fractions are represented. >> >> One might have a complexification class with one template >> argument. The current Guile 'complex' type is (in my installation) >> the >> complexification of 64-bit IEEE floats. > > Please forgive me if I misunderstand, but it seems to me that you are > thinking in terms of static type checking, which is wholly different > from how Guile operates internally. I just it as a language to describe it. It would be function of types with one parameter. One can implement template using lambda calculus as well, check Template Haskell. > Although I don't see a need for > complex numbers whose real and imaginary parts are of different types, > it would require additional implementation complexity to enforce this > constraint. I'm not sure it's worth the effort. My plan is to simply > call the generic arithmetic operators recursively to operate on the > real > and imaginary parts. > > Have I misunderstood you? I would very much like to understand. The Complexification C(R) of a ring R is a mathematical construction, the set R x R of pairs, written as x + iy where i is a formal symbol, with component-wise addition, and multiplication given by using the rule i^ = -1. So instead of making a new complex type for every numeric type, the idea is to do a one parameter complexification class. I'm not sure how that works out Scheme, but Haskell has such a module.