Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122881
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> <CAMrTa2HOEUWQcPdZE3FZ9JWCS1DWuRTNhhfqGGZOmr=v1Mctdw@mail.gmail.com>
 <CANS-=pfVuKKfAiu0LUJTrEPnSRaa_nHwJCgMvSORruAwHMsvQg@mail.gmail.com>
In-Reply-To: <CANS-=pfVuKKfAiu0LUJTrEPnSRaa_nHwJCgMvSORruAwHMsvQg@mail.gmail.com>
Date: Tue, 2 Apr 2024 10:24:42 -0700
Message-ID: <CAMrTa2HXD+62TKbaaA-v-mct5zdR5ortUAbtG1R1D22amAgpNA@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath
To: Lynn <kjarli@gmail.com>
Cc: Saki Takamachi <saki@sakiot.com>, Aleksander Machniak <alec@alec.pl>, 
	php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000091fe2d0615206254"
From: jordan.ledoux@gmail.com (Jordan LeDoux)

--00000000000091fe2d0615206254
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Apr 2, 2024 at 3:12=E2=80=AFAM Lynn <kjarli@gmail.com> wrote:

>
> I'm inexperienced when it comes to maths and the precision here, but I do
> have some experience when it comes to what the business I work for wants.
> I've implemented BCMath in a couple of places where this kind of precisio=
n
> is necessary, and I found that whenever I do divisions I prefer having at
> least 2 extra digits. Would it make sense to internally always just store=
 a
> more accurate number? For things like
> additions/multiplications/subtractions it could always use the highest
> precision, and then for divisions add like +3~6 or something. Whenever yo=
u
> have numbers that have a fraction like `10.5001` it makes sense to set it
> to 4, but when you have `10` it suddenly becomes 0 when implicitly settin=
g
> it.
>
> For the following examples assume each number is a BcNum:
> When doing something like `10 * 10.0000 * 10.000000000` I want the end
> result to have a precision of at least 9 so I don't lose information. Whe=
n
> I do `((10 / 3) * 100) * 2` I don't want it to implicitly become 0, becau=
se
> the precision here is important to me. I don't think using infinite
> precision here is a reasonable approach either. I'm not sure what the
> correct answer is, perhaps it's just "always manually set the precision"?
>

In my library, if the scale is unspecified, I actually set the scale to 10
OR the length of the input string, including integer decimals, whichever is
larger. Since I was designing my own library I could do things like that as
convention, and a scale of 10 is extremely fast, even with the horrifically
slow BCMath library, but covers most use cases (the overwhelmingly common
of which is exact calculation of money).

My library handles scale using the following design. It's not necessarily
correct here, as I was designing a PHP library instead of something for
core, AND my library does not have to deal with operator overloads so I'm
always working with method signatures instead, AND it's possible that my
class/method design is inferior to other alternatives, however it went:

1. Each number constructor allowed for an optional input scale.
2. The input number was converted into the proper formatting from allowed
input types, and then the implicit scale is set to the total number of
digits.
3. If the input scale was provided, the determined scale is set to that
value.
4. Otherwise, the determined scale at construction is set to 10 or the
implicit scale of "number of digits", whichever is larger.
5. The class contained the `roundToScale` method, which allowed you to
provide the desired scale and the rounding method, and then would set the
determined scale to that value after rounding. It contained the `round`
method with the same parameters to allow rounding to a specific scale
without also setting the internal determined scale at the same time.
6. The class contained the `setScale` method which set the value of the
internal determined scale value to an int without mutating the value at all=
.
7. All mathematical operation methods which depended on scale, (such as div
or pow), allowed an optional input scale that would be used for calculation
if present. If it was not present, the internal calculations were done by
taking the higher of the determined scale between the two operands, and
then adding 2, and then the result was done by rounding using the default
method of ROUND_HALF_EVEN if no rounding method was provided.

Again, though I have spent a lot of design time on this issue for the math
library I developed, my library did not have to deal with the RFC process
for PHP or maintain consistency with the conventions of PHP core, only with
the conventions it set for itself. However, I can provide a link to the
library for reference on the issue if that would be helpful for people that
are contributing to the design aspects of this RFC.

> The current assumption is that a Number always holds a single value. How
if we made it so that it held two values? They are the numerator and the
denominator.

Again, my experience on the issue is with the development of my own library
on the issue, however in my case I fully separated that kind of object into
its own class `Fraction`, and gave the kinds of operations we've been
discussing to the class `Decimal`. Storing numerators and denominators for
as long as possible involves a completely different set of math. For
instance, you need an algorithm to determine the Greatest Common Factor and
the Least Common Multiple in such a class, because there are a lot of
places where you would need to find the smallest common denominator or
simplify the fraction.

Abstracting between the `Fraction` and `Decimal` so that they worked with
each other honestly introduced the most complex and inscrutable code in my
entire library, so unless fractions are themselves also a design goal of
this RFC, I would recommend against it.

Jordan

--00000000000091fe2d0615206254
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 Tue, Apr 2, 2024 at 3:12=E2=80=AFA=
M Lynn &lt;<a href=3D"mailto:kjarli@gmail.com">kjarli@gmail.com</a>&gt; wro=
te:<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"><div dir=3D"=
ltr"><br><div class=3D"gmail_quote"><div>I&#39;m inexperienced when it come=
s to maths and the precision here, but I do have some experience when it co=
mes to what the business I work for wants. I&#39;ve implemented BCMath in a=
 couple of places where this kind of precision is necessary, and I found th=
at whenever I do divisions I prefer having at least 2 extra digits. Would i=
t make sense to internally always just store a more accurate number? For th=
ings like additions/multiplications/subtractions it could always use the hi=
ghest precision, and then for divisions add like=C2=A0+3~6 or something. Wh=
enever you have numbers that have a fraction like `10.5001` it makes sense =
to set it to 4, but when you have `10` it suddenly becomes 0 when implicitl=
y setting it.=C2=A0</div><div><br>For the following examples assume each nu=
mber is a BcNum:</div><div>When doing something like `10 * 10.0000 * 10.000=
000000` I want the end result to have a precision of at least 9 so I don=
9;t lose information. When I do `((10 / 3) * 100) * 2` I don&#39;t want it =
to implicitly become 0, because the precision here is important to me. I do=
n&#39;t think using infinite precision here is a reasonable approach either=
. I&#39;m not sure what the correct answer is, perhaps it&#39;s just &quot;=
always manually set the precision&quot;?</div></div></div></blockquote><div=
><br></div><div>In my library, if the scale is unspecified, I actually set =
the scale to 10 OR the length of the input string, including integer decima=
ls, whichever is larger. Since I was designing my own library I could do th=
ings like that as convention, and a scale of 10 is extremely fast, even wit=
h the horrifically slow BCMath library, but covers most use cases (the over=
whelmingly common of which is exact calculation of money).</div><div><br></=
div><div>My library handles scale using the following design. It&#39;s not =
necessarily correct here, as I was designing a PHP library instead of somet=
hing for core, AND my library does not have to deal with operator overloads=
 so I&#39;m always working with method signatures instead, AND it&#39;s pos=
sible that my class/method design is inferior to other alternatives, howeve=
r it went:</div><div><br></div><div>1. Each number constructor allowed for =
an optional input scale.</div><div>2. The input number was converted into t=
he proper formatting from allowed input types, and then the implicit scale =
is set to the total number of digits.</div><div>3. If the input scale was p=
rovided, the determined scale is set to that value.</div><div>4. Otherwise,=
 the determined scale at construction is set to 10 or the implicit scale of=
 &quot;number of digits&quot;, whichever is larger.</div><div>5. The class =
contained the `roundToScale` method, which allowed you to provide the desir=
ed scale and the rounding method, and then would set the determined scale t=
o that value after rounding. It contained the `round` method with the same =
parameters to allow rounding to a specific scale without also setting the i=
nternal determined scale at the same time.</div><div>6. The class contained=
 the `setScale` method which set the value of the internal determined scale=
 value to an int without mutating the value at all.</div><div>7. All mathem=
atical operation methods which depended on scale, (such as div or pow), all=
owed an optional input scale that would be used for calculation if present.=
 If it was not present, the internal calculations were done by taking the h=
igher of the determined scale between the two operands, and then adding 2, =
and then the result was done by rounding using the default method of ROUND_=
HALF_EVEN if no rounding method was provided.</div><div><br></div><div>Agai=
n, though I have spent a lot of design time on this issue for the math libr=
ary I developed, my library did not have to deal with the RFC process for P=
HP or maintain consistency with the conventions of PHP core, only with the =
conventions it set for itself. However, I can provide a link to the library=
 for reference on the issue if that would be helpful for people that are co=
ntributing to the design aspects of this RFC.</div><div><br></div><div>&gt;=
=20
The current assumption is that a Number always holds a single value. How
 if we made it so that it held two values? They are the numerator and=20
the denominator. <br></div><div><br></div><div>Again, my experience on the =
issue is with the development of my own library on the issue, however in my=
 case I fully separated that kind of object into its own class `Fraction`, =
and gave the kinds of operations we&#39;ve been discussing to the class `De=
cimal`. Storing numerators and denominators for as long as possible involve=
s a completely different set of math. For instance, you need an algorithm t=
o determine the Greatest Common Factor and the Least Common Multiple in suc=
h a class, because there are a lot of places where you would need to find t=
he smallest common denominator or simplify the fraction.</div><div><br></di=
v><div>Abstracting between the `Fraction` and `Decimal` so that they worked=
 with each other honestly introduced the most complex and inscrutable code =
in my entire library, so unless fractions are themselves also a design goal=
 of this RFC, I would recommend against it.<br></div><div><br></div><div>Jo=
rdan<br></div></div></div>

--00000000000091fe2d0615206254--