The usual arithmetic operators + – * / are used in Java for addition, subtraction, multiplication, and division. The / operator denotes integer division if both arguments are integers, and floating-point division otherwise. Integer remainder (sometimes called modulus) is denoted by %. For example, 15 / 2 is 7, 15 % 2 is 1, and 15.0 / 2 is 7.5.
通常的算术运算符+ – * /在Java中用来进行加，减，乘，除。当两个操作数都是整数时，运算符/表示整数除法，其他情况表示浮点除法。整数余数（有时也叫模数）用%表示。例如，15 / 2 等于 7, 15 % 2 等于 1, 而 15.0 / 2 等于 7.5。
Note that integer division by 0 raises an exception, whereas floating-point division by 0 yields an infinite or NaN result.
注意整数除法中0作除数将导致异常，而浮点除法中用0作除法将产生无穷或者NaN的结果。
There is a convenient shortcut for using binary arithmetic operators in an assignment. For example,
在一条赋值语句中有一个使用二元算术运算的捷径。例如：
x += 4;
is equivalent to
等效于
x = x + 4;
(In general, place the operator to the left of the = sign, such as *= or %=.)
（总之，就是把运算符放在等号的左边，例如*= 或者 %= 。）
NOTE注释
One of the stated goals of the Java programming language is portability. A computation should yield the same results no matter which virtual machine executes it. For arithmetic computations with floating-point numbers, it is surprisingly difficult to achieve this portability. The double type uses 64 bits to store a numeric value, but some processors use 80-bit floating-point registers. These registers yield added precision in intermediate steps of a computation. For example, consider the computation:
Java编程语言的一个初衷就是可移植性。对于一个运算应该产生相同的结果，无论何种虚拟机执行该运算。对于浮点数参与的算术运算，要实现这种可移植性是惊人的困难的。双精度类型的用64位存储一个数值，但是一些处理器使用的是80位浮点寄存器。这些寄存器在中等级别的计算中产生额外的精度。例如，考虑如下计算：
double w = x * y / z;
Many Intel processors compute x * y and leave the result in an 80-bit register, then divide by z and finally truncate the result back to 64 bits. That can yield a more accurate result, and it can avoid exponent overflow. But the result may be different from a computation that uses 64 bits throughout. For that reason, the initial specification of the Java virtual machine mandated that all intermediate computations must be truncated. The numeric community hated it. Not only can the truncated computations cause overflow, they are actually slower than the more precise computations because the truncation operations take time. For that reason, the Java programming language was updated to recognize the conflicting demands for optimum performance and perfect reproducibility. By default, virtual machine designers are now permitted to use extended precision for intermediate computations. However, methods tagged with the strictfp keyword must use strict floating-point operations that yield reproducible results. For example, you can tag main as
许多Intel处理器计算x*y并将结果存放于80位的寄存器中，然后除以z并最终将结果省略成64位的。那可以产生更为精确的结果，并可以避免指数溢出。但是完全使用64位计算将可能产生不同的结果。由于那个原因，起初Java虚拟机规格规定所有中间运算必须被舍掉多余的精度。数字团体厌恶这种处理方式。舍去操作不仅会引起溢出，而且由于舍去操作需要占用时间而花费了比精确计算更多的时间。由此，Java编程语言进行了升级，考虑了最适宜的性能和完美的再现性这两个互相冲突的要求。现在虚拟机设计者被许可使用扩展精度于中间级运算中。但是使用关键字strictfp标明的方法必须使用严格的浮点操作以产生有复验性的结果，例如，你可以标记main方法如下：
public static strictfp void main(String[] args)
Then all instructions inside the main method use strict floating-point computations. If you tag a class as strictfp, then all of its methods use strict floating-point computations.
于是main方法中的所有指令都采用严格的浮点运算。如果你标记一个类为strictfp，那么该类的所有方法都将使用严格的的浮点计算。
The gory details are very much tied to the behavior of the Intel processors. In default mode, intermediate results are allowed to use an extended exponent, but not an extended mantissa. (The Intel chips support truncation of the mantissa without loss of performance.) Therefore, the only difference between default and strict mode is that strict computations may overflow when default computations don't.
详细资料非常依赖于Intel处理器的表现。在默认模式下，中间结果被许可使用扩展指数，但不能使用扩展尾数。（Intel芯片支持不影响性能的情况下舍去尾数。）因此，默认模式和严格模式唯一的不同是严格计算可能引起溢出而默认模式不会。
If your eyes glazed over when reading this note, don't worry. Floating-point overflow isn't a problem that one encounters for most common programs. We don't use the strictfp keyword in this book.
如果阅读此注释时你的眼睛变得迟钝，不要紧。浮点溢出对大多数普通编程而言并不是个能遇到的问题。在本书中我们不使用strictfp关键字。（汗：你既然用不着，说这么一大堆废话干啥？害得老子翻译了足足一个小时，还稀里糊涂的。）
文章来源: http://x-spirit.spaces.live.com/Blog/cns!CC0B04AE126337C0!304.entry