Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123054
Date: Tue, 9 Apr 2024 11:59:03 +0100 (BST)
To: Jordan LeDoux <jordan.ledoux@gmail.com>
cc: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>, internals@lists.php.net
Subject: Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type
In-Reply-To: <CAMrTa2Gm4B++JvdddkHQkDDqWxmxLY6pCE7C5QeSPsV-08YRgw@mail.gmail.com>
Message-ID: <c0cc2909-4217-716d-8f10-30cfb4e26e52@php.net>
References: <18c42fdbb30.2831.17a3710df6d58f02ca570cc47e197a63@interi.co> <CAFPFaMLZ3MeGXt5OPmAkwM-n-eZcp1gT7RQCnpXSyHxZThOn2g@mail.gmail.com> <CAOyH9yReYorVd1jDPyk_O73JUn1VvqEAz0Fb7mvQ6ke9k9FcZA@mail.gmail.com> <CAFPFaMKoH1PD_qaBPLw9pwid0NB5zyZYM7AgogYOWFhPVysEwQ@mail.gmail.com>
 <CAOyH9ySfZnVgpZkDbL+sP_DCmnyBaq4D=K9kHjsXXLhX-dOkcA@mail.gmail.com> <f4002280-bec7-459b-b65b-b261e4f52aad@rwec.co.uk> <CAMrTa2Gm4B++JvdddkHQkDDqWxmxLY6pCE7C5QeSPsV-08YRgw@mail.gmail.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-861573137-1712660343=:26150"
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-861573137-1712660343=:26150
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: QUOTED-PRINTABLE

On Wed, 3 Apr 2024, Jordan LeDoux wrote:

> On Mon, Mar 18, 2024 at 1:35=E2=80=AFPM Rowan Tommins [IMSoP] <imsop.php@=
rwec.co.uk>
> wrote:
>=20
> >
> > Where things get more complicated is with *fixed-precision* decimals,
> > which is what is generally wanted for something like money. What is the
> > correct result of decimal(1.03, precision: 2) / 2 - decimal(0.515, 3)?
> > decimal(0.51, 2)? decimal (0.52, 2)? an error? And what about decimal(1=
0) /
> > 3?
> >
> > If you stick to functions / methods, this is slightly less of an issue,
> > because you can have decimal(1.03, 2)->dividedBy(2, RoundingMode::DOWN)=
 =3D=3D
> > decimal(0.51, 2); or decimal(1.03, 2)->split(2) =3D=3D [ decimal(0.52, =
2),
> > decimal(0.51, 2) ] Example names taken directly from the brick/money
> > package.
> >
> > At that point, backwards compatibility is less of an issue as well: mak=
e
> > the new functions convenient to use, but distinct from the existing one=
s
> >
> I came back to this discussion after my last reply on the BCMath as an
> object thread, because we went through a very similar discussion there wi=
th
> regard to operators.
>=20
> I think that, roughly, the fixed precision should be defined on the scala=
r
> itself:
>=20
> 1.234_d3
>=20
> 1.234 is the value, _d makes it a decimal type, and 3 shows that this val=
ue
> has a precision of 3. (Actually, it has a SCALE of 3, since precision is
> significant digits, and also includes the integer portion). But when it
> comes to fixed-precision values, it should follow rules very similar to
> those we discussed in the BCMath thread:

Woound't it be much better to capture this complex information in an=20
Object, and then allow operators on this? Like... Saki was pretty much=20
suggesting with her BCMatch/Number class RFC?

I can't imagine people looking at code understanding a syntax like this=20
right away, let alone of what it all means.

cheers,
Derick

--=20
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/suppo=
rt

mastodon: @derickr@phpc.social @xdebug@phpc.social
--8323329-861573137-1712660343=:26150--