Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123096
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: Thu, 11 Apr 2024 01:45:23 +0900
Message-ID: <C40230D1-C9F2-42B7-BF28-5F3A76489947@sakiot.com>
References: <15702F55-16D1-43AD-88CC-BC703E267FFC@rwec.co.uk>
Cc: internals@lists.php.net
In-Reply-To: <15702F55-16D1-43AD-88CC-BC703E267FFC@rwec.co.uk>
To: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>
From: saki@sakiot.com (Saki Takamachi)

Hi Rowan,

> Yes, I agree there's a dilemma there.
>=20
> The extra point in favour of TOWARD_ZERO is that it's more efficient, beca=
use we don't have to over-calculate and round, just pass scale directly to t=
he implementation. Any other option makes for unnecessary extra calculation i=
n code like this:
>=20
> $total =3D new Number('20');
> $raw_frac =3D $total / 7;
> $rounded_frac =3D $raw_frac->round(2, Round::HALF_UP);
>=20
> If HALF_UP rounding is the implied default, we have to calculate with scal=
e 11 giving 1.42857142857, round to 1.4285714286, then round again to 1.43.
>=20
> If truncation / TOWARD_ZERO is the implied default, we only calculate with=
 scale 10 giving 1.4285714285 and then round once to 1.43.
>=20
> (Of course, in this example, the most efficient would be for the user to w=
rite $rounded_frac =3D $total->div(7, 2, Round::HALF_UP) but they might have=
 reasons to keep the division and rounding separate.)

Thanks, when I expand on this issue, I'll also mention the pros and cons of b=
oth, including the points you mentioned.

Regards,

Saki=