It is relatively fast (given that you have a php function call on each op). About php and large integers, it never supported anything else than 32bits integer. Whether the integer was stored in the system default integer (64bits on amd64 for example) did not change this problem. It is annoying but once you know it

I have something about this topic on my todo, to expose the openssl math functions. They are not the faster on earth but they can then be available by default (as almost all setup has openssl installed).

you were right, it’s the default settings of “precision” affecting this in ALL cases. Setting it to precision=16 (enough to hold 2^53 w/o sign) helps everywhere. The default values (both php.ini-dist and compiled-in) seems to vary but none of these reaches 16. I’ll update the post.

It’s not mentioned at php.net/float and the embedded description in php.ini-dist is, well, not quite clear (”The number of significant digits displayed in floating point numbers”). I believe it’s kept at default 12 as most if not all sites.

Regarding other libraries to deal with big numbers in PHP they have one serious issue – they are rather slow.
Sometimes it does not matter but sometimes it does.

> First of all, I don’t see any strings there.

Peter just made a typo. I explicitly mentioned conversion TO string, in bold.

> in both cases float is expected to lose its precision

No, it’s not. It must not lose precision in THIS case. Refer to IEEE 754 section on 64-bit doubles (it’s a bit more trusted source than php.net/float by the way). Doubles have 52 bits allocated for mantissa, which means that 52-bit (actually 53-bit) INTEGER values MUST be stored without ANY precision loss.

> PHP tries to handle this in a crossplatform way

Even though it tries, it still fails. That failure is unexpected, and undocumented. For me, this is enough of a reason to make a blog post to warn the readers about such caveat.

> To be honest, the whole issue described in this post looks kinda weird: isn’t it obvious that you can’t use 64bit integer values on 32bit platform without a special library/extension?

No, it isn’t (other environments somehow manage to nicely support 64-bit values), but that’s out of scope.

One should be able to manipulate 52-bit integer values stored as doubles without any precision loss. That actually works, and might be a perfectly valid solution in some scenarios. It’s only the float to string conversion which suddenly, and unexpectedly, fails.

>However what Andrew is speaking about is completely different thing – conversion from string.

First of all, I don’t see any strings there.
I can see a float converted to a string in 2 different ways: using “$var” syntax and sprintf(”%.0f”).

Second, in both cases float is expected to lose its precision and the result you get is most likely different from the value it really holds, because that’s the way floats work (surprise!).

And the third thing: even though PHP tries to handle this in a crossplatform way (because it uses its own float-to-string and string-to-float utilities since 5.2 or so, I don’t remember exactly), the resulting value still depends on your system – compiler, CPU etc and may differ.

To be honest, the whole issue described in this post looks kinda weird: isn’t it obvious that you can’t use 64bit integer values on 32bit platform without a special library/extension?
There are at least 3 (three) extensions I know of designed especially for this purpose.
Not enough for the author?

—

Oh, yeah, surely “designers of PHP 5 (released in 2004) type system were either not aware of” long long.
As well as designers of MySQL (released in 1995) never heard of Unicode (released in 1991), eh?