Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122952
Precedence: bulk
MIME-Version: 1.0
References: <18c42fdbb30.2831.17a3710df6d58f02ca570cc47e197a63@interi.co>
 <CAFPFaMLZ3MeGXt5OPmAkwM-n-eZcp1gT7RQCnpXSyHxZThOn2g@mail.gmail.com>
 <CAOyH9yReYorVd1jDPyk_O73JUn1VvqEAz0Fb7mvQ6ke9k9FcZA@mail.gmail.com>
 <CAFPFaMKoH1PD_qaBPLw9pwid0NB5zyZYM7AgogYOWFhPVysEwQ@mail.gmail.com>
 <CAOyH9ySfZnVgpZkDbL+sP_DCmnyBaq4D=K9kHjsXXLhX-dOkcA@mail.gmail.com>
 <f4002280-bec7-459b-b65b-b261e4f52aad@rwec.co.uk> <CAMrTa2Gm4B++JvdddkHQkDDqWxmxLY6pCE7C5QeSPsV-08YRgw@mail.gmail.com>
 <9dfdd88a-f840-4933-b26b-8149a4381246@rwec.co.uk>
In-Reply-To: <9dfdd88a-f840-4933-b26b-8149a4381246@rwec.co.uk>
Date: Thu, 4 Apr 2024 15:31:33 -0700
Message-ID: <CAMrTa2FsLejL1GZi8-qVbq54_s2jA4SR_xL-OBSHR5u5hiZqoQ@mail.gmail.com>
Subject: Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type
To: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000af5aa006154ce7b6"
From: jordan.ledoux@gmail.com (Jordan LeDoux)

--000000000000af5aa006154ce7b6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Apr 4, 2024 at 2:28=E2=80=AFPM Rowan Tommins [IMSoP] <imsop.php@rwe=
c.co.uk>
wrote:

>
>
> I haven't followed the discussion in the other thread, but I'm not sure
> what the use case would be for a "fixed scale decimal" that followed
> those rules.
>
> As mentioned before, the use case I've encountered is money
> calculations, where what people want to fix is the smallest unit of
> account - e.g. =E2=82=AC0.01 for practical currency, or =E2=82=AC0.0001 f=
or detailed
> accounting / trading.
>
> If I write $total =3D 1.03_d2; $perPerson =3D $total / 2; I want a result=
 of
> 0.51_d2 or 0.52_d2 - that's why I specified a scale of 2 in the first
> place.
>

Well, firstly most of the financial applications that I've worked in (I
work for a firm that writes accounting software right now) do not calculate
intermediate steps like this with fixed precision, or even have an interest
in doing so. They generally want maximum precision that is computationally
reasonable, and then round it according to their preferred method at the
end. Doing the calculations as you are suggesting would introduce a maximum
error of several cents/pence/etc. after only two or three calculations,
which is utterly useless for most applications that deal with money.

Truly "fixed-precision" is not something that decimal should even try to
be, in my opinion. The use cases where you CANNOT simply round the result
at the end to fit your display output or your storage location are very
minimal.


> If I want an accurate result of 0.515_d3, I would just specify 1.03_d,
> since the scale hasn't had any effect on the result.
>
> If I want a lossless split into [0.51_d2, 0.52_d2] I still need a
> function to exist somewhere, whether you spell that $total->split(2), or
> decimal_split($total, 2), etc. So it seems safer to also have
> $total->div(2, Round::DOWN) or decimal_div($total, 2, Round::DOWN) and
> have $total / 2 give an error.
>

I mean, what you are describing is how such OBJECTS are designed in other
languages like Python, but not scalars. Python also has (almost completely
unrestricted) userland operator overloading, which PHP does not, which
further makes the comparison a little murky.

This kind of precision restriction isn't something you would place on an
individual value, it's something you would place on all calculations.
That's why in Python this is done with a global runtime setting using
`getContext().perc` and `getContext().rounding`. A particular value having
a precision of X doesn't imply anything concrete about a calculation that
uses that value necessarily.


> Possibly, it could only error if the result doesn't fit in the scale, so
> that this would be fine: $total =3D 11.00_d2; $perPerson =3D $total / 2;
> assert($perPerson =3D=3D=3D 5.50_d2)
>
> Or possibly, it would just be an error to perform division on a fixed
> scale decimal, but allowed on a variable-fixed scale decimal.
>

Maybe we're just not understanding each other. Are you opposed to the idea
of doing this as a scalar? It certainly feels that way. This feels more
like an argument in favor of doing object-like numerics for this. I suppose
that isn't really that strange either, because as I noted such a value will
almost certainly need to be refcounted because it will not fit into the 64
bits available for a zval no matter what underlying library is used to
perform the math.

Jordan

--000000000000af5aa006154ce7b6
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 Thu, Apr 4, 2024 at 2:28=E2=80=AFP=
M Rowan Tommins [IMSoP] &lt;<a href=3D"mailto:imsop.php@rwec.co.uk">imsop.p=
hp@rwec.co.uk</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi=
ng-left:1ex"><br>
<br>
I haven&#39;t followed the discussion in the other thread, but I&#39;m not =
sure <br>
what the use case would be for a &quot;fixed scale decimal&quot; that follo=
wed <br>
those rules.<br>
<br>
As mentioned before, the use case I&#39;ve encountered is money <br>
calculations, where what people want to fix is the smallest unit of <br>
account - e.g. =E2=82=AC0.01 for practical currency, or =E2=82=AC0.0001 for=
 detailed <br>
accounting / trading.<br>
<br>
If I write $total =3D 1.03_d2; $perPerson =3D $total / 2; I want a result o=
f <br>
0.51_d2 or 0.52_d2 - that&#39;s why I specified a scale of 2 in the first p=
lace.<br></blockquote><div><br></div><div>Well, firstly most of the financi=
al applications that I&#39;ve worked in (I work for a firm that writes acco=
unting software right now) do not calculate intermediate steps like this wi=
th fixed precision, or even have an interest in doing so. They generally wa=
nt maximum precision that is computationally reasonable, and then round it =
according to their preferred method at the end. Doing the calculations as y=
ou are suggesting would introduce a maximum error of several cents/pence/et=
c. after only two or three calculations, which is utterly useless for most =
applications that deal with money.</div><div><br></div><div>Truly &quot;fix=
ed-precision&quot; is not something that decimal should even try to be, in =
my opinion. The use cases where you CANNOT simply round the result at the e=
nd to fit your display output or your storage location are very minimal.</d=
iv><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
If I want an accurate result of 0.515_d3, I would just specify 1.03_d, <br>
since the scale hasn&#39;t had any effect on the result.<br>
<br>
If I want a lossless split into [0.51_d2, 0.52_d2] I still need a <br>
function to exist somewhere, whether you spell that $total-&gt;split(2), or=
 <br>
decimal_split($total, 2), etc. So it seems safer to also have <br>
$total-&gt;div(2, Round::DOWN) or decimal_div($total, 2, Round::DOWN) and <=
br>
have $total / 2 give an error.<br></blockquote><div><br></div><div>I mean, =
what you are describing is how such OBJECTS are designed in other languages=
 like Python, but not scalars. Python also has (almost completely unrestric=
ted) userland operator overloading, which PHP does not, which further makes=
 the comparison a little murky.</div><div><br></div><div>This kind of preci=
sion restriction isn&#39;t something you would place on an individual value=
, it&#39;s something you would place on all calculations. That&#39;s why in=
 Python this is done with a global runtime setting using `getContext().perc=
` and `getContext().rounding`. A particular value having a precision of X d=
oesn&#39;t imply anything concrete about a calculation that uses that value=
 necessarily.<br></div><div>=C2=A0<br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex">
Possibly, it could only error if the result doesn&#39;t fit in the scale, s=
o <br>
that this would be fine: $total =3D 11.00_d2; $perPerson =3D $total / 2; <b=
r>
assert($perPerson =3D=3D=3D 5.50_d2)<br>
<br>
Or possibly, it would just be an error to perform division on a fixed <br>
scale decimal, but allowed on a variable-fixed scale decimal.<br></blockquo=
te><div><br></div><div>Maybe we&#39;re just not understanding each other. A=
re you opposed to the idea of doing this as a scalar? It certainly feels th=
at way. This feels more like an argument in favor of doing object-like nume=
rics for this. I suppose that isn&#39;t really that strange either, because=
 as I noted such a value will almost certainly need to be refcounted becaus=
e it will not fit into the 64 bits available for a zval no matter what unde=
rlying library is used to perform the math. <br></div><div><br></div><div>J=
ordan<br></div></div></div>

--000000000000af5aa006154ce7b6--