<html>
<head>
<meta charset="UTF-8">
<title>两数区间求和</title>
<style type="text/css">
.resCls{
width: 100%
height: auto
border: solid 1px #ddd
word-break: break-all /* 允许任意非CJK(Chinese/Japanese/Korean)文本间的单词断行 */
word-wrap: break-word /* 允许英文单词内断句换行 */
box-shadow: 4px 6px 8px #ccc
}
input{
box-shadow: 2px 4px 6px #ccc
width: 80px
}
p{
text-shadow: 4px 3px 4px #678
}
</style>
<script src="jquery-1.8.3.min.js"></script>
</head>
<body>
<p>输入两个非负整数：</p>
<input type="text" id="tx0" value="0" />
<input type="text" id="tx1" value="130" />
<input type="button" value=" 求和 " onclick="getSum()"/>
<br><br>
<span id="sum0"></span>
<div id="sum"></div>
<script>
$(function(){
//0~9的keyCode: 主键区48~57 , keyup/keydown:数字小键盘96~105 , keypress:全同
$("#tx0").bind("keypress",function(e){
if(!(e.keyCode>47 && e.keyCode<58)){
return false
}
})
$("#tx1").bind("keypress",function(e){
if(!(e.keyCode>47 && e.keyCode<58)){
return false
}
})
})
function getSum(){
var int0=Number($("#tx0").val())
var int1=Number($("#tx1").val())
if(isNaN(int0)){ //如果为“非数值”
return
}
if(isNaN(int1)){
return
}
var sum=0
var process=""
if(int0<int1){
for(var i=int0i<=int1i++){
sum+=i
process+=i+"+"
}
}else{
for(var i=int1i<=int0i++){
sum+=i
process+=i+"+"
}
}
process=process.substring(0,process.lastIndexOf("+"))+" = "
$("#sum").text(process + sum).addClass("resCls")
}
</script>
</body>
</html>
这一篇真的要说0.1 + 0.2 了。。
先来一个计算题来热热身吧。
我知道你想怎么做：362500 + 314 = 362814。没错，是这样算的，再来一个。
还用刚才的办法吗？还是算了吧，实在太长了，换一种办法：
运算法则不用多说了吧，这种方法还是很简单的，IEEE754浮点数也是使用这种办法计算的加法的，准确来说，是计算机中所有种类的浮点数都是这么计算加法的，因为浮点数标准可不只有IEEE一家才有。
现在借用工具把 0.1 和 0.2 的 64位浮点数格式表示出来。
图中上面的64位浮点数代表0.1，下面的64位浮点数代表0.2（ 注意，因为计算时肯定是拿的内存中的值，所以此时的0.1 和 0.2 都是经过存储前舍入处理的了 ），并且已经列出了加法计算的5个步骤：
一. 阶码对阶
二. 尾数相加
三. 结果规格化
四. 尾数舍入处理
五. 溢出判断
那就按照顺序来一一说明。
首先，要把指数位（阶码）调整成一致才能计算加法，但是和开篇的计算题不同的是，这里规定必须是 小阶向大阶看齐 。
很明显，0.1的阶码比0.2的要小，所以0.1的尾数（小数位）向右移动一位，同时阶码 + 1。
点击下一步后如下所示：
因为阶码部分暂时已经确定，所以拿出来单独显示。
这一步比较简单，就是使用加法器把两个值相加，结果如下图所示。
还记得规格化是什么东西吗，联想一下科学计数法，计算后的尾数需要变成1.xxxx的形式，通过尾数的右移动来实现规格化，整体右移一位，阶码 +1。本案例中需要右移一位即可，所以阶码 +1。
舍入规则同第四章所说一致，可以返回 《JS基础-数字-0.1+0.2!=0.3（四）》 查看，当前命中了五取偶。
由于符合舍入规则五取偶中的 “如果X的值为1，则进1”，所以进1
溢出判断规则：
本案例没有命中溢出，所以不需要处理。
对比一下真正的0.3存入内存时的64位浮点数是什么样的:
细心的同学应该发现了其中的不同，0.1 + 0.2 的最终结果和 0.3 相比，在最后一位多进了一个1。这也就是为什么他们不相等的原因，0.1 + 0.2 已经不是 0.3 了。
首先，每一个IEEE754浮点编码都必须对应一个唯一的10进制的值，这是必须的，因为IEEE754没有规定每一个编码转化成的10进制的值必须是多少，但是却规定， 一个IEEE754浮点编码转化成10进制的值不做绝对限制，但当这个10进制的值在转化回IEEE754浮点编码时，必须还能还原成之前的IEEE754浮点编码。
如果 IEEE754浮点编码 0011111111010011001100110011001100110011001100110011001100110011 和 0011111111010011001100110011001100110011001100110011001100110100 都代表了0.3，那么当我存储0.3时，要转化成这两个编码的哪一个呢？
其次，如果如你所想的这么干了，0.3 占用了2个编码，其他的不精准情况是不是也要占用多个编码啊？（比如： 0.2 + 0.4 = 0.6000000000000001 等等）这种情况很常见，都这么干， IEEE754浮点编码一共才拥有 18437736874454810627（即，264 - 253 + 3）个值，将会有多少无效的编码掺杂其中。
最后，如果有个JS开发人员就想存 0.30000000000000004 这个值，为啥不让人家存啊， 0.30000000000000004 招谁惹谁了，它也是IEEE754 64位浮点编码的合法公民啊。
无论舍入界限值设置为多少，总会有这个值附近的倒霉蛋赶上。所以我现在只能使用《你不知道的JavaScript （中卷）》19页的最上面的话回复你：
看来我们能做的只有了解它，并且小心使用。
请不要以JavaScript的数值精度问题为借口来贬低这门语言，如果你这么做了，只能说明你还不懂爱情。
作为开发人员，针对小数的存储和运算问题不能怪罪IEEE754，因为误差不是IEEE754特有的，而是二进制浮点数表示方法引起的。怪罪2进制浮点数也不合适，因为计算机是2进制的。计算机也很冤枉，因为科学已经证实自然常数E（约等于2.718281828459045）进制的计算机执行效率最高，与之最近的只能是2和3，2进制计算机的物理原件相比于3进制更容易制造。即便普及的是3进制计算机，10进制小数依然无法完全转化。
如果你非要找个替罪羔羊泄愤，那只能拿锤子砸自己的手了，因为如果人类生来就只有8个手指头，习惯于使用8进制，转化成2进制小数就不会有转不尽的情况了。
以上全部，仅代表个人观点。
