Re: Proposal: Arbitrary precision native scalar type
| From: | Jordan LeDoux | Date: | Thu, 07 Dec 2023 14:27:37 +0000 |
| Subject: | Re: Proposal: Arbitrary precision native scalar type | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-121944@lists.php.net to get a copy of this message | ||
On Wed, Dec 6, 2023 at 10:36 PM Alex Pravdin <alex.pravdin@interi.co> 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=php-internals&m=168250492216838&w=2 was
> initiated 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