Hi, internals
I would like to start the discussion for my RFC "Adding bcround, bcfloor and bcceil to BCMath”.
https://wiki.php.net/rfc/adding_bcround_bcfloor_bcceil_to_bcmath
Regards.
Saki
Le 1 oct. 2023 à 14:35, Saki Takamachi saki@sakiot.com a écrit :
Hi, internals
I would like to start the discussion for my RFC "Adding bcround, bcfloor and bcceil to BCMath”.
https://wiki.php.net/rfc/adding_bcround_bcfloor_bcceil_to_bcmathRegards.
Saki
To unsubscribe, visit: https://www.php.net/unsub.php
Hi,
Some remarks about the paragraph “Backward Incompatible Changes”
These are new features and do not break existing functionality.
If I had to point out my concerns, I would say that code that satisfies the following conditions will cause an error to occur.
- A situation where the user has defined a function with the same name, such as bcround()
This is a real concern. I have personally defined a bcround() global function because I needed such a functionality. A quick search on GitHub shows that I am not alone: https://github.com/search?q=bcround+language%3Aphp&type=code
- And, the existence of the function is not checked in advance.
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.
Fortunately, the few examples I have seen don’t foolishly guard the definition with if (!function_exists(...)), so that there will be a hard break when upgrading PHP (static error: function already defined), and they’ll have to decide explicitly what to do.
In my case, I’ll wait until this RFC is accepted, then (and only then) I’ll decide what to do depending on whether my version of bcround() is compatible with yours (either rename or function_exists() guard).
However, I do not think it is necessary to consider these matters.
I think that it is necessary to acknowledge that there will be breakage for some people, and to decide explicitly whether this breakage is acceptable. (I think it is.)
—Claude
Hello,
Recently I was trying to fix and clean some of the stuff within the BCmath
extension along with Girgias who helped me. I wanted to enrich this
extension with similar functions that GMP contains and improve the
performance, however, I went to some conclusions and stopped it.
- BCMath extension isn't fast enough compared to other existing arbitrary
precision PHP extensions. Comparison:
https://php-decimal.github.io/#performance - BCMath doesn't have OO API and thus it may break the backward
compatibility as Claude noticed. - GMP GNU library provides support for float numbers, however, its
functionality is not exposed in the PHP extension. And BCMath doesn't
provide as many functions as GMP.
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.
If anyone also thought about this direction I could help and join forces to
have one proper math library in PHP.
Kind regards,
Jorg
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
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?
yes, they do, as do almost all floating points implementation.
Memory limited float values and their respective operations are still
useful in many areas, but financial values and the likes. Scaled integers
are the way for accuracy.
Also, side note, gmp recommends to rely on https://www.mpfr.org/ for
accurate FP operations
best,
yes, they do, as do almost all floating points implementation.
Memory limited float values and their respective operations are still useful in many areas, but financial values and the likes. Scaled integers are the way for accuracy.
Also, side note, gmp recommends to rely on https://www.mpfr.org/ for accurate FP operations
Hi
This seems to be a floating point number with extremely high precision compared to regular long doubles. However, as you say, even though the accuracy is very high, errors still occur. (the error is so small that it almost never becomes a problem.)
By its very nature, BCMath does not introduce any errors. It is debatable whether floating point calculations in GMP can play the role of BCMath.
Regards.
Saki
yes, they do, as do almost all floating points implementation.
Memory limited float values and their respective operations are still
useful in many areas, but financial values and the likes. Scaled integers
are the way for accuracy.Also, side note, gmp recommends to rely on https://www.mpfr.org/ for
accurate FP operationsHi
This seems to be a floating point number with extremely high precision
compared to regular long doubles. However, as you say, even though the
accuracy is very high, errors still occur. (the error is so small that it
almost never becomes a problem.)By its very nature, BCMath does not introduce any errors. It is debatable
whether floating point calculations in GMP can play the role of BCMath.
so does gmp. The point made about gmp earlier is more about the
sustainability of gmp vs bcmath.
Hi, Marc, Pierre
Thank you for all the information.
After all, I feel that BCMath and GMP have different roles.
Arbitrary precision mathematics and very high precision mathematics are similar but distinctly different.
If PHP has already started integrating these things, then of course I'll follow suit, but if not, I'm against these integrations.
If I missed something important, could you please let me know?
Regards.
Saki
Hi
Hi, Marc, Pierre
Thank you for all the information.
After all, I feel that BCMath and GMP have different roles.
Arbitrary precision mathematics and very high precision mathematics are
similar but distinctly different.
I replied about the FP specific question as it can be confusing. Adding
that gmp* may be a more sustainable solution as it is actively maintained
and widely used.
If PHP has already started integrating these things, then of course I'll
follow suit, but if not, I'm against these integrations.
If I missed something important, could you please let me know?
theoretically I agree, both may have different uses. Practically, and
within php ecosystem, they are used for the same purposes.
best,
Pierre
Hi, Pierre
In fact, I predict that many use cases will be covered by GMP.
Still, I think that there may be cases where calculation functions like mainframe BCD are required, such as when calculating money.
I am unable to decide whether it is correct to deprecate BCMath and only use GMP.
I'd like to hear other people's opinions as well.
Regards.
Saki
-----Original Message-----
Still, I think that there may be cases where calculation functions like mainframe
BCD are required, such as when calculating money.
We use BCMath for money calculations.
-Jeff
Hi, Jeff
Thanks for letting me know your use case.
This is important information when discussing this issue.
Saki
Hi,
Le 5 oct. 2023 à 14:26, Saki Takamachi saki@sakiot.com a écrit :
In fact, I predict that many use cases will be covered by GMP.
Still, I think that there may be cases where calculation functions like mainframe BCD are required, such as when calculating money.
I am unable to decide whether it is correct to deprecate BCMath and only use GMP.
I'd like to hear other people's opinions as well.
We use bcmath in particular for money calculation indeed, and some other things, most of them have in common to work with decimal numbers.
For those purposes, gmp (in its current state) is pointless, because it supports only integers. I could multiply my numbers with an appropriate power of ten and work with integers; but in that case I could just use native 64-bits integers: even if you work on Apple’s accounting, they won’t overflow.
Le 4 oct. 2023 à 13:39, Saki Takamachi saki@sakiot.com a écrit :
After all, I feel that BCMath and GMP have different roles.
Arbitrary precision mathematics and very high precision mathematics are similar but distinctly different.
If PHP has already started integrating these things, then of course I'll follow suit, but if not, I'm against these integrations.
If I missed something important, could you please let me know?
None of the above. As noted, my main use of bcmath is neither arbitrary precision, nor very high precision, it is decimal numbers.
Of course, bcmath works equally well for manipulation of big integers, which is my second use case of the library. Because I already use bcmath for other things and I don’t need Legendre symbols, I have not much incentive to switch to gmp for big integers.
—Claude
Hi, Claude
I'm very sorry, I'm not a native English speaker and I couldn't quite understand whether you think BCMath should be integrated into GMP.
I understand your use case well, so if you don't mind, can I ask if it should or should not be integrated?
Regards.
Saki
Hi, Pierre
In fact, I predict that many use cases will be covered by GMP.
Still, I think that there may be cases where calculation functions like
mainframe BCD are required, such as when calculating money.I am unable to decide whether it is correct to deprecate BCMath and only
use GMP.I'd like to hear other people's opinions as well.
Regards.
Saki
GMP cannot be used in any reasonable way to implement things like sin() or
cos(). It is technically possible, but not at all reasonable. Now, PHP
doesn't natively support trig functions for anything other than normal
floats, but things like that are exactly the extended capability that my
PHP math library adds. This is required for most statistics, which now HAVE
to be done in PHP itself since the ext-stats extension hasn't been updated
since... I think 7.1?
BCMath is one of the worst and slowest implementations of arbitrary
precision decimals. It absolutely should be replaced. I have explored
creating a new extension to do just this in fact for the express purpose of
deprecating and replacing the bundled BCMath. But GMP, as it is implemented
currently, is not a replacement at all.
Jordan
On Thu, Oct 12, 2023 at 11:24 AM Jordan LeDoux jordan.ledoux@gmail.com
wrote:
Hi, Pierre
In fact, I predict that many use cases will be covered by GMP.
Still, I think that there may be cases where calculation functions like
mainframe BCD are required, such as when calculating money.I am unable to decide whether it is correct to deprecate BCMath and only
use GMP.I'd like to hear other people's opinions as well.
Regards.
Saki
GMP cannot be used in any reasonable way to implement things like
sin()or
cos(). It is technically possible, but not at all reasonable. Now, PHP
doesn't natively support trig functions for anything other than normal
floats, but things like that are exactly the extended capability that my
PHP math library adds. This is required for most statistics, which now HAVE
to be done in PHP itself since the ext-stats extension hasn't been updated
since... I think 7.1?BCMath is one of the worst and slowest implementations of arbitrary
precision decimals. It absolutely should be replaced. I have explored
creating a new extension to do just this in fact for the express purpose of
deprecating and replacing the bundled BCMath. But GMP, as it is implemented
currently, is not a replacement at all.Jordan
Take a look at the ext-decimal extension if you are interested in replacing
BCMath. It honestly is almost a drop-in replacement.
Jordan
Hi, Jordan
Thank you, that was an easy to understand explanation.
I would agree with that, if it means creating new math features that aren't currently bundled, rather than unifying them with GMP.
How far along is this plan now? I'm very interested in that.
Regards.
Saki
Should we use MPFR for new mathematics?
I'm not very familiar with it, but am I correct in understanding that this can definitely represent a decimal number correctly, albeit a floating point number?
Regards.
Saki
Hi Jordan
Hi, Pierre
In fact, I predict that many use cases will be covered by GMP.
Still, I think that there may be cases where calculation functions like
mainframe BCD are required, such as when calculating money.I am unable to decide whether it is correct to deprecate BCMath and only
use GMP.I'd like to hear other people's opinions as well.
Regards.
Saki
GMP cannot be used in any reasonable way to implement things like
sin()or
cos(). It is technically possible, but not at all reasonable.
it is the reason I mentioned mpfr,
https://www.mpfr.org/mpfr-current/mpfr.html#Miscellaneous-Functions
the challenge I noticed in a couple of threads recently is the mixup of
radically different usages, like financial numbers with basic ops (+/-
eventually *//) and others.
they cannot use the same tools, most of the times. However there are libs
with different types or mode of operations, which could be a better fit
than what we do now.
It is not an easy research and priorities need to be clear.
BCMath is one of the worst and slowest implementations of arbitrary
precision decimals.
what I was trying to express :)
best ,
Hi Jordan
On Fri, Oct 13, 2023, 1:24 AM Jordan LeDoux jordan.ledoux@gmail.com
wrote:Hi, Pierre
In fact, I predict that many use cases will be covered by GMP.
Still, I think that there may be cases where calculation functions like
mainframe BCD are required, such as when calculating money.I am unable to decide whether it is correct to deprecate BCMath and only
use GMP.I'd like to hear other people's opinions as well.
Regards.
Saki
GMP cannot be used in any reasonable way to implement things like
sin()
orcos(). It is technically possible, but not at all reasonable.it is the reason I mentioned mpfr,
https://www.mpfr.org/mpfr-current/mpfr.html#Miscellaneous-Functionsthe challenge I noticed in a couple of threads recently is the mixup of
radically different usages, like financial numbers with basic ops (+/-
eventually *//) and others.they cannot use the same tools, most of the times. However there are libs
with different types or mode of operations, which could be a better fit
than what we do now.It is not an easy research and priorities need to be clear.
BCMath is one of the worst and slowest implementations of arbitrary
precision decimals.
what I was trying to express :)
best ,
I believe MPFR is what is used by ext-decimal. The only thing that makes
ext-decimal a somewhat difficult replacement for BCMath is that one of them
uses precision and the other uses scale. (Total accurate digits versus
total significant digits.) Fermat has implementations for both BCMath and
ext-decimal, while also using GMP. It is much more difficult to control the
number of accurate digits in ext-decimal than in BCMath, but ext-decimal is
literally hundreds of times faster. I think, however, that Rudi (the author
of ext-decimal) was against including ext-decimal in core.
But if you want an alternate implementation for arbitrary precision
decimals, it is certainly the place that someone should start.
Jordan
I believe MPFR is what is used by ext-decimal. The only thing that makes
ext-decimal a somewhat difficult replacement for BCMath is that one of them
uses precision and the other uses scale. (Total accurate digits versus
total significant digits.) Fermat has implementations for both BCMath and
ext-decimal, while also using GMP. It is much more difficult to control the
number of accurate digits in ext-decimal than in BCMath, but ext-decimal is
literally hundreds of times faster. I think, however, that Rudi (the author
of ext-decimal) was against including ext-decimal in core.
it isn't really needed if not at the language level.
scaled basic operations can be (relatively) easily optimized, with an order
of magnitude faster than what bcmath does.
however, the real challenge, imho, is the different uses. That's where rock
solid implementation like mpfr could help, for non basic ops or modes.
But if you want an alternate implementation for arbitrary precision
decimals, it is certainly the place that someone should start.
for the few areas I needed it, I made my own with add/sub and mul/div with
intrinsics. very little amount of codes and stable.
I am not completely sure how to cover the different usages, scaled
operations may be a good start and keeping bc math user land compatibility
may not too hard.
been years since i checked, but last time i checked, BCMath supports
floating point numbers,
and PHP's GMP wrappers does not (this is not a limitation of GMP
itself, but of PHP's GMP wrappers)
- has the GMP api floating issues been fixed? a quick test suggest
/no/: https://3v4l.org/FQaI4
I believe MPFR is what is used by ext-decimal. The only thing that makes
ext-decimal a somewhat difficult replacement for BCMath is that one of them
uses precision and the other uses scale. (Total accurate digits versus
total significant digits.) Fermat has implementations for both BCMath and
ext-decimal, while also using GMP. It is much more difficult to control the
number of accurate digits in ext-decimal than in BCMath, but ext-decimal is
literally hundreds of times faster. I think, however, that Rudi (the author
of ext-decimal) was against including ext-decimal in core.it isn't really needed if not at the language level.
scaled basic operations can be (relatively) easily optimized, with an order
of magnitude faster than what bcmath does.however, the real challenge, imho, is the different uses. That's where rock
solid implementation like mpfr could help, for non basic ops or modes.But if you want an alternate implementation for arbitrary precision
decimals, it is certainly the place that someone should start.for the few areas I needed it, I made my own with add/sub and mul/div with
intrinsics. very little amount of codes and stable.I am not completely sure how to cover the different usages, scaled
operations may be a good start and keeping bc math user land compatibility
may not too hard.
Hi,
Hello,
Recently I was trying to fix and clean some of the stuff within the BCmath
extension along with Girgias who helped me. I wanted to enrich this
extension with similar functions that GMP contains and improve the
performance, however, I went to some conclusions and stopped it.
- BCMath extension isn't fast enough compared to other existing arbitrary
precision PHP extensions. Comparison:
https://php-decimal.github.io/#performance- BCMath doesn't have OO API and thus it may break the backward
compatibility as Claude noticed.- GMP GNU library provides support for float numbers, however, its
functionality is not exposed in the PHP extension. And BCMath doesn't
provide as many functions as GMP.
There was an RFC back in 2014 from Sara :
https://wiki.php.net/rfc/gmp-floating-point (never put to vote)
and another one from 2013 : https://wiki.php.net/rfc/gmp_number (never
put to vote).
Also I think to remember about a proposal to have GMP natively supported
for numbers in PHP but I can't find it anymore.
Kind regards,
Jorg
Best,
Marc
Hi,
It's been two weeks since then.
I don't think there is any reason to prevent enhancements to BCMath's functionality at this point, unless there is a realistic discussion of deprecating BCMath and providing another math extension.
Also, regarding conflicts with functions of the same name that are already in user land, this is targeted for a minor update, so we believe there will be enough time to fix them. Also, if we consider conflicts with user land function names, it will be difficult for PHP to add functions in the future, so this is not a good idea.
Regards.
Saki
Hi,
The discussion seems to have calmed down, so I'll start voting at the beginning of next week.
Regards.
Saki