Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw
 
PerlMonks  

Re^10: Reasons for Using Perl 6

by chromatic (Archbishop)
on Jan 04, 2018 at 00:15 UTC ( #1206655=note: print w/replies, xml ) Need Help??


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

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.)

Replies are listed 'Best First'.
Re^11: Reasons for Using Perl 6
by Laurent_R (Canon) on Jan 04, 2018 at 08:29 UTC
    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.

      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.

        I certainly did not say (nor even insinuated) that "users are untrustworthy and wrong," but only that some types of users (namely finance and audit people in that case) very often don't have accuracy as a top item in their agenda. They may very well be right from their own standpoint. Whether I agree or not with their priorities is fairly irrelevant.

        The example of monthly time sheets that you have to submit ten days before the end of the month was not just a joke: it's a clear symptom that they care about having data early, but not about having correct data. If that's their priority, so be it! I don't particularly care about their priority. But they should probably not be taken as an example of people particularly rigorous on correctness and accuracy.

      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.
        Yeah, thanks, I have been in the business of data quality for a large financial application running in several different countries for long enough, I know very well how to make things look right, rounding first and then summing.

        But that's precisely my point. Making the thing look right this way is likely to make the sum less accurate (especially when they insist at the same time on using rounding methods that will not even out rounding errors in a large sum and will tend on average to make the sum slightly larger than reality -- but that's a different story).

        And that's exactly what I was saying about people in finance, accounting and audit departments: they want things to "look right" much more than they want the calculation to be accurate.

        I can perfectly understand their concerns and I have no problem with these choices. It even happened at least two or three times that I was the one who suggested them the solution to round first and then sum, as a way to get exactly the look they wanted, but warning them at the same time that it would make the calculations less accurate. In at least one occasion, I even prepared a detailed spreadsheet showing what happened depending on where the rounding was made in a number of scenarios and pointing out that it would look right but be slightly inaccurate in a relatively significant percentage of the invoices (usually just one or two cents above the real amount). They were really unimpressed about lesser accuracy to put it mildly (in fact they didn't give a sh*t about it) and they jumped on the solution that looked right.

        So, again, I am not criticizing their choices, but, contrary to what has been said by another monk before, these people should hardly be given as an example of rigor and accuracy.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1206655]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others taking refuge in the Monastery: (6)
As of 2018-08-18 17:59 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Asked to put a square peg in a round hole, I would:









    Results (185 votes). Check out past polls.

    Notices?