**Saki Takamachi**— view source

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

**Claude Pache**— view source

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

**Jorg Sowa**— view source

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

**Saki Takamachi**— view source

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

**Pierre Joye**— view source

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,

**Saki Takamachi**— view source

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

**Pierre Joye**— view source

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.

**Saki Takamachi**— view source

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

**Pierre Joye**— view source

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

**Saki Takamachi**— view source

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

**Jeffrey Dafoe**— view source

-----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

**Saki Takamachi**— view source

Hi, Jeff

Thanks for letting me know your use case.

This is important information when discussing this issue.

Saki

**Claude Pache**— view source

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

**Saki Takamachi**— view source

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

**Jordan LeDoux**— view source

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

**Jordan LeDoux**— view source

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.

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 istechnicallypossible, 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

**Saki Takamachi**— view source

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

**Saki Takamachi**— view source

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

**Pierre Joye**— view source

Hi Jordan

Hi, Pierre

In fact, I predict that many use cases will be covered by GMP.

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 istechnicallypossible, 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 ,

**Jordan LeDoux**— view source

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.

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 istechnicallypossible, 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

**Pierre Joye**— view source

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.

**Hans Henrik Bergan**— view source

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.

**Marc**— view source

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

**Saki Takamachi**— view source

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

**Saki Takamachi**— view source

Hi,

The discussion seems to have calmed down, so I'll start voting at the beginning of next week.

Regards.

Saki