Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121944
MIME-Version: 1.0
References: <18c42fdbb30.2831.17a3710df6d58f02ca570cc47e197a63@interi.co>
In-Reply-To: <18c42fdbb30.2831.17a3710df6d58f02ca570cc47e197a63@interi.co>
Date: Thu, 7 Dec 2023 06:27:37 -0800
Message-ID: <CAMrTa2EcwzB9J0NSLuP2DCamBSJW1iPikRAudQj6c+M1Xn7GMg@mail.gmail.com>
To: Alex Pravdin <alex.pravdin@interi.co>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000a6da92060bec4544"
Subject: Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type
From: jordan.ledoux@gmail.com (Jordan LeDoux)

--000000000000a6da92060bec4544
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Dec 6, 2023 at 10:36=E2=80=AFPM Alex Pravdin <alex.pravdin@interi.c=
o> wrote:

> Hello internals,
>
>
> This is the second round of the discussion regarding arbitrary precision
> scalar type integration into PHP. The previous part:
> https://marc.info/?l=3Dphp-internals&m=3D168250492216838&w=3D2 was initia=
ted by
> me before deep diving into the work with decimals in PHP. After 6 months
> of
> working, I would like to update my proposal taking into account my
> experience and the previous discussion.
> All builtin functions that currently accept float also accept decimal. So
> users don't need to care about separate function sets, and PHP developers
> don't need to maintain separate sets of functions. If such functions get
> the decimal parameter, they return decimal. If they have more than one
> float parameter and mixed float and decimal passed, decimals converted to
> float by default. If "default_decimal" or "as_decimal" used, float is
> converted to decimal with the warning.
>
>
You are going to run into some very difficult corners on this one. For the
last... 8 years i guess? I have been working on an arbitrary precision
library for PHP in userland. It utilizes BCMath, ext-decimal, and GMP,
depending on what is installed and what kind of operation you are
performing.

So, the functions that currently accept floats include functions such as
`sin()` or `atan()`. These functions are not at all trivial to do to
arbitrary precision. In fact, the VAST majority of the work I have done on
my library has been to handle cases like "What do I do if the user wants
2.921 ** 4.293810472934854?" or "How will I guarantee the precision that
the user requested for `tan()` in an efficient way?"

Now, libmpdec is going to actually have implementations for most of this
stuff that you can call directly, but if the PHP function `sin()` isn't
capable of *outputting* a `decimal`, then this isn't really that much of an
improvement over the current situation. I mean, it's still something I
would support, but that's the area where some help from the engine goes a
VERY long way.

You're probably also going to need a way for a user to grab certain
constants to a given precision. I would think e and pi at the least.

I have a lot of experience working on this problem space in PHP, and am
definitely willing to help. I looked into doing a libmpdec PHP integration
several years ago, but decided that voters were unlikely to give it a fair
shot, and so decided against it. If you're willing to try and roll the ball
up the hill though, I'll definitely help you.

Jordan

--000000000000a6da92060bec4544--