Java解惑

今天看了份文档<JAVA解惑>, 里面的描述了些挺有趣的问题, 在此列出部分, 分享分享。


(1)public static boolean isOdd(int i){
      return i % 2 == 1;   //取奇数
}
结果会如何呢?  嘿嘿 ,自己想…………(提示一下,千万别忘了int类型有 负数哟)


(2)Tom在一家汽车配件商店购买了一个价值$1.10的火花塞,但是他钱包中都是两美元一张的钞票。如果他用一张两美元的钞票支付这个火花塞,那么应该找给他多少零钱呢? 解决方案:
public class Change{
      public static void main(String args[]){
            System.out.println(2.00 - 1.10);
      }
}
呵呵,如果认识你天真的认为程序会为你打印出0.90,那就大错特错了
问题在于1.1这个数字不能被精确表示成为一个double,因此它被表示成为最接近它的double值。该程序从2中减去的就是这个值。遗憾的是,这个计算的结果并不是最接近0.9的double值。表示结果的double值的最短表示就是你所看到的打印出来的那个可恶的数字。

更一般地说,问题在于并不是所有的小数都可以用二进制浮点数来精确表示的

浮点运算在一个范围很广的值域上提供了很好的近似,但是它通常不能产生精确的结果。二进制浮点对于货币计算是非常不适合的,因为它不可能将0.1——或者10的其它任何次负幂——精确表示为一个长度有限的二进制小数  

解决该问题的一种方式是使用某种整数类型,例如int或long,并且以分为单位来执行计算。如果你采纳了此路线,请确保该整数类型大到足够表示在程序中你将要用到的所有值。对这里举例的谜题来说,int就足够了。下面是我们用int类型来以分为单位表示货币值后重写的println语句。这个版本将打印出正确答案90分:
System.out.println((200 - 110) + "cents");

解决该问题的另一种方式是使用执行精确小数运算的BigDecimal。它还可以通过JDBC与SQL DECIMAL类型进行互操作。这里要告诫你一点: 一定要用BigDecimal(String)构造器,而千万不要用BigDecimal(double)。后一个构造器将用它的参数的“精确”值来创建一个实例:new BigDecimal(.1)将返回一个表示0.100000000000000055511151231257827021181583404541015625的BigDecimal。通过正确使用BigDecimal,程序就可以打印出我们所期望的结果0.90:
import java.math.BigDecimal;
public class Change1{
      public static void main(String args[]){
            System.out.println(new BigDecimal("2.00").
            subtract(new BigDecimal("1.10")));
      }
}

这个版本并不是十分地完美,因为Java并没有为BigDecimal提供任何语言上的支持。使用BigDecimal的计算很有可能比那些使用原始类型的计算要慢一些,对某些大量使用小数计算的程序来说,这可能会成为问题,而对大多数程序来说,这显得一点也不重要。

总之,  在需要精确答案的地方,要避免使用float和double;对于货币计算,要使用int、long或BigDecimal。对于语言设计者来说,应该考虑对小数运算提供语言支持。一种方式是提供对操作符重载的有限支持,以使得运算符可以被塑造为能够对数值引用类型起作用,例如BigDecimal。另一种方式是提供原始的小数类型,就像COBOL与PL/I所作的一样。


谜题3:长整除
这个程序会打印出什么呢?
public class LongDivision{
      public static void main(String args[]){
            final long MICROS_PER_DAY = 24 * 60 * 60 * 1000 * 1000;
            final long MILLIS_PER_DAY = 24 * 60 * 60 * 1000;
            System.out.println(MICROS_PER_DAY/MILLIS_PER_DAY);
      }
}

除数和被除数都在long的范围内,似乎一切都很顺利,结果毫无疑问是1000~
但运行一看,结果是5,为何
问题在于常数MICROS_PER_DAY的计算“确实”溢出了尽管计算的结果适合放入long中,并且其空间还有富余,但是这个结果并不适合放入int中。这个计算完全是以int运算来执行的,并且只有在运算完成之后,其结果才被提升到long,而此时已经太迟了:计算已经溢出了,它返回的是一个小了200倍的数值。

为什么计算会是以int运算来执行的呢?因为所有乘在一起的因子都是int数值 。当你将两个int数值相乘时,你将得到另一个int数值。Java不具有目标确定类型的特性,这是一种语言特性,其含义是指存储结果的变量的类型会影响到计算所使用的类型。
通过使用long常量来替代int常量作为每一个乘积的第一个因子,我们就可以很容易地订正这个程序:
public class LongDivision{
      public static void main(String args[ ]){
            final long MICROS_PER_DAY = 24L * 60 * 60 * 1000 * 1000;
            final long MILLIS_PER_DAY = 24L * 60 * 60 * 1000;
            System.out.println(MICROS_PER_DAY/MILLIS_PER_DAY);
      }
}
这个教训很简单:当你在操作很大的数字时,千万要提防溢出——它可是一个缄默杀手 。即使用来保存结果的变量已显得足够大,也并不意味着要产生结果的计算具有正确的类型。当你拿不准时,就使用long运算来执行整个计算。

今天暂时看到这,明天继续~~





你可能感兴趣的:(java,sql,jdbc,cobol)