Recently I was working a problem of probabilities
and resorted to using logarithms for speed of execution.
Problem was that I ended up with a logarithm that was too
big to be represented in floating point.  My solution was
to do convert all logarithms to (large) integers, do the
calculation, then convert back to log.

This suggests an implementation for big-float: use bignums
with a (settable) scale factor (which corresponds to precision).

Has anyone implemented big-float?

Dave

|   We have bignum.  Why don't we have big-float?
:
|   Has anyone implemented big-float?

CLISP has this.

$ clisp

Floats are basicaly for speed, not high precision.

|   Floats are basicaly for speed, not high precision.

but transcendental functions are usually implemented with floats, even
though most of them can be computed with rationals in series.  this means
that we lose precision in converting from rational to float, and may run
into Dave's original question.  on the other hand, using series to compute
transcendental functions on rationals will require a "cut-off" after a
given precision is reached.  at this point, we might as well implement
"bigflos", and Bruno Haible's CLISP already does that.  unfortunately,
CLISP is byte-compiled and not particularly fast.  it's a tough choice.

(incidentally, several packages exist for C to achieve multiprecision
arithmetic.  they are not very easy to work with.  I think CLISP has done
the right thing when using one such package for Lisp's long float.)

(Btw: Can any symbolic computer algebra system prove that the exact value
of sin(2/7*pi)^-1 + sin(4/7*pi)^-1 - sin(6/7*pi)^-1 is zero?)

Reply-To: j...@macsyma.com

Moreover Macsyma gives more accurate bigfloat results than you show above:

--------------------------------------------------------------------------- --
(c1) expr: sin(2/7*%pi)^-1 + sin(4/7*%pi)^-1 - sin(6/7*%pi)^-1;
                      1           1          1
(d1)              ---------- - -------- + --------
                      3 %pi        %pi        %pi
                  cos(-----)   sin(---)   cos(---)
                       14           7         14

(c2) bfloat(expr);
(d2)                           0.0b0

/* The following is not a proof since it is based on a heuristic procedure
   which analyzes the constituent parts of expressions and determines the
   number of digits necessary to compute an expression to such that if the
   expression is not equivalent to zero you'll get a non-zero result.
   Obviously this doesn't work for all expressions in which case the
   procedure punts. */

(c3) sign(expr);
(d3)                            zero

/* But a proof is easy to come by by just simplifying: */

(c4) trigreduce(ratsimp(expr));
(d4)                             0
--------------------------------------------------------------------------- --