guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RFC: Arbitrary-precision floats for Guile


From: Hans Aberg
Subject: Re: RFC: Arbitrary-precision floats for Guile
Date: Tue, 1 Feb 2011 20:20:16 +0100

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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]