Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122902
Content-Type: text/plain;
	charset=us-ascii
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\))
Subject: Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath
In-Reply-To: <CAMrTa2GaK3AUp0WodhNO8RdvoLbbiCk14Gs2oWF6vEs_+qMYNg@mail.gmail.com>
Date: Wed, 3 Apr 2024 08:50:43 +0900
Cc: Lynn <kjarli@gmail.com>,
 Aleksander Machniak <alec@alec.pl>,
 php internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <655FEA80-9AB4-4AAD-A310-70ED968C97A2@sakiot.com>
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>
 <CAMrTa2GaK3AUp0WodhNO8RdvoLbbiCk14Gs2oWF6vEs_+qMYNg@mail.gmail.com>
To: Jordan LeDoux <jordan.ledoux@gmail.com>
From: saki@sakiot.com (Saki Takamachi)

Hi Barney, Jordan,

> I think that's a sufficiently different data type that it should be a =
different class (if required), and probably a separate RFC, and for now =
it's better to stay closer to the existing BCMath API.
>=20
> Developers should be prepared to accept that an arbitrary precision =
decimal can't represent 1/3 exactly, just like a binary float can't =
represent 1/10 exactly.

> 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.
>=20
> 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.

> 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.

Agree. I was a little too focused on precision and lost sight of the =
larger goal.


> 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).
>=20
> 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:
>=20
> 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.
>=20
> 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 two use cases at issue here are when the div and pow's exponent are =
negative values. So how about allowing only these two methods to =
optionally set `$scale` and `$roundMode` ?

- The constructor takes only `$num` and always uses implicit scaling. =
There is no option for the user to specify an arbitrary scale.
- `$scale`: If specified, use that value, otherwise use `10`. The scale =
specified here is added to the scale of the left operand and used as the =
scale of the result. In other words, `(new Number('0.01')->div('3', 2))` =
results in `'0.0030' // scale =3D 2 + 2 =3D 4`.
- `$roundMode`: Specifies the rounding method when the result does not =
fit within the scale. The initial value is `PHP_ROUND_TOWARD_ZERO`, =
which matches the behavior of the BCMath function. That is, just =
truncate.
- If lucky enough to get the result within the scale, apply the implicit =
scale to the result. In other words, if calculate `1 / 2`, the resulting =
scale will be `1`, even if scale is `null` or specify a value such as =
`20` for scale.
- The result of a calculation with operator overloading is the same as =
if the option was not used when executing the method.

However, I'm not sure if naming it `$scale` is appropriate.

Also, since `BCMath\Number` is not made into a final class, there is a =
possibility of implementing an inherited class in userland. Regarding =
this, is it better to make the calculation method a final method, or to =
use a function overridden by the user when executing from the opcode?

Regards.

Saki=