Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121997
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>
 <f2d7cbc4-46eb-4a16-8f5b-c79b34aa64a0@app.fastmail.com> <CAMrTa2Es3x=cySpGivGKHqLK_fL8_W9rahJbmbeMtY3_HxVoow@mail.gmail.com>
 <CAGS0MVDUNOxXsPSfXpLcEPbwG5Fejxc-SdAL0cOPdAe2FkEvTw@mail.gmail.com> <CAGS0MVDzJ681nZ0isftGmeYrPOZeuhvRV-WiYH3YWCG=p=aLtA@mail.gmail.com>
In-Reply-To: <CAGS0MVDzJ681nZ0isftGmeYrPOZeuhvRV-WiYH3YWCG=p=aLtA@mail.gmail.com>
Date: Tue, 12 Dec 2023 16:29:22 -0800
Message-ID: <CAMrTa2EWgq9eS_Rc9dGEEDxvnHuZjaEMhtsg8KV=DeDv4VhwLg@mail.gmail.com>
To: Erick de Azevedo Lima <ericklima.comp@gmail.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000ef17cd060c594295"
Subject: Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type
From: jordan.ledoux@gmail.com (Jordan LeDoux)

--000000000000ef17cd060c594295
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Dec 12, 2023 at 3:05=E2=80=AFPM Erick de Azevedo Lima <
ericklima.comp@gmail.com> wrote:

> Oh, I just realized that I used the wrong word, so let me rephrase that:
>
> What's the name of the library you're talking about? Maybe the *pros* of =
a
> core implementation can be highlighted if we can see the limitations of a
> user-land approach.
>
> Best,
> Erick
>
>
My library is Fermat: https://github.com/JordanRL/Fermat

Mine is the ONLY one that I'm aware of that even attempts to support
complex mathematical operations in PHP. However, there are other arbitrary
precision math libraries that are more limited in scope.

Other similar math libraries:

markrogoyski/math-php: The closest in terms of features compared to Fermat
brick/math: The most widely installed PHP math library on Packagist (due to
being a dependency of several other widely used packages). Has extremely
limited features for complex arbitrary precision functions.

MPDecimal (the underlying C library that we have discussed using here) has
extensions and functions for things like sine and cosine. Even just
exposing those would make writing algorithms for things like 3i^(2+5i)
much, much faster.

The problem is that there's no point in using arbitrary precision numbers
unless you're using the spaces after the decimal. I think we can all agree
on that. No matter how good the implementation, floats are always going to
be faster if you're unconcerned about rounding errors and such.

So if you're writing an arbitrary precision library and you want to support
the next obvious operation beyond add, subtract, multiply, and divide, you
probably naturally choose exponents. Except, calculating A^B where both A
and B have *arbitrary precision* and where the result will also have
*arbitrary precision* means that you cannot rely on things like the `pow()`
function. So you have to implement your own. Except implementing decimal
exponents means you *really* need to implement `exp()` first, since all of
the efficient algorithms rely on transforming A^B into C*e^D. Except the
most efficient ways of doing *that* really work best if you have access to
trig functions. And *ALL* your calculations in the middle can't be losing
precision, otherwise there's no point in doing your own implementation, so
that means all of these functions need to have implementations as well.

This rabbit hole is *so* insidious that the BCMath library simple says
"fuck it" and limits you to only using integers for your exponents. That's
basically pointless though if the reason you need arbitrary precision
numbers is something like a statistics application for instance, which PHP
*also* lacks support for since the one extension that used to provide
statistics functions is no longer maintained and hasn't been updated since
I think 7.4.

If we get scalar decimals that only support add, subtract, multiply, and
divide, that's a huge improvement. But if we can take this opportunity to
tackle *at least* the trig functions as well, that will enable a LOT of new
userland code that is very messy and very slow right now.

Jordan

--000000000000ef17cd060c594295--