Hi, Claude, Jorg > If the existence of the function is checked in advance, the BC risk is worst, > because they cannot have known whether the signature and semantics of the > function you will introduce will be compatible with the one they have > defined. In case of mismatch the eventual breakage could be more difficult to > notice and trace back. > >Note in particular this SO question: >https://stackoverflow.com/questions/231057/how-to-round-ceil-floor-a-bcmath-number-in-php, > where the second answer has a different rounding mode on halves than the >first and third answers.
I see now, I may have missed this point. If I implement these functions in BCMath, it seems that you need to think about the problem you mention a little more carefully. > And I understood that the BCMath extension should be abandoned eventually > when the GMP library is properly extended. There is no need for 2 arbitrary > precision extensions complementary to each other but for the rich one having > all of the functionalities. > >I don't want to discourage you, because there is clearly a need for such >functions. Speaking from my perspective I would rather invest time into the >GMP extension than extend the BCMath extension. I thought GMP was a function for integers, so I wasn't expecting that tbh. However, even if GMP supported floating point numbers, wouldn't it end up having the inherent error problem of floating point numbers? Regards. Saki -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
