30

What is the inclusive range of float and double in Java?

Why are you not recommended to use float or double for anything where precision is critical?

mskfisher
  • 3,291
  • 4
  • 35
  • 48
Catharsis
  • 466
  • 3
  • 9
  • 20
  • 5
    Citation for that peculiar remark about not using float or double "for anything critical"? – Jonathan Feinberg Oct 30 '09 at 15:35
  • 6
    You asked two different questions in the title and the body. Ask one question at a time, and take your time to actually write a complete question. – GEOCHET Oct 30 '09 at 15:48
  • 1
    True, but 'not precise' does not imply 'not critical'. If something is performance-critical rather than precision-critical, floating point is a way better choice than, say, BigDecimal. – Joren Oct 30 '09 at 15:49
  • You may also find this question useful: http://stackoverflow.com/questions/322749/retain-precision-with-doubles-in-java – Daniel Pryden Oct 30 '09 at 16:25

5 Answers5

32

Java's Primitive Data Types

boolean: 1-bit. May take on the values true and false only.

byte: 1 signed byte (two's complement). Covers values from -128 to 127.

short: 2 bytes, signed (two's complement), -32,768 to 32,767

int: 4 bytes, signed (two's complement). -2,147,483,648 to 2,147,483,647.

long: 8 bytes signed (two's complement). Ranges from -9,223,372,036,854,775,808 to +9,223,372,036,854,775,807.

float: 4 bytes, IEEE 754. Covers a range from 1.40129846432481707e-45 to 3.40282346638528860e+38 (positive or negative).

double: 8 bytes IEEE 754. Covers a range from 4.94065645841246544e-324d to 1.79769313486231570e+308d (positive or negative).

char: 2 bytes, unsigned, Unicode, 0 to 65,535

jechaviz
  • 551
  • 1
  • 9
  • 23
24

Java's Double class has members containing the Min and Max value for the type. 

2^-1074 <= x <= (2-2^-52)·2^1023 // where x is the double.

Check out the Min_VALUE and MAX_VALUE static final members of Double.

(some)People will suggest against using floating point types for things where accuracy and precision are critical because rounding errors can throw off calculations by measurable (small) amounts.

jjnguy
  • 136,852
  • 53
  • 295
  • 323
  • 12
    Don't forget that some numbers are just not representable in Float or Double. The standard example is imagine a banking app where you are withdrawing $1.10 from $2.00. The result using doubles would be $0.899999999999999, due to a like of ability to represent 1.1 in double. – Brandon Bodnar Oct 30 '09 at 16:25
  • 1
    ...and that's why you should always use a BigDecimal to represent money types (or in a more general sense, exact decimal amounts). – Andrzej Doyle Oct 30 '09 at 17:03
  • 8
    @dtsazza - it's not required to use BigDecimal, you could also use an integer type and represent numbers in cents (instead of fractional dollars). The point is that you must not use float or double for money because of limited precision. – Jesper Oct 30 '09 at 22:18
  • @Jesper - +1. This point is very important as many systems rely on this trick to conserve space while not trading precision. Odd you only had on "+1" on this. BigDecimal is 32 bytes (including class overhead) where as an int is 32 "bits" or 4 bytes. There are variations in fractions among currencies to consider but overall it is a viable strategy. There may be reasons one would choose object representation over primitives but you do deserve a +1 here :) – Zack Jannsen Dec 06 '15 at 13:02
11

Binary floating-point numbers have interesting precision characteristics, since the value is stored as a binary integer raised to a binary power. When dealing with sub-integer values (that is, values between 0 and 1), negative powers of two "round off" very differently than negative powers of ten.

For example, the number 0.1 can be represented by 1 x 10-1, but there is no combination of base-2 exponent and mantissa that can precisely represent 0.1 -- the closest you get is 0.10000000000000001.

So if you have an application where you are working with values like 0.1 or 0.01 a great deal, but where small (less than 0.000000000000001%) errors cannot be tolerated, then binary floating-point numbers are not for you.

Conversely, if powers of ten are not "special" to your application (powers of ten are important in currency calculations, but not in, say, most applications of physics), then you are actually better off using binary floating-point, since it's usually at least an order of magnitude faster, and it is much more memory efficient.

The article from the Python documentation on floating point issues and limitations does an excellent job of explaining this issue in an easy to understand form. Wikipedia also has a good article on floating point that explains the math behind the representation.

Daniel Pryden
  • 59,486
  • 16
  • 97
  • 135
7

From Primitives Data Types:

  • float: The float data type is a single-precision 32-bit IEEE 754 floating point. Its range of values is beyond the scope of this discussion, but is specified in section 4.2.3 of the Java Language Specification. As with the recommendations for byte and short, use a float (instead of double) if you need to save memory in large arrays of floating point numbers. This data type should never be used for precise values, such as currency. For that, you will need to use the java.math.BigDecimal class instead. Numbers and Strings covers BigDecimal and other useful classes provided by the Java platform.

  • double: The double data type is a double-precision 64-bit IEEE 754 floating point. Its range of values is beyond the scope of this discussion, but is specified in section 4.2.3 of the Java Language Specification. For decimal values, this data type is generally the default choice. As mentioned above, this data type should never be used for precise values, such as currency.

For the range of values, see the section 4.2.3 Floating-Point Types, Formats, and Values of the JLS.

Pascal Thivent
  • 562,542
  • 136
  • 1,062
  • 1,124
3

Of course you can use floats or doubles for "critical" things ... Many applications do nothing but crunch numbers using these datatypes.

You might have misunderstood some of the various caveats regarding floating-point numbers, such as the recommendation to never compare for exact equality, and so on.

unwind
  • 391,730
  • 64
  • 469
  • 606