zoukankan      html  css  js  c++  java
  • chrome的javascript 中的一个奇怪现象,引申到javascript的interger存储机制,ECMA standerd script的int engine分析

    首先看看这个帖子:  

    JavaScript Integer math incorrect results http://stackoverflow.com/questions/3428136/javascript-integer-math-incorrect-results

    这里,这位老兄试图使用119106029 * 1103515245这两个超大整数相乘,结果自然不言而喻,出错了。首先我们想到的都是:是不是overflow的呢?

    查看javascript官网的documentation,我了解到在javascript中最大整数用 Number.MAX_VALUE 表示,我的机器是32位操作系统,在chrome的console中打印这个变量,得到的值是 1.7976931348623157e+308 ,那么是不是说因为 119106029 * 1103515245 =131435318772912110 < 1.7976931348623157e+308 就可以说不是overflow导致的这个问题呢?

    从上面的链接看到的帖子解释中,我们看到这样一段话:When an integer in javascript is too big to fit in a 32 bit value, some browsers will convert it to a floating point. Since the value of floating points is only save to a limited precision, some rounding can occur on big values.

    那么我们又会发出这样的疑问,什么是some browsers 呢?有哪些呢?做实验吧孩子!

    在chrome的console中,我们输入以下代码:

    console.log(16384648710428869);

    看看chrome返回给我们什么?

    16384648710428868  !!

    但是当我们输入:

    console.log(16384648710428868);

    chrome返回的就是:

    16384648710428868

    这从一个侧面反映出,上面这位大哥所说的some browsers 中,肯定包含了chrome,正因为其处理16384648710428869时使用了float point,故导致了rounding(舍入),造成值错误,ECMA还是要优化啊!


    firefox、opera、Safari等浏览器还留给大家自己下去实验哦!


    这里附上 【Firebug & Chrome Console 控制台使用指南】 http://yangguoklose.iteye.com/blog/1250590

    关于ECMA script内部int存储机制的分析,未完待续。

  • 相关阅读:
    leetcode204-统计质数个数之一步步调试超时
    SpringBoot-注解一句话
    算法-总结规律
    kafka-版本变更相关
    异步线程池如何做同步业务
    es-快捷DSL检索手记
    并发学习第七篇——ThreadPoolExecutor
    kafka-consumer端的设计细节
    kafka-producer使用总结
    kafka-topic重要配置分析
  • 原文地址:https://www.cnblogs.com/gameboy90/p/2264748.html
Copyright © 2011-2022 走看看