In my app i want save float or double values that are calculated using php into mysql.
I also want to make calculations with these columns in stored procedures using sql.
But i notice that double and float data types show different in php and mysql.
for example after a calculation in php i might get a value 4.00 while the same calculation is mysql is 4.0027.
How can i make possible to have more or less the same value calclated. what type should my columns in mysql be and what cast should i make in php?
Thanx
You may read this page for answers why sum of two integers often results in a float.
Considering the MySQL data type, the difference is discussed and explained in this question: Difference between float and decimal data type
I would suggest to store in decimal with some rounding before insert/update in PHP.
Again, everything depends on the calculations you perform on the values.
Try this
use number_format("4.0024",2); output 4.00
or Update
use number_format("6556564.0024",2, '.', ''); or number_format(6556564.0024,2, '.', ''); output 6556564.00
Related
I have copied this table from Wikipedia into a PostgreSQL database. The column Cultivated land (km2) became a column of type real. Then I use the PHP command
echo rtrim(rtrim(sprintf('%.10F',$v),'0'),'.');
to display the numbers ($v) in a table (both integers and float), but some values lose precision. For instance, the value from United States, 1669302, becomes 1669300, what is strange, since I expected 10 decimal digits of precision. I thought I have lost the precision when saving into a real column, but converting the column to double precision makes the difference (02) appear again, so it was there somewhere.
I don't think I need double precision, so how can I display the real value correctly? Keep in mind that some columns have decimal places, while some others are bigint, and they also should be displayed correctly.
The problem seems to originate from the way PHP returns results. The values are not returned as the corresponding data type, but rather formatted as a string using PostgreSQL default formatting. This formatting, is different for real and double precision types hence you are seeing different results when you convert the column types of your table. The reason you are seeing this specific result is that PostgreSQL guarantees 6 decimal places for real types and 15 decimal places for double precision.
Setting extra_float_digits
The manual states
Note: The extra_float_digits setting controls the number of extra significant digits included when a floating point value is converted to text for output. With the default value of 0, the output is the same on every platform supported by PostgreSQL. Increasing it will produce output that more accurately represents the stored value, but may be unportable.
Therefore, a simple solution to your problem is to increase extra_float_digits before issuing your SELECT-query:
pg_query($connection, "set extra_float_digits = 3");
Alternatively, you can also specify this change when connecting to your database by adding options to your connection string as follows:
$connection = pg_connect("host=localhost port=5432 dbname=test user=php password=pass connect_timeout=5 options='-c extra_float_digits=3'");
Another option would be to set this flag in the postgresql.conf configuration file of the PostgreSQL server if you have access to the server and want to change the option globally.
Casting the values
A different solution would be to have PostgreSQL return a different string to the PHP backend. This can be achieved by casting your columns to types with different default formatting which avoids cutting off some of the digits. In your case you could either cast to integer or double precision, i.e. instead of using
select cultivated_land from table
you could use
select cultivated_land::integer from table
or
select cultivated_land::double precision from table
Changing data types
Looking at the data you specified, I noticed that all numerical values except those columns specifying percentages contain integers, hence the usage of the integer data type is more suitable in this case. It can fit all the integer values of this table (the maximum being 149,000,000, therefore bigint is not required), requires the same storage size as real (4 bytes) and implies the default formatting of integers that you are looking for.
Update: Background on PostgreSQL-PHP interface and floating point representation
As mentioned above the way the PostgreSQL-PHP interface works is that all values sent from PostgreSQL to PHP are formatted as a string in some type-dependent way. Neither any of the pg_fetch_* functions nor pg_copy_to will provide raw values and all of these functions convert the values to strings in the same manner. As far as I am aware the current PHP interface will not provide you with anything different from a string (which, in my opinion, is not the best interface design).
The reason 18.22 is returned as 18.2199993 can be found in how PostgreSQL converts float4 to strings. You can check the code of how PostgreSQL is internally using float4out and find this relevant line that does the string-conversion:
snprintf(ascii, MAXFLOATWIDTH + 1, "%.*g", ndig, num);
num is the float4-number to be printed as a string. Note however that C will promote the float-variable to a double-variable when calling snprintf. This conversion to double precision results in the value 18.219999313354492 which is why you end up seeing 18.2199993 (you can check this here and will also find some details on floating point number representation on this site).
The takeaway message is that all your float4 values will be converted using this function and the only parameter you can influence is ndig by varying extra_float_digits, however no single value for this variable will suffice all your needs in representing the values as you want them. So as long as you keep using float4 as your data type and use the current PHP-interface to obtain the data you will run into these problems.
I therefore still recommend choosing different data types for your columns. If you think you have a requirement for decimal numbers you might want to investigate decimal data types where you can specify precision and scale as required for your application. If you would like to stick with floating point numbers I suggest rounding the values in PHP before displaying them to the user.
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.
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 just want to ask if there is any PHP/MySQL datatype that can store a number with a comma and decimal such as 10,000.35
when the user hit the save button with this value, it should be stored in a MySQL table and the system can retrieve it also to be processed as number 10000.35
thanks for any help!
That would be a CHAR/string datatype.
Numeric values don't have formats. They only contain the numeric value. Commas are not relevant for numeric computation. Format the values on output using, for instance, number_format. That's the only time a comma is relevant, it does not need to be stored.
Store the number without the comma in MySQL and just format the number in PHP when you are displaying it. It would be easier to keep the number without the comma in PHP as well if you're doing math with it - only use the comma when displaying the data!
If you are going to be storing numeric values it is best to leave all the formatting out of it.
For instance, what if you need to localize the display so that 10,000.05 needs to be 10.000,05? You'd have a lot of work to do.
You should store the value in the database as 10000.05 and use number_format($myValue,2,'.',','); to display the value when it's time. This will allow you to change the literals to variables or constants should you ever have to localize. It will also allow you to configure how many decimal places you care to display.
Here's the PHP docs for number_format()
It would be best to store it in your MySQL database without the comma, and then using PHP's number_format to display it with the commas.
The MySQL datatype that does this is DECIMAL. DECIMAL gives you fixed decimal places without the precision errors inherent in float type. (ie 123.45 instead of 123.4499999999999999)
You have 2 options , using MySQL to format directly or Using PHP .... see below for examples
MySQL Direct Solution
SELECT FORMAT(number, 2) as formatNumber FROM table ;
PHP Solution
number_format($number,2,'.',',');
Thanks
:)
I try to store the PHP floating point value 63.59072952118762 into a double precision column in postgres. Postgres stores the value as 63.59073. Does anyone know why? 8 byte should be more than enough for that value. I've tried with the data type numeric, which works when specifying the precision, but that shouldn't really be necessary.
Update: The same problem is present when trying to store 63.5907295, so the suggestion that something happens with the double before it's getting stored seems realistic.
Update II (partly solved): The line where I assign the double parameter looks like this:
$stmt->bindParam(4, $this->latitude);
The thing I didn't know is that PDO defaults its param type to string. I changed it to PDO::PARAM INT in lack of a better alternative (PARAM DOUBLE was not an option), and got 10 digits precision in the double stored in postgres (some progress, at least). I've checked that the numeric type works well, so it seems that numeric is the way to go when using PDO and doubles that has to have a precision of more than 10 decimals.
Anyways, as someone has mentioned, I don't know if it's a must for me to have this kind of precision, but I think the problem in itself deserved to be investigated.
How do you determine what PostgreSQL is storing?
How do you send the data to PostgreSQL?
How do you get the data back again?
How do you display it?
What type is the column in the database?
There are many, many places on the path between PHP and PostgreSQL where there could be confusion about how to represent the data.
It is important to explain how data is inserted into the DBMS. Using a literal value in the INSERT statement leads to a different set of problems from using bound parameters. If you wrote the value out in the SQL:
INSERT INTO SomeTable(SomeColumn) VALUES(63.xxxxxxxxx);
and the data was truncated, you'd have a problem down in PostgreSQL. If you bind the variable, you have to be sure to understand what PHP and the PDO PostgresSQL modules do with the value - is it sent as a double, or as a string, and which code deals with the conversion, and so on.
You run into analogous issues with Perl + DBI + DBD::YourDBMS (DBD::Pg in your case).
Consider using the DECIMAL/NUMERIC type if you need that much precision
PostgreSQL accepts float(1) to float(24) as selecting the real type, while float(25) to float(53) select double precision.
On most platforms PG, the real type has a range of at least 1E-37 to 1E+37 with a precision of at least 6 decimal digits. The double precision type typically has a range of around 1E-307 to 1E+308 with a precision of at least 15 digits (REF)
Which one do you use?