Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123834
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
Mime-Version: 1.0 (1.0)
Subject: Re: [PHP-DEV] Add bcdivmod() to BCMath
Date: Wed, 26 Jun 2024 03:06:29 +0900
Message-ID: <98CEBD66-4E2C-4CB8-8792-A4AEF9982E41@sakiot.com>
References: <190506515d4.f695d014203438.1450648485347018411@barneylaurance.uk>
Cc: php internals <internals@lists.php.net>
In-Reply-To: <190506515d4.f695d014203438.1450648485347018411@barneylaurance.uk>
To: Barney Laurance <barney@barneylaurance.uk>
From: saki@sakiot.com (Saki Takamachi)

Hi Barney,

> If anything I was thinking of recording the remainder in the the original n=
umber object, not the one returned (or possibly in something like a WeakMap k=
eyed to it). So it does increase state and makes it technically no longer im=
mutable, but that change in state would not be detectable from outside excep=
t by profiling performance. It's state that would have to be ignored in the e=
quality check.

I see, I understand.

But I don't think that's wise. For example, if we reversed the order of the d=
iv and mod, there would be no cache and we wouldn't get the speed boost. (Or=
 does it cache the quotient as well?)

Also, even if the order is as expected, if another division is performed in b=
etween, the cache will be overwritten and it will become meaningless.

The main concern is the cost of having to mod data during division for the s=
urplus that we may never use.

There is the issue of data capacity, but the extra processing such as memory=
 allocation will inevitably occur, so for those who don't need mod, the chan=
ge will make slow down.

Regards,

Saki=