[Top][All Lists]

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

Re: RFC: Arbitrary-precision floats for Guile

From: Andy Wingo
Subject: Re: RFC: Arbitrary-precision floats for Guile
Date: Tue, 01 Feb 2011 21:37:25 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)

Hi Mark,

On Tue 01 Feb 2011 14:57, Mark H Weaver <address@hidden> writes:

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

What other procedures would use this fluid?  Can you enumerate them?

In (* inum flonum bigflonum), with what precision would the first
multiplication be performed?  Note that currently the compiler compiles
it as (* (* inum flonum) bigflownum).

I would like to avoid adding more core numeric types during the 2.0.  I
don't think we have time for a full implementation of this before 2.0,
either.  Is there a minimal change that you can make that adds this

The same consideration applies to exact complex numbers.  I wonder
though: could we keep things simple and just have complex components as
SCM values?  In the common flonum case, we can allocate the SCM values
inline, at the end of the complex SCM object.  That's probably enough of
a performance win that we can claim victory there, and avoid two kinds
of complex numbers.

Also, I would like for the mpfr dependency to be optional, if possible.

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

Possibly :)  If it makes it in, great.  ~Small changes can go into 2.0,
at this point.  But if it doesn't, that will just be a good reason to
get a 2.2 out soonish.



reply via email to

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