big FLOATS? 
Author Message
 big FLOATS?

i am really enjoying Lisp and its expressive power.  I particularly enjoy
number-theoretic type calculations, and was really pleased to find out
that it has support for rationals, complex numbers, and bignums built
into the language (having come from a C background)

i use maple for Linux, and you can evaluate floats to an arbitrary number
of digits:

sqrt(17*17*19);

     1/2
17 19

evalf(", 99);

that would evaluate the square root to 99 decimal places of accuracy.

i guess you could call these 'bigfloats' ala 'bignums' for.  I
believe Java has such a beast built into it, is there a package I could
get for Lisp which would allow similar calculations?  Wouldn't you
have to have special bigfloat versions of sin, cos, sqrt, expt, log, and
so forth, or could that be integrated into the said functions, as they
already know how to handle bignums,fixnums,rationals, etc.

this reminds me of operator overloading in C++.  What is actually
happening here when I do (+ 4/5 #C(1 1))?  is it using the CLOS
system internally ?  (I am familiar with CLOS in passing, haven't found
the Art of the Metaobject protocol in my library yet .)



Sun, 10 Sep 2000 03:00:00 GMT  
 big FLOATS?

Quote:

> i am really enjoying Lisp and its expressive power.  I particularly enjoy
> number-theoretic type calculations, and was really pleased to find out
> that it has support for rationals, complex numbers, and bignums built
> into the language (having come from a C background)

> i use maple for Linux, and you can evaluate floats to an arbitrary number
> of digits:

> sqrt(17*17*19);

>      1/2
> 17 19

> evalf(", 99);

> that would evaluate the square root to 99 decimal places of accuracy.

> i guess you could call these 'bigfloats' ala 'bignums' for.

CLISP has such big-floats built-in. It does not contain a full computer
algebra system, though, therefore you have to set the precision before
computing the result, not afterwards. Try this:

  (setq *read-default-float-format* 'long-float)
  (setq *default-float-format* 'long-float)
  (setf (long-float-digits) (ceiling (* 99 (log 10 2))))
  (sqrt (* 17 17 19))

Result is

  74.1012820401914503880286937256134662053290667289515639271358503487124745794536874561547056494830569573962

Quote:
> Wouldn't you
> have to have special bigfloat versions of sin, cos, sqrt, expt, log, and
> so forth, or could that be integrated into the said functions, as they
> already know how to handle bignums,fixnums,rationals, etc.

In CLISP, all the built-in functions including sin, cos, sqrt, expt, log
treat bigfloats, and with a reasonable efficiency (O(N^2.5) where N is the
number digits).

Quote:
> What is actually happening here when I do (+ 4/5 #C(1 1))?  is it using
> the CLOS system internally ?

Depends on the implementation. In CLISP, it's done using a normal non-CLOS
dispatch.

                      Bruno



Mon, 11 Sep 2000 03:00:00 GMT  
 big FLOATS?


Quote:


>> What is actually happening here when I do (+ 4/5 #C(1 1))?  is it using
>> the CLOS system internally ?

>Depends on the implementation. In CLISP, it's done using a normal non-CLOS
>dispatch.

I expect this is the case for most implementations.  While there are
techniques for optimizing CLOS dispatch, they're still often too slow for
arithmetic, which is often found in inner loops.  Also, CLOS can't handle
functions with variable numbers of arguments, so plus would have to be
implemented as:

(defun + (&rest args)
  (reduce #'generic-plus args :initial-value 0))

GENERIC-PLUS would then be a two-argument CLOS generic function.  That will
result in quite a bit of generic function dispatching.

The more likely way to implement it is for the + function to scan all the
arguments to determine the type that they should all be coerced to, coerce
them as necessary, and then call an appropriate type-specific routine to
perform the addition.

--

GTE Internetworking, Powered by BBN, Cambridge, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.



Mon, 11 Sep 2000 03:00:00 GMT  
 
 [ 3 post ] 

 Relevant Pages 

1. Biggest float number?

2. why no big-float?

3. Can Python handel bignum or big floating point data type please?

4. A BIG BIG thanks and a merry Xmas

5. BIG problem with BIG designs in SYNOPSYS

6. Examples of big VHDL codes for big Altera chips

7. BIG BIG PROBLEM. Please reply

8. big arrays cause big object files in g77

9. Loading big big images in Tk (with/without Img)

10. Tk and big (BIG) fonts

11. python is growing bigger and bigger!

12. An alternative to floating point (was Re: Floating point non-exactness)

 

 
Powered by phpBB® Forum Software