Re: RFC: Arbitrary-precision floats for Guile

[Mark H Weaver <mhw@netris.org>]

Hans Aberg <haberg-1@telia.com> writes:
>> 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.

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.

>> 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.

>> 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.  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.

      Thanks,
        Mark