Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122883
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> <CAMrTa2HXD+62TKbaaA-v-mct5zdR5ortUAbtG1R1D22amAgpNA@mail.gmail.com>
In-Reply-To: <CAMrTa2HXD+62TKbaaA-v-mct5zdR5ortUAbtG1R1D22amAgpNA@mail.gmail.com>
Date: Tue, 2 Apr 2024 10:33:20 -0700
Message-ID: <CAMrTa2GaK3AUp0WodhNO8RdvoLbbiCk14Gs2oWF6vEs_+qMYNg@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="0000000000006240bf06152081b2"
From: jordan.ledoux@gmail.com (Jordan LeDoux)

--0000000000006240bf06152081b2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Apr 2, 2024 at 10:24=E2=80=AFAM Jordan LeDoux <jordan.ledoux@gmail.=
com>
wrote:

>
>
> 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 d=
o
>> 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 precisi=
on
>> is necessary, and I found that whenever I do divisions I prefer having a=
t
>> least 2 extra digits. Would it make sense to internally always just stor=
e 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 y=
ou
>> have numbers that have a fraction like `10.5001` it makes sense to set i=
t
>> to 4, but when you have `10` it suddenly becomes 0 when implicitly setti=
ng
>> 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. Wh=
en
>> I do `((10 / 3) * 100) * 2` I don't want it to implicitly become 0, beca=
use
>> 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 1=
0
> 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 horrifical=
ly
> 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 a=
ll.
> 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 usi=
ng
> 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 mat=
h
> 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 wi=
th
> 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 th=
at
> are contributing to the design aspects of this RFC.
>
> > The current assumption is that a Number always holds a single value. Ho=
w
> 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 Commo=
n
> 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 denominato=
r
> 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 m=
y
> entire library, so unless fractions are themselves also a design goal of
> this RFC, I would recommend against it.
>
> Jordan
>

An addendum:

Having two classes `Fraction` and `Decimal` necessitated that I had a
`Number` class they both extended, as there are many situations where I
would want to type-hint "anything that calculation can be done on with
arbitrary precision" instead of specifically one or the other. I also
provided the `NumberInterface`, `DecimalInterface`, and
`FractionInterface`, though I don't think that would be necessary here as
this is much more just a wrapper for BCMath than an extension of it. The
main goal of my library was not to act as a wrapper for BCMath, it was to
EXTEND BCMath with additional capabilities, such as trigonometric functions
that have arbitrary precision, so keep that in mind when weighing input of
mine that is referencing the work I have done on this topic. The design
goals were different.

Jordan

--0000000000006240bf06152081b2
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 10:24=E2=80=AF=
AM Jordan LeDoux &lt;<a href=3D"mailto:jordan.ledoux@gmail.com">jordan.ledo=
ux@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"g=
mail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Apr 2, 2024 at 3:=
12=E2=80=AFAM Lynn &lt;<a href=3D"mailto:kjarli@gmail.com" target=3D"_blank=
">kjarli@gmail.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"><div dir=3D"ltr"><br><div class=3D"gmail_quote"><div>I=
9;m inexperienced when it comes to maths and the precision here, but I do h=
ave some experience when it comes to what the business I work for wants. I&=
#39;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/subtracti=
ons it could always use the highest precision, and then for divisions add l=
ike=C2=A0+3~6 or something. Whenever you have numbers that have a fraction =
like `10.5001` it makes sense to set it to 4, but when you have `10` it sud=
denly becomes 0 when implicitly setting it.=C2=A0</div><div><br>For the fol=
lowing examples assume each number is a BcNum:</div><div>When doing somethi=
ng like `10 * 10.0000 * 10.000000000` I want the end result to have a preci=
sion of at least 9 so I don&#39;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 don&#39;t think using infinite precision here i=
s 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 i=
s unspecified, I actually set the scale to 10 OR the length of the input st=
ring, including integer decimals, whichever is larger. Since I was designin=
g 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 c=
overs most use cases (the overwhelmingly common of which is exact calculati=
on of money).</div><div><br></div><div>My library handles scale using the f=
ollowing design. It&#39;s not necessarily correct here, as I was designing =
a PHP library instead of something for core, AND my library does not have t=
o deal with operator overloads so I&#39;m always working with method signat=
ures instead, AND it&#39;s possible that my class/method design is inferior=
 to other alternatives, however it went:</div><div><br></div><div>1. Each n=
umber constructor allowed for an optional input scale.</div><div>2. The inp=
ut number was converted into the proper formatting from allowed input types=
, and then the implicit scale is set to the total number of digits.</div><d=
iv>3. If the input scale was provided, 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 l=
arger.</div><div>5. The class contained the `roundToScale` method, which al=
lowed you to provide the desired scale and the rounding method, and then wo=
uld set the determined scale to that value after rounding. It contained the=
 `round` method with the same parameters to allow rounding to a specific sc=
ale without also setting the internal determined scale at the same time.</d=
iv><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 a=
t all.</div><div>7. All mathematical operation methods which depended on sc=
ale, (such as div or pow), allowed an optional input scale that would be us=
ed for calculation if present. If it was not present, the internal calculat=
ions 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 usin=
g the default method of ROUND_HALF_EVEN if no rounding method was provided.=
</div><div><br></div><div>Again, though I have spent a lot of design time o=
n this issue for the math library I developed, my library did not have to d=
eal with the RFC process for PHP or maintain consistency with the conventio=
ns 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.=
</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></blockquote><div><br></div><div>An addendum:<br>=
<br></div><div>Having two classes `Fraction` and `Decimal` necessitated tha=
t I had a `Number` class they both extended, as there are many situations w=
here I would want to type-hint &quot;anything that calculation can be done =
on with arbitrary precision&quot; instead of specifically one or the other.=
 I also provided the `NumberInterface`, `DecimalInterface`, and `FractionIn=
terface`, though I don&#39;t think that would be necessary here as this is =
much more just a wrapper for BCMath than an extension of it. The main goal =
of my library was not to act as a wrapper for BCMath, it was to EXTEND BCMa=
th with additional capabilities, such as trigonometric functions that have =
arbitrary precision, so keep that in mind when weighing input of mine that =
is referencing the work I have done on this topic. The design goals were di=
fferent.</div><div><br></div><div>Jordan<br></div></div></div>

--0000000000006240bf06152081b2--