Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122010
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>
 <CAPzBOBMw-mjjuKEX1udq2XaKGcRneT_DWinqP9aAtU0oGfLhzw@mail.gmail.com>
 <CAFPFaMJY=Q+vaFbhA1Xe-9xun_LPkdhL-oX2opGyV7uA_8v4Pg@mail.gmail.com>
 <CAPzBOBMVViMjZk2d0J77Ck7qktCbMnN1BpDogx=u40=gbYR7ZA@mail.gmail.com>
 <CAMrTa2FzhFKYM+ZOkbNXTN2_uhEvmOdvCepF8_nG0_cLAHscOQ@mail.gmail.com> <CAL0xaBFaAzpQcjA4V55CuPfi7yTMEpAJNW-s2Z+BOHsZQHPtBw@mail.gmail.com>
In-Reply-To: <CAL0xaBFaAzpQcjA4V55CuPfi7yTMEpAJNW-s2Z+BOHsZQHPtBw@mail.gmail.com>
Date: Fri, 15 Dec 2023 21:59:09 -0800
Message-ID: <CAMrTa2GChhhEdYCMq+aq37qRa2NaLkkfH652NTuz01dEoZ4_kw@mail.gmail.com>
To: Arvids Godjuks <arvids.godjuks@gmail.com>
Cc: Robert Landers <landers.robert@gmail.com>, "G. P. B." <george.banyard@gmail.com>, 
	Alexander Pravdin <alex.pravdin@interi.co>, internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000efee48060c9a375c"
Subject: Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type
From: jordan.ledoux@gmail.com (Jordan LeDoux)

--000000000000efee48060c9a375c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Dec 15, 2023 at 12:59=E2=80=AFPM Arvids Godjuks <arvids.godjuks@gma=
il.com>
wrote:

>
>
> On Fri, 15 Dec 2023 at 22:32, Jordan LeDoux <jordan.ledoux@gmail.com>
> wrote:
>
>> On Fri, Dec 15, 2023 at 12:14=E2=80=AFAM Robert Landers <landers.robert@=
gmail.com
>> >
>> wrote:
>>
>> >
>> > nobody will likely ever try this again, at least in the foreseeable
>> > future. With comments like that, there is simply no way forward.
>> > There's no convincing (at least via email) and by that point, it's too
>> > late anyway, they already voted but didn't even show up for the
>> > discussion that happened for weeks. Literally wasting everyone's time.
>> > The only way we'd ever get something like this passed is if someone
>> > proposes an RFC that prevents people from voting based on
>> > political/personal reasons and restricts voting "no" to technical
>> > reasons only; or some voters reopen one of the original RFC's for a
>> > revote and leave it in the "Pending Implementation" section as needing
>> > an implementation.
>> >
>> > The fact that people can and do vote "no" for no other reason than
>> > they "don't like it" or they "don't want to use it" leaves a bad taste
>> > in my mouth.
>> >
>>
>> Okay, so I'm probably the most affected by this, considering we're
>> discussing my proposal which was declined and I spent over 400 hours of
>> work on it prior to the vote. So please understand where I'm coming from
>> when I say this: I firmly believe that people should be allowed to vote =
no
>> on an RFC simply because they feel that it "doesn't belong in PHP". That
>> is
>> a voter taking a position on what the language is for, how it should be
>> designed from a more broad perspective, and I think it's important to ha=
ve
>> that in order to maintain a productive language that does its job well.
>>
>> The main issue I have discovered through this experience is that some
>> people have difficulty or lack the experience necessary to separate an
>> opinion about the language design philosophy from what would be personal=
ly
>> useful to *them*. That is a problem, but it's a problem that is just par=
t
>> of working collaboratively with humans. It's not unique to this group, t=
o
>> PHP, or to this situation.
>>
>> The reason, for everyone else reading, that this is relevant to the
>> current
>> discussion about a scalar decimal type is that this is likely to face so=
me
>> similar pushback. This email will go out to hundreds of people, but only=
 a
>> few are going to reply, and most of the people currently participating i=
n
>> this discussion do not have voting rights, so this RFC if it's worked on
>> will have to be developed without the feedback of the people who actuall=
y
>> decide whether it goes into the language.
>>
>> A scalar decimal type will be extremely useful for certain types of
>> applications, foundationally critical to other types of applications, an=
d
>> completely unused for others. A big part of writing this RFC would be
>> explaining to the people who do not work on any applications that benefi=
t
>> why it would be good to include it in the language anyway.
>>
>> A scalar decimal type would create a hard dependency on libmpdec, which =
I
>> also expect to be something that needs to be addressed. MPDec is license=
d
>> under the Simplified BSD License. I *think* it could be bundled if neede=
d,
>> but it couldn't be relicensed with the PHP License itself.
>>
>> Jordan
>>
>
> Jordan has highlighted good points that probably should be addressed and
> in general, I think, this project will take a while, so I would settle in
> for the long haul here and think things through and reach out to people w=
ho
> actively work and maintain the PHP core. There have been recent instances
> of people fitting in and passing things and then regretting the way it wa=
s
> done (*cought* readonly rfc *cought* ).
>
> As for the idea itself - I fully support it. A decimal type would be
> invaluable in quite a lot of places and a lot of PHP apps are handling
> money and other precise numbers that really would benefit from a proper
> decimal type (right now in most cases people just do it with integers or
> use libraries like brick/money, but that's only a subset covered).
> This is really adding a new type into the engine, so this is going to be =
a
> big undertaking and this probably will require the work to go into PHP 9
> because extensions probably are going to be affected and will need to be
> upgraded to handle the new type. Especially PDO and database drivers. Thi=
s
> is far from a small project.
>
>
Here's the research that I did into this subject when I was considering
making my own decimal scalar proposal about a year ago.

MPDec: This is used by ext-decimal. It's licensed with the Simplified BSD
License. It has functions for basic arithmetic (add, subtract, multiply,
divide), as well as logarithmic functions (ln, log10, exp, power, square
root). It does not have functions for trigonometric operations, and has
some limitations for where arbitrary precision numbers can be used (for
instance with pow).

GMP: This is the underlying library of several other math libraries in C.
It is dual licensed with the LGPL 3 and GPL 2 licenses. It has functions
for basic arithmetic.

MPFR: This is an extension of the GMP library that supports a much wider
variety of math. It is licensed with the LGPL. It supports arithmetic,
logarithmic, trigonometric, inverse trigonometric, hyperbolic, and number
theory operations (such as the gamma function which extends the factorial
operation beyond integers).

FLINT: This is a library built on top of MPFR (or rather, it depends on
MPFR). It is licensed with the LGPL 2. It supports everything that MPFR
does, with additional support for complex numbers, expressions (such as
polynomials and exponentials), derivatives and integrals, additional number
theory operations (such as generating Bernoulli numbers), and other
features.

I *think* all of these could be bundled.

MPDec will not supply all of the features that have been discussed in this
mailing list thread. The minimal library that does is probably MPFR.

A zval has to fit in 64 bits, which none of these will do, so our scalar
decimal type would probably have to be refcounted the same way that objects
are. To have it behave like other scalars would probably involve some very
tricky work implementing efficient copying into scopes. Otherwise, decimal
scalars would pass-by-pointer in the same way objects do where they ignore
function scope isolation to avoid copying large amounts of memory for
temporary scope changes. Having it behave like an int or float zval would
require either a big change to how zvals work, or something rather creative
with pointers and scope based copy-on-write with garbage collection to
clean things up.

While the arbitrary precision types would not fit in a zval, they would be
much smaller than objects are in PHP (generally), so something creative
might be worth at least exploring. I think the kind of radical change that
would be necessary for them to fit entirely in a zval instead of just
fitting the pointer in a zval are likely to be a non-starter. I would
imagine it would reduce the performance of other zval optimizations.
However, the specifics of zval implementation is something that I am not at
all an expert in, so take my research on that front with a grain of salt.

Jordan

--000000000000efee48060c9a375c--