On Tue, Dec 12, 2023 at 4:29 PM Jordan LeDoux <jordan.led...@gmail.com> wrote:
> > > On Tue, Dec 12, 2023 at 3:05 PM Erick de Azevedo Lima < > ericklima.c...@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 > 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
