Deprecated
This rule may be deprecated and replaced by a similar guideline.
06/28/2014  Version 1.0
The Java language provides two primitive floatingpoint types, float
and double
, which are associated with the singleprecision 32bit and doubleprecision 64bit format values and operations specified by IEEE 754 [IEEE 754]. Each of the floatingpoint types has a fixed, limited number of mantissa bits. Consequently, it is impossible to precisely represent any irrational number (for example, pi). Further, because these types use a binary mantissa, they cannot precisely represent many finite decimal numbers, such as 0.1, because these numbers have repeating binary representations.
When precise computation is necessary, such as when performing currency calculations, floatingpoint types must not be used. Instead, use an alternative representation that can completely represent the necessary values.
When precise computation is unnecessary, floatingpoint representations may be used. In these cases, you must carefully and methodically estimate the maximum cumulative error of the computations to ensure that the resulting error is within acceptable tolerances. Consider using numerical analysis to properly understand the problem. See Goldberg's work for an introduction to this topic [Goldberg 1991].
Noncompliant Code Example
This noncompliant code example performs some basic currency calculations:
double dollar = 1.00; double dime = 0.10; int number = 7; System.out.println( "A dollar less " + number + " dimes is $" + (dollar  number * dime) );
Because the value 0.10 lacks an exact representation in Java floatingpoint type (or any floatingpoint format that uses a binary mantissa), on most platforms, this program prints the following:
A dollar less 7 dimes is $0.29999999999999993
Compliant Solution
This compliant solution uses an integer type (such as int
) and works with cents rather than dollars:
int dollar = 100; int dime = 10; int number = 7; System.out.println( "A dollar less " + number + " dimes is $0." + (dollar  number * dime) );
This code correctly outputs the following:
A dollar less 7 dimes is $0.30
Compliant Solution
This compliant solution uses the BigDecimal
type, which provides exact representation of decimal values. Note that on most platforms, computations performed using BigDecimal
are less efficient than those performed using primitive types.
import java.math.BigDecimal; BigDecimal dollar = new BigDecimal("1.0"); BigDecimal dime = new BigDecimal("0.1"); int number = 7; System.out.println ("A dollar less " + number + " dimes is $" + (dollar.subtract(new BigDecimal(number).multiply(dime) )) );
This code outputs the following:
A dollar less 7 dimes is $0.3
Risk Assessment
Using floatingpoint representations when precise computation is required can result in a loss of precision and incorrect values.
Rule  Severity  Likelihood  Remediation Cost  Priority  Level 

NUM04J  Low  Probable  High  P2  L3 
Automated Detection
Automated detection of floatingpoint arithmetic is straightforward. However, determining which code suffers from insufficient precision is not feasible in the general case. Heuristic checks, such as flagging floatingpoint literals that cannot be represented precisely, could be useful.
Tool  Version  Checker  Description 

Parasoft Jtest  10.3  PB.NUM.UBD  Implemented 
Related Guidelines
FLP02C. Avoid using floatingpoint numbers when precise computation is needed  
VOID FLP02CPP. Avoid using floating point numbers when precise computation is needed  
FloatingPoint Arithmetic [PLF] 
Android Implementation Details
The use of floatingpoint on Android is not recommended for performance reasons.
Bibliography
Item 48, "Avoid  
Puzzle 2, "Time for a Change"  
 
[IEEE 754] 

[JLS 2015]  
[Seacord 2015]  NUM04J. Do not use floatingpoint numbers if precise computation is required LiveLesson 
3 Comments
Yozo TODA
This guideline has been marked deprecated since June of 2014 (maybe right after publishing the book).
> This rule may be deprecated and replaced by a similar guideline.
Any plan to merge the contents to some other guidelines?
With quick looking other guidelines, I feel the contents are related to NUM13J and NUM52J, but restructuring those guidelines (to a new set of guidelines) sounds a nontrivial work...
David Svoboda
Well, given how long ago that sign has existed, I'd say that any such plans are long dead
My offhand suggestion is to demote this rule to a recommendation, but otherwise leave it unchanged. That would mirror C, which has a similar recommendation. What do you think?
Jérôme GUY
I would keep this rule such as.
In particular, I think of the equality test between floatting point number with may cause bad flow.