guile-devel
[Top][All Lists]
Advanced

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

RFC: Arbitrary-precision floats for Guile


From: Mark H Weaver
Subject: RFC: Arbitrary-precision floats for Guile
Date: Tue, 01 Feb 2011 08:57:32 -0500

Hello all,

I want to add arbitrary-precision floats to Guile.
I'd use the mpf_t type from GNU MP.

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.  Procedures that produce inexact numbers (including read and
exact->inexact) would use the precision of the most precise inexact
operand contributing to the result, or the value of the fluid, whichever
is greater.  There would also be a procedure to reduce the precision of
an inexact number to some specified value.  The syntax for inexact
numbers would allow an optional suffix to specify the precision.

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.

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.  The primary motivation would be to
support arbitrary-precision complex numbers, but as an added bonus,
would be able to support exact Gaussian integers.  The existing complex
representation would still be supported in the interests of efficiency.

scm_make_rectangular would automatically choose the right
representation: if the imaginary part was an exact zero, it would simply
return the specified real part.  If both parts were normal floats it
would return the existing fast complex numbers, otherwise it would
return the new more general complex number type.

Now I know we have a release coming soon.  I don't necessarily expect to
get these changes merged before then, although I'm willing and able to
implement all of this in the next week.  However, I was hoping that I
could at least get enough of it into 2.0 so that it could be part of 2.1
without breaking ABI compatibility.  Do you think this is feasible?
If not, would it be possible to delay the release a week or two?

What do you think of this?  Am I crazy? :)

    Best,
     Mark



reply via email to

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