The size of integers in PHP is platform dependent.
The size of an integer is platform-dependent, although a maximum value of about two billion is the usual value (that's 32 bits signed). 64-bit platforms usually have a maximum value of about 9E18. PHP does not support unsigned integers. Integer size can be determined using the constant PHP_INT_SIZE, and maximum value using the constant PHP_INT_MAX since PHP 4.4.0 and PHP 5.0.5.
The size of floats, is also platform dependent:
The size of a float is platform-dependent, although a maximum of ~1.8e308 with a precision of roughly 14 decimal digits is a common value (the 64 bit IEEE format).
and there's a big red warning in the manual about float precision:
Floating point numbers have limited precision. Although it depends on the system, PHP typically uses the IEEE 754 double precision format, which will give a maximum relative error due to rounding in the order of 1.11e-16. Non elementary arithmetic operations may give larger errors, and, of course, error progragation must be considered when several operations are compounded.
Additionally, rational numbers that are exactly representable as floating point numbers in base 10, like 0.1 or 0.7, do not have an exact representation as floating point numbers in base 2, which is used internally, no matter the size of the mantissa. Hence, they cannot be converted into their internal binary counterparts without a small loss of precision. This can lead to confusing results: for example, floor((0.1+0.7)*10) will usually return 7 instead of the expected 8, since the internal representation will be something like 7.9999999999999991118....
The BC Math extension bypasses the dependencies, allowing you to explicitly specify a large integer as a string, and avoid PHP's interpretation of integer literals. The GMP functions are also good alternatives and work in similar fashion. We can safely assume that any size
refers to the maximum size of strings, which is only limited by available memory:
It is no problem for a string to become very large. PHP imposes no boundary on the size of a string; the only limit is the available memory of the computer on which PHP is running.
Whether it makes sense or not can only be decided on a per case basis. I've never noticed any actual performance issues with the extension's functions, but most certainly they aren't as fast as native alternatives.
Is it really necessary?
It's only necessary when it is, but that's not always obvious. You can easily identify blatant abuse, but can't as easily argue on more complex scenarios.
Discuss with your colleague, and find out why he uses them everywhere. Overflows lead to extremely ugly situations, ones that I find quite difficult to identify and solve. If he's abusing BC Math, it might be just because he got horribly stuck once and tries to play it as safe as possible. Although there's nothing inherently wrong with using BC Math, the otherwise insignificant performance penalty may be a serious issue in several scenarios. If you notice any performance issue, make sure you profile your application and be certain that's BC Math related.
Always remember that your calculations should work correctly:
- On every system you're targeting, individual developer machines and (of course) production machine included.
- Regardless of possible system/platform upgrades or downgrades.
In multi platform development you should always consider the lowest limit as a hard limit. If you are absolutely certain that your calculations will not go over the limits (including their results), then there's no point in using BC Math.
But if what you're describing is that he prefers echo bcadd("1", "2");
over echo 1+2;
, well, good luck!
I found an extremely interesting & relevant blog post in my huge list of bookmarks, Integers in PHP, running with scissors, and portability, on Percona's MySQL Performance blog. It's old (2007) but it gives a good overview of various snafus with integer portability in PHP.