I have single record on a table. So on MySQL when
select myamount from table 1 -- returns amount 420.67
But when i do MySQL as
select sum(myamount) from table 1 -- returns amount 420.8699951171875
should n't it return same amount 420.67 since I have only one record? and how to get amount 420.67 if SUM used.
Any help is appreciated and yes myamount datatype is float.
Float variables are stored in "scientific notation" (the 2,4E+04 format, which is the same as 2,4*10^4). But to make it even worse, it is also stored in binary. When calculating things with numbers stored as float, you may get a bit strange results because of this.
This video by Computerphile describes the problem very nicely.
Related
After switching to Eloquent, when querying our database the values are automatically cast to numeric data types. This results in strange values like 8.0000000000000002E-2 instead of 0.08. This causes all sorts of issues with our reporting system. Is there a flag that can be set to retrieve the values as strings?
We've tried using casts in the Eloquent Model but that seems to happen after the fact. Adding rounding on the web side would be a very significant effort.
Example Query via DB::select($query);
SELECT (CAST(0.08 as float)) as ex1,
(CAST(0.04 as float)) as item2
The casts are to imply the data is stored as float in the database. These are custom queries and therefore are not using querybuilder on them.
Results in:
8.0000000000000002E-2 4.0000000000000001E-2
If you were to run this query directly in MSSQL for example it would show 0.08 and 0.04 which is what our webserver also used to report. I get that floating point numbers have finite precision but we are looking for a solution to mirror the previous behavior.
Try casting to decimal instead of float:
SELECT (CAST(0.08 as decimal)) as ex1,
(CAST(0.04 as decimal)) as item2
You may want to change your column types to be decimal too, especially if you're dealing with currency values.
More about the DECIMAL type in MySQL
I have tried to insert integer like 356361070084127 in mysql table named IMEI. However, while inserting it from excel file it convert these IMEI automatically to 356361070084120 changing last digit to 0. I have used PHPExccel to upload the excel file.
SUGGESTIONS:
Do a "select" in mysql to verify the "bigint" shows as expected in the database.
In "Excel":
a) select one of the integer values
b) Navigate to Home > Number
c) Increase Decimal
I suspect the actual problem is that Excel might be converting the integer to floating point, then rounding the floating point value.
One way to prevent this is to store the value as a "string" instead of "integer" - that way you can store a decimal value that's arbitrarily long.
Here is some additional information:
https://www.cnet.com/forums/discussions/displaying-long-numbers-greater-than-15-char-in-excel-292538/
ADDENDUM:
If you want to store an IMEI number ... THEN USE TYPE "STRING"! In the database, and ESPECIALLY in Excel!
if I want to change a column data type from REAL to something else, like NUMERIC, what data type and precision I should use? i.e. NUMERIC(?,?)
please help~~ thank you.
this is what data I have in current column with data type REAL.
0.5
0.0086
2E-07
NULL
4
0.5
0.00375
1E-07
I need get exactly same value as usual when doing query,
but since php driver have some problem with the REAL data type,
I cannot use REAL anymore.
I tried with a new column in float,
I use update sql clause to copy value to the new column
and the new column shown exactly as I queried in PHP... :-(
and it's annoying, because if I insert 16.7 into the REAL column,
I got 16.7 in SMS, 16.700000762939 in PHP query.
that's why I trying to find a alternative data type.
Thank you all in advanced.
If you want the exact values then stay away from float datatype as it is an Imaginary or Approximate representation of the number. Therefore using Float datatype you can get slightly different results then expected.
Use one of the NUMERIC or DECIMAL datatype. Which are only datatype allows you to store fractional values with exact numeric representation (Debateable but somewhat exact). :)
Read here MSDN Documentation to learn more about different Datatypes in Sql Server.
I am in need of storing a score in a mysql field but this score could be a time,integer or float. My first way of doing this was to identify the score type and then enter it into one of three fields but if the need arises to add a new score type I dont want to have to continually add a field to the database. I remember somewhere down the line someone told me that if you store somethign as a varchar then is wont be able to be read as an integer or float or even date. My question is, can I store all three of those as one specific type but read it any way I need when taking it from the database and using it in my php code?
In my opinion you could model the field as FLOAT except if you absolutely need to know about the type of variable stored. Time can be converted to an integer value by converting to timestamp. Integers are a subset of the real (floating point) numbers set actually so I guess that way you have everything covered. Floating point arithmetic can cause some issues with precision and equality testing though so be careful!
You can use CAST and CONVERT functions to convert the string datatype into another MySQL datatype such as INT, FLOAT, DECIMAL, DATE, DATETIME etc.
There are a few issues. How do you know what datatype is stored in a row? MySQL does have RegExp support but I do not recommend using it in your WHERE clauses. Store the datatype in another column.
Also, using cast functions in the where clause of your query will make them run slow. If you need to search upon/sort by the data you should use proper datatypes. Perhaps you should add one column for each datatype; and for each row, populate only the corresponding column.
mysql will happily convert text to numbers of the appropriate type if you perform a mathematical operation on it. However, it will also convert non-numeric text to zero and perform the same operation on it, so you need to check that you're only pulling fields of the appropriate type beforehand.
This forum post shows how to add a regular expression condition to your query to ensure that you're only pulling fields with numeric data in them. However, I think it's probably wiser to use a separate column to indicate what type of score each record is, and use that to retrieve the appropriate ones.
I don't know how to convert text to a date (putting it through date() doesn't work). However, note that the mysql date format (2012-05-08 11:20:23) has the date elements in order of descending significance. If you just want to find the highest / lowest date, or sort by date, treating them as strings will work fine.
I have one PHP script inserting rows in a MySQL database. Each row has a field 'created_at' which is filled with the value of the PHP function microtime(true), and inserted as a double. (microtime because I need something more precise than to the second)
I have another PHP script that selects rows based on that created_at field.
When I go ahead and select like this:
SELECT * FROM `ms_voltage` WHERE created_at > 1302775523.51878
I receive a resultset with, as the first row, the row with exactly that value for created_at.
This occurs from within my PHP script and from within PhpMyAdmin when manually doing the query. But not always, not for every value. Just once and a while really.
How is this possible? I didn't ask for greater than/equals, I want strictly greater than.
Am I overlooking something type-related perhaps?
Yeah, floating point arithmetic can do that sometimes. To understand why, it's helpful to realize that just as not all numbers can be accurately represented in base 10, not all numbers can be accurately represented in base 2 either.
For example, "1/3" may be written in base 10 as 0.33333 or 0.33334. Neither is really "correct"; they're just the best we can do. A "DOUBLE" in base 10 might be 0.3333333333 or 0.3333333334, which is double the digits, yet still not "correct".
The best options are to either use a DECIMAL value, or use an INT value (and multiply your actual values by, say, 10000 or 100000 in order to get the decimal digits you care about into that int).
The DOUBLE type represent only approximate numeric data values. Try to use the DECIMAL type.
Is your column floating point? Calling microtime with true gives you a float, and that looks like a float, which will have digits after the .51878 that you don't see, so those digits make the stored value greater than the value you have in your query.
Unless you really need the float I'd convert the string result to an int, or even two columns for seconds and useconds. Then you can use > or < on known values without worrying about the imprecision of the floating point value.