Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78194
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 198.187.29.244 as permitted sender)
References: <8C47FA53-0964-49C0-963C-332A936348A5@ajf.me> <CA+9eiLuOcd-u_kzu+MZM71Ns_-9vsSbifFF5x9Q1b4k0NV12Wg@mail.gmail.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <CA+9eiLuOcd-u_kzu+MZM71Ns_-9vsSbifFF5x9Q1b4k0NV12Wg@mail.gmail.com>
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-ID: <04EB15ED-95F4-451E-9B79-5072FF59DD1E@ajf.me>
Cc: PHP Internals <internals@lists.php.net>
Date: Tue, 21 Oct 2014 11:48:58 +0100
To: Dmitry Stogov <dmitry@zend.com>
Subject: Re: [PHP-DEV] [RFC] Big Integer Support
From: ajf@ajf.me (Andrea Faulds)


> On 21 Oct 2014, at 09:35, Dmitry Stogov <dmitry@zend.com> wrote:
>=20
> Hi Andrea,
>=20
> Why don't you use the ability of operator overloading? (it's in the engine=
 since 5.6).

I've already answered this in this thread, but I'll answer it again if I mus=
t.

>=20
> BIGINT don't have to be completely transparent. If user would like to work=
 with BIGINT, let them crate PHP objects explicitly and then use operator ov=
erloading. e.g.

Well, they already can. ext/gmp exists.

> Your solution would allows writing the same without BIGINT, but not for fr=
ee.
> I expect, it'll make some slowdown for all PHP scripts, independently, if t=
hey use BIGINT or not.
> I'll try to take a deeper look into the patch later...
>=20
> Could you provide some benchmark results, comparing your patch with master=
?

So, the point of this RFC is basically to make PHP a language where, like Py=
thon, Haskell, Prolog or (de jure but not de facto) Dart, integers can be ar=
bitrarily large and you never have to worry about overflow. Instead of appli=
cations which definitely need bigints using them explicitly, all application=
s can now support integers of any size transparently, essentially for free. I=
t also makes the language more intuitive in a way. Plus, it's one less cross=
-platform difference so code is more portable.

You're right it might not actually be free, though. I'll need to run some be=
nchmarks - will do later today if I remember. It shouldn't be any slower tha=
n master, though. All it does is change what we do in our usual overflow che=
cks, which we already had. Now, once you've overflowed and got a bigint, obv=
iously they're slower than floats. However if you need floating-point perfor=
mance you can explicitly cast to double and deliberately lose accuracy.
--
Andrea Faulds
http://ajf.me/=