Summary of PHP floating point precision issues_PHP tutorial

A summary of PHP floating-point number accuracy issues

This article mainly introduces a summary of PHP floating-point number accuracy issues. This article focuses on the issue of PHP floating-point number accuracy loss, using three different paragraphs. The method explains the causes and solutions to this problem. Friends in need can refer to it

1. PHP floating point precision loss problem

First look at the following code:

The code is as follows:

　$f = 0.57;

echo intval($f * 100); //56

The result may be a bit surprising to you, PHP follows IEEE 754 double precision:

Floating point number, with 64-bit double precision, is represented by 1 sign bit (E), 11 exponent bits (Q), and 52-bit mantissa (M) (a total of 64 bits).

Sign bit: The highest bit represents the sign of the data, 0 represents a positive number, and 1 represents a negative number.

Exponent bit: represents the data raised to the power of base 2, and the exponent is represented by an offset code

Mantissa: Indicates the significant digits after the decimal point of the data.

Let’s take a look at how decimals are expressed in binary:

Multiply by 2 and round up, arrange in order, that is, multiply the decimal part by 2, then take the integer part, continue to multiply the remaining decimal part by 2, then take the integer part, multiply the remaining decimal part by 2, and keep taking To the decimal part, but if you multiply a decimal like 0.57 like this, the decimal part cannot be 0. The decimal representation of the significant digits is infinite in binary.

The binary representation of 0.57 is basically (52 bits): 0010001111010111000010100011110101110000101000111101

If there are only 52 bits, 0.57 =》 0.56999999999999995

It is not difficult to see the unexpected results above.

2. Precision problem of PHP floating point numbers

Let’s look at the question first:

The code is as follows:

　$f = 0.58;

　var_dump(intval($f * 100)); //Why is it outputting 57

I believe that many students have had such questions.

For the specific principle, you can read an article by "Brother Bird", where there is a detailed explanation: Answers to a common question about PHP floating point numbers

So how to avoid this problem?

There are many ways, here are two:

　1. sprintf

The code is as follows:

substr(sprintf("%.10f", ($a/ $b)), 0, -7);

2. round (note that rounding will be performed)

The code is as follows:

round($a/$b, 3);

Or if you have a better way, please leave a message and tell me.

3. Answer to a common question about PHP floating point numbers

Regarding floating point numbers in PHP, I have written an article before: All ‘bogus’ about the float in PHP (All ‘bogus’ about the float in PHP)

However, I missed one thing at the time, which is the answer to this common question:

The code is as follows:

　$f = 0.58;

　var_dump(intval($f * 100)); //Why is it outputting 57

　?>

Why is the output 57? Is it a PHP bug?

I believe that many students have had such questions, because there are many people asking me similar questions, not to mention that people often ask on bugs.php.net...

To understand this reason, first we need to know the representation of floating point numbers (IEEE 754):

Floating point numbers, taking 64-bit length (double precision) as an example, will be represented by 1 sign bit (E), 11 exponent bits (Q), and 52-bit mantissa (M) (a total of 64 bits).

Sign bit: The highest bit represents the sign of the data, 0 represents a positive number, and 1 represents a negative number.

Exponent bit: represents the data raised to the power of base 2, and the exponent is represented by an offset code

Mantissa: Indicates the significant digits after the decimal point of the data.

The key point here is the representation of decimals in binary. As for how decimals are represented in binary, you can search on Baidu. I won’t go into details here. The key thing we need to understand is that for binary representation, 0.58 is infinite. Long values ​​(numbers below omit the implicit 1)..

The binary representation of 0.58 is basically (52 bits): 0010100011110101110000101000111101011100001010001111

The binary representation of 0.57 is basically (52 bits): 0010001111010111000010100011110101110000101000111101

And the binary numbers of the two, if calculated only through these 52 bits, are:

The code is as follows:

　0.58 -> 0.579999999999999996

　0.57 -> 0.569999999999999995

As for the specific floating point multiplication of 0.58 * 100, we will not consider it in detail. Those who are interested can look at the floating point. We will look at it vaguely through mental arithmetic... 0.58 * 100 = 57.999999999

Then if you intval it, it will naturally be 57…

It can be seen that the key point of this problem is: "Your seemingly finite decimal is actually infinite in the binary representation of the computer"

So, don’t think this is a PHP bug anymore, this is what it is...

http://www.bkjia.com/PHPjc/1000080.htmlwww.bkjia.comtruehttp: //www.bkjia.com/PHPjc/1000080.htmlTechArticleA summary of PHP floating point precision issues. This article mainly introduces a summary of PHP floating point precision issues. This article focuses on PHP floating point precision issues. The problem of point accuracy loss is explained in three paragraphs in different ways...