Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103406
MIME-Version: 1.0
References: <9BA56FEF-D2DE-4696-B765-04BE3D70C244@gmail.com>
 <CAHFNTwfOq+TYb=9UgaNTauPKZUmoQ+QtM1Xexzq2-WNbshBdcQ@mail.gmail.com> <CAG9XoMQWgmnaUx6vD74aUZBoZwTSvxm9oNVzgbpPytN-Dac4ag@mail.gmail.com>
In-Reply-To: <CAG9XoMQWgmnaUx6vD74aUZBoZwTSvxm9oNVzgbpPytN-Dac4ag@mail.gmail.com>
Date: Sat, 27 Oct 2018 09:00:11 -0700
Message-ID: <CAHFNTwfCO41WWjPYA7k=GQ5rpZe=Djov=3=YoV-8Drtxpe3Nfw@mail.gmail.com>
To: Benjamin Morel <benjamin.morel@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000f312f8057937ee6e"
Subject: Re: Extension: arbitrary precision decimal arithmetic in PHP 7
From: rtheunissen@php.net (Rudi Theunissen)

--000000000000f312f8057937ee6e
Content-Type: text/plain; charset="UTF-8"

> 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 <benjamin.morel@gmail.com>
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.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
>

--000000000000f312f8057937ee6e--