关于PHP浮点数之 intval((0.1+0.7)*10) 为什么是7

PHP是一种弱类型语言, 这样的特性, 必然要求有无缝透明的隐式类型转换, PHP内部使用zval来保存任意类型的数值, zval的结构如下(5.2为例):

  1. struct _zval_struct {
  2. /* Variable information */
  3. zvalue_value value; /* value */
  4. zend_uint refcount;
  5. zend_uchar type; /* active type */
  6. zend_uchar is_ref;
  7. };

上面的结构中, 实际保存数值本身的是zvalue_value联合体:

  1. typedef union _zvalue_value {
  2. long lval; /* long value */
  3. double dval; /* double value */
  4. struct {
  5. char *val;
  6. int len;
  7. } str;
  8. HashTable *ht; /* hash table value */
  9. zend_object_value obj;
  10. } 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):

  1. long a = x;
  2. assert(a == (long)(double)a);

请问, a的取值在什么范围内的时候, 上面的代码可以断言成功?(留在文章最后解答)

现在我们回归正题, PHP在执行一个脚本之前, 首先需要读入脚本, 分析脚本, 这个过程中也包含着, 对脚本中的字面量进行zval化, 比如对于如下脚本:

  1. <?php
  2. $a = 9223372036854775807; //64位有符号数最大值
  3. $b = 9223372036854775808; //最大值+1
  4. var_dump($a);
  5. var_dump($b);

输出:

  1. int(9223372036854775807)
  2. float(9.22337203685E+18)

也就说, PHP在词法分析阶段, 对于一个字面量的数值, 会去判断, 是否超出了当前系统的long的表值范围, 如果不是, 则用lval来保存, zval为IS_LONG, 否则就用dval表示, zval IS_FLOAT.

凡是大于最大的整数值的数值, 我们都要小心, 因为它可能会有精度损失:

  1. <?php
  2. $a = 9223372036854775807;
  3. $b = 9223372036854775808;
  4. var_dump($a === ($b - 1));

输出是false.

现在接上开头的讨论, 之前说过, PHP的整数, 可能是32位, 也可能是64位, 那么就决定了, 一些在64位上可以运行正常的代码, 可能会因为隐形的类型转换, 发生精度丢失, 从而造成代码不能正常的运行在32位系统上.

所以, 我们一定要警惕这个临界值, 好在PHP中已经定义了这个临界值:

  1. <?php
  2. echo PHP_INT_MAX;
  3. ?>

当然, 为了保险起见, 我们应该使用字符串来保存大整数, 并且采用比如bcmath这样的数学函数库来进行计算.

另外, 还有一个关键的配置, 会让我们产生迷惑, 这个配置就是php.precision, 这配置决定了PHP再输出一个float值的时候, 输出多少有效位.

最后, 我们再来回头看上面提出的问题, 也就是一个long的整数, 最大的值是多少, 才能保证转到float以后再转回long不会发生精度丢失?

比如, 对于整数, 我们知道它的二进制表示是, 101, 现在, 让我们右移俩位, 变成1.01, 舍去高位的隐含有效位1, 我们得到在double中存储5的二进制数值为:

  1. 0/*符号位*/ 10000000001/*指数位*/ 0100000000000000000000000000000000000000000000000000

5的二进制表示, 丝毫未损的保存在了尾数部分, 这个情况下, 从double转会回long, 不会发生精度丢失.

我们知道double用52位表示尾数, 算上隐含的首位1, 一共是53位精度.. 那么也就可以得出, 如果一个long的整数, 值小于:

  1. 2^53 - 1 == 9007199254740991; //牢记, 我们现在假设是64bits的long

那么, 这个整数, 在发生long->double->long的数值转换时, 不会发生精度丢失.

  1. <?php
  2. $f = 0.58;
  3. var_dump(intval($f * 100)); //为啥输出57
  4. ?>

为啥输出是57啊? PHP的bug么?

我相信有很多的同学有过这样的疑问, 因为光问我类似问题的人就很多, 更不用说bugs.php.net上经常有人问…

要搞明白这个原因, 首先我们要知道浮点数的表示(IEEE 754):

浮点数, 以64位的长度(双精度)为例, 会采用1位符号位(E), 11指数位(Q), 52位尾数(M)表示(一共64位).

符号位:最高位表示数据的正负,0表示正数,1表示负数。

指数位:表示数据以2为底的幂,指数采用偏移码表示

尾数:表示数据小数点后的有效数字.

这里的关键点就在于, 小数在二进制的表示, 关于小数如何用二进制表示, 大家可以百度一下, 我这里就不再赘述, 我们关键的要了解, 0.58 对于二进制表示来说, 是无限长的值(下面的数字省掉了隐含的1)..

  1. 0.58的二进制表示基本上(52位)是: 0010100011110101110000101000111101011100001010001111
  2. 0.57的二进制表示基本上(52位)是: 0010001111010111000010100011110101110000101000111101

而两者的二进制, 如果只是通过这52位计算的话,分别是:

  1. 0.58 -> 0.57999999999999996
  2. 0.57 -> 0.56999999999999995

至于0.58 * 100的具体浮点数乘法, 我们不考虑那么细, 有兴趣的可以看(Floating point), 我们就模糊的以心算来看… 0.58 * 100 = 57.999999999

那你intval一下, 自然就是57了….

可见, 这个问题的关键点就是: “你看似有穷的小数, 在计算机的二进制表示里却是无穷的”

so, 不要再以为这是PHP的bug了, 这就是这样的…..

时间: 2024-10-13 04:37:00

关于PHP浮点数之 intval((0.1+0.7)*10) 为什么是7的相关文章

Python保留浮点数位数和整数补0的方法

最简单的格式如下: a=1.333333344,将这个数保存为小数点后3位 '%.03f'%a 不过这样做返回的结果会变成一个字符串,显示为: p.p1 { margin: 0.0px 0.0px 0.0px 0.0px; font: 14.0px Courier; background-color: #ffffff } span.s1 { } '1.333' 所以只要再在前面加个float()即可返回正常浮点数,即: float('%.03f'%a) 但如果输入 '%03f'%a 这里没有了那

自写小函数处理 javascript 0.3*0.2 浮点类型相乘问题

const reg = /^([0-9]+)\.([0-9]*)$/; // 判断是不是浮点数 const isFloat = function(number){ return reg.test(number); } // 去除小数点转为整数 const floatToInt = function(head,tail){//head:String tail:String // head和tail都是字符串 Number("005")可以去零 let result = head + Nu

0.1 + 0.2 = 0.30000000000000004怎样理解

如果你以前没了解过类似的坑,乍一看似乎觉得不可思议.但是某些语言下事实确实如此(比如 Javascript): 再看个例子,+1 后居然等于原数,没天理啊! 如果你不知道原因,跟着楼主一起来探究下精度丢失的过程吧. 事实上不仅仅是 Javascript,在很多语言中 0.1 + 0.2 都会得到 0.30000000000000004,为此还诞生了一个好玩的网站 0.30000000000000004.究其根本,这些语言中的数字都是以IEEE 754 双精度 64 位浮点数 来存储的,它的表示格

0.1+0.2 ! = 0.3?

解释一下下面代码的输出 ? 1 2 console.log(0.1 + 0.2); //0.30000000000000004 console.log(0.1 + 0.2 == 0.3); //false JavaScript 中的 number 类型就是浮点型,JavaScript 中的浮点数采用IEEE-754 格式的规定,这是一种二进制表示法,可以精确地表示分数,比如1/2,1/8,1/1024,每个浮点数占64位.但是,二进制浮点数表示法并不能精确的表示类似0.1这样 的简单的数字,会有

JS魔法堂:彻底理解0.1 + 0.2 === 0.30000000000000004的背后

Brief 一天有个朋友问我“JS中计算0.7 * 180怎么会等于125.99999999998,坑也太多了吧!”那时我猜测是二进制表示数值时发生round-off error所导致,但并不清楚具体是如何导致,并且有什么方法去规避.于是用了3周时间静下心把这个问题搞懂,在学习的过程中还发现不仅0.7 * 180==125.99999999998,还有以下的坑 1. 著名的 0.1 + 0.2 === 0.30000000000000004 2. 1000000000000000128 ===

关于 -128 ,+128,-0,+0,-1,+1 的反码补码

一.反码的范围 反码表示法规定:正数的反码与其原码相同.负数的反码是对其原码逐位取反,但符号位除外. 在规定中,8位二进制码能表示的反码范围是-127~127. -128没有反码. 那么,为什么规定-128没有反码呢?下面解释. 首先看-0,[-0]原码=1000 000,其中1是符号位,根据反码规定,算出[-0]反码=1111 1111, 再看-128,[-128]原码=1000 000,假如让-128也有反码,根据反码规定,则[-128]反码=1111 1111, 你会发现,-128的反码和

为什么0.1+0.2=0.30000000000000004

浮点数运算 你使用的语言并不烂,它能够做浮点数运算.计算机天生只能存储整数,因此它需要某种方法来表示小数.这种表示方式会带来某种程度的误差.这就是为什么往往 0.1 + 0.2 不等于 0.3. 为什么会这样? 实际上很简单.对于十进制数值系统(就是我们现实中使用的),它只能表示以进制数的质因子为分母的分数.10 的质因子有 2 和 5.因此 1/2.1/4.1/5.1/8和 1/10 都可以精确表示,因为这些分母只使用了10的质因子.相反,1/3.1/6 和 1/7 都是循环小数,因为它们的分

原来 0.1*0.2!=0.02

今天老大一本正经的跟我说要交给我一个重大任务.解决关于0.1*0.2的问题. 0.1*0.2不就等于0.02吗??!!一个小学生都知道的答案,但是程序告诉你0.1*0.2并不是0.02. 事实上,不仅仅是 JS,在其他采用 IEEE754 浮点数标准的语言中,0.1 * 0.2 都不会等于 0.02,0.1+0.2也不会等于0.3,就是这样. 如果以后有人问你0.1+0.2 等于多少,0.1*0.2等于多少可别被坑了,就是这么神奇. 更神奇的是,9007199254740992+1=900719

JavaScript中的两个“0” -0和+0

JavaScript中的两个"0"(翻译) 本文翻译自JavaScript's two zeros JavaScript has two zeros: ?0 and +0. This post explains why that is and where it matters in practice. JavaScript 中有两个"0": -0 和 +0 .这篇文章解释了为什么,并且指出实际生产中会造成什么影响 1.The signed zero 1."