Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81744
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.199 as permitted sender)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
In-Reply-To: <54D14268.3050500@lsces.co.uk>
Date: Tue, 3 Feb 2015 22:35:25 +0000
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <57216450-F110-401D-A42C-63F1E92C8645@ajf.me>
References: <8C47FA53-0964-49C0-963C-332A936348A5@ajf.me> <BCFDECB6-8FBC-4EA1-A081-21BDCC79C1C2@ajf.me> <B9B67D82-CB4E-4CA6-AFAB-25A22EC386B4@ajf.me> <54D00C40.8060907@lsces.co.uk> <54C5DC93-9600-4EE2-BF06-7BF10FC6AD5C@ajf.me> <54D08D50.5050407@lsces.co.uk> <1C2ED70C-72A0-4513-A134-5DAE4CCA5B3D@ajf.me> <54D0DFE5.9030602@lsces.co.uk> <06F175EB-D44A-445F-8015-8421C7C12F39@ajf.me> <54D14268.3050500@lsces.co.uk>
To: Lester Caine <lester@lsces.co.uk>
Subject: Re: [PHP-DEV] [RFC] Big Integer Support
From: ajf@ajf.me (Andrea Faulds)


> On 3 Feb 2015, at 21:49, Lester Caine <lester@lsces.co.uk> wrote:
>=20
> On 03/02/15 16:44, Andrea Faulds wrote:
>> Sure, but I don=92t think we shouldn=92t cripple the language merely =
for the sake of really low-end embedded devices. Also, I=92m not =
convinced that the overhead, at least in terms of file size, is really =
that big of an issue.
>=20
> 'I don=92t think we should cripple' ?
>=20
> There are two views on the handling of integers. Obviously it would be
> nice if there was no limit to the size of a number and there are
> situations where that is indeed useful. However there are equally
> situations where both the natural 32bit and 64bit limits of the target
> hardware and software needs to be observed and these require a =
different
> method of handling things like 'overflow=92.

Maybe. But PHP has never cared about those things. We promote to float =
when integers would =93overflow=94 in another language.

> Simply automatically
> upgrading an integer value to a more complex object depending on what
> hardware one is running on adds the overhead of having to create code =
to
> disable things depending on some hardware flag.

Not really. We already do promotion for integers to float, and it=92s a =
very simple operation to check for overflow, natively supported by many =
compilers, and we also have a pure C fallback. All that bigints do is =
that instead of promoting to float, we promote to bigints. There=92s no =
new overhead, these checks already existed, and have done for well over =
a decade.

The only complexity bigints add are the addition of the new IS_BIGINT =
type (which goes in your operator type matrices etc.), and requiring =
some bigint library.

> With the bulk of SQL persistent data having to manage both 32 and =
64bit
> integer limits and the matching float/numeric limits, a system of
> working which mirrors that would naturally seem to be the sensible
> default.

Why should it match SQL? Why should we have the complexity of two =
different sizes of integer? Why not just have a single, unified =
arbitrary-precision integer type, like the RFC proposes.

> If those limitations have been avoided by the use of additional
> libraries, then a matching additional library in PHP also comes into =
play.
>=20
> Currently we have a problem with the size of integers, but simply
> ignoring that there are limits is not the may to fix that problem.

This RFC doesn=92t ignore that there are limits. Arbitrary-precision =
integers are, naturally, bounded by available RAM (including the request =
memory limit).

--
Andrea Faulds
http://ajf.me/