1. FP accuracy
Let's get real about this. The are infinitely many real numbers that cannot
be represented exactly with a finite number of bits--perhaps the most
commonly encountered: 1/3. Note that decimal can't represent this in a
finite number of digits either.
The significance of this is that there will be "fuzz" in fp calculations no
matter how many bits/digits are used. The advantage of using more
bits/digits is that the fuzz occurs in the least significant places--so it
would seem that more bits is always better, but there is the tradeoff of
accuracy vs. speed and storage size.
Euphoria's accuracy is good enough for most purposes, in the rare cases
where it isn't there are two alternatives:
1. If you can afford to lose speed, use or write a specialized library in
Eu.
2. If not, use assembly--but be aware, you will never get better than 80-bit
accuracy on Intel hardware, unless you use alternative 1 in assembly (which
will cost speed).
-- Mike Nelson
2. Re: FP accuracy
- Posted by a.tammer at hetnet.nl
Jun 06, 2002
HEAR, HEAR!!
Let's end it.
The lib is there to build on for real math-heads.
It's called adame.e, Mike.
For the rest of you, thr limits I stated in this
thread were far too LOW. Real limits are:
Your reserve in free_mem+ available diskspace-
program to be ran /16
So calculate the limits for your own setup
EUrs, a@t
3. Re: FP accuracy
> Therefore, Eu only properly represents an infinitesimal amount of the
> numberline (even if we only talk about 0 to 1e-300). Rob, please explain
> why you left out so many numbers! :P
LOL! I just graduated from an Algebra II college course and I wish I'd had
these things to say during class! I think people woulda thought me even
weirder... ;)
Matt, thanks for the laugh. :)
Now, everybody shut up and get back to programming the next killer app.
Thanks,
ck
