Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121282
MIME-Version: 1.0
References: <CAEZPtU6PT7yOhVZfGQ1Vh3soKH0tkXh86v0GiNJo79ZMiuO4XQ@mail.gmail.com>
 <9812BAD1-5003-4E91-BB3B-00637B9687AC@sakiot.com> <CAMrTa2H553O1CesPU95ma-HYnejWkMgZf-QOVvCxs=NHMOAc+g@mail.gmail.com>
 <CAEZPtU4v8Z0=pX7+YSXYPp+TDUcdWBk-WYHkbySabMnyFGqHiQ@mail.gmail.com>
In-Reply-To: <CAEZPtU4v8Z0=pX7+YSXYPp+TDUcdWBk-WYHkbySabMnyFGqHiQ@mail.gmail.com>
Date: Thu, 12 Oct 2023 12:00:54 -0700
Message-ID: <CAMrTa2GT9BD1=8hf5U98ZeTqot=qRMffHmkw30ww5GvELLQzbw@mail.gmail.com>
To: Pierre Joye <pierre.php@gmail.com>
Cc: Saki Takamachi <saki@sakiot.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000d9369f0607898f66"
Subject: Re: [PHP-DEV] [RFC] [Discussion] Adding bcround, bcfloor and bcceil
 to BCMath
From: jordan.ledoux@gmail.com (Jordan LeDoux)

--000000000000d9369f0607898f66
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Oct 12, 2023 at 11:32=E2=80=AFAM Pierre Joye <pierre.php@gmail.com>=
 wrote:

> Hi Jordan
>
> On Fri, Oct 13, 2023, 1:24 AM Jordan LeDoux <jordan.ledoux@gmail.com>
> wrote:
>
>>
>>
>> On Thu, Oct 5, 2023 at 5:27=E2=80=AFAM Saki Takamachi <saki@sakiot.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 onl=
y
>>> 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 ,
>

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

--000000000000d9369f0607898f66--