Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123042
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>
 <F36A5C9B-7F3E-4EB7-A254-2ADB47AB6AE0@sakiot.com> <CAL0xaBEQdWX735rE-EoxEr=44VTX5ud=XOvxn_g1Y28V2fugFg@mail.gmail.com>
 <57c268e9be57edad86155c461b0fd181@gliadin.co.uk>
In-Reply-To: <57c268e9be57edad86155c461b0fd181@gliadin.co.uk>
Date: Mon, 8 Apr 2024 15:42:12 +0300
Message-ID: <CAL0xaBHW8wdPu4qsnoXwzmensO5Yj=0HQS0VLknFcSonYcci=g@mail.gmail.com>
Subject: Re: [PHP-DEV] Native decimal scalar support and object types in
 BcMath - do we want both?
To: Barney Laurance <barney@redmagic.org.uk>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000a0b2cc0615952439"
From: arvids.godjuks@gmail.com (Arvids Godjuks)

--000000000000a0b2cc0615952439
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 8 Apr 2024 at 14:33, Barney Laurance <barney@redmagic.org.uk> wrote=
:

> On 2024-04-08 12:17, Arvids Godjuks wrote:
>
> > Why not have decimal be represented as 2 64-bit ints at the engine
> > level
>
> Just to clarify this point, what's the formula to convert back and
> forth between a decimal and two integers? Are you thinking like
> scientific notation: decimal =3D coefficient * 10^exponent.
>
> 64 bits for the exponent seems excessive, and it might be nice to have
> more for the coefficient but maybe that doesn't matter too much.
>


I was thinking of no exponents, just a straightforward integer
representation for the fractional part, 14 digits long (48 bits). Taking
two 64-bit numbers and combining them into a single 128-bit value would
give us a range of "-604,462,909,807,314,587,353,088" to
"604,462,909,807,314,587,353,087" for the integer part (80 bits) and
"281,474,976,710,655" for the unsigned integer for fractions (48 bits).
With this, we can achieve 14 digits of precision without any problem. I
would say these numbers are sufficiently large to realistically cover most
scenarios that the vast majority of us, PHP developers, will ever
encounter. For everything else, extensions that handle arbitrary numbers
exist. :)

The ini setting I was considering would function similarly to what it does
for floats right now - I assume it changes the exponent, thereby increasing
their precision but reducing the integer range they can cover. The same
adjustment could be applied to decimals if people really need to tweak
those ini settings (I've never seen anyone change that from the default in
20 years, but hey, I'm sure someone out there does and needs it).

-

Arv=C4=ABds Godjuks
+371 26 851 664
arvids.godjuks@gmail.com
Telegram: @psihius https://t.me/psihius

--000000000000a0b2cc0615952439
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Mon, 8 Apr 2024 at 14:33, Barney Laura=
nce &lt;<a href=3D"mailto:barney@redmagic.org.uk" target=3D"_blank">barney@=
redmagic.org.uk</a>&gt; wrote:<br></div><div class=3D"gmail_quote"><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px=
 solid rgb(204,204,204);padding-left:1ex">On 2024-04-08 12:17, Arvids Godju=
ks wrote:<br>
<br>
&gt; Why not have decimal be represented as 2 64-bit ints at the engine <br=
>
&gt; level<br>
<br>
Just to clarify this point, what&#39;s the formula to convert back and <br>
forth between a decimal and two integers? Are you thinking like <br>
scientific notation: decimal =3D coefficient * 10^exponent.<br>
<br>
64 bits for the exponent seems excessive, and it might be nice to have <br>
more for the coefficient but maybe that doesn&#39;t matter too much.<br>
</blockquote></div><br clear=3D"all"><div><br>I was thinking of no exponent=
s, just a straightforward integer representation for the fractional part, 1=
4 digits long (48 bits). Taking two 64-bit numbers and combining them into =
a single 128-bit value would give us a range of &quot;-604,462,909,807,314,=
587,353,088&quot; to &quot;604,462,909,807,314,587,353,087&quot; for the in=
teger part (80 bits) and &quot;281,474,976,710,655&quot; for the unsigned i=
nteger for fractions (48 bits). With this, we can achieve 14 digits of prec=
ision without any problem. I would say these numbers are sufficiently large=
 to realistically cover most scenarios that the vast majority of us, PHP de=
velopers, will ever encounter. For everything else, extensions that handle =
arbitrary numbers exist. :)<br><br>The ini setting I was considering would =
function similarly to what it does for floats right now - I assume it chang=
es the exponent, thereby increasing their precision but reducing the intege=
r range they can cover. The same adjustment could be applied to decimals if=
 people really need to tweak those ini settings (I&#39;ve never seen anyone=
 change that from the default in 20 years, but hey, I&#39;m sure someone ou=
t there does and needs it).<br></div><div><br></div><div></div><span class=
=3D"gmail_signature_prefix">-</span><br><div dir=3D"ltr" class=3D"gmail_sig=
nature"><div dir=3D"ltr"><div><br></div>Arv=C4=ABds Godjuks<div>+371 26 851=
 664</div><div><a href=3D"mailto:arvids.godjuks@gmail.com" target=3D"_blank=
">arvids.godjuks@gmail.com</a></div><div>Telegram: @psihius=C2=A0<a href=3D=
"https://t.me/psihius" target=3D"_blank">https://t.me/psihius</a></div></di=
v></div></div>

--000000000000a0b2cc0615952439--