Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128564
Message-ID: <499395ff-4ac9-4dc1-86fd-697b205467ba@bastelstu.be>
Date: Tue, 26 Aug 2025 20:23:20 +0200
Precedence: list
MIME-Version: 1.0
Subject: Re: [PHP-DEV] [RFC] Add "is_representable_as_float()" and
 "is_representable_as_int()" functions
To: Alexandre Daubois <alex.daubois+php@gmail.com>
Cc: PHP internals list <internals@lists.php.net>
References: <CAMU7irKj_SyyM2kVz4kEqjDK+ucc8uRP1amJgASTFRM+V+Ld3w@mail.gmail.com>
 <f419f96e3cf4ce194a8d59349a625817@bastelstu.be>
 <CAMU7ir+GT0KYEQVWCVo=Rj9VH-BfhBGTzSDd-bZNREf_rKK=9w@mail.gmail.com>
Content-Language: en-US
In-Reply-To: <CAMU7ir+GT0KYEQVWCVo=Rj9VH-BfhBGTzSDd-bZNREf_rKK=9w@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

Hi

On 8/26/25 19:14, Alexandre Daubois wrote:
>> 3.14 is not exactly representable as a IEEE-754 double-precision
>> floating point number. The two nearest representable values are
>> 3.14000000000000012434 (this one is the nearest) and
>> 3.13999999999999968026. Returning `true` for
>> `is_representable_as_float("3.14")` is therefore wrong to me.
> 
> You're right about mathematical precision. Perhaps the function name
> is misleading. What the function actually should check is whether a
> string > float > string roundtrip preserves the value as PHP
> developers would expect it, not whether it's mathematically exactly
> representable in IEEE-754.
> 
> Maybe a more accurate name would better reflect this behavior. Naming
> is super hard again here. The goal is pragmatic: "will this value
> survive a type conversion cycle without surprising changes?"

"Surprising changes" is not a meaningful term. Keep in mind that the 
behavior of the function will need to be accurately documented and that 
folks need something to work with to determine whether a report is valid 
or not when bugs in the function get reported - which will inevitably 
happen.

In fact to use one of the examples for the RFC: 1e10 does not roundtrip.

     php > var_dump((string)(float)"1e10");
     string(11) "10000000000"

"1e10" clearly is different than "10000000000".

Generally speaking, I'm also not sure if “printing raw floats” is a 
use-case we should encourage. Instead almost any application will need 
to format a number for a specific use-case. Formatting numbers for human 
consumption [1] has different requirements compared to formatting 
numbers for programmatic consumption.

Also note that the stringification of floats unfortunately is controlled 
by INI settings `precision` and `serialize_precision` which adds 
additional complexity.

[1] My recommendation is using ext/intl's NumberFormatter: 
https://www.php.net/manual/en/class.numberformatter.php

> need to communicate with JavaScript frontends, and knowing when a
> numeric ID exceeds JavaScript's safe integer range would improve
> interoperability.

For *this* use case we would not need a complex function. A simple 
constant FLOAT_INTEGER_RANGE or similar would be sufficient.

>> I also question how meaningful it is knowing that a given number is
>> exactly representable as a float when (e.g. a power of two) when almost
>> any operation on it will incur implicit rounding.
> 
> To me, the code snippet in the RFC introduction illustrates a valid
> use-case of a numeric identifier that could be dangerous to cast.

Please note my remark regarding “strongly typed consumers”. Magically 
switching from JSON's number type to JSON's string type for specific 
values is needlessly increasing complexity for everyone who interacts 
with the JSON payload, particularly for compiled languages. If you know 
that the consumers of your JSON are having troubles with certain numbers 
you emit and you want to emit strings for those kind of numbers instead, 
then you should just emit strings all the time.

In fact I'd argue that using JSON's number type for numeric IDs is 
wrong, just like treating phone numbers or zip codes as numbers is 
wrong. If it's not reasonable to do math on a value then it's likely not 
a number, but instead a numeric string.

>> Long story short: What actual real-world problem does this RFC attempt
>> to solve? The list in the “Introduction” section is not particularly
>> meaningful with regard to the real world and the JSON example is wrong
>> as outlined above.
> 
> A few examples, as interoperability between with JSON/JavaScript is
> the main point here, could be:
> 
> - Snowflake IDs

At the application boundary these should just be a string, since 
consumers of your API should treat IDs as opaque values, unless you want 
to give some guarantees (e.g. rough ordering, which would still work 
with strings).

> - High-precision timestamps in microseconds

Using a number is reasonable here, but see above regarding “magically 
switching types”.

(From my experience timestamps are generally represented as ISO-8601 
strings in JSON APIs anyways)

> - Large auto-increment IDs in mature applications

Same as snowflakes.

> Hope I addressed your concerns.

I'm afraid not.

Best regards
Tim Düsterhus