Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122850
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> <CAMrTa2EK6ymBQuxeFj7tMV0M2crqCCCR=mLN-FSfuCgrQHEZ6A@mail.gmail.com>
 <AB663F3F-A888-45F7-B19A-00530A4EDB0C@sakiot.com>
In-Reply-To: <AB663F3F-A888-45F7-B19A-00530A4EDB0C@sakiot.com>
Date: Tue, 2 Apr 2024 02:09:13 -0700
Message-ID: <CAMrTa2HOEUWQcPdZE3FZ9JWCS1DWuRTNhhfqGGZOmr=v1Mctdw@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath
To: Saki Takamachi <saki@sakiot.com>
Cc: Aleksander Machniak <alec@alec.pl>, php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000007b588d061519763b"
From: jordan.ledoux@gmail.com (Jordan LeDoux)

--0000000000007b588d061519763b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, Mar 30, 2024 at 5:09=E2=80=AFPM Saki Takamachi <saki@sakiot.com> wr=
ote:

> Hi Jordan,
>
> Your opinion may be reasonable given the original BCMath calculation
> order. That is, do you intend code like this?
>
> Signature:
> ```
> // public function __construct(string|int $number)
> // public function getNumber(?int $scale =3D null): string
> ```
>
> Add:
> ```
> // public function add(Number|string|int $number): string
>
> $num =3D new Number('1.23456');
> $num2 =3D new Number('1.23');
>
> $add =3D $num + $num2;
> $add->getNumber(); // '2.46456'
> $add->getNumber(1); // =E2=80=982.4'
>
> $add =3D $num->add($num2);
> $add->getNumber(); // '2.46456'
> $add->getNumber(1); // '2.4'
> ```
>
> Div:
> ```
> // public function div(Number|string|int $number, int $scaleExpansionLimi=
t
> =3D 10): string
>
>
> // case 1
> $num =3D new Number('0.0001');
> $num2 =3D new Number('3');
>
> $div =3D $num / $num2; // scale expansion limit is always 10
> $div->getNumber(); // '0.0000333333333'
>
> $div =3D $num->div($num2, 20);
> $div->getNumber(); // '0.00003333333333333333333'
> $div->getNumber(7); // =E2=80=980.0000333'
>
>
> // case 2
> $num =3D new Number('1.111111');
> $num2 =3D new Number('3');
>
> $div =3D $num->div($num2, 3);
> $div->getNumber(); // '0.370'
> $div->getNumber(7); // =E2=80=980.3700000'
> ```
>
> Since the scale can be inferred for everything other than div, a special
> argument is given only for div.
>
> Regards.
>
> Saki


Something like the signature for `getNumber()` in this example would be a
decent solution. Operations which have ambiguous scale (of which truly only
div is in the BCMath library) should *require* scale in the method that
calls the calculation, however for consistency I can certainly see the
argument for requiring it for all calculation methods. The issue is how you
want to handle that for operator overloads, since you cannot provide
arguments in that situation.

Probably the most sensible way (and I think the way I handled it as well in
my library) is to look at both the left and right operand, grab the
calculated scale of the input for both (or the set scale if the scale has
been manually set), and then calculate with a higher scale. If internally
it produces a rounded result, the calculation should be done at
`$desireScale + 2` to avoid compound rounding errors from the BCMath
library and then the implementation. If the result is truncated, the
calculation should be done at `$desiredScale + 1` to avoid calculating
unnecessary digits.

So we have multiple usage scenarios and the behavior needs to remain
consistent no matter which usage occurs, and what order the items are
called in, so long as the resulting calculation is the same.

**Method Call**
$bcNum =3D new Number('1.0394567'); // Input scale is implicitly 7
$bcNum->div('1.2534', 3); // Resulting scale is 3
$bcNum->div('1.2534'); // Implicit scale of denominator is 4, Implicit
scale of numerator is 7, calculate with scale of 8 then truncate

**Operators**
$bcNum =3D new Number('1.0394567'); // Input scale is implicitly 7
$bcNum / '1.2534'; // Implicit scale of denominator is 4, Implicit scale of
numerator is 7, calculate with scale of 8 then truncate

This allows you to perhaps keep an input scale in the constructor and also
maintain consistency across various calculations. But whatever the behavior
is, it should be mathematically sound, consistent across different syntax
for the same calculation, and never reducing scale UNLESS it is told to do
so in the calculation step OR during the value retrieval.

Jordan

--0000000000007b588d061519763b
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 Sat, Mar 30, 2024 at 5:09=E2=80=AF=
PM 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 =
Jordan,<br>
<br>
Your opinion may be reasonable given the original BCMath calculation order.=
 That is, do you intend code like this?<br>
<br>
Signature:<br>
```<br>
// public function __construct(string|int $number)<br>
// public function getNumber(?int $scale =3D null): string<br>
```<br>
<br>
Add:<br>
```<br>
// public function add(Number|string|int $number): string<br>
<br>
$num =3D new Number(&#39;1.23456&#39;);<br>
$num2 =3D new Number(&#39;1.23&#39;);<br>
<br>
$add =3D $num + $num2;<br>
$add-&gt;getNumber(); // &#39;2.46456&#39;<br>
$add-&gt;getNumber(1); // =E2=80=982.4&#39;<br>
<br>
$add =3D $num-&gt;add($num2);<br>
$add-&gt;getNumber(); // &#39;2.46456&#39;<br>
$add-&gt;getNumber(1); // &#39;2.4&#39;<br>
```<br>
<br>
Div:<br>
```<br>
// public function div(Number|string|int $number, int $scaleExpansionLimit =
=3D 10): string<br>
<br>
<br>
// case 1<br>
$num =3D new Number(&#39;0.0001&#39;);<br>
$num2 =3D new Number(&#39;3&#39;);<br>
<br>
$div =3D $num / $num2; // scale expansion limit is always 10<br>
$div-&gt;getNumber(); // &#39;0.0000333333333&#39;<br>
<br>
$div =3D $num-&gt;div($num2, 20);<br>
$div-&gt;getNumber(); // &#39;0.00003333333333333333333&#39;<br>
$div-&gt;getNumber(7); // =E2=80=980.0000333&#39;<br>
<br>
<br>
// case 2<br>
$num =3D new Number(&#39;1.111111&#39;);<br>
$num2 =3D new Number(&#39;3&#39;);<br>
<br>
$div =3D $num-&gt;div($num2, 3);<br>
$div-&gt;getNumber(); // &#39;0.370&#39;<br>
$div-&gt;getNumber(7); // =E2=80=980.3700000&#39;<br>
```<br>
<br>
Since the scale can be inferred for everything other than div, a special ar=
gument is given only for div.<br>
<br>
Regards.<br>
<br>
Saki</blockquote><div><br></div><div>Something like the signature for `getN=
umber()` in this example would be a decent solution. Operations which have =
ambiguous scale (of which truly only div is in the BCMath library) should *=
require* scale in the method that calls the calculation, however for consis=
tency I can certainly see the argument for requiring it for all calculation=
 methods. The issue is how you want to handle that for operator overloads, =
since you cannot provide arguments in that situation. <br></div><div><br></=
div><div>Probably the most sensible way (and I think the way I handled it a=
s well in my library) is to look at both the left and right operand, grab t=
he calculated scale of the input for both (or the set scale if the scale ha=
s been manually set), and then calculate with a higher scale. If internally=
 it produces a rounded result, the calculation should be done at `$desireSc=
ale + 2` to avoid compound rounding errors from the BCMath library and then=
 the implementation. If the result is truncated, the calculation should be =
done at `$desiredScale + 1` to avoid calculating unnecessary digits.</div><=
div><br></div><div>So we have multiple usage scenarios and the behavior nee=
ds to remain consistent no matter which usage occurs, and what order the it=
ems are called in, so long as the resulting calculation is the same.</div><=
div><br></div><div>**Method Call**</div><div>$bcNum =3D new Number(&#39;1.0=
394567&#39;); // Input scale is implicitly 7<br></div><div>$bcNum-&gt;div(&=
#39;1.2534&#39;, 3); // Resulting scale is 3</div><div>$bcNum-&gt;div(&#39;=
1.2534&#39;); // Implicit scale of denominator is 4, Implicit scale of nume=
rator is 7, calculate with scale of 8 then truncate<br></div><div><br></div=
><div>**Operators**</div><div>$bcNum =3D new Number(&#39;1.0394567&#39;); /=
/ Input scale is implicitly 7</div><div>$bcNum / &#39;1.2534&#39;; //=20
Implicit scale of denominator is 4, Implicit scale of numerator is 7, calcu=
late with scale of 8 then truncate <br></div><div><br></div><div>This allow=
s you to perhaps keep an input scale in the constructor and also maintain c=
onsistency across various calculations. But whatever the behavior is, it sh=
ould be mathematically sound, consistent across different syntax for the sa=
me calculation, and never reducing scale UNLESS it is told to do so in the =
calculation step OR during the value retrieval.</div><div><br></div><div>Jo=
rdan<br></div></div></div>

--0000000000007b588d061519763b--