**Benjamin Morel**— view source

Just for the record, I've written a userland arbitrary precision arithmetic library, that provides a BigDecimal class which should be pretty similar to what you're aiming to do:

https://github.com/brick/math

This library uses the existing GMP or BCMath extensions when available, but also works without them, using a (slower, but fully functional) pure PHP implementation.

A new PHP extension that would provide native arbitrary precision numbers with an OO API would be welcome, IMO.

Maybe brick/math can help inspire your API?

Benjamin

Le 29 sept. 2018 à 01:05, Rudi Theunissen [email protected] a écrit :

Hi everyone,

I've been working on adding arbitrary precision decimal support as an

alternative to *bcmath. *I have created an extension based onmpdecimal,

which is what Python 3's decimal module is also based on. I haven't

released or broadcast this project yet, because I wanted to discuss the API

and implementation with internals first.See: https://github.com/php-decimal/php-decimal

Any advice, commentary or objection is welcome. :)

Thank you,

Rudi Theunissen--0000000000001ef4ff0576f68080

**Rudi Theunissen**— view source

Hi Benjamin,

Brick\Math looks awesome. I really like the static initializers and

descriptive method names. I recognize some of the patterns from OpenJDK's

BigDecimal source. :)

The major difference to me is scale vs precision, ie. number of significant

digits vs number of digits behind the decimal point. Not sure which is

better, just noticing the difference.

Your production is so good, by the way. I really appreciate it.

Rudi

On Tue, Oct 23, 2018 at 5:45 AM Benjamin Morel [email protected]

wrote:

Just for the record, I've written a userland arbitrary precision

arithmetic library, that provides a BigDecimal class which should be pretty

similar to what you're aiming to do:This library uses the existing GMP or BCMath extensions when available,

but also works without them, using a (slower, but fully functional) pure

PHP implementation.A new PHP extension that would provide native arbitrary precision numbers

with an OO API would be welcome, IMO.Maybe brick/math can help inspire your API?

Benjamin

Le 29 sept. 2018 à 01:05, Rudi Theunissen [email protected] a écrit :

Hi everyone,

I've been working on adding arbitrary precision decimal support as an

alternative to *bcmath. *I have created an extension based onmpdecimal,

which is what Python 3's decimal module is also based on. I haven't

released or broadcast this project yet, because I wanted to discuss the API

and implementation with internals first.See: https://github.com/php-decimal/php-decimal

Any advice, commentary or objection is welcome. :)

Thank you,

Rudi Theunissen--0000000000001ef4ff0576f68080

**Benjamin Morel**— view source

I recognize some of the patterns from OpenJDK's BigDecimal source. :)

Indeed, Brick\Math was largely inspired by Java's implementation!

The major difference to me is scale vs precision, ie. number of significant

digits vs number of digits behind the decimal point. Not sure which is

better, just noticing the difference.

Brick\Math does not have a concept of precision or "significant digits".

It only cares about scale, and has unlimited precision.

Its aim is to always return an exact result, unless rounding is explicitly

requested.

The scale is automatically adjusted for common operations such as plus(),

minus() and multipliedBy().

For dividedBy(), you have to explicitly specify the requested scale of the

result and an optional rounding mode; if no rounding mode is provided, and

the result does not fit in this scale, you get an exception.

If you don't know the scale but do know that the division yields a number

with a finite scale, you can use the exactlyDividedBy(), which will either

return an exact result with the correct scale, or throw an exception.

This is the first difference that strikes me with your current

implementation:

0.1 / 7 == 0.01428571428571428571428571429

Because the result is an infinite repeating decimal, in my opinion, your

Decimal class should not allow such a division without explicitly

specifying a scale and a rounding mode.

In other words, I would expect an exception here.

To exactly represent the result of this division, another concept such as

Brick\Math's BigRational can be used instead.

Ben

**Rudi Theunissen**— view source

Because the result is an infinite repeating decimal, in my opinion, your

Decimal class should not allow such a division without explicitly

specifying a scale and a rounding mode. In other words, I would expect an

exception here.

There is already an internal flag for inexact division, but is currently

ignored. If exact division is a requirement, I would rather a dedicated

type for that like Decimal\Exact or Decimal\Fraction.

Brick\Math does not have a concept of precision or "significant digits".

It only cares about scale, and has unlimited precision.

That's the main difference here. Arbitrary scale might be more intuitive

and practical than arbitrary precision - I honestly don't have an opinion

here. It would be interesting to compare some use cases and

interoperability with SQL DECIMAL, which I assume would be a common analog

for any PHP type.

On Sat, Oct 27, 2018 at 3:14 AM Benjamin Morel [email protected]

wrote:

I recognize some of the patterns from OpenJDK's BigDecimal source. :)

Indeed, Brick\Math was largely inspired by Java's implementation!

The major difference to me is scale vs precision, ie. number of

significant digits vs number of digits behind the decimal point. Not sure

which is better, just noticing the difference.Brick\Math does not have a concept of precision or "significant digits".

It only cares about scale, and has unlimited precision.Its aim is to always return an exact result, unless rounding is explicitly

requested.

The scale is automatically adjusted for common operations such as plus(),

minus() and multipliedBy().

For dividedBy(), you have to explicitly specify the requested scale of the

result and an optional rounding mode; if no rounding mode is provided, and

the result does not fit in this scale, you get an exception.

If you don't know the scale but do know that the division yields a number

with a finite scale, you can use the exactlyDividedBy(), which will either

return an exact result with the correct scale, or throw an exception.This is the first difference that strikes me with your current

implementation:

0.1 / 7 == 0.01428571428571428571428571429Because the result is an infinite repeating decimal, in my opinion, your

Decimal class should not allow such a division without explicitly

specifying a scale and a rounding mode.

In other words, I would expect an exception here.To exactly represent the result of this division, another concept such as

Brick\Math's BigRational can be used instead.Ben