Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123089
Feedback-ID: id5114917:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-379-gabd37849b7-fm-20240408.001-gabd37849
Precedence: bulk
MIME-Version: 1.0
Message-ID: <15702F55-16D1-43AD-88CC-BC703E267FFC@rwec.co.uk>
In-Reply-To: <04F88690-82B6-4441-B155-C489EACD6DC5@sakiot.com>
References: <B154D767-31E9-460A-9F93-187F7FF11836@rwec.co.uk>
 <04F88690-82B6-4441-B155-C489EACD6DC5@sakiot.com>
Date: Wed, 10 Apr 2024 14:07:42 +0100
To: internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath
Content-Type: text/plain
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

On 10 April 2024 10:38:44 BST, Saki Takamachi <saki@sakiot.com> wrote:

>I was thinking about this today, and I think both are correct opinions on whether 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 within a class, and they can never be met simultaneously.

Yes, I agree there's a dilemma there.

The extra point in favour of TOWARD_ZERO is that it's more efficient, because we don't have to over-calculate and round, just pass scale directly to the implementation. Any other option makes for unnecessary extra calculation in code like this:

$total = new Number('20');
$raw_frac = $total / 7;
$rounded_frac = $raw_frac->round(2, Round::HALF_UP);

If HALF_UP rounding is the implied default, we have to calculate with scale 11 giving 1.42857142857, round to 1.4285714286, then round again to 1.43.

If truncation / TOWARD_ZERO is the implied default, we only calculate with scale 10 giving 1.4285714285 and then round once to 1.43.

(Of course, in this example, the most efficient would be for the user to write $rounded_frac = $total->div(7, 2, Round::HALF_UP) but they might have reasons to keep the division and rounding separate.)

Regards,
-- 
Rowan Tommins
[IMSoP]