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

Rounding errors problem

by perlcgi (Hermit)
on Sep 28, 2001 at 15:13 UTC ( #115370=perlquestion: print w/replies, xml ) Need Help??

perlcgi has asked for the wisdom of the Perl Monks concerning the following question:

This is a basic Math question, I think :-) Any help really appreciated. I can't get the following to balance i.e. the total of all line_items ($unconverted_amount) once converted is different to the converted invoice total. Is there a solution? Maybe I don't need Math::BigFloat. The amounts are all in pennies.
sub convert { use Math::BigFloat; my %currency_conv_hash = (IEP=>"EUR",GBP=>"GBP",USD=>"USD",EUR=>"EUR", FFR=>"EUR", NLG=>"EUR", ESP=>"EUR", DEM=>"EUR", ITL=>"EUR", ATS=>"EUR" +, BEF=>"EUR", PTE=>"EUR" ); my %rate_hash = (IEP=>".787564",GBP=>"1",USD=>"1",EUR=>"1", FFR=>"6.55 +957",NLG=>"2.20371", ESP=>"166.386", DEM=>"1.95583", ITL=>"1936.27", +ATS=>"13.7603", BEF=>"16.11", PTE=>"200.482" ); my($source_currency, $unconverted_amount, $unconverted_total_amount) = + @_; my $rate=$rate_hash{$source_currency}; my $line_amount = Math::BigFloat->new($unconverted_amount/$rat +e); my $total_amount = Math::BigFloat->new($unconverted_total_amount +/$rate); return ($currency_conv_hash{$source_currency}, (sprintf "%.0f",$line_ +amount->fround(0)), (sprintf "%.0f",$total_amount->fround(0)) ); } Now when I later total all the line amounts i.e. what is returned by s +printf "%.0f",$line_amount>fround(0)), the total is out by a penny or + so when compared to (sprintf "%.0f",$total_amount->fround(0))
Any assistance hugely appreciated.

Replies are listed 'Best First'.
Re: Rounding errors problem
by Zaxo (Archbishop) on Sep 28, 2001 at 15:33 UTC

    Floating point arithmetic is inherently imprecise. Since you record as pennies, Math::BigInt might be a better choice than Math::BigFloat. Currency exchange rates are, in themselves, a bit fuzzy, so I suggest getting your spec clarified as to how rounding is done, what quotation is used, when the quote is changed, etc. There is an accountant somewhere in this job. There's where to get the real needs.

    Update: If Math::BigInt is overkill, what do you need with Math::BigFloat? To round an ordinary perl number, a float, to an integer ($n+.5)|0 or else sprintf "%.0f",$n. Again, talk to the accountant.

    After Compline,
    Zaxo

      Thanks for the input Zaxo.
      The exchange rates are fixed and are offical Euro exchange rates. The invoice total, before conversion, equals the sum of the line items. After conversion they differ by a penny or so. I need to be sufficiently precise so that they are equal after conversion. The sums are not large, and would not require Math::BigInt.
      Thanks again.
      Perlcgi
        The exchange rates are fixed and are offical Euro exchange rates. The invoice total, before conversion, equals the sum of the line items. After conversion they differ by a penny or so. I need to be sufficiently precise so that they are equal after conversion.
        Maybe you don't get that this is not always possible. For example, consider a series of transactions of 103, 103, and 104 units. Those added together make 310 units. Now convert those into a currency that is 1/10 the size. We round 10.3 to 10 (twice) and 10.4 to 10 (once). The "total" should be 31, but it's really only 30. This is the way this works. You cannot always balance to the penny when you map values from one currency to another and it's considered fair accounting practice to simply note that and move on.

        A parallel example: my brother noted that at a particular Washington State sales tax rate, it was cheaper by a penny to buy two single Big Gulps rung up separately than it was to buy them as a combined transaction. So whenever he had to buy two, he'd always buy one, pay, then buy the second one.

        This is the real world, and it's accepted practice. Don't attempt the impossible. {grin}

        -- Randal L. Schwartz, Perl hacker

Re: Rounding errors problem
by jujubee (Acolyte) on Sep 28, 2001 at 17:00 UTC
    Math::Round was recently updated to deal with floating point rounding. Check out sub nearest(). Cheers...
Re: Rounding errors problem
by Albannach (Monsignor) on Sep 28, 2001 at 19:02 UTC
    For what it's worth, there is a method called "bucket rounding" that is often used in transportation planning (but nowhere else according to google) which can help in this type of problem (within the limits of machine precision). The process is very simple: the "residue" from each rounding operation in a sequence is retained to be applied as a bias to the next one. So for merlyn's example:
    # Value Residue Rounded Comment 1 10.3 0.0 10 0.3 is added to the residue 2 10.3 0.3 11 10.3 + 0.3 = 10.6, which rounds to +11 with -0.4 residue 3 10.4 -0.4 10 ==== ==== 31.0 31
    This is most commonly applied in the factoring of 2D matrices representing trips from location to location. While the value of each cell is not usually affected by a minor rounding error, the total of the matrix needs to be held constant.

    I'm certainly not qualified to say whether this would be appropriate for financial work though.

    --
    I'd like to be able to assign to an luser

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://115370]
Approved by root
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others rifling through the Monastery: (4)
As of 2022-12-06 01:32 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found

    Notices?