Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122858
To: <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain;
 charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 7bit
Date: Tue, 02 Apr 2024 14:49:21 +0100
In-Reply-To: <AEE95357-FBEE-47EA-9281-CDC5733242E2@sakiot.com>
References: <CANS-=pfVuKKfAiu0LUJTrEPnSRaa_nHwJCgMvSORruAwHMsvQg@mail.gmail.com>
 <AEE95357-FBEE-47EA-9281-CDC5733242E2@sakiot.com>
Message-ID: <f725fac0499f7c29c3719c880a8f705e@gliadin.co.uk>
User-Agent: Roundcube Webmail/0.7.1
From: barney@redmagic.org.uk (Barney Laurance)

On 2024-04-02 12:26, Saki Takamachi wrote:

> Also, an idea occurred to me while reading your comments.
>
> The current assumption is that a Number always holds a single value.
> How if we made it so that it held two values? They are the numerator
> and the denominator.

Then we'd have a rational number, instead of an arbitrary precision 
decimal. I think that's a sufficiently different data type that it 
should be a different class (if required), and probably a separate RFC, 
and for now it's better to stay closer to the existing BCMath API.

Developers should be prepared to accept that an arbitrary precision 
decimal can't represent 1/3 exactly, just like a binary float can't 
represent 1/10 exactly.