Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123222
Precedence: bulk
MIME-Version: 1.0
References: <18c42fdbb30.2831.17a3710df6d58f02ca570cc47e197a63@interi.co>
 <0f64523d-d949-75ed-682b-789fc33fa3b2@php.net> <CAOyH9yRfFBKis_eoMp=V_Y8+03yrqg=rMtJMbd+ifeJUwkGczw@mail.gmail.com>
 <CAOyH9ySpRv9uTj5+p7JzE=j1f49gO6N4W73NYSse7Ax1VYjd3Q@mail.gmail.com>
In-Reply-To: <CAOyH9ySpRv9uTj5+p7JzE=j1f49gO6N4W73NYSse7Ax1VYjd3Q@mail.gmail.com>
Date: Sat, 27 Apr 2024 23:28:33 -0700
Message-ID: <CAMrTa2GMm8Tj9QCru9MUNoe-Hm_Scto1ff_8cEKBzr7S3bZdhQ@mail.gmail.com>
Subject: Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type
To: Alexander Pravdin <alex.pravdin@interi.co>
Cc: Derick Rethans <derick@php.net>, internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000c936070617223f0b"
From: jordan.ledoux@gmail.com (Jordan LeDoux)

--000000000000c936070617223f0b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, Apr 27, 2024 at 11:04=E2=80=AFPM Alexander Pravdin <alex.pravdin@in=
teri.co>
wrote:

>
> All builtin functions that currently accept float also accept decimal.
> So users don't need to care about separate function sets, and PHP
> developers don't need to maintain separate sets of functions. If any
> of the parameters is decimal, they return decimal. Float parameters
> are converted to decimals implicitly according to the conversion rules
> mentioned above.
>
>
So, as I mentioned months ago, this is the reason that having actually
looked into implementing things like this, I was interested in using a
library. Proposing this is fine. But doing a fully custom implementation
that includes this? You're going to implement `sin` and `cos` and `atan`
for 128-bit decimals? When we could use an open source library that has a
compatible license instead and is proven to work for these already instead,
likely with better performance as well?

This is likely to be more work than doing a type backed by a library while
also being less capable.

I know that your shift in proposal here is not aimed at me, and also I'm
not a voter so in that sense it doesn't matter. But if this is what the
proposal ends up being, I'll probably just continue on the research for an
actual arbitrary precision implementation based on MPFR instead of helping
with this implementation.

Jordan

--000000000000c936070617223f0b
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 Sat, Apr 27, 2024 at 11:04=E2=80=
=AFPM Alexander Pravdin &lt;<a href=3D"mailto:alex.pravdin@interi.co">alex.=
pravdin@interi.co</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p=
adding-left:1ex"><br>
All builtin functions that currently accept float also accept decimal.<br>
So users don&#39;t need to care about separate function sets, and PHP<br>
developers don&#39;t need to maintain separate sets of functions. If any<br=
>
of the parameters is decimal, they return decimal. Float parameters<br>
are converted to decimals implicitly according to the conversion rules<br>
mentioned above.<br>
<br></blockquote><div><br></div><div>So, as I mentioned months ago, this is=
 the reason that having actually looked into implementing things like this,=
 I was interested in using a library. Proposing this is fine. But doing a f=
ully custom implementation that includes this? You&#39;re going to implemen=
t `sin` and `cos` and `atan` for 128-bit decimals? When we could use an ope=
n source library that has a compatible license instead and is proven to wor=
k for these already instead, likely with better performance as well? <br></=
div><div><br></div><div>This is likely to be more work than doing a type ba=
cked by a library while also being less capable.<br></div><div><br></div><d=
iv>I know that your shift in proposal here is not aimed at me, and also I&#=
39;m not a voter so in that sense it doesn&#39;t matter. But if this is wha=
t the proposal ends up being, I&#39;ll probably just continue on the resear=
ch for an actual arbitrary precision implementation based on MPFR instead o=
f helping with this implementation.</div><div><br></div><div>Jordan<br></di=
v></div></div>

--000000000000c936070617223f0b--