Date:         Fri, 22 Aug 2003 03:44:40 GMT
Reply-To:     Tim Berryhill <tim@AARTWOLF.COM>
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:         Tim Berryhill <tim@AARTWOLF.COM>
Organization: Aartwolf Technology
Subject:      Re: Tiny Roundoff Errors in 8.2 for Windows

Dear TMK, It is a documented feature.

Most numbers which can be expressed as precise base 10 decimals cannot be
expressed as precise base 16 heximals.  SAS numbers are floating point,
which means base 16 internally.  The amounts the numbers are adjusted when
you round them are not perfect, so that after you add or subtract rounded
numbers you need to round again to keep them pretty.

You might get more acceptable results by formatting your numbers 10.2 (or
one of the financial formats, as long as you specify 2 decimals) for
reporting, including formatting the tr_amount variable.  If your customer
accepts any rounding, they should accept the rounding implicit in the 10.2
format.

My SAS machine is 30 miles away, but I suspect
DIFF=3-(0-3);
will also give you a tiny discrepancy because "twos complement" messed up
the last bit.

Enjoy,
Tim Berryhill

"Talbot Michael Katz" <topkatz@MSN.COM> wrote in message
news:200308220252.h7M2qR707234@listserv.cc.uga.edu...
> Hi, gang.
>
> I seem to be experiencing very small arithmetic roundoff errors in SAS 8.2
> for Windows.  Here is the code snippet :
>
>  run_bal = round(run_bal+tr_amount,0.01);
>  bal_dif = run_bal - prod_balance;
>  tr_amount = -bal_dif;
>  if tr_amount ne round(tr_amount,0.01) then do;
>   put "prec_num = " prec_num " tr_amount not round 27";
>  end ;
>
> Note that run_bal is rounded to 0.01 (i.e., dollars and cents) at the top.
> Prod_balance has also been rounded to 0.01, so bal_dif should be, too.
> But, somehow, tr_amount = -bal_dif is off by about 10**(-12).
>
> Has anyone else experienced something like this?  Is it a documented
> problem?
>
> --  TMK  --