Accuracy of numerical calculation in Java

The basic type float in Java has a very serious lack of precision. This is mainly through Java. math. bigdecimal is used to make up for it, but bigdecimal is a class after all, with complicated tasks such as object creation and destruction. Besides, Java does not have the destroy () method in itself, this completely destroys all objects and then recycles the memory into an unmeasurable variable, even if you call the system. GC (), but the execution time of this method is unknown;
So this requires programmers to create as few objects as possible (of course, this is also related to the memory consumption of Java itself). Once an object is not used, set it to null as much as possible, otherwise, when the program runs several times, it will find that the memory usage is high, or even cause a crash. Bigdecimal another note is that even if the values of the two objects are equal, they may lead to unequal results during comparison. For example:

 
Bigdecimal Testa = new bigdecimal (200) and
Bigdecimal testb = new bigdecimal (200.00 ),

Maybe you think Testa. Equals (testb) = true; but the result is false. However, Testa. tostring (). equals (testb. tostring () = true, because testb. the value of tostring () is 200. During type conversion, it has removed the two zeros after the decimal point.

To solve this problem, I usually add the digits of the decimal points and then compare them. In this way, no errors will occur, such as Testa = Testa. setscale (2, 5); testb = testb. setscale (); of course, you can set the number of decimal places to be more or less as needed. The first digit in setscale (INT, INT) is the set number of decimal places, the second digit is the rounded boundary value. You can modify it at will. For example, if the value is greater than or equal to 6, it is a carry.

Testa = Testa. setscale () will always appear when bigdecimal is used, because it must replace existing values by returning values to itself, if you write Testa like this. add (New bigdecimal (0), then you will find that your result is not the expected 200, but 0. Of course, addition, subtraction, multiplication, division are the same. As for why the comparison just now does not require Testa. floatvalue (), of course, is still because of the loss of precision. Of course, if your decimal point is no more than 5 digits, it is also possible. If it is more than 5 digits, it is related to the value of the fifth digit (because it only keeps the five decimal places). If the fifth digit is greater than or equal to five, even if the sixth digit is zero, it will add one to the fifth digit, otherwise, the following will only be intercepted!

Speaking of this, I suddenly think of the ending number and accuracy in Javascript. In JavaScript, there is a method "tofixed ()", which is used to intercept the length of the ending number after the decimal point. For example, var a = 343.12345465; var B = B. tofixed (4); in this way, the tail number of B after the decimal point is four digits. Note that it is truncated by rounding.