可以直接将数字进行计算
function Add(num1,num2){return (num1+num2)//返回num1和num2的和
//return (num1-num2)//返回num1和num2的差
//return (num1*num2)//返回num1和num2相乘结果
//return (num1/num2)//返回num1和num2相除结果
}
返回由字符串转换得到的整数。
parseInt(numString, [radix])
参数：numString 必选项。要转换为数字的字符串。
radix 可选项。在 2 和 36 之间的表示 numString 所保存数字的进制的值。如果没有提供，则前缀为 '0x' 的字符串被当作十六进制，前缀为 '0' 的字符串被当作八进制。所有其它字符串都被当作是十进制的。
说明 ：parseInt 方法返回与保存在 numString 中的数字值相等的整数。如果 numString 的前缀不能解释为整数，则返回 NaN（而不是数字）。
parseInt("abc") // 返回 NaN。
parseInt("12abc") // 返回 12。
可以用 isNaN 方法检测 NaN。
-----------------------------
floor 返回不大于的最大整数
round 则是4舍5入的计算，入的时候是到大于它的整数
ceil 则是不小于他的最小整数
数字因为js只有number这一种类型，包含整数和浮点数。
运算符有算术运算符、操作运算符、比较运算符、和逻辑运算符。
我最近再用的一个很好用的application, 叫实验楼，里面做了很详细明了的归类，故搬运过来。
①算数运算符
②操作运算符
③比较运算符
④逻辑运算符
⑤运算符的优先级
这一篇真的要说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进制小数就不会有转不尽的情况了。
以上全部，仅代表个人观点。
