Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123024
Precedence: bulk
MIME-Version: 1.0
References: <40553F28-2EC2-475A-BD8E-1D6517AA2A51@rwec.co.uk>
 <2B518F62-B774-45C9-82A2-EF6653AAE34E@sakiot.com> <A703D145-1A10-4C7E-9E0C-1F0BEF94CF99@rwec.co.uk>
In-Reply-To: <A703D145-1A10-4C7E-9E0C-1F0BEF94CF99@rwec.co.uk>
Date: Sun, 7 Apr 2024 12:55:53 -0700
Message-ID: <CAMrTa2G+_v1aO_g7NLiLsTwquJaf9=Zj5bp2ODGzVSB3iGr6pw@mail.gmail.com>
Subject: Re: [PHP-DEV] Native decimal scalar support and object types in
 BcMath - do we want both?
To: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="00000000000064c97f06158714cc"
From: jordan.ledoux@gmail.com (Jordan LeDoux)

--00000000000064c97f06158714cc
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, Apr 7, 2024 at 8:27=E2=80=AFAM Rowan Tommins [IMSoP] <imsop.php@rwe=
c.co.uk>
wrote:

>
>
> On 7 April 2024 15:38:04 BST, Saki Takamachi <saki@sakiot.com> wrote:
> >> In other words, looking at how the efforts overlap doesn't have to mea=
n
> abandoning one of them, it can mean finding how one can benefit the other=
.
> >
> >I agree that the essence of the debate is as you say.
> >However, an argument must always reach a conclusion based on its purpose=
,
> and combining two arguments with different purposes can make it unclear h=
ow
> to reach a conclusion.
>
> Well, that's the original question: are they actually different purposes,
> from the point of view of a user?
>
> I just gave a concrete suggestion, which didn't involve "combining two
> arguments", it involved splitting them up into three projects which all
> complement each other.
>
> It feels like both you and Jordan feel the need to defend the work you've
> put in so far, which is a shame; as a neutral party, I want to benefit fr=
om
> *both* of your efforts. It really doesn't matter to me how many mailing
> list threads that requires, as long as there aren't two teams making
> conflicting designs for the same feature.
>
> Regards,
> Rowan Tommins
> [IMSoP]
>

Eh, my first reply wasn't really about defending anything. It was to
inform. I have been doing small bits of work, research, and investigation
into an MPDec or MPFR implementation for years, and I'm likely to continue
doing my research on that regardless of whatever is discussed in this
thread.

Rowan, my point wasn't so much that a discussion like this one is
pointless, it was that MOST of the people who actually vote on RFCs don't
reply at all to internals, so a discussion like this actually does not help
anyone understand the opinion of MOST of the people that actually need to
be convinced. We hope the discussion is representative of the people who do
not engage with it, but we don't know for sure.

In any case, an alternative implementation using MPDec/MPFR probably can't
be done until 9.0 at the earliest, but Saki's improvements to BCMath are
ready to merge now, essentially.

>  Is there anything in the proposal which would actually be different if
it was based on a different library

Yes. BCMath uses fixed-scale, all the other libraries use fixed-precision.
That is, the other libraries use a fixed number of significant digits,
while BCMath uses a fixed number of digits after the decimal point. So, for
instance, it would not actually be possible without manual rounding in the
PHP implementation to force exactly 2 decimal digits of accuracy in the
result and no more with MPDec. The idea of money, for instance, wanting
exactly two digits would require the implementation to round, because
something like 0.00000013 has two digits of *precision*, which is what
MPDec uses, but it has 8 digits of scale which is what BCMath uses.

Jordan

--00000000000064c97f06158714cc
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Sun, Apr 7, 2024 at 8:27=E2=80=AFA=
M Rowan Tommins [IMSoP] &lt;<a href=3D"mailto:imsop.php@rwec.co.uk">imsop.p=
hp@rwec.co.uk</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi=
ng-left:1ex"><br>
<br>
On 7 April 2024 15:38:04 BST, Saki Takamachi &lt;<a href=3D"mailto:saki@sak=
iot.com" target=3D"_blank">saki@sakiot.com</a>&gt; wrote:<br>
&gt;&gt; In other words, looking at how the efforts overlap doesn&#39;t hav=
e to mean abandoning one of them, it can mean finding how one can benefit t=
he other.<br>
&gt;<br>
&gt;I agree that the essence of the debate is as you say.<br>
&gt;However, an argument must always reach a conclusion based on its purpos=
e, and combining two arguments with different purposes can make it unclear =
how to reach a conclusion.<br>
<br>
Well, that&#39;s the original question: are they actually different purpose=
s, from the point of view of a user?<br>
<br>
I just gave a concrete suggestion, which didn&#39;t involve &quot;combining=
 two arguments&quot;, it involved splitting them up into three projects whi=
ch all complement each other. <br>
<br>
It feels like both you and Jordan feel the need to defend the work you&#39;=
ve put in so far, which is a shame; as a neutral party, I want to benefit f=
rom *both* of your efforts. It really doesn&#39;t matter to me how many mai=
ling list threads that requires, as long as there aren&#39;t two teams maki=
ng conflicting designs for the same feature.<br>
<br>
Regards,<br>
Rowan Tommins<br>
[IMSoP]<br></blockquote><div><br></div><div>Eh, my first reply wasn&#39;t r=
eally about defending anything. It was to inform. I have been doing small b=
its of work, research, and investigation into an MPDec or MPFR implementati=
on for years, and I&#39;m likely to continue doing my research on that rega=
rdless of whatever is discussed in this thread.</div><div><br></div><div>Ro=
wan, my point wasn&#39;t so much that a discussion like this one is pointle=
ss, it was that MOST of the people who actually vote on RFCs don&#39;t repl=
y at all to internals, so a discussion like this actually does not help any=
one understand the opinion of MOST of the people that actually need to be c=
onvinced. We hope the discussion is representative of the people who do not=
 engage with it, but we don&#39;t know for sure.</div><div><br></div><div>I=
n any case, an alternative implementation using MPDec/MPFR probably can&#39=
;t be done until 9.0 at the earliest, but Saki&#39;s improvements to BCMath=
 are ready to merge now, essentially.</div><div><br></div><div>&gt;=C2=A0
Is there anything in the proposal which would actually be different if it w=
as based on a different library=C2=A0</div><div><br></div><div>Yes. BCMath =
uses fixed-scale, all the other libraries use fixed-precision. That is, the=
 other libraries use a fixed number of significant digits, while BCMath use=
s a fixed number of digits after the decimal point. So, for instance, it wo=
uld not actually be possible without manual rounding in the PHP implementat=
ion to force exactly 2 decimal digits of accuracy in the result and no more=
 with MPDec. The idea of money, for instance, wanting exactly two digits wo=
uld require the implementation to round, because something like 0.00000013 =
has two digits of *precision*, which is what MPDec uses, but it has 8 digit=
s of scale which is what BCMath uses.</div><div><br></div><div>Jordan<br> <=
/div></div></div>

--00000000000064c97f06158714cc--