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
