Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128565
Feedback-ID: ifab94697:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Tue, 26 Aug 2025 20:33:00 +0200
To: =?UTF-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>,
 "Alexandre Daubois" <alex.daubois+php@gmail.com>
Cc: "PHP internals list" <internals@lists.php.net>
Message-ID: <78af4148-101f-4ced-90a7-51a32fe33d14@app.fastmail.com>
In-Reply-To: <499395ff-4ac9-4dc1-86fd-697b205467ba@bastelstu.be>
References: 
 <CAMU7irKj_SyyM2kVz4kEqjDK+ucc8uRP1amJgASTFRM+V+Ld3w@mail.gmail.com>
 <f419f96e3cf4ce194a8d59349a625817@bastelstu.be>
 <CAMU7ir+GT0KYEQVWCVo=Rj9VH-BfhBGTzSDd-bZNREf_rKK=9w@mail.gmail.com>
 <499395ff-4ac9-4dc1-86fd-697b205467ba@bastelstu.be>
Subject: Re: [PHP-DEV] [RFC] Add "is_representable_as_float()" and
 "is_representable_as_int()" functions
Content-Type: multipart/alternative;
 boundary=30356179f7304b06935c14d2f969f534
From: rob@bottled.codes ("Rob Landers")

--30356179f7304b06935c14d2f969f534
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Tue, Aug 26, 2025, at 20:23, Tim D=C3=BCsterhus wrote:
> Hi
>=20
> 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.
> >=20
> > 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.
> >=20
> > 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?"
>=20
> "Surprising changes" is not a meaningful term. Keep in mind that the=20
> behavior of the function will need to be accurately documented and tha=
t=20
> folks need something to work with to determine whether a report is val=
id=20
> or not when bugs in the function get reported - which will inevitably=20
> happen.
>=20
> In fact to use one of the examples for the RFC: 1e10 does not roundtri=
p.
>=20
>      php > var_dump((string)(float)"1e10");
>      string(11) "10000000000"
>=20
> "1e10" clearly is different than "10000000000".
>=20
> Generally speaking, I'm also not sure if =E2=80=9Cprinting raw floats=E2=
=80=9D is a=20
> use-case we should encourage. Instead almost any application will need=20
> to format a number for a specific use-case. Formatting numbers for hum=
an=20
> consumption [1] has different requirements compared to formatting=20
> numbers for programmatic consumption.

Indeed. In some parts of the world, 1.000,01 is interpreted as 1000.01 i=
n computers. That format also doesn=E2=80=99t roundtrip but is a valid n=
umeric string, depending on locale.

=E2=80=94 Rob
--30356179f7304b06935c14d2f969f534
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title></head><body><div><br></div><d=
iv><br></div><div>On Tue, Aug 26, 2025, at 20:23, Tim D=C3=BCsterhus wro=
te:</div><blockquote type=3D"cite" id=3D"qt" style=3D""><div>Hi</div><di=
v><br></div><div>On 8/26/25 19:14, Alexandre Daubois wrote:</div><div>&g=
t;&gt; 3.14 is not exactly representable as a IEEE-754 double-precision<=
/div><div>&gt;&gt; floating point number. The two nearest representable =
values are</div><div>&gt;&gt; 3.14000000000000012434 (this one is the ne=
arest) and</div><div>&gt;&gt; 3.13999999999999968026. Returning `true` f=
or</div><div>&gt;&gt; `is_representable_as_float("3.14")` is therefore w=
rong to me.</div><div>&gt;&nbsp;</div><div>&gt; You're right about mathe=
matical precision. Perhaps the function name</div><div>&gt; is misleadin=
g. What the function actually should check is whether a</div><div>&gt; s=
tring &gt; float &gt; string roundtrip preserves the value as PHP</div><=
div>&gt; developers would expect it, not whether it's mathematically exa=
ctly</div><div>&gt; representable in IEEE-754.</div><div>&gt;&nbsp;</div=
><div>&gt; Maybe a more accurate name would better reflect this behavior=
. Naming</div><div>&gt; is super hard again here. The goal is pragmatic:=
 "will this value</div><div>&gt; survive a type conversion cycle without=
 surprising changes?"</div><div><br></div><div>"Surprising changes" is n=
ot a meaningful term. Keep in mind that the&nbsp;</div><div>behavior of =
the function will need to be accurately documented and that&nbsp;</div><=
div>folks need something to work with to determine whether a report is v=
alid&nbsp;</div><div>or not when bugs in the function get reported - whi=
ch will inevitably&nbsp;</div><div>happen.</div><div><br></div><div>In f=
act to use one of the examples for the RFC: 1e10 does not roundtrip.</di=
v><div><br></div><div>&nbsp;&nbsp;&nbsp;&nbsp; php &gt; var_dump((string=
)(float)"1e10");</div><div>&nbsp;&nbsp;&nbsp;&nbsp; string(11) "10000000=
000"</div><div><br></div><div>"1e10" clearly is different than "10000000=
000".</div><div><br></div><div>Generally speaking, I'm also not sure if =
=E2=80=9Cprinting raw floats=E2=80=9D is a&nbsp;</div><div>use-case we s=
hould encourage. Instead almost any application will need&nbsp;</div><di=
v>to format a number for a specific use-case. Formatting numbers for hum=
an&nbsp;</div><div>consumption [1] has different requirements compared t=
o formatting&nbsp;</div><div>numbers for programmatic consumption.</div>=
</blockquote><div><br></div><div>Indeed. In some parts of the world, 1.0=
00,01 is interpreted as 1000.01 in computers. That format also doesn=E2=80=
=99t roundtrip but is a valid numeric string, depending on locale.<br></=
div><div><br></div><div id=3D"sig121229152">=E2=80=94 Rob</div></body></=
html>
--30356179f7304b06935c14d2f969f534--