Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121998
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> <CAMrTa2EWgq9eS_Rc9dGEEDxvnHuZjaEMhtsg8KV=DeDv4VhwLg@mail.gmail.com>
In-Reply-To: <CAMrTa2EWgq9eS_Rc9dGEEDxvnHuZjaEMhtsg8KV=DeDv4VhwLg@mail.gmail.com>
Date: Tue, 12 Dec 2023 16:33:06 -0800
Message-ID: <CAMrTa2F-7kB9mp5_jDNLMo5mXrDqrEKqtrrD3xeLoDADX1-U1g@mail.gmail.com>
To: Erick de Azevedo Lima <ericklima.comp@gmail.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000039eb7f060c59508f"
Subject: Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type
From: jordan.ledoux@gmail.com (Jordan LeDoux)

--00000000000039eb7f060c59508f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Dec 12, 2023 at 4:29=E2=80=AFPM Jordan LeDoux <jordan.ledoux@gmail.=
com>
wrote:

>
>
> 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 arbitrar=
y
> precision math libraries that are more limited in scope.
>
> Other similar math libraries:
>
> markrogoyski/math-php: The closest in terms of features compared to Ferma=
t
> brick/math: The most widely installed PHP math library on Packagist (due
> to being a dependency of several other widely used packages). Has extreme=
ly
> limited features for complex arbitrary precision functions.
>
> MPDecimal (the underlying C library that we have discussed using here) ha=
s
> 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 agre=
e
> on that. No matter how good the implementation, floats are always going t=
o
> 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 int=
o
> 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 you=
r
> 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 PH=
P
> *also* lacks support for since the one extension that used to provide
> statistics functions is no longer maintained and hasn't been updated sinc=
e
> 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 n=
ew
> userland code that is very messy and very slow right now.
>
> Jordan
>

Apologies, I just realized that you were asking about the libraries that
implemented rationals with complex operations. I don't have THOSE libraries
handy unfortunately. Even my library converts to decimal first.

Jordan

--00000000000039eb7f060c59508f--