Zack: If MzScheme indeed prints that, it is violating the Scheme standard, which requires that all inexact numbers be printed using the nearest exact numeral. Python is doing the right thing.

My perspective about analyzing the above code in java would be,

BUG:
Total:9.879999999999999
Expected:
Total:9.88
Problem description:
In Java floating points are expressed as fractions in binary formats , so using double as data type for these would have caused the problem.

Solution:
Quick Fix:

1.Use float instead of double that would give the exact answer need for this case.
2.In case if the double is needed in anyways then use NumberFormat class to format the output

Original Solution:
1.Use BigDecimal and NumberFormat class to format the output.

Any language used by folks who might use money to do anything, needs a Money or Currency intrinsic type so that rookie programmers don’t shoot themselves in the feet using floating point.

I’m not asking for Euro to Pounds Sterling to Dollars, just a Money datatype.

I see this from an user perspective.If you see realistic currencies,you can maximum pay to someone for 2 decimal points,you can pay for figures like 12.3456 and all .. you can max pay for 12.34

So the best deal would be to use double for calculations since it takes care of decimal issues by default or use explicit type conversion to float or use BigDecimal whatever but keep it rounded to 2 decimal points at the end when the results are shown to the user.

Cheers
Ram

class phew {
public static void main( String[] args ) {
double price = 5.89, tax = 3.99;
System.out.println( price + ” + ” + tax + ” = ” +
(price + tax) );
// ( java.lang.Math.round( 100 * (price + tax) ) / 100.00 )
}
}

5.89 + 3.99 = 9.879999999999999

>(9.879~) == (9.88)
>Not approximately – exactly.

Ok fair point. I’d already forgotten http://en.wikipedia.org/wiki/0.999… after reading it a few months ago.

I’ll have to fall back on arguing that 9.88 is a better representation for the users in this case.