Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124282
Precedence: bulk
MIME-Version: 1.0
References: <668B4C78.2000808@adviesenzo.nl> <8FA0DE3B-2AF4-4110-9836-14E035DC8169@sakiot.com>
In-Reply-To: <8FA0DE3B-2AF4-4110-9836-14E035DC8169@sakiot.com>
Date: Mon, 8 Jul 2024 02:36:28 -0700
Message-ID: <CAMrTa2GZqDTTLQDvD-gf9V20+cg_ANoHT97ad+KRvvzgYG+v8w@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Allow int type argument to BCMath function
To: Saki Takamachi <saki@sakiot.com>
Cc: Juliette Reinders Folmer <php-internals_nospam@adviesenzo.nl>, internals@lists.php.net
Content-Type: multipart/alternative; boundary="0000000000008b3796061cb926e8"
From: jordan.ledoux@gmail.com (Jordan LeDoux)

--0000000000008b3796061cb926e8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, Jul 7, 2024 at 8:19=E2=80=AFPM Saki Takamachi <saki@sakiot.com> wro=
te:

> Hi Juliette,
>
> > Hi Saki,
> >
> > Just wondering: why `int|string` instead of `float|string` ?
> > In my experience, floats are the more pertinent type for which to use
> the BCMath extension.
> >
> > Smile,
> > Juliette
>
> Since floating point numbers always contain a certain amount of error, I
> believe that they are not suitable as arguments for BCMath.
>
> For example, 0.285 becomes 0.284999... in floating point. From the
> perspective of arbitrary precision math, there is no universally agreeabl=
e
> way to properly handle values like this: there will always be people who
> want to treat it as 0.285, and people who want to treat it as 0.284999...=
.
>
> Therefore, I believe BCMath should not accept floats as arguments.
>
> Regards,
>
> Saki


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

Jordan

--0000000000008b3796061cb926e8
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 Sun, Jul 7, 2024 at 8:19=E2=80=AFP=
M Saki Takamachi &lt;<a href=3D"mailto:saki@sakiot.com">saki@sakiot.com</a>=
&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi J=
uliette,<br>
<br>
&gt; Hi Saki,<br>
&gt; <br>
&gt; Just wondering: why `int|string` instead of `float|string` ?<br>
&gt; In my experience, floats are the more pertinent type for which to use =
the BCMath extension.<br>
&gt; <br>
&gt; Smile,<br>
&gt; Juliette<br>
<br>
Since floating point numbers always contain a certain amount of error, I be=
lieve that they are not suitable as arguments for BCMath.<br>
<br>
For example, 0.285 becomes 0.284999... in floating point. From the perspect=
ive of arbitrary precision math, there is no universally agreeable way to p=
roperly handle values like this: there will always be people who want to tr=
eat it as 0.285, and people who want to treat it as 0.284999....<br>
<br>
Therefore, I believe BCMath should not accept floats as arguments.<br>
<br>
Regards,<br>
<br>
Saki</blockquote><div><br></div><div>I suspected the same thing when I was =
doing my arbitrary precision library, but I actually have yet to find a tes=
t case in all my unit tests where this happens when converting to a string.=
 You can see this here:<br><br><a href=3D"https://3v4l.org/Ud8Cn">https://3=
v4l.org/Ud8Cn</a></div><div><br></div><div>Jordan<br> </div></div></div>

--0000000000008b3796061cb926e8--