[RFC] [Discussion] Rounding Integers as int

Hi Larry,

Hi internals

I'd like to put a new RFC under discussion:
https://wiki.php.net/rfc/integer-rounding

Best,
Marc
I'm honestly kind of confused by this. The basic concept, as I understand it, is sound. But the rest of the description seems to suggest that the returned type will depend on the passed-in type? That makes little sense to me. Since we already know that int is contravariant to float, I would expect round to return int if it can, float if there is a decimal precision set. ceil and floor should always return ints, unconditionally, because that's literally what their purpose is. But that RFC doesn't say that, which makes me quite confused.

Similarly, the BC shim would therefore be (float)ceil($x), not ceil((float)$x), which... I don't think that would even do anything, would it?

Currently, all three functions return float, no matter what. This is an
implicit cast and results in inaccurate values for numbers above 2^53.
The RFC proposes to keep the given type if possible.

Given that, the return value is (and was) guaranteed to be float if the
given number is float.

If the given number is int the return value will most likely be int
except in case of integer over- / underflow.

If instead all integers would be returned as int-type, we would have
additional issues...

• additional BC due to additional implicit cast from float to int

• less accuracy on 32bit platforms (numbers > 2^31)

• what to do on integer overflow?

--Larry Garfield
Marc

ceil and floor should
always return ints, unconditionally, because that's literally what
their purpose is. But that RFC doesn't say that, which makes me quite
confused.

They can't do that. ceil(2.4e102) can't be repesented as an integer.

Similarly, the BC shim would therefore be (float)ceil($x), not
ceil((float)$x), which... I don't think that would even do anything,
would it?

(float) $int could also do something:

$ php -dprecision=20 -r 'echo (float) 1152921504606846974;'

1152921504606846976

$ php -dprecision=20 -r 'var_dump(ceil((float) 1152921504606846974));'

double(1152921504606846976)

(see how the 74 changes into 76 at the end).

Integers in the ranges LONG_MAX to 2^53, and -2^53 to LONG_MIN can't be
represented as whole numbers as float, and some precision is lost.

cheers,
Derick

Hi Tim,

Hi

I'd like to put a new RFC under discussion:
https://wiki.php.net/rfc/integer-rounding

I find the proposal reasonable, but I don't like the deprecation
proposal, because it does not allow me to opt into the new behavior
before PHP 9.0 arrives.

Getting rid of the deprecation would also require me to either add a
cast everywhere or add the error suppression operator everywhere and
then revert that with PHP 9 depending on whether I want the new
behavior or not.

As far as I can tell all the other deprecations allow me to use the
replacement functionality right away without needing to go through a
two-step process.

As the results of not casting to float first are arguably more
correct, perhaps this could be considered a bugfix. While it would
cause breakage for users that rely on strict types, obtaining the old
behavior is just one (float) cast away.

The deprecation would act as an information for upcoming behavior
change, not classical deprecation of future removal. If the new behavior
is what you want, than you don't need to change anything as a
deprecation message should not break anything. At the same time people
relying on the old behavior of implicit cast gets informed that they
have to cast explicit now.

I first was playing around with adding a new argument. First by default
keep existing behavior, in next changing default to new behavior and
later again get rid of the argument. But this would force users to
migrate multiple times and it would take years to finish.

Changing the behavior without further notice (deprecation) this could be
a huge BC ending up in a lot of uncaught bugs especially on such high
frequently used functions.

Best regards
Tim Düsterhus

Best,

Marc

Hi internals

I'd like to put a new RFC under discussion:
https://wiki.php.net/rfc/integer-rounding

I don't understand the point of the deprecation phase at all.
Frankly, I consider this RFC a bug fix of the current "broken"
implementation, which was broken with 7.0 and the move to 64bit integers.
As such, I would just make the behaviour of returning integers the default
behaviour in 8.4.
If, for some weird reason, people want less accurate numbers, they can
always cast the input to float.

I don't see a bug or broken behavior here as these functions were
processing floating point numbers since .... forever.

https://3v4l.org/PrrmO

Best regards,

George P. Banyard

Best,
Marc

Hi internals

I'd like to put a new RFC under discussion:
https://wiki.php.net/rfc/integer-rounding

I would personally prefer a new function for rounding integers if anyone
wants to round large integers.

The things is that the current round behaviour is consistent with a way how
floats to int conversion is done for strict types.

<?php
declare(strict_types=1);

function test(float $a) {
echo $a;
}
test(987654321098765432);

So it won't really help that much if this function returns long for long in
cases where the result is passed to another function expecting float.

The main problem that I see with the current approach is that it changes
return type for an edge case that most people are not impacted with. For
example it is quite usual that people had a float value with 0 fraction
which gets json encode to int. When they decode it and use round, the
return type is suddenly int. Even though it's usually not a problem, there
might be some code that expects float and maybe even assert that with
is_float. Such code will break.

On the other hand I see use some case for rounding large integers with
negative precision. But for that to work I think it would be better to have
a special function.

If you really want to make such change to round, then I would be prefer
targeting just 9.0 without any deprecation as I don't think the deprecation
should be informational only and not fixable in the code.

Cheers

Jakub

Just to add some nuance, if you are going anywhere near the edges of
ints (e.g., custom encryption prototypes from papers), you generally
know that will happen -- it's math and pretty easy to verify. In those
cases, you likely will be using GMP or some other extension to handle
the large numbers. The point is, I highly doubt people are unknowingly
using round() with exceptionally large numbers. If they are doing so,
they probably know exactly what they are doing and already handle all
potential edge cases or they use an extension specifically for dealing
with large numbers.

Hi Jakub,

Hi internals

I'd like to put a new RFC under discussion:
https://wiki.php.net/rfc/integer-rounding

I would personally prefer a new function for rounding integers if anyone
wants to round large integers.

The things is that the current round behaviour is consistent with a way how
floats to int conversion is done for strict types.

<?php
declare(strict_types=1);

function test(float $a) {
echo $a;
}
test(987654321098765432);

So it won't really help that much if this function returns long for long in
cases where the result is passed to another function expecting float.

The main problem that I see with the current approach is that it changes
return type for an edge case that most people are not impacted with. For
example it is quite usual that people had a float value with 0 fraction
which gets json encode to int. When they decode it and use round, the
return type is suddenly int. Even though it's usually not a problem, there
might be some code that expects float and maybe even assert that with
is_float. Such code will break.

On the other hand I see use some case for rounding large integers with
negative precision. But for that to work I think it would be better to have
a special function.

Your JSON example is a bit unrelated because if you care about your
types your should have used JSON_RESERVE_ZERO_FRACTION in the first
place else you should not care about int vs float at all.

It's true that passing/returning int to/from a function expecting float
will cast but currently with these rounding functions it's a different
deal as they expect an int|float instead of just float. So it's not
cast on passing the argument but the functions itself are casting.

Where another set of functions would avoid the BC break it also would be
against having PHP as a loosely typed languageputting the burden to
everyone caring. I already see hundreds of is_int($v) ? round_int($v) : round($v) everywhere around.

If you really want to make such change to round, then I would be prefer
targeting just 9.0 without any deprecation as I don't think the deprecation
should be informational only and not fixable in the code.

Cheers

Jakub

Best,
Marc

Hi internals,

Just want to resent this note about the updated RFC as there where no
comments last time and I'm unsure if this was due to mailing list issues.

I now have updated the RFC to allow to opt-in to new behavior on PHP 8.4
and be able to opt-out to previous behavior in PHP 9.0 via new parameter
"force_float".

Also the deprecation has been removed as nobody liked it.

If no further comments arrive I'll like to start voting next week Friday.

Best regards,
Marc

Hi all,

I now have updated the RFC to allow to opt-in to new behavior on PHP
8.4 and be able to opt-out to previous behavior in PHP 9.0 via new
parameter "force_float".

Also the deprecation has been removed as nobody liked it.

Best regards,
Marc

Hi internals

I'd like to put a new RFC under discussion:
https://wiki.php.net/rfc/integer-rounding

Best,
Marc