number_format: zero out until negative decimals

[marc-mabe]

On formatting big floating point numbers using number_format with negative decimal places the resulting number did not contain zeros for the decimal places requested to round due to how floating point numbers work.

This PR now explicitly zeros out these places so the resulting number is rounded for humans even so the closest floating point number would not. If you cast that back to floating point number you still get the same result.

Previously

printf("%s", number_format(1234567897576501234567.0, -5, "", "")); // 1234567897576501149696
printf("%f", (float)number_format(1234567897576501234567.0, -5, "", "")); // 1234567897576501149696.000000

After this change:

printf("%s", number_format(1234567897576501234567.0, -5, "", "")); // 1234567897576501100000
printf("%f", (float)number_format(1234567897576501234567.0, -5, "", "")); // 1234567897576501149696.000000

[mvorisek]

Suggested change

	... with precision -1: string(25) "9,223,372,036,854,775,800"
	... with precision -1: string(25) "9,223,372,036,854,775,810"

to be consistent with https://3v4l.org/ZGU7I

[marc-mabe]

mh I could try to use _php_math_number_format_long in case the rounded number fits long and decimal places are <= 0

[mvorisek]

because of https://3v4l.org/SoS6N rounding it should be possible to check if the 1st rounded digit is 5-9

[SakiTakamachi]

The precision is too fine to make much sense in testing the rounding results for this case.

[SakiTakamachi]

I misunderstood. Admittedly, it works a little differently than in 8.3. However, if the documentation is correct, the current behavior is more broken. We need to investigate a little more to see which is the correct behavior.

[SakiTakamachi]

Personally, I think it's too fine a precision to do rounding...
However, we need consistency in the specifications, so let's think a little about how we can make it more persuasive.

[SakiTakamachi]

@marc-mabe
I thought about this for a bit, but if we want accurate results we should use BCMath. It makes no sense to round to such fine precision. It is not possible using normal methods.

As in the following example, the precision is such that it is difficult to even determine what the value received was intended in the first place.
https://3v4l.org/N6r4B

If the precision is so fine that rounding is not possible, I think your implementation is fine.

[mvorisek]

this is for double only, for int it is ok - https://3v4l.org/5HqRt, so it seems ok for now

[SakiTakamachi]

Yes, but it exceeds the "meaningful precision" of double.
(edit) In the first place, there is no point in comparing int and double. These are completely different data.

[marc-mabe]

@mvorisek formatting big floating point numbers still within the range of int are using the integer variant already (which internally uses unsigned long to be able to still round up). See #12333

[SakiTakamachi]

LGTM

[marc-mabe]

Damn I have done more testing and this approach can also break revert logic to floating point ...

$ ./sapi/cli/php -r 'printf("%f", (float)number_format(9223372036854775800.0, -9, "", ""));'
9223372036000000000.000000 
$ ./sapi/cli/php -r 'printf("%f", (float)number_format(9223372036854775800, -9, "", ""));'
9223372036999999488.000000

So I'm closing this one as it would need another solution.