I am running a command similar to this in mysql 5.6:
SELECT pow(2, 87) FROM `table`
And the results are always shown in scientific notation, and when trying to CAST it to a decimal I am losing all the precision. Is there a way to simply output the full decimal value of this equation?
Related
I'm using MySQL database and trying to change column precision. I need to restrict numbers to 2 zeros afrer comma. But after execute this code: $this->alterColumn(offer::tableName(), 'price', $this->double(8.2)->null()); column precision in database is empty.
Result:
What I'm doing wrong?
If you want to restrict the numbers to 2 decimal numbers you should use fixed-point type like DECIMAL(8, 2).
In migration:
$this->decimal(8, 2)
Floating point types like FLOAT and DOUBLE allows only limited ways to set precision. There is support for FLOAT(M, D) and DOUBLE(M, D) syntax in MySQL. But, it's pretty much just an alias and you will always end with 4-byte float or 8-byte double. See documentation
Similar to this question, I have a CSV of currency rates which up to 9 decimal places accuracy.
For example : 0.558659218 , 4470.011076 , 7.02E-05, 0.000641138, 20832.46989
Which data type should I use for the column ?
I tried FLOAT , DOUBLE and DECIMAL(11,11), they produce one of the following warnings:
Out of range value for column 'column_name' at row X
Value truncated for column 'column_name' at row X
when I use SHOW WARNINGS command.
FYI, The SQL statement is as follow (but I guess it is not related):
LOAD DATA LOCAL INFILE 'currency.csv' INTO TABLE the_currency FIELDS TERMINATED BY ',' LINES TERMINATED BY '\n' (currency_code, currency_buyin, currency_buyout);
Sample data of the CSV is as follow:
PHP,41.46218559,0.024118362
PKR,95.71731228,0.010447431
PLN,3.2056255,0.311951599
PYG,4470.011076,0.000223713
QAR,3.641148462,0.274638623
RON,3.524472347,0.283730415
RSD,87.59544136,0.011416119
RUB,31.41607934,0.031830834
RWF,626.1686594,0.001597014
SAR,3.750383024,0.266639432
SBD,7.130814403,0.140236436
SCR,13.08102784,0.076446592
SDG,4.412494807,0.226629162
SEK,6.683528257,0.149621571
SGD,1.221878378,0.81841206
SHP,0.623503208,1.603840987
SLL,4349.905174,0.00022989
SOS,1615.486542,0.000619009
SPL,0.166666667,6
SRD,3.274628066,0.305378193
STD,18949.99968,5.28E-05
SVC,8.75,0.114285714
MySQL version: 5.5.34-0ubuntu0.12.04.1 and I'm working in console command.
You need DECIMAL(22,11) if you want 11 digits before as well as after the decimal place. DECIMAL(11,11) doesn't have any storage for digits before the decimal place, and is scarcely even valid at all.
For storing decimal or currency values, DECIMAL or NUMERIC (largely equivalent) are the way to go. Conversion rates are conceptually a little bit different -- since occasionally, they could be variable by much wider factors -- but DECIMAL could be a reasonable place to start, since at least it gives you accurate decimal math results.
The alternative would be DOUBLE (FLOAT does not have very good precision), which would allow conversion rates between hyper-inflated currencies to be stored; however, mixing float-point scaling into 'decimal' math requires a well-defined rounding strategy on output.
Decimal is what you need. The parameters are length then decimal places. Decimal(length,decimal place)
Example decimal(4,2) = max value is 99.99
Decimal(6,2) = max value is 9999.99
Hope this helps.
I know all the numerical implications, that is, the possible rounding issues inherent to floating point formats, but in my case I have DECIMAL columns in MySQL that I want to convert to DOUBLE straight in the MySQL query rather than down stream.
Could anyone help?
SELECT my_decimal_field + 0E0 FROM my_table
The following quotes from MySQL manual explain how this works:
9.1.2 Numeric Literals
Number literals include exact-value (integer and DECIMAL) literals and approximate-value (floating-point) literals.
Numbers represented in scientific notation with a mantissa and exponent are approximate-value numbers.
12.22.3 Expression Handling
Handling of a numeric expression depends on what kind of values the expression contains:
If any approximate values are present, the expression is approximate and is evaluated using floating-point arithmetic.
Because of the limitations of the built in CAST function in MySQL, it is only possible to convert DECIMAL to DOUBLE with your own user defined cast function.
Sample use case:
SELECT castDecimalAsDouble(0.000000000000000000100000000000);
Result: 1e-23
CREATE DEFINER=`root`#`localhost` FUNCTION `castDecimalAsDouble`(
decimalInput DECIMAL(65,30) ) RETURNS double
DETERMINISTIC
BEGIN
DECLARE doubleOutput DOUBLE;
SET doubleOutput = decimalInput;
RETURN doubleOutput;
END
It seems not possible to cast it to DOUBLE which brings problems if you do calculations and for example want to ROUND() a DECIMAL 12,2 in the third digit. Using ROUND(foo * bar,2) will just ignore the additional digits if your foo and bar are DECIMAL 12,2 fields.
That said you can do something like this to still make it work:
ROUND(CAST(foo AS DECIMAL(30,15)*CAST(bar AS DECIMAL(30,15)),2)
DECIMAL may save space. For example, DECIMAL(4,2) occupies only 2 bytes. FLOAT takes 4; DOUBLE takes 8.
As for the original question, simply do:
ALTER TABLE t MODIFY COLUMN c DOUBLE ...;
(The "..." should include the other stuff you already had, such as NOT NULL.)
I have this fragment of MSSQL -
CONVERT(INT, HASHBYTES('MD5', {some_field}))
...and I'd really like a MySQL equivalent. I'm pretty sure the HASHBYTES('MD5', ...) bit is the same as MySQL's MD5(...) - it's the CONVERT(INT, ...) bit that's really puzzling me.
Thanks.
From the MySQL manual entry for the MD5() function:
The value is returned as a string of 32 hex digits, or NULL if the argument was NULL.
The MSSQL CONVERT() function which you quote above converts its varbinary argument to a signed 32-bit integer by truncating to the 4 lowest-order bytes. This is a bit of a nuisance because MySQL arithmetic works to 64-bit precision.
We must therefore take the rightmost 8 digits of MySQL's hex representation (representing the 4 lowest-order bytes) and convert to decimal using MySQL's CONV() function, then sign-extend the result:
CONV(RIGHT(MD5('foo'),8), 16, 10) ^ 0x80000000 - 0x80000000
i want to understand this:
i have a dump of a table (a sql script file) from a database that use float 9,2 as default type for numbers.
In the backup file i have a value like '4172.08'.
I restore this file in a new database and i convert the float to decimal 20,5.
Now the value in the field is 4172.08008
...where come from the 008??
tnx at all
where come from the 008??
Short answer:
In order to avoid the float inherent precision error, cast first to decimal(9,2), then to decimal(20,5).
Long answer:
Floating point numbers are prone to rounding errors in digital computers. It is a little hard to explain without throwing up a lot of math, but lets try: the same way 1/3 represented in decimal requires an infinite number of digits (it is 1.3333333...), some numbers that are "round" in decimal notation have infinite number of digits in binary. Because this format is stored in binary and has finite precision, there is an implicit rounding error and you may experience funny things like getting 0.30000000000000004 as the result of 1.1 + 1.2.
This is the difference between float and decimal. Float is a binary type, and can't represent that value exactly. So when you convert to decimal (as expected, a decimal type), its not exactly the original value.
See http://floating-point-gui.de/ for some more information.