Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122856
Date: Tue, 2 Apr 2024 14:25:53 +0100 (BST)
To: Jordan LeDoux <jordan.ledoux@gmail.com>
cc: Aleksander Machniak <alec@alec.pl>, internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath
In-Reply-To: <CAMrTa2EK6ymBQuxeFj7tMV0M2crqCCCR=mLN-FSfuCgrQHEZ6A@mail.gmail.com>
Message-ID: <667254b6-d2f2-271c-2e37-d049957427d5@php.net>
References: <4F094EDA-5058-407D-AF39-06FD934FDE1F@sakiot.com> <bbcff629-4dd6-bc50-ac9f-641849dc218a@php.net> <68CF373E-6ABF-4471-8992-813B4BA1B508@sakiot.com> <904197f4-afb5-401e-9e17-7a655c5449d0@alec.pl>
 <CAMrTa2EK6ymBQuxeFj7tMV0M2crqCCCR=mLN-FSfuCgrQHEZ6A@mail.gmail.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-2142553491-1712064353=:14553"
From: derick@php.net (Derick Rethans)

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-2142553491-1712064353=:14553
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: QUOTED-PRINTABLE

On Fri, 29 Mar 2024, Jordan LeDoux wrote:

> On Wed, Mar 27, 2024 at 12:08=E2=80=AFAM Aleksander Machniak <alec@alec.p=
l> wrote:
>=20
> > On 27.03.2024 01:03, Saki Takamachi wrote:
> > >> $num =3D new BcNum('1.23', 2);
> > >> $result =3D $num + '1.23456';
> > >> $result->value; // '2.46456'
> > >> $result->scale; // ??
> > >
> > > In this case, `$result->scale` will be `'5'`. I added this to the=20
> > > RFC.
> >
> > I'm not sure I like this. Maybe we should be more strict here and=20
> > treat the $scale in constructor (and later withScale()) as the=20
> > actual scale for all operations.
> >
> >
> For addition, it absolutely should expand scale like this, unless the=20
> constructor also defines a default rounding type that is used in that=20
> situation. All numbers, while arbitrary, will be finite, so addition=20
> will always be exact and known based on inputs prior to calculation.
>=20
> Treating scale like this isn't more strict, it's confusing. For=20
> instance:
>=20
> ```
> $numA =3D new Number('1.23', 2);
> $numB =3D new Number('1.23456', 5);
>=20
> $expandedScale1 =3D $numA + $numB; // 2.46456
> $expandedScale2 =3D $numB + $numA; // 2.46456
>=20
> $strictScale1 =3D $numA + $numB; // 2.46 assuming truncation
> $strictScale2 =3D $numB + $numA; // 2.46456
> ```
>=20
> I ran into this same issue with operand ordering when I was writing my=20
> operator overload RFC.
>=20
> There are ways you could do the overload implementation that would get=20
> around this for object + object operations, but it's also=20
> mathematically unsound and probably unexpected for anyone who is going=20
> to the trouble of using an arbitrary precision library.
>=20
> Addition and subtraction should automatically use the largest scale=20
> from all operands. Division and multiplication should require a=20
> specified scale.

I agree. I think add/subtract also should always take the largest scale=20
here.

cheers,
Derick
--8323329-2142553491-1712064353=:14553--