views:

390

answers:

6

The problem is this, when I add two or more doubles from a table to a view, instead of giving me the right results, it adds a about ten or so more digits. For example 0.5+1.5=1.99999999998 or 5.5+8.5=14.0000000001. Any ideas? (I know this is sort of n00b question and I remember having to deal with stuff like that in the exams at 9th grade, but I just cannot remember how I did it back then :P)

+2  A: 

Don't expect integers when you work with floating point types.

shambleh
I'd go so far as to say, "If you don't know the intended purpose of floating point types, don't use them." And "to keep track of pennies" or "add a decimal place" is not the intended purpose.
quillbreaker
+3  A: 

This article explains the issue pretty well.

In a nutshell, very large, or very small floating point numbers can result in a loss of precision during calculations.

Matthew Vines
+7  A: 

http://dev.mysql.com/doc/refman/5.0/en/string-functions.html#function_format

You can format numbers this way if thats what your after?

Paul Janaway
Thanks, that was what I was after. Sorry for not specifying what I wanted...
Ant
no problem mate :)
Paul Janaway
+2  A: 

Not sure if you're looking for an explanation or a solution, but since you've already gotten pointers to good explanations....

If you need your numbers to behave like integers, use integers. If you need a finite degree of precision (ie, two decimal places, for fields that represent money), store it as an integer anyway, but multiply it by whatever factor of 10 you need to get rid of the decimal when you put it into the database and divide by the same when you pull it back out.

So if you're representing a widget that costs $3.99, you put 399 into the WIDGET.cost field.

Dunno if that applies to your situation or not. But the general rule of thumb is that floating point numbers are ALWAYS mere approximations. :-) If precision matters, figure out a way to use integers.

BlairHippo
+8  A: 

Adding 1 and 1 as floats or doubles should not result in anything but 2.

I find it hard to believe that 0.5 + 1.5 comes out to anything but 2.

All these numbers can be represented correctly in binary floating point.

I hate to say I don't believe your examples, but I don't. :-)

However, I do believe that you might have trouble with a number such as 1.1.

Why? Because 1/10 turns out to be a repeating decimal in binary.

The problem comes when trying to convert floating point numbers between decimal and binary representations. Some numbers make the trip fine, but others are only approximated.


However, if your examples really work like that, I have no idea what is happening, and I'd love to know.

Nosredna
actually yeah, the examples are just examples. The real problem includes a lot of SUM from different tables and I think it wouldn't really help posting the whole process...
Ant
I knew it! Your examples had the smell of authenticity only until I actually paid attention to them. So I give you +1 for successful hoodwinking. You can tell that SOers have seen similar questions so many times that we don't actually read them anymore. :-)
Nosredna
+2  A: 

floating point numbers are ALWAYS mere approximations. :-) If precision matters, figure out a way to use integers.

In my experience, when I used decimal datatype instead of float/double, I did always got the precise results.

shantanuo