Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121994
MIME-Version: 1.0
References: <18c42fdbb30.2831.17a3710df6d58f02ca570cc47e197a63@interi.co>
 <CAFPFaMLZ3MeGXt5OPmAkwM-n-eZcp1gT7RQCnpXSyHxZThOn2g@mail.gmail.com>
 <CAOyH9yReYorVd1jDPyk_O73JUn1VvqEAz0Fb7mvQ6ke9k9FcZA@mail.gmail.com>
 <CAFPFaMKoH1PD_qaBPLw9pwid0NB5zyZYM7AgogYOWFhPVysEwQ@mail.gmail.com> <f2d7cbc4-46eb-4a16-8f5b-c79b34aa64a0@app.fastmail.com>
In-Reply-To: <f2d7cbc4-46eb-4a16-8f5b-c79b34aa64a0@app.fastmail.com>
Date: Tue, 12 Dec 2023 13:34:38 -0800
Message-ID: <CAMrTa2Es3x=cySpGivGKHqLK_fL8_W9rahJbmbeMtY3_HxVoow@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000121e1e060c56d260"
Subject: Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type
From: jordan.ledoux@gmail.com (Jordan LeDoux)

--000000000000121e1e060c56d260
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Dec 12, 2023 at 1:26=E2=80=AFPM Larry Garfield <larry@garfieldtech.=
com>
wrote:

> On Tue, Dec 12, 2023, at 1:03 PM, G. P. B. wrote:
>
> > The issue is that I don't think having arbitrary precision decimals as =
a
> > core language feature is a necessity compared to rational types.
> > A cast from rational to float wouldn't produce a large round trip,
> whereas
> > trying to figure out arbitrary precision is more difficult.
> > But in any case, having a declare/INI or whatever that changes the
> > behaviour of the engine/language is not a good design choice.
>
> I don't have strong feelings about arbitrary precision decimals either
> way, but I do strongly agree with this point.  Having the language behavi=
or
> (including the precision of numbers) change with an ini setting is
> long-understood to be a bad idea, and we've been trying to phase it out. =
 A
> decimal feature that relies on a language-affecting ini setting is just n=
ot
> going to fly these days, IMO, and rightly so.
>
> I am curious, GB, if you're proposing an actual `rational` type, which
> stores values internally as just numerator and denominator separately unt=
il
> some point when it renders down to a float (eg, on print)?  That sounds
> neat, though I am nowhere near expert enough in that area to say what ugl=
y
> edge cases that might run into.
>
> --Larry Garfield
>

I agree that an INI setting or declare is wrong for this.

The ugly edge cases on a native rational type tend to be in complex
algorithms, which many libraries deal with by converting the rational to a
float or decimal for those complex algorithms and just avoiding the issue.
(Algorithms like `sin()`, `atan()`, or `exp()`). It's not an unsolveable
problem if you really want rational types. There are libraries that do it.
But unless there's someone here volunteering, it's probably a non-starter,
as that's something I won't touch.

Jordan

--000000000000121e1e060c56d260--