in reply to Re^8: Reasons for Using Perl 6
in thread Reasons for Using Perl 6

On compound interests, as I already said earlier, I would normally use the standard exponential formulas and, of course, end up with floats. For example, with a 1.6% interest rate over 10 years compound annually and an initial value of 10,000: 
> my $start_val = 10_000;
10000
> my $end_val = $start_val * (1 + 0.016)**10
11720.2555035677
> say $end_val.WHAT
(Num)

[download]
But if I make the same calculation without the exponential formula within a a loop: 
> my $end_val = $start_val;
10000
> $end_val *= 1.016 for 1..10
Nil
> say $end_val
11720.25550356773576542599
> say $end_val.WHAT
(Rat)
> say $end_val.nude
(17464541649174296506384 1490116119384765625)

[download]
As you can see, I still get a Rat. And, BTW, I get a better accuracy with this loop, but, in fact, we don't really care about this better accuracy, since the final monetary amount will be rounded to two decimal places anyway (although you could conceivably find start values for the error on the floating point value would propagate and make a 1 cent difference on the final rounded value). To tell the truth, I was fairly lucky here: with just 11 years, I would no longer get a Rat.

And, of course, the loop will fall back to floats if we compound the interests monthly: 

> my $end_val = $start_val * (1 + 0.016/12)**120
11733.8581431786
> say $end_val.WHAT
(Num)
>
> my $end_val = $start_val;
10000
> $end_val *= 1 + 0.016/12 for 1..120
Nil
> say $end_val
11733.8581431787
> say $end_val.WHAT
(Num)

[download]
We get the same result (there is a rounding difference of 1 on the last digit, but we don't care, it will be rounded to 11,733.86 anyway).

So yes, we often fall back on floats when compounding interests, but that really doesn't matter, nobody cares.

A company for which I worked as a freelance consultant had to spend tens of thousands of euros in a software project to fix invoices which looked wrong because of rounding problems on FP arithmetic inaccuracies. One invoice in tens of thousands looked wrong (the total was actually accurate, but the individual values and subtotals did not seem to match); some consumers complained and the legal and/or tax authorities demanded a correction. All these amounts would have matched properly if the calculations had been done with Perl 6 Rat type.

Replies are listed 'Best First'.
Re^10: Reasons for Using Perl 6
by chromatic (Archbishop) on Jan 04, 2018 at 00:15 UTC
    I get a better accuracy with this loop, but, in fact, we don't really care about this better accuracy, since the final monetary amount will be rounded to two decimal places anyway (although you could conceivably find start values for the error on the floating point value would propagate and make a 1 cent difference on the final rounded value). To tell the truth, I was fairly lucky here: with just 11 years, I would no longer get a Rat.

    Please tell me you don't work on financial applications. This would be unacceptable behavior for any application in my purview.

    (I've recently worked on financial applications. "It doesn't matter" and "it doesn't happen that often" is doubly unacceptable if you care about auditing your finances or if you process more than a few thousand values.)

[reply]
      Please tell me you don't work on financial applications. This would be unacceptable behavior for any application in my purview.
      Then, with all due respect, I am afraid that you probably did not read what I wrote in this post and other posts in this thread with enough care.

      And please don't take my sentences out of context. When multiplying a single value by a single certain factor, whether the 15th decimal place of that factor is accurate or not is usually completely irrelevant. And anyone having worked long enough with finance, accounting and audit departments know that these people care much more about "looking good" than about being accurate. If they cared about accuracy, they wouldn't ask you to fill your monthly time sheets tens days before the end of the month.

[reply]
        If they cared about accuracy....

        It's a curious kind of Rakudo advocacy that responds to "Rakudo doesn't live up to its advocacy in this specific technical place" by insinuating that users are untrustworthy and wrong.

[reply]
        It's all about the rounding. Gotta watch that rounding. On your orders that "didn't look right," did you sum up the items and then round off? You have to round first, then sum.
[reply]
Re^10: Reasons for Using Perl 6
by Anonymous Monk on Jan 03, 2018 at 23:17 UTC
    As you can see, I still get a Rat.
    Now try looping eleven times. It becomes a Num.
    All these amounts would have matched properly if the calculations had been done with Perl 6 Rat type.
    Maybe, maybe not. Did you try implementing it in Perl6 to see if it worked?

    You're saying that Rationals are more accurate, and at the same time "that really doesn't matter, nobody cares." You have a level of cognitive dissonance going on that I just can't seem to break through.

[reply]
      Haha, I missed the fact that you knew 11 times would be a Num. Wow, don't you realize that your post refutes itself? Alright, peace out.
[reply]
        I am not desperately trying to prove something, right or wrong, I am just trying honestly report my findings. I am genuinely sure you can understand this mindset.
[reply]

In Section Seekers of Perl Wisdom