I am trying to save a float in my MySQL database as a decimal(20,10). But I don't think this is a good way, because when I try to save 2.14 it will save 2.1400000000.
At least this one is better than float(20,10) because that one was rounding it wrong.
But which type should I use to store it as 2.14? I can't just say 20,2 because sometimes I have for example 34.2222291 as value.
SOLUTION:
double(20,10) fixed it.
The difference between 2.14 and 2.1400000000 is just an issue of output formatting (in whatever language you use for that - but even possible with MySQL if you will).
So if you want exact decimal values, DECIMAL(20,10) is the way to go. DOUBLE (double precision floating point) just has less rounding problems than FLOAT (single precision floating point), it does not eliminate them because it is still a floating point type.
Related
I want to store traditional 64-bit floating points but I am confused with all the various options I have in MYSQL e.g. FLOAT(M,D), REAL(M,D), DOUBLE(M,D), FLOAT, DOUBLE PRECISION(M,D), REAL, DOUBLE, DECIMAL(M,D) and NUMERIC. Which one is best suited to store double precision floating point formats? If I need to specify M or D, what should I specify?
To store a 64 bit (8 byte) floating point number, use DOUBLE PRECISION or its alias/equivalent DOUBLE. They are the same. FLOAT is a single-precision 32-bit number, and REAL might be either one, depending on server config, so stay away from that one.
Don't specify the (M,D) values unless you have a reason to, because then you're not getting a "traditional" 64-bit number.
Standard disclaimer, don't use any of these -- use DECIMAL instead -- unless you fully understand the inherent imprecision of floating point number storage and operations. Money values, for example, are almost always candidates for a DECIMAL column.
http://dev.mysql.com/doc/refman/5.7/en/numeric-types.html
http://dev.mysql.com/doc/refman/5.7/en/floating-point-types.html
Why Subtraction of two equal values in mysql does not equal zero?
both field type are double. See image below
That's known as a approximate precision . This isn't an error, floating point data types are intended to work such way. They can not store data precisely. So if that matters, you should use fixed-point data types, such as DECIMAL in MySQL.
On the other hand, you can always use precision delta for comparisons for floating point, like:
SELECT
`foo`,
`bar`,
IF(ABS(`foo`-`bar`)<1E-13, 0, `foo`-`bar`) AS zero_compared
FROM
t
as you can see, here delta is 1E-13 (normally, that will be enough)
This problem is due to floating point precision and calculations on them.
You can also refer this Issue for clarity on your problem:
MySQL floating point comparison issues
Currently using MySQL version 5.1.6
This is my first real world build and so far I have actually been enjoying it; however, I now am stuck on a decision regarding a field datatype and hoping someone could sort it out for me.
I essentially have 10 fields that are all different test results. The numbers range from -100 to 100 and can have a decimal with one spot after the actual point.
For example, -5.1, 0, 1, 16.3, 99.2, and 100 are all possible data. From what I have read, one should use DECIMAL for those things that we usually measure and are exact (which these are), whereas FLOAT and DOUBLE are approximations, which I do not really want (though I am sure at this level, the approximation is very small if existent at all).
If I use DECIMAL, do I have to include a space for the '-' at the beginning if used? I.E, would I use DECIMAL(4,1) or DECIMAL(5,1) or am I way off here? I might be overthinking this a bit.
DECIMAL(4,1) will be enough, the sign digit does not need to be included.
More info: http://dev.mysql.com/doc/refman/5.1/en/precision-math-decimal-changes.html
For example, a DECIMAL(3,0) column supports a range of -999 to 999
Decimal will be indeed the best option for your needs. Float and Double can give you ugly numbers (e.g. 0.2 cannot be represented as float, you'd get 0.19999999)
The negative symbol does NOT count as a digit in your calculation, so DECIMAL(4,1) should be fine.
Edit: That also seems like the right field to use for your purposes. Try it out!
The round function sometime doesn't work very well. I have in my db a row like this:
field_1= 375
field_2= 0.65
field_3= 0.1
field_4= 11
So we know that: field_1*field_2*field_3*field_4 = 268.125 so if I round it to 2 decimals -> 268.13.
But in mysql I got 268.12 -> Select round(field_1*field_2*field_3*field_4) from my table -> 268.12
This situation just happens with these values, I tried with other numbers and no problem the round works.
Any workaround about it. I tried in mysql 4.1.22, and 5.1.44 and I get the same issue. I read in other forum http://bugs.mysql.com/bug.php?id=6251 that it is not a bug, they said that it depends on the C library implementation.
What data type are you using for those columns?
If you want exact precision then you should use NUMERIC or DECIMAL, not FLOAT, REAL, or DOUBLE.
From the manual:
The DECIMAL and NUMERIC types store exact numeric data values.
These types are used when it is important to preserve exact precision,
for example with monetary data.
If applicable you can use FLOOR()
If not applicable you will be better off handling this on the application side. I.e. do the entire calculation application side and then round, or just round application side.
SELECT (field_1*field_2*field_3*field_4) AS myCalculation FROM my table
Look at this query please
SELECT max( val_amd ) FROM `best_deposits`
I have the max value in the table equal to 14.6(the fields has type float),
But it returns 14.3599996566772
why does it happen, and how can i get the exact value?
Thanks much
floats are evil!
NEVER use floats for storing amounts or prices. instead of that, use an int and store the amount in cents. thats the only way to get around those problems forever.
why this happens: because floats can't be saved exactly in many cases (such as 0.6 in your case)
PS: we had those questions a hundret times for different languages till now:
Use Float or Decimal for Accounting Application Dollar Amount?
PHP rounding problem (5.2.3)?
Rounding problem with double type
Javascript rounding v c# rounding
Python rounding problem
... and a lot more
EDIT: to your comment: as i said:
use an int and store the amount in
cents
(alternatively you could use an DECIMAL(10,2) (or how big/how much decimal places you need)... not sure about how this works)
Or you better use "decimal" with length 10,2 or something like that for storing prices.