Yesterday I was lisping some statistics so I needed e, considering I
couldn't find it at hyperspec (too much coffein I guess) so I used
(exp 1) => 2.7182818 but author of the stat book seemed to have
different idea about some digits. So I've done this to calculate
accuracy of e , actually it's power n:
;;;; Exponent of e
;;; e is the base of the natural logarithms
;;; 1 n
;;; calculated as e =(1 + - )
;;; n
;;; or in lisp
(defun calculate-e (n)
(expt (+ 1.0 (/ 1.0 n)) n))
;;; value of e of your lisp
(defvar *implementation-e* (exp 1))
;;; Calculate the n of your lisp implementation
(defun trial (start step implementation-e)
(let ((n start)
(e 0))
(loop
(setq e (calculate-e n))
(cond ((< e implementation-e)
(incf n step))
((= e implementation-e)
(return (values n nil)))
(t
(return (values (- n step) (/ step 2))))))))
(defun find-n (implementation-e)
(let ((start 1)
(stop 1))
(loop
(multiple-value-bind (n s)
(trial start stop implementation-e)
(if (null s)
(return (* 1.0 n))
(setq start n
stop s))))))
(find-n (exp 1))
=>3017.9849
The problem is that I'm using single-float here so I'm using accuracy
very quickly (around n =1000) how to tell lisp that my numbers are
long-floats or made my program use bignums.
so I could do calculate n of numbers like 2.71828182845904523536
On 30 May 2007 00:19:57 -0700, fireblade <·················@gmail.com> wrote:
> Yesterday I was lisping some statistics so I needed e, considering I
> couldn't find it at hyperspec (too much coffein I guess) so I used
> (exp 1) => 2.7182818 but author of the stat book seemed to have
> different idea about some digits.
This looks like the correct approximation for 8 digits to me. If the
author of your book thinks that some of the digits should be
different, then maybe you need another book.
If you need more digits, try (EXP 1D0).
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
(message (Hello 'Edi)
(you :wrote :on '(Wed, 30 May 2007 09:26:35 +0200))
(
??>> Yesterday I was lisping some statistics so I needed e, considering I
??>> couldn't find it at hyperspec (too much coffein I guess) so I used
??>> (exp 1) => 2.7182818 but author of the stat book seemed to have
??>> different idea about some digits.
EW> This looks like the correct approximation for 8 digits to me.
btw, in CLISP:
[1]> (exp 1l0)
2.7182818284590452354L0
[2]> (exp 1d0)
2.718281828459045d0
[3]> (exp 1.0)
2.7182817
last value looks a bit strange, double and long versions have all digits
correct.
f>>how to tell lisp that my numbers are
f>>long-floats or made my program use bignums.
if this was a question, in CLISP you can control how long long numbers are.
(SETF (EXT:LONG-FLOAT-DIGITS) digits)
to tell that number is long, use 1.0L0 etc.
when i was in the University, i've made numeric DE solving in CLISP using
longer long numbers, and this saved me from some weird errors that other
people with doubles had. but it's a bit slow :).
only change to use bignums is to use only rational arithmetic, no "expt" and
other functions allowed.
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"I am everything you want and I am everything you need")
In article <·························@news.sunsite.dk>,
"Alex Mizrahi" <········@users.sourceforge.net> wrote:
> (message (Hello 'Edi)
> (you :wrote :on '(Wed, 30 May 2007 09:26:35 +0200))
> (
>
> ??>> Yesterday I was lisping some statistics so I needed e, considering I
> ??>> couldn't find it at hyperspec (too much coffein I guess) so I used
> ??>> (exp 1) => 2.7182818 but author of the stat book seemed to have
> ??>> different idea about some digits.
>
> EW> This looks like the correct approximation for 8 digits to me.
>
> btw, in CLISP:
>
> [1]> (exp 1l0)
> 2.7182818284590452354L0
> [2]> (exp 1d0)
> 2.718281828459045d0
> [3]> (exp 1.0)
> 2.7182817
>
> last value looks a bit strange, double and long versions have all digits
> correct.
What do you get if you simply type:
2.7182818
?
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
(message (Hello 'Barry)
(you :wrote :on '(Wed, 30 May 2007 05:33:10 -0400))
(
??>>>> Yesterday I was lisping some statistics so I needed e, considering I
??>>>> couldn't find it at hyperspec (too much coffein I guess) so I used
??>>>> (exp 1) => 2.7182818 but author of the stat book seemed to have
??>>>> different idea about some digits.
??>> 2.7182817
??>> last value looks a bit strange, double and long versions have all
??>> digits correct.
BM> What do you get if you simply type:
BM> 2.7182818
BM> ?
it gets converted to ..17. it appears that single-presision IEEE 754 numbers
are not able to represent that decimal value correctly. so i wonder how did
OP get that result. maybe implementation with some other FP numbers..
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"I am everything you want and I am everything you need")
Thanks everybody I'll try with long-floats declarations and using the
d0 suffix.
On May 30, 1:17 pm, "Alex Mizrahi" <········@users.sourceforge.net>
wrote:
> (message (Hello 'Barry)
> (you :wrote :on '(Wed, 30 May 2007 05:33:10 -0400))
> (
>
> ??>>>> Yesterday I was lisping some statistics so I needed e, considering I
> ??>>>> couldn't find it at hyperspec (too much coffein I guess) so I used
> ??>>>> (exp 1) => 2.7182818 but author of the stat book seemed to have
> ??>>>> different idea about some digits.
>
> ??>> 2.7182817
> ??>> last value looks a bit strange, double and long versions have all
> ??>> digits correct.
>
> BM> What do you get if you simply type:
> BM> 2.7182818
> BM> ?
>
> it gets converted to ..17. it appears that single-presision IEEE 754 numbers
> are not able to represent that decimal value correctly. so i wonder how did
> OP get that result. maybe implementation with some other FP numbers..
>
> )
> (With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
> "I am everything you want and I am everything you need")
It's LW 5.0.1 result with type-of single-float
On 30 May 2007 05:10:07 -0700, fireblade <·················@gmail.com> wrote:
>> it gets converted to ..17. it appears that single-presision IEEE
>> 754 numbers are not able to represent that decimal value
>> correctly. so i wonder how did OP get that result. maybe
>> implementation with some other FP numbers..
>
> It's LW 5.0.1 result with type-of single-float
Note that the CLHS says that "implementations of EXPT are permitted to
use different algorithms for the cases of a power-number of type
RATIONAL and a power-number of type FLOAT." There'll likely be a
difference between (EXPT 1) and (EXPT 1s0).
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
On Wed, 30 May 2007 14:17:09 +0300, "Alex Mizrahi" <········@users.sourceforge.net> said:
| ...
| ??>> 2.7182817
| ??>> last value looks a bit strange, double and long versions have all
| ??>> digits correct.
| BM> What do you get if you simply type:
| BM> 2.7182818
| BM> ?
| it gets converted to ..17. it appears that single-presision IEEE 754 numbers
| are not able to represent that decimal value correctly.
No base-power-of-2 floating-point representation, including IEEE
754, can represent either 2.7182817 or 2.7182818 _exactly_; all of
them can, of course, represent both numbers _correctly_ according to
the rules of floating-point representations...
---Vassil,
in pedantic mode...
--
The truly good code is the obviously correct code.
fireblade wrote:
> Yesterday I was lisping some statistics so I needed e, considering I
> couldn't find it at hyperspec (too much coffein I guess) so I used
> (exp 1) => 2.7182818 but author of the stat book seemed to have
> different idea about some digits. So I've done this to calculate
> accuracy of e , actually it's power n:
> ;;;; Exponent of e
>
> ;;; e is the base of the natural logarithms
> ;;; 1 n
> ;;; calculated as e =(1 + - )
> ;;; n
> ;;; or in lisp
I forget whether you're going to have some issues with rounding error or
not, when using that formula. You may want to check a proper numerics
manual (NOT "Numerical Methods") to be sure.
mfh