Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123038
Precedence: bulk
MIME-Version: 1.0
References: <40553F28-2EC2-475A-BD8E-1D6517AA2A51@rwec.co.uk>
 <2B518F62-B774-45C9-82A2-EF6653AAE34E@sakiot.com> <A703D145-1A10-4C7E-9E0C-1F0BEF94CF99@rwec.co.uk>
 <F36A5C9B-7F3E-4EB7-A254-2ADB47AB6AE0@sakiot.com>
In-Reply-To: <F36A5C9B-7F3E-4EB7-A254-2ADB47AB6AE0@sakiot.com>
Date: Mon, 8 Apr 2024 14:17:55 +0300
Message-ID: <CAL0xaBEQdWX735rE-EoxEr=44VTX5ud=XOvxn_g1Y28V2fugFg@mail.gmail.com>
Subject: Re: [PHP-DEV] Native decimal scalar support and object types in
 BcMath - do we want both?
To: Saki Takamachi <saki@sakiot.com>
Cc: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>, php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000029003a061593f789"
From: arvids.godjuks@gmail.com (Arvids Godjuks)

--00000000000029003a061593f789
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello everyone, I've been following the discussion threads and forming my
own opinion to share since I have done a bunch of financial stuff
throughout my career: I did the integers only at the application level and
DECIMAL(20,8) in the database due to handling Bitcoin, Litecoin, etc.

My feeling on the discussion is that it got seriously sidetracked from the
core tenet of what is actually needed from the PHP engine/core to
discussing developing/upgrading a library that can handle money, scientific
calculations, yada yada yada. Basically, in my view, the discussion has
been catastrophically scope-creeped to a point where nobody could agree on
anything and discuss things that were irrelevant to the initial scope.

To me, the BCMath library stuff is just that - a BCMath library. It's a
tool that can handle any size number. It's a specialized tool. And,
frankly, for the vast majority of use cases, it's complete overkill.

If we are talking about implementing a Decimal type into the language as a
first-class citizen alongside int/float/etc, do we really need it to handle
numbers outside 64-bit space? Ints have a size limit (64 bits), floats also
have a defined range. Why not have decimal be represented as 2 64-bit ints
at the engine level, and similarly to floating-point numbers, you can have
a php.ini setting where you can define the precision you want? Floats have
a default of 14 positions. Why not have a setting that defines precision
for the decimal type, set it to the same 14 positions, and you can have a
decimal type that has 114 bits for the integer part and 14 bits for the
floating-point part? In the vast majority of cases, for all practical
intents and purposes, that would be enough. For the rest - you have
ext/decimal, BCMath, GMP extensions (and by all means, improve those as
much as needed, make them as powerful as Python's math libs). This approach
has some major benefits: if done right, it's just another type that is
compatible with float, but does integer precision math, and having the
precision of 14 in the vast majority of needs is basically overkill
already. Ideally, you should be able to just replace your float and ints
with decimal type hints and just do the roundings/formatting via the usual
means of round/ceil/floor/number_format. Normal math just works. If any
part of the expression has a decimal type, the result is a decimal number.
The only sticking point I see is how to define a decimal type variable
since we do not have var/let for/const; we can only define types on class
properties and their constants. Do we add a function decimal(int|float
$value): decimal? Or do we need to do prep work to be able to define
variables with type? Another idea I have is to just do $decimal =3D
(decimal)10.054 when instantiating a variable. Actually, that's not that
uncommon to do it like that already when you want to ensure the result is
of a certain type, PSL library does a lot of that and I do quite like it.

Long story short, give people a tool that's simple and works, things like
scale and all that stuff we can just handle in userland code ourselves
because everyone has different needs, different scales, and so on. It's the
same as right now with integers - if you require an integer bigger than 64
bits, you use GMP/BCMath/etc. You are also not going to have fun with
databases and PDO because there are going to be some shenanigans there too.
Basically, at that point, you are running against various other PHP engine
limitations and when software has to be written with those considerations
in mind anyway in literally any language to begin with. Some are easier
than others.

Sorry for it being a bit long, I'm happy to clarify/expand on any parts you
have questions about.
--=20

Arv=C4=ABds Godjuks
+371 26 851 664
arvids.godjuks@gmail.com
Telegram: @psihius https://t.me/psihius

--00000000000029003a061593f789
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hello everyone, I&#39;ve been following the discussio=
n threads and forming my own opinion to share since I have done a bunch of =
financial stuff throughout my career: I did the integers only at the applic=
ation level and DECIMAL(20,8) in the database due to handling Bitcoin, Lite=
coin, etc.<br><br>My feeling on the discussion is that it got seriously sid=
etracked from the core tenet of what is actually needed from the PHP engine=
/core to discussing developing/upgrading a library that can handle money, s=
cientific calculations, yada yada yada. Basically, in my view, the discussi=
on has been catastrophically scope-creeped to a point where nobody could ag=
ree on anything and discuss things that were irrelevant to the initial scop=
e.<br><br>To me, the BCMath library stuff is just that - a BCMath library. =
It&#39;s a tool that can handle any size number. It&#39;s a specialized too=
l. And, frankly, for the vast majority of use cases, it&#39;s complete over=
kill.<br><br>If we are talking about implementing a Decimal type into the l=
anguage as a first-class citizen alongside int/float/etc, do we really need=
 it to handle numbers outside 64-bit space? Ints have a size limit (64 bits=
), floats also have a defined range. Why not have decimal be represented as=
 2 64-bit ints at the engine level, and similarly to floating-point numbers=
, you can have a php.ini setting where you can define the precision you wan=
t? Floats have a default of 14 positions. Why not have a setting that defin=
es precision for the decimal type, set it to the same 14 positions, and you=
 can have a decimal type that has 114 bits for the integer part and 14 bits=
 for the floating-point part? In the vast majority of cases, for all practi=
cal intents and purposes, that would be enough. For the rest - you have ext=
/decimal, BCMath, GMP extensions (and by all means, improve those as much a=
s needed, make them as powerful as Python&#39;s math libs). This approach h=
as some major benefits: if done right, it&#39;s just another type that is c=
ompatible with float, but does integer precision math, and having the preci=
sion of 14 in the vast majority of needs is basically overkill already. Ide=
ally, you should be able to just replace your float and ints with decimal t=
ype hints and just do the roundings/formatting via the usual means of round=
/ceil/floor/number_format. Normal math just works. If any part of the expre=
ssion has a decimal type, the result is a decimal number. The only sticking=
 point I see is how to define a decimal type variable since we do not have =
var/let for/const; we can only define types on class properties and their c=
onstants. Do we add a function decimal(int|float $value): decimal? Or do we=
 need to do prep work to be able to define variables with type? Another ide=
a I have is to just do $decimal =3D (decimal)10.054 when instantiating a va=
riable. Actually, that&#39;s not that uncommon to do it like that already w=
hen you want to ensure the result is of a certain type, PSL library does a =
lot of that and I do quite like it.<br><br>Long story short, give people a =
tool that&#39;s simple and works, things like scale and all that stuff we c=
an just handle in userland code ourselves because everyone has different ne=
eds, different scales, and so on. It&#39;s the same as right now with integ=
ers - if you require an integer bigger than 64 bits, you use GMP/BCMath/etc=
. You are also not going to have fun with databases and PDO because there a=
re going to be some shenanigans there too. Basically, at that point, you ar=
e running against various other PHP engine limitations and when software ha=
s to be written with those considerations in mind anyway in literally any l=
anguage to begin with. Some are easier than others.<br></div><div><br></div=
><div>Sorry for it being a bit long, I&#39;m happy to clarify/expand on any=
 parts you have questions about.</div><span class=3D"gmail_signature_prefix=
">-- </span><br><div dir=3D"ltr" class=3D"gmail_signature"><div dir=3D"ltr"=
><div><br></div>Arv=C4=ABds Godjuks<div>+371 26 851 664</div><div><a href=
=3D"mailto:arvids.godjuks@gmail.com" target=3D"_blank">arvids.godjuks@gmail=
.com</a></div><div>Telegram: @psihius=C2=A0<a href=3D"https://t.me/psihius"=
 target=3D"_blank">https://t.me/psihius</a></div></div></div></div>

--00000000000029003a061593f789--