Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122919
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>
In-Reply-To: <f4002280-bec7-459b-b65b-b261e4f52aad@rwec.co.uk>
Date: Wed, 3 Apr 2024 18:29:55 -0700
Message-ID: <CAMrTa2Gm4B++JvdddkHQkDDqWxmxLY6pCE7C5QeSPsV-08YRgw@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="0000000000009232f806153b4774"
From: jordan.ledoux@gmail.com (Jordan LeDoux)

--0000000000009232f806153b4774
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Mar 18, 2024 at 1:35=E2=80=AFPM Rowan Tommins [IMSoP] <imsop.php@rw=
ec.co.uk>
wrote:

>
> Where things get more complicated is with *fixed-precision* decimals,
> which is what is generally wanted for something like money. What is the
> correct result of decimal(1.03, precision: 2) / 2 - decimal(0.515, 3)?
> decimal(0.51, 2)? decimal (0.52, 2)? an error? And what about decimal(10)=
 /
> 3?
>
> If you stick to functions / methods, this is slightly less of an issue,
> because you can have decimal(1.03, 2)->dividedBy(2, RoundingMode::DOWN) =
=3D=3D
> decimal(0.51, 2); or decimal(1.03, 2)->split(2) =3D=3D [ decimal(0.52, 2)=
,
> decimal(0.51, 2) ] Example names taken directly from the brick/money
> package.
>
> At that point, backwards compatibility is less of an issue as well: make
> the new functions convenient to use, but distinct from the existing ones
>
I came back to this discussion after my last reply on the BCMath as an
object thread, because we went through a very similar discussion there with
regard to operators.

I think that, roughly, the fixed precision should be defined on the scalar
itself:

1.234_d3

1.234 is the value, _d makes it a decimal type, and 3 shows that this value
has a precision of 3. (Actually, it has a SCALE of 3, since precision is
significant digits, and also includes the integer portion). But when it
comes to fixed-precision values, it should follow rules very similar to
those we discussed in the BCMath thread:

- Addition and subtraction should return a value that is the largest
scale/precision of any operands in the calculation.
- Division and multiplication should return a value that is the sum of the
scale/precision of any operands + 2 or a default (perhaps configurable)
value if the sum is small, to ensure that rounding occurs correctly. Near
zero, floats have about 12-ish decimal digits of accuracy, and will return
their full accuracy for example.
- Pow is extremely difficult to work with if you allow a decimal in the
exponent. The libraries we have discussed previously handle this
difficulty, but the precision needed often depends on what the calculation
is for, so I'm not entirely sure what the best way to handle this with
operators would be. Minimally, probably the same as division and
multiplication.

But if we have scalar decimal types, we need something like that _d12 to
denote a decimal scalar with a scale/precision of 12.

Jordan

--0000000000009232f806153b4774
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 Mon, Mar 18, 2024 at 1:35=E2=80=AF=
PM Rowan Tommins [IMSoP] &lt;<a href=3D"mailto:imsop.php@rwec.co.uk">imsop.=
php@rwec.co.uk</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex"><u></u>

 =20
   =20
 =20
  <div><br><p>Where things get more complicated is with *fixed-precision*
      decimals, which is what is generally wanted for something like
      money. What is the correct result of decimal(1.03, precision: 2) /
      2 - decimal(0.515, 3)? decimal(0.51, 2)? decimal (0.52, 2)? an
      error? And what about decimal(10) / 3?</p>
    <p>If you stick to functions / methods, this is slightly less of an
      issue, because you can have decimal(1.03, 2)-&gt;dividedBy(2,
      RoundingMode::DOWN) =3D=3D decimal(0.51, 2); or decimal(1.03,
      2)-&gt;split(2) =3D=3D [ decimal(0.52, 2), decimal(0.51, 2) ] Example
      names taken directly from the brick/money package.=C2=A0</p>
    <p>At that point, backwards compatibility is less of an issue as
      well: make the new functions convenient to use, but distinct from
      the existing ones</p></div></blockquote><div>I came back to this disc=
ussion after my last reply on the BCMath as an object thread, because we we=
nt through a very similar discussion there with regard to operators. <br></=
div><div><br></div><div>I think that, roughly, the fixed precision should b=
e defined on the scalar itself:</div><div><br></div><div>1.234_d3</div><div=
><br></div><div>1.234 is the value, _d makes it a decimal type, and 3 shows=
 that this value has a precision of 3. (Actually, it has a SCALE of 3, sinc=
e precision is significant digits, and also includes the integer portion). =
But when it comes to fixed-precision values, it should follow rules very si=
milar to those we discussed in the BCMath thread:</div><div><br></div><div>=
- Addition and subtraction should return a value that is the largest scale/=
precision of any operands in the calculation.</div><div>- Division and mult=
iplication should return a value that is the sum of the scale/precision of =
any operands + 2 or a default (perhaps configurable) value if the sum is sm=
all, to ensure that rounding occurs correctly. Near zero, floats have about=
 12-ish decimal digits of accuracy, and will return their full accuracy for=
 example.<br></div><div>- Pow is extremely difficult to work with if you al=
low a decimal in the exponent. The libraries we have discussed previously h=
andle this difficulty, but the precision needed often depends on what the c=
alculation is for, so I&#39;m not entirely sure what the best way to handle=
 this with operators would be. Minimally, probably the same as division and=
 multiplication.</div><div><br></div><div>But if we have scalar decimal typ=
es, we need something like that _d12 to denote a decimal scalar with a scal=
e/precision of 12.</div><div><br></div><div>Jordan<br></div></div></div>

--0000000000009232f806153b4774--