Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122853
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
Mime-Version: 1.0 (1.0)
Subject: Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath
In-Reply-To: <CANS-=pfVuKKfAiu0LUJTrEPnSRaa_nHwJCgMvSORruAwHMsvQg@mail.gmail.com>
Cc: Jordan LeDoux <jordan.ledoux@gmail.com>,
 Aleksander Machniak <alec@alec.pl>,
 php internals <internals@lists.php.net>
Date: Tue, 2 Apr 2024 20:26:26 +0900
Message-ID: <AEE95357-FBEE-47EA-9281-CDC5733242E2@sakiot.com>
References: <CANS-=pfVuKKfAiu0LUJTrEPnSRaa_nHwJCgMvSORruAwHMsvQg@mail.gmail.com>
To: Lynn <kjarli@gmail.com>
From: saki@sakiot.com (Saki Takamachi)

Hi Jordan, Lynn,

> Something like the signature for `getNumber()` in this example would be a d=
ecent solution. Operations which have ambiguous scale (of which truly only d=
iv is in the BCMath library) should *require* scale in the method that calls=
 the calculation, however for consistency I can certainly see the argument f=
or requiring it for all calculation methods. The issue is how you want to ha=
ndle that for operator overloads, since you cannot provide arguments in that=
 situation.
>=20
> Probably the most sensible way (and I think the way I handled it as well i=
n my library) is to look at both the left and right operand, grab the calcul=
ated scale of the input for both (or the set scale if the scale has been man=
ually set), and then calculate with a higher scale. If internally it produce=
s a rounded result, the calculation should be done at `$desireScale + 2` to a=
void compound rounding errors from the BCMath library and then the implement=
ation. If the result is truncated, the calculation should be done at `$desir=
edScale + 1` to avoid calculating unnecessary digits.
>=20
> So we have multiple usage scenarios and the behavior needs to remain consi=
stent no matter which usage occurs, and what order the items are called in, s=
o long as the resulting calculation is the same.
>=20
> **Method Call**
> $bcNum =3D new Number('1.0394567'); // Input scale is implicitly 7
> $bcNum->div('1.2534', 3); // Resulting scale is 3
> $bcNum->div('1.2534'); // Implicit scale of denominator is 4, Implicit sca=
le of numerator is 7, calculate with scale of 8 then truncate
>=20
> **Operators**
> $bcNum =3D new Number('1.0394567'); // Input scale is implicitly 7
> $bcNum / '1.2534'; // Implicit scale of denominator is 4, Implicit scale o=
f numerator is 7, calculate with scale of 8 then truncate
>=20
> This allows you to perhaps keep an input scale in the constructor and also=
 maintain consistency across various calculations. But whatever the behavior=
 is, it should be mathematically sound, consistent across different syntax f=
or the same calculation, and never reducing scale UNLESS it is told to do so=
 in the calculation step OR during the value retrieval.

> I'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'v=
e implemented BCMath in a couple of places where this kind of precision is n=
ecessary, 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 ac=
curate number? For things like additions/multiplications/subtractions it cou=
ld always use the highest precision, and then for divisions add like +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 suddenly becomes 0 wh=
en implicitly setting it.=20
>=20
> For the following examples assume each number is a BcNum:
> When doing something like `10 * 10.0000 * 10.000000000` I want the end res=
ult to have a precision of at least 9 so I don't lose information. When I do=
 `((10 / 3) * 100) * 2` I don't want it to implicitly become 0, because the p=
recision here is important to me. I don't think using infinite precision her=
e is a reasonable approach either. I'm not sure what the correct answer is, p=
erhaps it's just "always manually set the precision"?

Thanks for the important perspective feedback.

One thing I overlooked: if the exponent of pow is negative, the scale of the=
 result becomes unpredictable, just like with div.

e.g.
```
3 ** -1
=3D 0.333333.....
```

Also, an idea occurred to me while reading your comments.

The current assumption is that a Number always holds a single value. How if w=
e made it so that it held two values? They are the numerator and the denomin=
ator.

This means that when we do division, no division is done internally, but we a=
ctually multiply the denominator. At the very end of the process, when conve=
rting to string, any reserved division is performed according to the specifi=
ed scale.

If we have the option of not specifying a scale when converting to a string,=
 it may be preferable to convert based on an implicit scale.

Regards.

Saki=