Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122815
Precedence: bulk
MIME-Version: 1.0
References: <4F094EDA-5058-407D-AF39-06FD934FDE1F@sakiot.com>
 <bbcff629-4dd6-bc50-ac9f-641849dc218a@php.net> <68CF373E-6ABF-4471-8992-813B4BA1B508@sakiot.com>
 <904197f4-afb5-401e-9e17-7a655c5449d0@alec.pl>
In-Reply-To: <904197f4-afb5-401e-9e17-7a655c5449d0@alec.pl>
Date: Fri, 29 Mar 2024 19:11:15 -0700
Message-ID: <CAMrTa2EK6ymBQuxeFj7tMV0M2crqCCCR=mLN-FSfuCgrQHEZ6A@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath
To: Aleksander Machniak <alec@alec.pl>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="00000000000039ae4a0614d74652"
From: jordan.ledoux@gmail.com (Jordan LeDoux)

--00000000000039ae4a0614d74652
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Mar 27, 2024 at 12:08=E2=80=AFAM Aleksander Machniak <alec@alec.pl>=
 wrote:

> On 27.03.2024 01:03, Saki Takamachi wrote:
> >> $num =3D new BcNum('1.23', 2);
> >> $result =3D $num + '1.23456';
> >> $result->value; // '2.46456'
> >> $result->scale; // ??
> >
> > In this case, `$result->scale` will be `'5'`. I added this to the RFC.
>
> I'm not sure I like this. Maybe we should be more strict here and treat
> the $scale in constructor (and later withScale()) as the actual scale
> for all operations.
>
>
For addition, it absolutely should expand scale like this, unless the
constructor also defines a default rounding type that is used in that
situation. All numbers, while arbitrary, will be finite, so addition will
always be exact and known based on inputs prior to calculation.

Treating scale like this isn't more strict, it's confusing. For instance:

```
$numA =3D new Number('1.23', 2);
$numB =3D new Number('1.23456', 5);

$expandedScale1 =3D $numA + $numB; // 2.46456
$expandedScale2 =3D $numB + $numA; // 2.46456

$strictScale1 =3D $numA + $numB; // 2.46 assuming truncation
$strictScale2 =3D $numB + $numA; // 2.46456
```

I ran into this same issue with operand ordering when I was writing my
operator overload RFC.

There are ways you could do the overload implementation that would get
around this for object + object operations, but it's also mathematically
unsound and probably unexpected for anyone who is going to the trouble of
using an arbitrary precision library.

Addition and subtraction should automatically use the largest scale from
all operands. Division and multiplication should require a specified scale.

Because of this, I'm not entirely sure that specifying a scale in the
constructor is actually a good thing. It is incredibly easy to create
situations, unless the implementation in C is VERY careful, where the
operand positions matter beyond the simple calculation. Multiplication is
commutative, but division is not. This would almost certainly lead to some
very difficult to track down bugs.

Putting scale in the constructor is similar to some of the examples of
"possible misuse cases of operator overloading" that I had to go over when
I was making my RFC. We definitely want to avoid that if possible for the
first number/math object that has operator overloads.

Jordan

--00000000000039ae4a0614d74652
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 Wed, Mar 27, 2024 at 12:08=E2=80=
=AFAM Aleksander Machniak &lt;<a href=3D"mailto:alec@alec.pl">alec@alec.pl<=
/a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">O=
n 27.03.2024 01:03, Saki Takamachi wrote:<br>
&gt;&gt; $num =3D new BcNum(&#39;1.23&#39;, 2);<br>
&gt;&gt; $result =3D $num + &#39;1.23456&#39;;<br>
&gt;&gt; $result-&gt;value; // &#39;2.46456&#39;<br>
&gt;&gt; $result-&gt;scale; // ??<br>
&gt; <br>
&gt; In this case, `$result-&gt;scale` will be `&#39;5&#39;`. I added this =
to the RFC.<br>
<br>
I&#39;m not sure I like this. Maybe we should be more strict here and treat=
 <br>
the $scale in constructor (and later withScale()) as the actual scale <br>
for all operations.<br>
<br></blockquote><div><br></div><div>For addition, it absolutely should exp=
and scale like this, unless the constructor also defines a default rounding=
 type that is used in that situation. All numbers, while arbitrary, will be=
 finite, so addition will always be exact and known based on inputs prior t=
o calculation. <br></div><div><br></div><div>Treating scale like this isn&#=
39;t more strict, it&#39;s confusing. For instance:</div><div><br></div><di=
v>```</div><div>$numA =3D new Number(&#39;1.23&#39;, 2);</div><div>$numB =
=3D new Number(&#39;1.23456&#39;, 5);</div><div><br></div><div>$expandedSca=
le1 =3D $numA + $numB; // 2.46456</div><div>$expandedScale2 =3D $numB + $nu=
mA; // 2.46456</div><div><br></div><div>$strictScale1 =3D $numA + $numB; //=
 2.46 assuming truncation</div><div>$strictScale2 =3D $numB + $numA; // 2.4=
6456</div><div>```</div><div><br></div><div>I ran into this same issue with=
 operand ordering when I was writing my operator overload RFC.</div><div><b=
r></div><div>There are ways you could do the overload implementation that w=
ould get around this for object + object operations, but it&#39;s also math=
ematically unsound and probably unexpected for anyone who is going to the t=
rouble of using an arbitrary precision library.</div><div><br></div><div>Ad=
dition and subtraction should automatically use the largest scale from all =
operands. Division and multiplication should require a specified scale.</di=
v><div><br></div><div>Because of this, I&#39;m not entirely sure that speci=
fying a scale in the constructor is actually a good thing. It is incredibly=
 easy to create situations, unless the implementation in C is VERY careful,=
 where the operand positions matter beyond the simple calculation. Multipli=
cation is commutative, but division is not. This would almost certainly lea=
d to some very difficult to track down bugs.</div><div><br></div><div>Putti=
ng scale in the constructor is similar to some of the examples of &quot;pos=
sible misuse cases of operator overloading&quot; that I had to go over when=
 I was making my RFC. We definitely want to avoid that if possible for the =
first number/math object that has operator overloads.<br></div><div><br></d=
iv><div>Jordan<br></div></div></div>

--00000000000039ae4a0614d74652--