Java FAQ Notes (i)

"Java doubts" are some of the programming is easy to ignore the details, but also quite interesting, so the contents of the inside a little to sort out, briefly summed up:

1. Odd sex

At the time of programming often encounter to determine whether the parameters passed in is odd, and it is easy to assume that the remainder is 1 can be determined, the following code:

public static Boolean isodd (int i) {

return I% 2 = = 1

}

The procedure returned in One-fourth of the time is the wrong answer.

Because half of all int values are negative, and the IsOdd method fails to judge all negative odd numbers. Calling the method on any negative integer returns false, regardless of whether the integer is even or odd. This is the result of Java's definition of the remainder operator (%). The operator is defined to satisfy the following identities for all int values A and all non-0 int value B:
(A/b) * + (a% b) = = A

When I is a negative odd number, I% 2 equals-1 instead of 1, so the IsOdd method returns false incorrectly.

The question is easy to revise. Simply compare the I% 2 with 0 instead of 1 and reverse the meaning of the comparison:
public static Boolean isodd (int i) {
return I% 2! = 0;
}

2. Change Time

Consider the problem described in the following paragraph:
Tom buys a spark plug that is worth $1.10 in a car parts store, but he has a $ two note in his wallet. If he pays the spark plug with a $ two bill, how much change should he get? Here is a program that tries to solve the above problem, what does it print?
public class change{
public static void Main (String args[]) {
System.out.println (2.00-1.10);
}
}

The result of this code output is not what we expected 0.9, but 0.899999999999. The problem is that not all decimals can be accurately represented by binary floating-point numbers . Floating-point arithmetic provides a good approximation on a wide range of domains, but it usually does not produce accurate results. Binary floating-point is very inappropriate for currency calculations because it is not possible to accurately represent 0.1--or any other negative power of 10 as a finite binary fraction of a length.

To solve this problem, you can use the BigDecimal that performs the exact decimal operation. Note: Be sure to use the BigDecimal (String) constructor, and never use BigDecimal (double) . Using BigDecimal correctly, the program can print out the results we expect 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"));
}
}

In summary, avoid the use of float and double in places where precise answers are needed, and use int, long, or bigdecimal for currency calculations. For language designers, you should consider providing language support for decimal operations. One way is to provide limited support for operator overloading so that operators can be molded to work on numeric reference types, such as BigDecimal. Another way is to provide the original decimal type, just as COBOL did with pl/i.

3. Character issues

• The precedence of string connections should not be the same as addition. This means that overloading the + operator to perform string joins is problematic.
• Also, the equivalence ratio of references to non-modifiable types, such as String, is more confusing. Perhaps the = = operator should perform a value comparison when applied to a type that is not modifiable. One way to do this is to use the = = operator as a handy way to approach the Equals method and provide a separate, system.identityhashcode-like method to perform a comparison of reference identities.

Java FAQ Notes (i)