LanX,
Did you look at the article I quoted?
It has an example of a comparison of Binary Floating Point ( BFP ) and a DFP using both hardware and software to show:
# ./dfp_hw 10 1.000001 60000000
double fund= 10.0000000000 interest= 1.000000999999999917733362053700
Decimal fund= 10.0000000000 interest= 1.000001000000000000000000000000
Print final funds
double fund = 1141973124493563816969240576.0000000000
Decimal fund = 1141973130130727445029596475.9717600000
That's a big difference! The difference starts after '11419731'...
Also, my under graduate degree was in math!
Regards...Ed
"Well done is better than well said." - Benjamin Franklin
| [reply]
[d/l] |
> Did you look at the article I quoted?
No it didn't load, but I never considered leaving my money for 60,000,000 years on a bank account.
Did you read my post about calculating in cents right away?
(The one I linked)
Maybe a lexical option for decimal precision could be a reasonable feature request, such that for precision
2 the literal 10.01 is always internally represented as 1001.
| [reply] |
They example you used cheats by using a number that's rational in decimal but irrational in binary. If they had picked a number that's irrational in both (e.g. 1000001/999999 instead of 1000001/1000000), both the BFP and the DFP calculations would suffer from the same problem.
DFP helps in some cases, but it might not be the best solution.
| [reply] |
Hello ikegami,
Unfortunately, this thread became an accuracy problem/solution discussion.
My original intent was to discuss the Perl beginner's question of " Why isn't Perl as accurate as my calculator? "
Any experienced programmer, engineer, scientist, etc. understands the problems associated with base n arithmetic. The problem for the new user of any programming language ( Perl preferred ) is '...why does Perl give me 1.999999999999999, when my simple calculator gives me the *correct* answer of 2." They really don't care that it's technically correct, because they want the calculator answer.
I contributed to this re-direction by showing that I could get the DFP to work on a Linux box with the software shown in the wiki article. I think the writer of the article wanted to show that the integer part of the result was inaccurate (most articles on binary floating point imply the inaccuracy is only after the decimal point). So then the accuracy became the new issue!
This topic is more about the future of Perl, then about the accuracy of Perl. Just like the calculator designer(s) realized that rounding was an important element if they wanted to sell calculators, I think Perl needs to do a *better* job meeting the expectations of new users.
Let me be the example:
I was a system programmer for 15 years and then later an application programmer for many more years before ever using Perl. My stumbling block in the beginning was 'use strict;'. Today all my scripts have that statement. But in the beginning, I would get cryptic warnings, and when I commented out 'use strict;', the script ran and gave the correct answer. But I had to get a lot more experience with Perl before I understood the warning messages. Now I fix the warning and have a better script!
My original intent was to discuss Decimal Floating Point(DFP) as a way to give calculator like answers for most beginners. When more experienced they could use the speed of binary floating point, but would need to do the rounding themselves.
I hope I clarified my intended topic.
Regards...Ed
"Well done is better than well said." - Benjamin Franklin
| [reply] |
It's not C ... it's math! Hi LanX, why do you keep shouting at perlmonks?
| [reply] |