Note | ||
---|---|---|
| ||
This rule may be deprecated and replaced by a similar guideline. 06/28/2014 -- Version 1.0 |
The Java language provides two primitive floating-point types, float
and double
, which are associated with the single-precision 32-bit and double-precision 64-bit format values and operations specified by IEEE 754 [IEEE 754]. Each of the floating-point 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
Wiki Markup |
---|
The Java language provides two primitive types, {{float}} and {{double}}, which are associated with the single-precision 32-bit and double-precision 64-bit format IEEE 754 values and operations \[[IEEE 754|AA. Bibliography#IEEE 754 2006]\]. Each of the floating-point 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 1/10, because these numbers have repeating binary representations. |
If precise computation is necessary, such as when performing currency calculations, then floating-point types must not be used, . Instead, use an alternative representation that is able to can completely represent the necessary values.
If precise computation is not necessary, floatin-gpoint 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 1991|AA. Bibliography#Goldberg 91]\] for an introduction to this topicWhen precise computation is unnecessary, floating-point 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]. Wiki Markup
Noncompliant Code Example
This noncompliant code example performs some basic currency calculations.:
Code Block | ||
---|---|---|
| ||
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 either Java floating-point type (or any floating-point format that uses a binary mantissa), on most platforms, this program prints the following:
Code Block |
---|
A dollar less 7 dimes is $0.29999999999999993
|
...
This compliant solution uses an integer type (such as long
int
) and works with cents rather than dollars.:
Code Block | ||
---|---|---|
| ||
longint dollar = 100; longint dime = 10; int number = 7; System.out.println( ("A dollar less " + number + " dimes is $0." + (dollar - number * dime) + " cents" ); |
This code correctly outputs the following:
Code Block |
---|
A dollar less 7 dimes is $0.30 cents |
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. The importance of this reduced efficiency is application-specific.
Code Block | ||
---|---|---|
| ||
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:
Code Block |
---|
A dollar less 7 dimes is $0.3
|
...
Using floating-point representations when precise computation is required can result in a loss of precision and incorrect values.
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
NUM04-J |
Low |
Probable |
High | P2 | L3 |
Automated Detection
Automated detection of floating-point arithmetic is straight-forward; straightforward. However, determining which code suffers from insufficient precision is not feasible in the general case. Heuristic checks, such as flagging floating-point literals that cannot be represented precisely, could be useful.
Tool | Version | Checker | Description | ||||||
---|---|---|---|---|---|---|---|---|---|
Parasoft Jtest |
| CERT.NUM04.UBD | Do not use "float" and "double" if exact answers are required |
Related Guidelines
FLP02-C. Avoid using floating-point numbers when precise computation is needed | |
VOID FLP02-CPP. Avoid using floating point numbers when precise computation is needed |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="127953c2-8907-49aa-8087-8286c89adcb2"><ac:plain-text-body><![CDATA[
http://www.aitcnet.org/isai/]
Floating-Point Arithmetic [PLF] |
]]></ac:plain-text-body></ac:structured-macro>
Bibliography
Android Implementation Details
The use of floating-point on Android is not recommended for performance reasons.
Bibliography
Item 48, "Avoid | |
Puzzle 2, "Time for a Change" | |
[IEEE 754] | |
[JLS 2015] |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="c1f9c367-6bf0-432a-b60b-3937260b54e3"><ac:plain-text-body><![CDATA[
[[Bloch 2008
AA. Bibliography#Bloch 08]]
Item 48: Avoid float
and double
if exact answers are required
]]></ac:plain-text-body></ac:structured-macro>
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="b5078541-dbe2-4b77-98b5-7fdc04fd5b86"><ac:plain-text-body><![CDATA[
[[Bloch 2005
AA. Bibliography#Bloch 05]]
Puzzle 2: Time for a Change
]]></ac:plain-text-body></ac:structured-macro>
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="98d7e01f-7cf5-45c1-9a26-053d43357e01"><ac:plain-text-body><![CDATA[
[[Goldberg 1991
AA. Bibliography#Goldberg 91]]
]]></ac:plain-text-body></ac:structured-macro>
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="edf3d05b-c91a-4301-9947-01bf8a59275d"><ac:plain-text-body><![CDATA[
[[IEEE 754
AA. Bibliography#IEEE 754 2006]]
]]></ac:plain-text-body></ac:structured-macro>
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="315a4a88-f43e-48f1-81e2-fa72a1d0852a"><ac:plain-text-body><![CDATA[
[[JLS 2005
AA. Bibliography#JLS 05]]
http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3]
]]></ac:plain-text-body></ac:structured-macro>
[Seacord 2015] |
...
NUM03-J. Provide mechanisms to handle unsigned data when required 03. Numeric Types and Operations (NUM) NUM05-J. Do not use denormalized numbers