Re^2: Decimal Floating Point (DFP) and does Perl needs DFP?

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
[download]

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

Comment on Re^2: Decimal Floating Point (DFP) and does Perl needs DFP? Download Code

Replies are listed 'Best First'.
Re^3: Decimal Floating Point (DFP) and does Perl needs DFP? by LanX (Saint) on Jan 16, 2015 at 21:33 UTC
> 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. Cheers Rolf PS: Je suis Charlie!	[reply]
Re^3: Decimal Floating Point (DFP) and does Perl needs DFP? by ikegami (Patriarch) on Jan 23, 2015 at 20:31 UTC
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]
Re^4: Decimal Floating Point (DFP) and does Perl needs DFP? by flexvault (Monsignor) on Jan 24, 2015 at 12:19 UTC
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]