number_format rounding in 8.4 is different from older versions

[romanstingler]

Description

<?php

$a = [0.06,0.0025,0.0225,0.01];

$s = array_sum($a);
echo $s . "\n";

echo number_format($s, 2, '.', '');

Output for 8.4.1 - 8.4.5
    0.095
    0.09

Output for 8.2.0 - 8.2.28, 8.3.0 - 8.3.19
    0.095
    0.10

https://3v4l.org/WQVRub

PHP Version

8.4.5

Operating System

No response

[TimWolla]

The floating point sum of 0.06 + 0.0025 + 0.0225 + 0.01 is 0.0949999999999999872324. The nearest representable float to 0.095 is 0.0950000000000000011102. Thus 0.06 + 0.0025 + 0.0225 + 0.01 is now correctly rounded to 0.09, since it is clearly below the midway point between 0.09 and 0.10.

see also: #17136.

[rlerdorf]

@TimWolla There is a simpler case, though, where the changed HALF_ROUND_UP which is used by number_format() in 8.4 causes weirdness: https://3v4l.org/DoEpU
Interestingly it doesn't happen at 14 nor 16 decimal places, only 15 and only for integers 5 through 9 converted to floats.

[TimWolla]

Simpler test case:

<?php
var_dump(round((float)5, 15));

In this case the rounding is wrong indeed. Probably introduced by #12268 (the implementation of which I don't understand). /cc @SakiTakamachi

[TimWolla]

More specifically it regressed in 703ead5 / #12222.

[nielsdos]

We've had quite a few of similar behaviour change reports, but this didn't go through RFC. In fact, the RFC about rounding was declined (https://wiki.php.net/rfc/change_the_edge_case_of_round) yet it says "If this RFC is rejected, this PR will be adopted. #12268" . Not all breaks need an RFC considering this fixes a bug, but the fact there was a declined RFC about rounding behaviour makes for a weird situation...

[SakiTakamachi]

I investigated the issue.
This was caused by php_round_get_basic_edge_case() generating an edge case where the precision was so high that the added 0.5 was lost. As a result, the input value was incorrectly classified as an edge case and rounded upward.

php-src/ext/standard/math.c

Line 52 in aab2815

static zend_always_inline double php_round_get_basic_edge_case(double integral, double exponent, int places)

Breakpoint 2, php_round_get_basic_edge_case (integral=5000000000000000, exponent=1000000000000000, places=15) at /master/ext/standard/math.c:56
56                      : fabs((integral + copysign(0.5, integral)) * exponent);
(gdb) p integral
$14 = 5000000000000000
(gdb) p (integral + copysign(0.5, integral))
$15 = 5000000000000000

This is essentially unrelated to https://wiki.php.net/rfc/change_the_edge_case_of_round, and is only related to #12222, which extended the rounding precision up to 1e16.

edit: The RFC is indirectly related in the sense that, instead of using modf() to check the fractional part, it takes the approach of adding 0.5 to the integer part.

It seems that this specific precision case may require special handling when detecting edge cases.
I'll look into finding a good approach for it.

[SakiTakamachi]

That said... this is a bit tricky to handle.
Reverting the precision limit back to 1e15 seems like the least troublesome option, but...

If we treat 0.2849999... as 0.285, then in a sense, the current behavior might be considered correct. Hmm...

[rlerdorf]

I don't think we can consider this being correct:

php > printf("%.15f", (float) 8);
8.000000000000000
php > echo number_format( (float) 8, 15);
8.000000000000002
php > echo number_format( (float) 8, 16);
8.0000000000000000

[SakiTakamachi]

I’ve created a patch.
#18936

However, it's unavoidable that number_format((float) 8, 15) results in 8.000000000000002, because 8.000000000000000 and 8.0000000000000005 are considered equal and thus treated as an edge case.
https://3v4l.org/SYDtF

The case with (float) 5 is improved.