Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123085
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
Date: Wed, 10 Apr 2024 18:38:44 +0900
Message-ID: <04F88690-82B6-4441-B155-C489EACD6DC5@sakiot.com>
References: <B154D767-31E9-460A-9F93-187F7FF11836@rwec.co.uk>
Cc: internals@lists.php.net
In-Reply-To: <B154D767-31E9-460A-9F93-187F7FF11836@rwec.co.uk>
To: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>
From: saki@sakiot.com (Saki Takamachi)

Hi Rowan,

> That's why I mentioned the two different groups of users. The scale and ro=
unding mode aren't there for group (a), who just want the scale to be manage=
d automatically; they are there for group (b), who want to guarantee a parti=
cular result has a particular scale. The result of $a->add($b, 2, Round::HAL=
F_UP) will always be the same as $a->add($b)->round(Round::HALF_UP)  but is m=
ore convenient, and in some cases more efficient, since it doesn't calculate=
 unnecessary digits.
>=20
> Remember also the title and original aim of the RFC: add object support to=
 BCMath. The scale parameter is already there on the existing functions (bca=
dd, bcmul, etc), so removing it on the object version would be surprising. T=
he rounding mode is a new feature, but there doesn't seem a good reason not t=
o include it everywhere as well.

Ah, I understand. There may certainly be use cases where demand specifies a s=
cale smaller than the maximum scale in order to save computational costs. Th=
at makes sense to me.

Also, considering the two groups you presented, the group that wants to cont=
rol the scale is probably not going to use operator calculations, even thoug=
h they could provide various options in the constructor. Unless look at the c=
ontents of objects in the calculation process using var_dump or something, c=
an't understand the state just by looking at the code, which can lead to bug=
s. They probably don't like that kind of code.


> Again, the aim was to match the functionality of the existing functions. I=
t's likely that users will migrate code written using bcdiv() to use BCMath\=
Number->div() and expect it to work the same, at least when specifying a sca=
le. Having it behave differently by rounding up the last digit by default se=
ems like a bad idea.
>=20
> Thinking about the implementation, the truncation behaviour also makes sen=
se: the library isn't actually rounding anything, it's calculating digit by d=
igit, and stopping when it reaches the requested scale.
>=20
> The whole concept of rounding is something that we are adding, presumably b=
y passing $scale+1 to the underlying library functions. It's a nice feature t=
o add, but not one that should be on by default, given we're not writing the=
 extension from scratch.

I was thinking about this today, and I think both are correct opinions on wh=
ether to set the initial value to HALF_UP or TOWARD_ZERO. It's just a matter=
 of prioritizing whether consistency with existing behavior or consistency w=
ithin a class, and they can never be met simultaneously.

Therefore, I am considering adding a more detailed explanation to the RFC on=
 this issue and taking a second vote to decide.

Regards.

Saki=