let r = 1
while (n) {
r *= n
n--
}
return r
}
let getSum = n => {
let r = 0
while (n) {
r += getJC(n)
n--
}
return r
}
console.log(getJC(3))
console.log(getSum(3))
1、DOM深入3、DOM访问
4、属性访问和设置
5、节点关系
6、子节点属性childNodes
7、firstChild和lastChild属性
8、parentNode属性
9、nextSibling和prevSibling属性
10、节点操作
11、创建节点和上树
12、移动节点
13、删除节点 removeChild()方法
14、替换节点 replaceChild()方法
15、克隆节点 cloneNode()方法
16、jQuery中的节点操作
17、创建节点
18、上树的8种方法
19、wrap()和unwrap()、wrapAll()
20、replaceWith()和replaceAll()方法
21、empty()和remove()方法
22、clone()方法
23、拼图轮播
1、事件流
2、事件流概述
3、DOM0级事件监听方法
4、DOM2级事件监听
5、低版本IE的事件添加
6、事件绑定小轮子
7、event事件对象
8、IE6、7、8的兼容问题
9、通用属性
10、阻止事件冒泡
11、阻止默认事件
12、讲解三个案例
13、鼠标位置
2、原生JS的元素位置和尺寸
3、认识offsetParent
4、offsetTop和offsetLeft
5、在页面中的净位置
6、clientWidth、clientHeight、offsetWidth、offsetWidth
7、拖拽
8、去掉监听
9、jQuery中的事件
10、jQuery中的同名事件是不会覆盖的
11、$(document).ready()
12、jQuery的事件相关方法
2、鼠标滚轮事件
3、Onmousewheel
4、火狐中的鼠标滚轮事件
5、滚轮的滚动方向与速度
6、区别
7、onscroll事件
8、页面的卷动值
10、头像裁剪布局
11、键盘事件
12、键盘对象
13、fromCharCode
1、ECMA中的数据类型
2、对象
3、delete关键字
4、如何快速创建相似对象
5、构造函数
6、方法和属性
7、原型
8、hasOwnProperty方法
9、instanceof关键字
10、继承
11、构造函数式继承
12、类式继承
13、组合式继承
这是一个大概的流程，想要学习完整的内容可以进群前面是2九六中间是5九一后边是29零，希望可以帮助到你。
这一篇真的要说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进制小数就不会有转不尽的情况了。
以上全部，仅代表个人观点。
