Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123037
Precedence: bulk
MIME-Version: 1.0
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>
In-Reply-To: <f4002280-bec7-459b-b65b-b261e4f52aad@rwec.co.uk>
Date: Mon, 8 Apr 2024 19:23:24 +0900
Message-ID: <CAOyH9ySpHepZKvAVMrt+vBP_hyo6HrQVq6tsdDMyUJCheVwq=Q@mail.gmail.com>
Subject: Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type
To: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>
Cc: internals@lists.php.net
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: alex.pravdin@interi.co (Alexander Pravdin)

On Tue, Mar 19, 2024 at 5:35=E2=80=AFAM Rowan Tommins [IMSoP]
<imsop.php@rwec.co.uk> wrote:

> I think a reasonable number of people do share the sentiment that having =
two separate modes was a mistake; and neither mode is actually perfect. It'=
s not about "making it on by default", it's about coming up with a unified =
behaviour that makes the setting redundant.

This is off-topic, but just to conclude: as a user, I personally would
love to see strict_types to be always enabled eventually.


> I don't think choice is really what you want: if you were designing a lan=
guage from scratch, I doubt you would say "let's give the user a choice of =
what type 1 / 10 returns". What it's actually about is *backwards compatibi=
lity*: what will happen to code that expects 1/10 to give a float, if it su=
ddenly starts giving a decimal.

> In short, the best way of avoiding declare() directives is not to replace=
 them with something else, but to choose a design where nobody feels the ne=
ed for them.

I understand your point and it is completely valid. But I'm speaking
from a different angle. There are obviously two opposite areas of
calculations, two "modes": "I don't care much about the performance,
give me precise results" and "I don't care about rounding errors, give
me the fastest results". I can't imagine a way of joining them and
unifying the work with them until a completely new CPU architecture is
invented. It makes me think "how can we make both types of users
happy"? I would like to see native and intuitive support for both of
the "modes". So "declare(default_decimal)" seems to be a good option.
Users already know what is "declare" so it will be not a problem to
start using another option. Again, I'm not trying to replace float
calculations with decimals due to performance and backward
compatibility. My goal is to invent a way to make two "modes"
convenient without bandaids.


> For most cases, I think the rule can be as simple as "decimal in means de=
cimal out". What's maybe not as obvious at first sight is that that can app=
ly to operators as functions, and already does: 100 / 10 gives int(10), but=
 100.0 / 10  gives float(10.0), as do 100 / 10.0  and 100.0 / 10.0

I agree that if one of the operands is decimal then the result should
be decimal. The "declare(default_decimal)" is suggested specifically
for the cases when it is unclear what result we should return and to
not introduce monstrous syntax with a lot of typecast or special
syntax.


> By the same logic, decimal(1) / 10 can produce decimal(0.1) instead of fl=
oat(0.1), and we don't need any fancy directives. Even better if we can int=
roduce a shorter syntax for decimal literals, so that it becomes 1_d / 10

With "declare(default_decimal)" there's no need to introduce new
syntax for numbers. I personally would prefer to work with "normal"
number literals and let PHP decide (under my guidance) how to
represent them internally - as floats or as decimals.


> Where things get more complicated is with *fixed-precision* decimals, whi=
ch is what is generally wanted for something like money. What is the correc=
t 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(10) / 3?

As a user, I see it as we store a decimal number internally with the
maximum number of fractional digits and let the user choose how to
represent it only when converting it from decimal to something else.
Only at this moment, some rounding will happen and we may give users
the proper tools for this. When it comes to 1/3, we may hardcode some
specific rounding mode when it exceeds the internal limit of
fractional digits. In my view, this limit will be more than enough for
99.9% of so they will be able to apply their own rounding mode to 0 or
2 or 10 fractional digits with no issues.


> If you stick to functions / methods, this is slightly less of an issue, b=
ecause 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 pa=
ckage.

Yes, but the whole point of my suggestion is to go away from the
object syntax :) My goal is not to make the future implementation
simpler but to lift the PHP language to the next level even if will
cost much more effort in total.

And just to clarify. I'm not a big expert in decimal calculations, my
proposal is still not so specific and I may have a lack of knowledge
in some terms or details and may need help from more experienced
people. I'm discussing possible ways of the implementation and I would
like to help the community to develop some design that will make
future development aligned with some principles and eventually achieve
the final goal. I understand the complexity of the proposal so I'm not
standing on the implementation as a whole by some PHP version. But I
would be more than happy to know that the language is evolving in the
defined direction.

--
Best, Alexander