This week's book giveaway is in the Agile and other Processes forum. We're giving away four copies of The Mikado Method and have Ola Ellnestam and Daniel Brolund on-line! See this thread for details.
try to run the following code: //code starts here long n16 = 9999999999999999L;//16 9s BigDecimal bd = new BigDecimal(n16); System.out.println("n16= " + n16); System.out.println("bd= " + bd); System.out.println("bd.longValue= " + bd.longValue()); //code ends here //the result is n16= 9999999999999999 #correct bd= 100000000000000000 #wrong bd.longValue= 1000000000000000 #wrong If it's not a bug, how can I safe convert "n16" into a BigDecimal? thanks. Jay
Jay Feng
Greenhorn
Joined: Oct 03, 2001
Posts: 2
posted
0
Never mind. It's not bug. In case anybody want to know, here's the reason. Before the long is converted into a BigDecimal, it has to be converted into a double(implicit cast), where some precision is lost. "Conversion of an int or a long value to float, or of a long value to double, may lose precision, that is, the result may lose some of the least significant bits of the value; the resulting floating-point value is a correctly rounded version of the integer value, using IEEE 754 round to nearest mode."(Quoted from VM spec).
Jim Yingst
Wanderer
Sheriff
Joined: Jan 30, 2000
Posts: 18670
posted
0
Use BigDecimal.valueOf(long) for this. This illustrates the main problem with static factory methods - they're easy to overlook in an API when you're looking for a constructor.
"I'm not back." - Bill Harding, Twister
I agree. Here's the link: http://ej-technologies/jprofiler - if it wasn't for jprofiler, we would need to
run our stuff on 16 servers instead of 3.
0
