Strange results when adding two double primitives - Java 1.5.0_04

C

Chris Brat

Hi,

I've found this little oddity in the application I'm working on where
the result of adding two double primitives gives a result that either
has an extra 0.0000000000000002 or it is 0.0000000000000001 less than
the expected result.

This sample app illustrates it.

Does anyone know why this happens ?

Thanks
Chris



public class A {

public static void main (String[] args){
double a = 67.41;
double b = 51.85;
double result = a + b;

// I get 119.25999999999999
System.out.println(result);



a = 1.01;
b = 2.02;
result = a + b;

// I get 3.0300000000000002
System.out.println(result);

a = 1.100;
b = 2.103;

result = a + b;
// 3.2030000000000003
System.out.println(result);
}
}
 
M

Mike Beaty

I recently ran into this when doing an 80%/20% split on a number,
storing it and then trying to put those two parts back together. It's
crazy that the Java language can't handle this and provide the expected
results. They are saying it's not a defect it's a feature...I wish I
could use that one.

-Mike
 
O

opalpa opalpa

Mike said:
I recently ran into this when doing an 80%/20% split on a number,
storing it and then trying to put those two parts back together. It's
crazy that the Java language can't handle this and provide the expected
results. They are saying it's not a defect it's a feature...I wish I
could use that one.

How numbers are stored in computer memory is introductory programming
material. There is wide consensus on storing real numbers in finite
sequences of bits. The Java language handles the situation according
to this cosmopolitan consensus.

The Java language is ready to accomodate your needs in various ways. I
suspect a little programming education will go a long ways for you.

All the best,
opalpa
(e-mail address removed)
http://opalpa.info/
 
T

Thomas Weidenfeller

Mike said:
I recently ran into this when doing an 80%/20% split on a number,
storing it and then trying to put those two parts back together. It's
crazy that the Java language can't handle this and provide the expected
results. They are saying it's not a defect it's a feature...I wish I
could use that one.

You have done a serious design mistake if you design software using
float or double and expecting unlimited accuracy. This is not something
new. It wasn't just discovered yesterday. It dates back to the dawn of
computers. It happens with every language which uses the typical
fixed-length mantissa + exponent representation internally.

I looked at the rants in the bug report. Boy, don't these kids learn
anything in school any more?

And I am not talking about knowing the precise internal format of IEEE
754. I am talking about basic things like knowing that 0.1 in base ten
is a periodic number in base two. So it can hardly be accurately
represented in a fixed amount of bits. Or just applying some basic
logic. It is logical that not every existing real (in the mathematical
sense) number can be represented with a fixed amount of bits. Simply
because there is an infinite amount of real numbers.

Do they really not teach these basics any more?

Shocking, shocking ...

/Thomas
 
M

Mike Beaty

The Java language is ready to accomodate your needs in various ways. I
suspect a little programming education will go a long ways for you.

Mike Beaty --> MBA, BBA, SCJP, SCWCD

I suspect I was just stating an opinion that the Java language should
handle this mathematical inaccuracy, even though it is a commonly
accepted defect.
 
M

Mike Beaty

I f*cking forgot okay...suck my fukkin a$$.

I try and try, but I hate these friggin' newsgroups. All you do is try
to help somebody and friggin' arrogant a-holes like you jump all over
my case, trying to act like you're all high and mighty. You know,
being a wanna-be know-it-all doesn't make people respect you more.

Newsgroups suck...you can all kiss my a$$!!!!!
 
P

Patricia Shanahan

Chris said:
Hi,

I've found this little oddity in the application I'm working on where
the result of adding two double primitives gives a result that either
has an extra 0.0000000000000002 or it is 0.0000000000000001 less than
the expected result.

No matter what radix is used, there will be some rationals that cannot
be represented exactly as an integer scaled by a power of the radix,
leading to rounding error.

For many applications, the radix does not matter to the application. For
example, some applications do calculations whose infinitely precise
result is irrational, and, short of symbolic math systems, rounding
error is inevitable. Two is the best radix for very compact, high
performance hardware implementation.

However, it is also a reality that, for some applications, those numbers
that are exactly representable with radix 10 are particularly important.
That is why Java provides the class java.math.BigDecimal. It gives up
some of the efficiency of double, but gains exact representation of any
decimal fraction. Here is your program, converted to use BigDecimal:

import java.math.BigDecimal;

public class BigDecimalTest {

public static void main(String[] args) {
// double a = 67.41;
BigDecimal a = new BigDecimal("67.41");
// double b = 51.85;
BigDecimal b = new BigDecimal("51.85");
// double result = a + b;
BigDecimal result = a.add(b);
//
// // I get 119.25999999999999
System.out.println(result);
//
//
//
// a = 1.01;
a = new BigDecimal("1.01");
// b = 2.02;
b = new BigDecimal("2.02");
// result = a + b;
result = a.add(b);
//
// // I get 3.0300000000000002
System.out.println(result);
//
// a = 1.100;
a = new BigDecimal("1.100");
// b = 2.103;
b = new BigDecimal("2.103");
//
// result = a + b;
result = a.add(b);
// // 3.2030000000000003
System.out.println(result);
}

}

Output:

119.26
3.03
3.203

Note that, in this particular case, you could have got the ideal output
by just using DecimalFormat or System.out.printf to print the doubles
rounded to a reasonable precision. However, with more significant digits
in the inputs, or a lot more steps in the calculations, the rounding
error could affect digits that matter.

Patricia
 
O

Oliver Wong

Thomas Weidenfeller said:
I looked at the rants in the bug report. Boy, don't these kids learn
anything in school any more?
[...]

Do they really not teach these basics any more?

Shocking, shocking ...

Indeed. It is *so* unbelievable to me, in fact, that I suspect it's a
form of trolling, rather than genuinely misguided programmers.

- Oliver
 
C

Chris Uppal

Oliver said:
Indeed. It is *so* unbelievable to me, in fact, that I suspect it's a
form of trolling, rather than genuinely misguided programmers.

Hmm, yes. Looking at, for instance, this comment on the "bug" report:

It is ridicule and stupid.
0.33 can be store like a float or a double.
I think the IEEE 754 rounding implementation is bugged.
It's scandalous! Think about financial or scientific
application !

I would say that whoever posted that was indulging a somewhat warped[*] sense
of humour.

-- chris

[*] still pretty funny, though.
 
J

Jeffrey Schwab

Chris said:
Oliver said:
Indeed. It is *so* unbelievable to me, in fact, that I suspect it's a
form of trolling, rather than genuinely misguided programmers.

Hmm, yes. Looking at, for instance, this comment on the "bug" report:

It is ridicule and stupid.
0.33 can be store like a float or a double.
I think the IEEE 754 rounding implementation is bugged.
It's scandalous! Think about financial or scientific
application !

I would say that whoever posted that was indulging a somewhat warped[*] sense
of humour.

-- chris

[*] still pretty funny, though.

It's annoying that support folks and usenetters have wasted time on
this, but that has got to be the funniest bug report I've ever read.

"Pffff ... don't tell me that's normal, and it's not a bug ... What is
floating-point arithmetic advantage if it gives false results ..?

"I'm looking for a SOLUTION, not explanation .. And I don't want to hear
about any "BigDecimal" class, my application took 1000 man days to
develop, imagine how long it will be to adapt all floating points
operations. . . "
 
A

Andy Dingley

Oliver said:
Indeed. It is *so* unbelievable to me, in fact, that I suspect it's a
form of trolling, rather than genuinely misguided programmers.

Never put down to conspiracy that which can be explained by stupidity.
- especially not on Usenet!


Remember the sqrt(-1) bug that was in Excel a few years ago ?
When reporting this to an Excel-loving manager at a major bank in the
Square Mile, his response was "So? Just how inaccurate is it?"
 
G

Greg R. Broderick

the Java language should handle this mathematical inaccuracy, even
though it is a commonly accepted defect.

Feel free to design and submit a Java Community Process (c.f.
http://www.jcp.org/) Java Specification Request to remedy this 'defect'.

Oh, and while you're at it, you might want to submit the same design
proposal to Intel, AMD and other microprocessor designers to remedy the
same 'defect' in their floating point hardware.


Regards
GRB
 
P

Patricia Shanahan

Greg said:
Feel free to design and submit a Java Community Process (c.f.
http://www.jcp.org/) Java Specification Request to remedy this 'defect'.

Oh, and while you're at it, you might want to submit the same design
proposal to Intel, AMD and other microprocessor designers to remedy the
same 'defect' in their floating point hardware.


Regards
GRB

I want to see the proposal for ensuring exact results for square root,
sine, cosine, logarithm etc.

Patricia
 
J

John W. Kennedy

Greg said:
Feel free to design and submit a Java Community Process (c.f.
http://www.jcp.org/) Java Specification Request to remedy this 'defect'.

Oh, and while you're at it, you might want to submit the same design
proposal to Intel, AMD and other microprocessor designers to remedy the
same 'defect' in their floating point hardware.

Don't forget telling IBM about this same "defect" in every mainframe
they made in the last 40 years.
 
M

Mark Thornton

Thomas said:
And I am not talking about knowing the precise internal format of IEEE
754. I am talking about basic things like knowing that 0.1 in base ten
is a periodic number in base two. So it can hardly be accurately
represented in a fixed amount of bits. Or just applying some basic
logic. It is logical that not every existing real (in the mathematical
sense) number can be represented with a fixed amount of bits. Simply
because there is an infinite amount of real numbers.

Do they really not teach these basics any more?

I'm sure they are still taught, but many students probably don't take
the units which contain this information. After all quite a lot of
programming can be done without using floating point at all. I guess
what is missing is they haven't been taught that use of floating point
without having done relevant units is an exercise fraught with
unexpected experiences.

Mark Thornton
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top