Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121996
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>
 <CAGS0MVDUNOxXsPSfXpLcEPbwG5Fejxc-SdAL0cOPdAe2FkEvTw@mail.gmail.com>
In-Reply-To: <CAGS0MVDUNOxXsPSfXpLcEPbwG5Fejxc-SdAL0cOPdAe2FkEvTw@mail.gmail.com>
Date: Tue, 12 Dec 2023 20:04:33 -0300
Message-ID: <CAGS0MVDzJ681nZ0isftGmeYrPOZeuhvRV-WiYH3YWCG=p=aLtA@mail.gmail.com>
To: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000010a864060c5815b9"
Subject: Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type
From: ericklima.comp@gmail.com (Erick de Azevedo Lima)

--00000000000010a864060c5815b9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Oh, I just realized that I used the wrong word, so let me rephrase that:

What's the name of the library you're talking about? Maybe the *pros* 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:52, Erick de Azevedo Lima <
ericklima.comp@gmail.com> escreveu:

> 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@gmail.com> escreveu:
>
>> On Tue, Dec 12, 2023 at 1:26=E2=80=AFPM Larry Garfield <larry@garfieldte=
ch.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
>> 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 jus=
t
>> 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 sound=
s
>> > 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 issu=
e.
>> (Algorithms like `sin()`, `atan()`, or `exp()`). It's not an unsolveable
>> problem if you really want rational types. There are libraries that do i=
t.
>> But unless there's someone here volunteering, it's probably a non-starte=
r,
>> as that's something I won't touch.
>>
>> Jordan
>>
>

--00000000000010a864060c5815b9--