struct _zval_struct { / Variable information / zvalue_value value; / value / zend_uint refcount; zend_uchar type; / active type / zend_uchar is_ref;};
上面的构造中, 实际保存数值本身的是zvalue_value联合体:
typedef union _zvalue_value { long lval; / long value / double dval; / double value / struct { char val; int len; } str; HashTable ht; / hash table value / zend_object_value obj;} zvalue_value;
本日的话题, 我们只关注个中的俩个成员, lval和dval, 我们要意识到, long lval是随着编译器, OS的字长不同而不定长的, 它有可能是32bits或者64bits, 而double dval(双精度)由IEEE 754规定, 是定长的, 一定是64bits.
请记住这一点, 造就了PHP的一些代码的”非平台无关性”. 我们接下来的谈论, 除了特殊指明, 都是假设long为64bits
IEEE 754的浮点计数法, 我这里就不引用了, 大家有兴趣的可以自己查看, 关键的一点是, double的尾数采取52位bit来保存, 算上隐蔽的1位有效位, 一共是53bits.
在这里, 引出一个很故意思的问题, 我们用c代码举例(假设long为64bits):
long a = x; assert(a == (long)(double)a);
叨教, a的取值在什么范围内的时候, 上面的代码可以断言成功?(留在文章末了解答)
现在我们回归正题, PHP在实行一个脚本之前, 首先须要读入脚本, 剖析脚本, 这个过程中也包含着, 对脚本中的字面量进行zval化, 比如对付如下脚本:
<?php$a = 9223372036854775807; //64位有符号数最大值$b = 9223372036854775808; //最大值+1var_dump($a);var_dump($b);
输出:
int(9223372036854775807)float(9.22337203685E+18)
也就说, PHP在词法剖析阶段, 对付一个字面量的数值, 会去判断, 是否超出了当前系统的long的表值范围, 如果不是, 则用lval来保存, zval为IS_LONG, 否则就用dval表示, zval IS_FLOAT.
凡是大于最大的整数值的数值, 我们都要小心, 由于它可能会有精度丢失:
<?php$a = 9223372036854775807;$b = 9223372036854775808;var_dump($a === ($b - 1));
输出是false.
现在接上开头的谈论, 之前说过, PHP的整数, 可能是32位, 也可能是64位, 那么就决定了, 一些在64位上可以运行正常的代码, 可能会由于隐形的类型转换, 发生精度丢失, 从而造成代码不能正常的运行在32位系统上.
以是, 我们一定要当心这个临界值, 好在PHP中已经定义了这个临界值:
<?php echo PHP_INT_MAX; ?>
当然, 为了保险起见, 我们该当利用字符串来保存大整数, 并且采取比如bcmath这样的数学函数库来进行打算.
其余, 还有一个关键的配置, 会让我们产生迷惑, 这个配置便是php.precision, 这配置决定了PHP再输出一个float值的时候, 输出多少有效位.
末了, 我们再来回头看上面提出的问题, 也便是一个long的整数, 最大的值是多少, 才能担保转到float往后再转回long不会发生精度丢失?
比如, 对付整数, 我们知道它的二进制表示是, 101, 现在, 让我们右移俩位, 变成1.01, 舍去高位的隐含有效位1, 我们得到在double中存储5的二进制数值为:
0/符号位/ 10000000001/指数位/ 01000000000000000000000000000000000000000000000000005的二进制表示, 丝毫未损的保存在了尾数部分, 这个情形下, 从double转会回long, 不会发生精度丢失.
我们知道double用52位表示尾数, 算上隐含的首位1, 一共是53位精度.. 那么也就可以得出, 如果一个long的整数, 值小于:
2^53 - 1 == 9007199254740991; //牢记, 我们现在假设是64bits的long
那么, 这个整数, 在发生long->double->long的数值转换时, 不会发生精度丢失.
还有php打算常常碰着的一个问题
<?php $f = 0.58; var_dump(intval($f 100)); //为啥输出57?>
为啥输出是57啊? PHP的bug么?
我相信有很多的同学有过这样的疑问, 由于光问我类似问题的人就很多, 更不用说bugs.php.net上常常有人问…
要搞明白这个缘故原由, 首先我们要知道浮点数的表示(IEEE 754):
浮点数, 以64位的长度(双精度)为例, 会采取1位符号位(E), 11指数位(Q), 52位尾数(M)表示(一共64位).符号位：最高位表示数据的正负，0表示正数，1表示负数。指数位：表示数据以2为底的幂，指数采取偏移码表示尾数：表示数据小数点后的有效数字.这里的关键点就在于, 小数在二进制的表示, 关于小数如何用二进制表示, 大家可以百度一下, 我这里就不再赘述, 我们关键的要理解, 0.58 对付二进制表示来说, 是无限长的值(下面的数字省却了隐含的1)..
0.58的二进制表示基本上(52位)是: 00101000111101011100001010001111010111000010100011110.57的二进制表示基本上(52位)是: 0010001111010111000010100011110101110000101000111101
而两者的二进制, 如果只是通过这52位打算的话,分别是:
0.58 -> 0.579999999999999960.57 -> 0.56999999999999995
至于0.58 100的详细浮点数乘法, 我们不考虑那么细, 有兴趣的可以看(Floating point), 我们就模糊的以心算来看… 0.58 100 = 57.999999999
那你intval一下, 自然便是57了….
可见, 这个问题的关键点便是: “你看似有穷的小数, 在打算机的二进制表示里却是无穷的”
so, 不要再以为这是PHP的bug了, 这便是这样的......
这种情形下如果须要精确打算可以利用bc扩展函数
string bcmul ( string $left_operand , string $right_operand [, int $scale = 0 ] )int bccomp ( string $left_operand , string $right_operand [, int $scale = 0 ] )string bcsqrt ( string $operand [, int $scale = 0 ] )string bcadd ( string $left_operand , string $right_operand [, int $scale = 0 ] )string bcdiv ( string $dividend , string $divisor [, int $scale = 0 ] )string bcmod ( string $dividend , string $divisor [, int $scale ] )string bcpow ( string $base , string $exponent [, int $scale = 0 ] )string bcsub ( string $left_operand , string $right_operand [, int $scale = 0 ] )int bcscale ([ int $scale ] )string bcpowmod ( string $base , string $exponent , string $modulus [, int $scale = 0 ] )
