Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122676
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>
In-Reply-To: <CAFPFaMKoH1PD_qaBPLw9pwid0NB5zyZYM7AgogYOWFhPVysEwQ@mail.gmail.com>
Date: Mon, 18 Mar 2024 13:39:34 +0900
Message-ID: <CAOyH9ySfZnVgpZkDbL+sP_DCmnyBaq4D=K9kHjsXXLhX-dOkcA@mail.gmail.com>
Subject: Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type
To: "G. P. B." <george.banyard@gmail.com>
Cc: internals@lists.php.net
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: alex.pravdin@interi.co (Alexander Pravdin)

Sorry for the so late reply, but I would like to continue the
discussion on this topic.


On Tue, Dec 12, 2023 at 10:04=E2=80=AFPM G. P. B. <george.banyard@gmail.com=
> wrote:

>> I didn't know that the strict types directive was a mistake. My intentio=
n is to be able to write clean all-decimal units of code and not break the =
backward compatibility. The old code should work as it was before. At the s=
ame time, there are use cases when the whole class/project should be writte=
n with decimals only. As a user, I want to do that without complex language=
 structures and excessive typehints or explicit conversions. The all-decima=
l code  should be as clean as it is now with floats. This is why I proposed=
 this directive. Can you suggest something better to achieve the same?
>
>
> The issue is that I don't think having arbitrary precision decimals as a =
core language feature is a necessity compared to rational types.
> A cast from rational to float wouldn't produce a large round trip, wherea=
s trying to figure out arbitrary precision is more difficult.
> But in any case, having a declare/INI or whatever that changes the behavi=
our of the engine/language is not a good design choice.

How can we introduce the ability to write user code in default
decimals and at the same time keep the old way of working as it was
before, to not introduce any troubles into the existing code and not
introduce performance issues? As a user, I would like to have a
choice. When I need speed and I don't care about rounding errors, I
will use default floats. When I need precise calculations and can
sacrifice some performance, I will use default decimals. And I would
like to be able to switch between these modes selectively, not
app-wide. Just give me a choice and inform me in the documentation
about the differences and pros/cons of both types.


I'm not in the context of the core team plans regarding "strict
types". Could you share some details here? What is the current plan
regarding it? To make strict types on by default eventually? Or
something else?



>> If you can suggest a better way of working with fractional numbers - ple=
ase do :) But IMO limiting the language by 64 bits is not a good way. It is=
 more easy to go over the limit than you may think :) Especially in some in=
termediary values while performing complex calculations. I could be wrong, =
but fractional numbers limited to 64 bits sound like a bandaid. The languag=
e will tell users "hey, you can do something general, but if you want somet=
hing else please don't use me at all or involve bandaids with extensions". =
My key point is not only to allow working with decimals, but also to make a=
ll the alternatives useless, cover their functionality by builtin tools, to=
 free users from thinking about workarounds and bandaids. From my POV, intr=
oducing a new decimal type that does not cover the GMP/bcmath/ext-decimal f=
unctionality is pointless and a waste of time.
>
>
> Again, the use cases for arbitrary precision numbers seems rather limited=
, and having this as an extension does not seem problematic at all.
> My current issue is that there is no way to represent "small" numbers suc=
h as 0.1 or 5.8 exactly.
> Arbitrary precision is a totally different ballpark, be that for integers=
 and/or fractional values and makes everything slow, just look at Python wh=
o is *finally* investing time and money to make the most common numbers (th=
ose that fit in a machine word) not be abysmally slow.

Honestly speaking, my current pain point is that I need to work with
precise money calculations in business automation and accounting
fields. I would like to see a good tool in the PHP language to do
that. As an engineer, I understand that it should be fast enough. I
suggested mpdecimal as a good enough option. If you could suggest
something else that would fit the majority of user needs, I'm totally
for it.



>> How quickly you would be able to read something like this: gmp_add(gmp_m=
ul(gmp_div(gmp_sub($value, $add), $value2, $factor, gmp_sin($value3), gmp_i=
ntval($value))) ?
>>
>> This absence of intuitive readability makes the development and support =
difficult and it's better to choose another language. This is what I want t=
o change and make PHP powerful enough for this kind of applications.
>
> GMP supports operator overloading, so you do not need to write this, and =
as far as I see, ext/decimal *also* supports operator overloading so you ca=
n just write it using the normal arithmetic operations.
> Moreover, it supports type casts so you can just do (int) $GMP instead of=
 gmp_intval($GMP);
> And it also supports using the comparisons operatos on it instead of usin=
g gmp_cmp()
>
> The only thing that is, currently, not possible to do is a cast _to_ GMP =
using (GMP), but maybe that's something that could be added to the engine f=
or internal objects, but I'm not sure about this.

If GMP can be converted to a scalar builtin language type, that also
will be totally fine from my point of view.



> It seems, your main motivation to have this as a language feature is to h=
ave access to operator overloading and casting behaviour, that internal obj=
ects already support.

My points are the following:
- Work with scalar numeric types when I work with numbers, not with
objects or strings mimicking numbers. I want (bool)Decimal(0) to be
equal to false, not to true because non-null objects are always true.
- Have it as a built-in language feature allowing anyone to use it
without requiring extension installation.
- Keep backward compatibility for the code that already works with
floats while introducing an option to use only the new type when
performing math operations on numbers. And being able to have two
versions of the code working in the same app.
- IDEs and static analyzers sometimes go crazy when I do math
operations or comparisons on objects.



> Which diminish the cost/benefit of making the engine changes, especially =
if the default behaviour doesn't change and one needs to maintain effective=
ly two different versions of PHP depending on if it is in "decimal" or "flo=
ating" mode, which raises a plethora of questions just in its own.

As a developer, I don't see an issue with having two fractional
numeric types in the language. My old code with floats is working as
usual and doesn't break. If I want to introduce precise calculations
for money/accounting/whatever using decimals, I change my code and I'm
fully responsible for its maintenance. PHP has warnings to inform
developers if they do something wrong and this is what can be used to
prevent errors in the code. The only problem here that I foresee is
the division on two ints (and some other operations I think) should
return some specific type (float or decimal) and the language needs a
mechanism to determine the intention and return the proper result
type. This is why I suggested using "declare". In other cases, if at
least one of the operands is decimal we can always return decimals.