Re: [s]printf %d oddity

[chas]

Curious indeed! 8.78 does seem to behave peculiarly in this respect. For example:

if(8.78*100==878){print "OK for 8.78\n"} #prints nothing

if(7.78*100==778){print "OK for 7.78\n"}  #prints "OK for 7.78"

etc
chas

[astroboy]

I'd love to see an explanation for this. It's got me doubting Perl as a language for doing even simple calculations. I can't see how this can be put down to rounding errors between binary and decimal

[Joost]

This is *just* what happens when you convert between binary and decimal - see the links I provided in the post below.

update:
Think of it like this: decimal floats are inaccurate too, since they can't represent a rational number like 1/3 in finite notation:

1/3 = 0.333333333333333333....

If all arithmatic was done using decimal notation, assuming a maximum of 10 places you get:

$x = 1/3; #  0.3333333333
$y = $x * 3;
$y == 1 -> false  # $y == 0.9999999999

The same thing happens here, only since humans have a hard time thinking in floating binary, it's much harder to predict where.

[astroboy]

Ok, well since I've had to do most of my financial calculations in PL/SQL in the past since I was dealing with Oracle Financials, I thought I'd try it out:

create or replace function test return varchar2 as
begin
  if (8.78 * 100 = 878) then
     return 'ok';
  end if;
  return 'not ok';
end;
/

SQL> select test from dual;

TEST
-------------------------------------------------------------------
ok

They're dealing with binary and decimal conversions. Now granted, I've had to deal with rounding errors in the past, but not for trivial calculations like the one above. I still contend that in this example, where we're not dealing with repeating numbers, that a language should be able to get it right