Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121995
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> <CAMrTa2Es3x=cySpGivGKHqLK_fL8_W9rahJbmbeMtY3_HxVoow@mail.gmail.com>
In-Reply-To: <CAMrTa2Es3x=cySpGivGKHqLK_fL8_W9rahJbmbeMtY3_HxVoow@mail.gmail.com>
Date: Tue, 12 Dec 2023 18:52:30 -0300
Message-ID: <CAGS0MVDUNOxXsPSfXpLcEPbwG5Fejxc-SdAL0cOPdAe2FkEvTw@mail.gmail.com>
To: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000567f44060c57137c"
Subject: Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type
From: ericklima.comp@gmail.com (Erick de Azevedo Lima)

--000000000000567f44060c57137c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Jordan.

What's the name of the library you're talking about? Maybe the cons of a
core implementation can be highlighted if we can see the limitations of a
user-land approach.

Best,
Erick

Em ter., 12 de dez. de 2023 =C3=A0s 18:35, Jordan LeDoux <jordan.ledoux@gma=
il.com>
escreveu:

> On Tue, Dec 12, 2023 at 1:26=E2=80=AFPM Larry Garfield <larry@garfieldtec=
h.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 a=
s
> 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
> behavior
> > (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
> not
> > 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
> until
> > 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
> ugly
> > 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
>

--000000000000567f44060c57137c--