Rounding regression with calculated values.

[turbo124]

Description

https://3v4l.org/KWK15

This demonstrates the problems with the new implementation of rounding.

PHP 8.x

round(33.325,2) => 33.33

However this changes when using any form of arithmetic

25 x 1.333

Returns as 33.325 from PHP 8.x

However we now get divergence when we consider this

round((25x1.333),2)

PHP 8.4 => 33.32

PHP <= 8.3 => 33.33

33.325 represented as a floating point is

33.324999999999996

Which the new approach to rounding believes that the intention here is to round down.

I believe this is a regression and if not at the very least should be treated like a breaking change.

Whilst the old approach was not perfect, it provided predictable results. I believe a better approach would be to consider the use of an epsilon value in order to coerce the float based on the range of potential error.

PHP Version

PHP 8.4

Operating System

No response

[SakiTakamachi]

@turbo124

Hi!

Take a look at the following code:
https://3v4l.org/1Ggvd

25 * 1.333 is not equal to 33.325, even approximately, and the previous behavior was caused by a bug.

(I believe you understand this, but to clarify things for others who might look at this issue)

This is covered in the migration guide on the following page:
https://www.php.net/manual/en/migration84.other-changes.php

(standard section -> Rounding with round() section)

I don't think a fix to previous broken behavior should be described as a "backwards incompatible change". Otherwise, many bug fixes would have to be called "backwards incompatible changes".

However, it would be nice to make this information a bit more discoverable, perhaps with a mention in the changelog on the round function's documentation page.

[turbo124]

25 * 1.333 is not equal to 33.325, even approximately, and the previous behavior was caused by a bug.

I am sorry can you clarify this? What does 25*1.333 equal if not 33.325

I have read all the PHP docs page reflecting this change, but none explain the scenarios I have presented.

Is it now not safe to assume that round((25*1.333),2) != round(33.325,2) ?

https://3v4l.org/1NnHX

There is also a trick in the code you have presented here.

This PR increases the precision to 17, if you leave the precision at 16, equality is restored!

[TimWolla]

33.325 represented as a floating point is 33.324999999999996

This is false. The nearest representable IEEE 754 double precision floating point value to 33.325 is 33.3250000000000028422 (error of .0000000000000028422). 33.3249999999999957367 has an error of .0000000000000042633, which is roughly twice as large.

[cmb69]

Floating point numbers (IEEE 754 binary64) are not decimals, and you must not expect otherwise. Particularly, using floats for monetary calculations/representations is a serious bug.

See https://floating-point-gui.de/ for more details.

This is not a bug in php-src, and the pending documentation update is already tracked via php/doc-en#4176.

[turbo124]

@cmb69

Thanks for your reply.

My only point here is the treatment of floats under the new system is not consistent. Ignores the way FP math and rounding have been historically used in PHP from day 1, and has not been categorized as a breaking change.

Judging by the noise created in other issues only 3 weeks after GA. I doubt this will be the last issue to be raised around this.

[cmb69]

I doubt this will be the last issue to be raised around this.

I'm pretty sure that this will come up again, even in a couple of years. It might have been better to postpone this change to a major version, but, for me, the old behavior of https://3v4l.org/YbUMA is clearly a bug. And changing the behavior might have even some benefits for existing code, namely to be pointed to some misconceptions about floating point numbers (for instance, equality comparisons are often pointless, https://3v4l.org/nRgVs).