Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124322
Precedence: bulk
MIME-Version: 1.0
References: <668B4C78.2000808@adviesenzo.nl> <8FA0DE3B-2AF4-4110-9836-14E035DC8169@sakiot.com>
 <CAMrTa2GZqDTTLQDvD-gf9V20+cg_ANoHT97ad+KRvvzgYG+v8w@mail.gmail.com> <2ac2914f-1672-4f7a-863b-86b6692bff60@bastelstu.be>
In-Reply-To: <2ac2914f-1672-4f7a-863b-86b6692bff60@bastelstu.be>
Date: Tue, 9 Jul 2024 13:27:35 -0700
Message-ID: <CAMrTa2GT-komjCePzJ0cV8OJVhYCrX-3yCMJH9DXyZNYAxk39A@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Allow int type argument to BCMath function
To: =?UTF-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>
Cc: Saki Takamachi <saki@sakiot.com>, 
	Juliette Reinders Folmer <php-internals_nospam@adviesenzo.nl>, internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000f5c8d9061cd65c47"
From: jordan.ledoux@gmail.com (Jordan LeDoux)

--000000000000f5c8d9061cd65c47
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Jul 9, 2024 at 10:47=E2=80=AFAM Tim D=C3=BCsterhus <tim@bastelstu.b=
e> wrote:

> Hi
>
> On 7/8/24 11:36, Jordan LeDoux wrote:
> > I suspected the same thing when I was doing my arbitrary precision
> library,
> > but I actually have yet to find a test case in all my unit tests where
> this
> > happens when converting to a string. You can see this here:
> >
> > https://3v4l.org/Ud8Cn
>
> PHP emits the shortest possible representation that roundtrips, so the
> precision loss indeed does not happen when converting from float, but
> rather when converting to float / when the implicit rounding happens
> during the calculation.
>
> Nevertheless the inherent rounding error of floats and an arbitrary
> precision maths library do not mix: Users should not be encouraged to
> mindlessly pass a float, but rather work with strings all the time or
> explicitly perform the necessary conversion as appropriate for their use
> case - which of course is easier with strict_types enabled because then
> the conversion would need to be made explicit with a cast.
>
> Best regards
> Tim D=C3=BCsterhus
>

Yes, absolutely agree that arbitrary precision math should not be done with
floats, and developers should not be encouraged to use floats. However for
the specific case of type-coercion into the argument of a `bcadd` or
similar call, the detailed string conversion issues do not happen, which is
all I was saying.

Integers ALSO have a maximum precision, detailed by the `PHP_INT_MAX`
constant, which varies by system and install (mainly on whether 64-bit
integers are available).

My point was not that floats or integers are sufficient, but that the entry
point into an arbitrary precision calculation often comes from numbers that
are stored as ints and floats. If we accept ints, and don't ask the
developer to explicitly cast to string, I think we should do the same for
floats. Both or neither. I can see the argument against accepting either, I
can see the argument for accepting either.

I do not understand the argument for accepting one but not the other.

Jordan

--000000000000f5c8d9061cd65c47
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Tue, Jul 9, 2024 at 10:47=E2=80=AF=
AM Tim D=C3=BCsterhus &lt;<a href=3D"mailto:tim@bastelstu.be">tim@bastelstu=
.be</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x">Hi<br>
<br>
On 7/8/24 11:36, Jordan LeDoux wrote:<br>
&gt; I suspected the same thing when I was doing my arbitrary precision lib=
rary,<br>
&gt; but I actually have yet to find a test case in all my unit tests where=
 this<br>
&gt; happens when converting to a string. You can see this here:<br>
&gt; <br>
&gt; <a href=3D"https://3v4l.org/Ud8Cn" rel=3D"noreferrer" target=3D"_blank=
">https://3v4l.org/Ud8Cn</a><br>
<br>
PHP emits the shortest possible representation that roundtrips, so the <br>
precision loss indeed does not happen when converting from float, but <br>
rather when converting to float / when the implicit rounding happens <br>
during the calculation.<br>
<br>
Nevertheless the inherent rounding error of floats and an arbitrary <br>
precision maths library do not mix: Users should not be encouraged to <br>
mindlessly pass a float, but rather work with strings all the time or <br>
explicitly perform the necessary conversion as appropriate for their use <b=
r>
case - which of course is easier with strict_types enabled because then <br=
>
the conversion would need to be made explicit with a cast.<br>
<br>
Best regards<br>
Tim D=C3=BCsterhus<br></blockquote><div><br></div><div>Yes, absolutely agre=
e that arbitrary precision math should not be done with floats, and develop=
ers should not be encouraged to use floats. However for the specific case o=
f type-coercion into the argument of a `bcadd` or similar call, the detaile=
d string conversion issues do not happen, which is all I was saying. <br></=
div><div><br></div><div>Integers ALSO have a maximum precision, detailed by=
 the `PHP_INT_MAX` constant, which varies by system and install (mainly on =
whether 64-bit integers are available).</div><div><br></div><div>My point w=
as not that floats or integers are sufficient, but that the entry point int=
o an arbitrary precision calculation often comes from numbers that are stor=
ed as ints and floats. If we accept ints, and don&#39;t ask the developer t=
o explicitly cast to string, I think we should do the same for floats. Both=
 or neither. I can see the argument against accepting either, I can see the=
 argument for accepting either.</div><div><br></div><div>I do not understan=
d the argument for accepting one but not the other.</div><div><br></div><di=
v>Jordan<br></div></div></div>

--000000000000f5c8d9061cd65c47--