Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123082
Feedback-ID: id5114917:Fastmail
Date: Wed, 10 Apr 2024 08:37:14 +0100
To: internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath
User-Agent: K-9 Mail for Android
In-Reply-To: <E7B8397C-4A45-45C8-A0FD-7DF581801861@sakiot.com>
References: <6628b5e3-5f4b-4c9c-a940-56f72a645af1@rwec.co.uk> <E7B8397C-4A45-45C8-A0FD-7DF581801861@sakiot.com>
Message-ID: <B154D767-31E9-460A-9F93-187F7FF11836@rwec.co.uk>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")



On 10 April 2024 00:36:21 BST, Saki Takamachi <saki@sakiot=2Ecom> wrote:
>- The scale and rounding mode are not required for example in add, since =
the scale of the result will never be infinite and we can automatically cal=
culate the scale needed to fit the result=2E Does adding those two options =
to all calculations mean adding them to calculations like add as well?

That's why I mentioned the two different groups of users=2E The scale and =
rounding mode aren't there for group (a), who just want the scale to be man=
aged automatically; they are there for group (b), who want to guarantee a p=
articular result has a particular scale=2E The result of $a->add($b, 2, Rou=
nd::HALF_UP) will always be the same as $a->add($b)->round(Round::HALF_UP) =
 but is more convenient, and in some cases more efficient, since it doesn't=
 calculate unnecessary digits=2E=20

Remember also the title and original aim of the RFC: add object support to=
 BCMath=2E The scale parameter is already there on the existing functions (=
bcadd, bcmul, etc), so removing it on the object version would be surprisin=
g=2E The rounding mode is a new feature, but there doesn't seem a good reas=
on not to include it everywhere as well=2E



>- As Tim mentioned, it may be confusing to have an initial value separate=
 from the mode of the `round()` method=2E Would it make sense to have an in=
itial value of HALF_UP?

Again, the aim was to match the functionality of the existing functions=2E=
 It's likely that users will migrate code written using bcdiv() to use BCMa=
th\Number->div() and expect it to work the same, at least when specifying a=
 scale=2E Having it behave differently by rounding up the last digit by def=
ault seems like a bad idea=2E=20

Thinking about the implementation, the truncation behaviour also makes sen=
se: the library isn't actually rounding anything, it's calculating digit by=
 digit, and stopping when it reaches the requested scale=2E

The whole concept of rounding is something that we are adding, presumably =
by passing $scale+1 to the underlying library functions=2E It's a nice feat=
ure to add, but not one that should be on by default, given we're not writi=
ng the extension from scratch=2E


Regards,
Rowan Tommins
[IMSoP]