Purpose of defining POSITIVE_INFINITY, NEGATIVE_INFINITY, NaN constants only for floating-point data types, but not for integral data types [duplicate]

Question

I want to understand why the POSITIVE_INFINITY and NEGATIVE_INFINITY constants are defined only for floating-point data types (float, double and their wrappers),

public static final float POSITIVE_INFINITY = 1.0f / 0.0f;
public static final float NEGATIVE_INFINITY = -1.0f / 0.0f;

but not for integral data types (byte, short, int, long and their wrappers). This affects the divide operation result on different data types. For example:

For integral types:

int z = 10/0;
System.out.println(z);

Output:
Exception in thread "main" java.lang.ArithmeticException: / by zero
at TesterClass.main(TesterClass.java:16)

For floating-point types:

double z = 10/0.0;
System.out.println(z);

Output:
Infinity

Answer 1

The integer types in Java use either unsigned binary (for char) or two's complement signed representation. There is no representation for "infinity" in either of these kinds of representations. For example, with int there are 2^32 possible values, and all of them represent finite numbers.

(Integer.MIN_VALUE is -2³¹, Integer.MAX_VALUE is 2³¹ - 1, and if you count them all ... including zero ... that makes 2³² different values.)

By contrast, floating-point numbers are represented using IEEE binary floating-point representations, and these do have a standard way to represent both infinity and not-a-number values.

Therefore it makes sense to define POSITIVE_INFINITY and NEGATIVE_INFINITY constants for the floating-point types, and it is impossible to define them for the integer types.

---

If you wanted to know why it is like this:

• The integer representations were designed / selected (a long time ago!) to maximize speed. Any special cases (like values reserved to represent infinity, etc.) would make the integer arithmetic hardware more complicated and slower. If the hardware designer's goal is to do an integer addition in one clock cycle, then making addition more complicated means that the clock speed must be slower. That effects the speed of the entire processor.

  The flip-side is that:

  • Overflow happens without any explicit notification (which may or may not be desirable)
  • Division by zero has to be dealt with via a hardware exception, and that results in a major performance penalty ... if it actually happens.

• The standard committee that designed the IEEE floating-point representations were also taking account of the requirements of scientific and engineering domains where there was a need to be able to represent infinites. Floating point operations are already slower and more complicated because of the need to do scaling, etc. Therefore they most likely are already multi-cycle instructions, and there is probably some "slack" for dealing with the special cases.

  Also, there is the advantage that: INF and NaN values allow the operations that create them to proceed without a hardware exception, but without "sweeping the bad operations under the carpet" like with integer overflow.

Note that two's complement was used in a working computer in 1949 (EDSAC). The IEEE 754 standard emerged in 1985.

---

For what it is worth, some programming languages are aware of integer overflow; for example Ada. But they don't do this with representations of infinity, etc. Instead, they throw an exception (or equivalent) when when an operation overflows. Even so, this adds a performance penalty, since overflow detection typically entails an extra instruction after each integer arithmetic instruction to test an "overflow" status bit. (That's the way modern instruction sets work ...)

Answer 2

It's part of the IEEE 754 floating-point standard, as mentioned in this spec:

The floating-point types are float and double, which are conceptually associated with the single-precision 32-bit and double-precision 64-bit format IEEE 754 values and operations as specified in IEEE Standard for Binary Floating-Point Arithmetic, ANSI/IEEE Standard 754-1985 (IEEE, New York).

The IEEE 754 standard includes not only positive and negative numbers that consist of a sign and magnitude, but also positive and negative zeros, positive and negative infinities, and special Not-a-Number values (hereafter abbreviated NaN).

These special values are computed based on their bit representations according to the standard. For example, the Double positive infinity is computed based on the 0x7ff0000000000000 bit representation.

In contrast, integer types have no bit representation for infinite values. They only have representations for finite numbers. The Integer class defines the minimum and maximum finite values as -2³¹ and 2^31-1.