Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Agile forum!

# why 0/0 is an EXCEPTION and 0.0/0.0 is NaN ?

Nutan Choubey
Greenhorn
Posts: 2
why 0/0 is an EXCEPTION and 0.0/0.0 is NaN ?
Probably this is due to precision in float.
Can someone clarify the reason?

Stephan van Hulst
Bartender
Posts: 5381
52
An operation on two integers should produce an integer. NaN rarely makes sense for integers, and dividing by zero is often a sign of a mistake.

Henry Wong
author
Marshal
Posts: 20892
75
• 3
Java doubles follow the IEEE specification. The IEEE specification for floating point defines special values for Infinity, Negative infinity, Negative zero, and NaN (not a number). These are actually defined numbers, along with operations that generate them.

Java integers follow the twos complement format. There are no special definitions for any of the above values. In this case, there is no representation of a NaN for an integer.

Henry

Colin Wang
Greenhorn
Posts: 4
Henry Wong wrote:Java doubles follow the IEEE specification. The IEEE specification for floating point defines special values for Infinity, Negative infinity, Negative zero, and NaN (not a number). These are actually defined numbers, along with operations that generate them.

Java integers follow the twos complement format. There are no special definitions for any of the above values. In this case, there is no representation of a NaN for an integer.

Henry

Java follow the IEEE specification on double/float, but no specification on int.

samir vasani
Ranch Hand
Posts: 65

Lester Burnham
Rancher
Posts: 1337
samir vasani wrote:The above answers are not satisfactory,so please give the correct reason

Are you saying that you don't understand the answers, or that you think they are incorrect? If the former, what *do* you understand about them? If the latter, *why* do you think they're incorrect? (And please don't post in all-bold; it's annoying to read, and does nothing to make people want to answer.)

samir vasani
Ranch Hand
Posts: 65
Lester Burnham wrote:
samir vasani wrote:The above answers are not satisfactory,so please give the correct reason

Are you saying that you don't understand the answers, or that you think they are incorrect? If the former, what *do* you understand about them? If the latter, *why* do you think they're incorrect? (And please don't post in all-bold; it's annoying to read, and does nothing to make people want to answer.)

Henry Wong
author
Marshal
Posts: 20892
75
samir vasani wrote:
Lester Burnham wrote:
samir vasani wrote:The above answers are not satisfactory,so please give the correct reason

Are you saying that you don't understand the answers, or that you think they are incorrect? If the former, what *do* you understand about them? If the latter, *why* do you think they're incorrect? (And please don't post in all-bold; it's annoying to read, and does nothing to make people want to answer.)

Lester's response wasn't to bust your chops. "Twos complement" is not something that can be explain in the paragraph. And IEEE 754 is even more complex -- much much much more complex. You are not going to get a "teach you from square one" response here. It is just not feasible.

However, if you get very very specific, maybe we can give you a one paragraph response, on one small detail. Otherwise, the best we can do is to tell you to google "twos complement" and "IEEE 754", the details for the integer and floating point format respectively.

Henry

Stephan van Hulst
Bartender
Posts: 5381
52
The simple answer is that the way the developers designed integers, there is no room for values such as NaN.

Here's an example: ints can holds values -2.147.483.648 to 2.147.483.647. Then all the possible combinations of bits are exhausted. There is no way to fit a value like NaN in there. The designers could have chosen to make the value -2.147.483.648 mean the same as NaN, but they chose not to, because it makes integer values unnecessarily complex (consider what values they would have to use to define NaN in short, byte and long as well, and how these values have to be converted when casting to another type).

Simply put, it's too complex and it's barely useful.

Henry Wong
author
Marshal
Posts: 20892
75
Stephan van Hulst wrote:The simple answer is that the way the developers designed integers, there is no room for values such as NaN.

Here's an example: ints can holds values -2.147.483.648 to 2.147.483.647. Then all the possible combinations of bits are exhausted. There is no way to fit a value like NaN in there. The designers could have chosen to make the value -2.147.483.648 mean the same as NaN, but they chose not to, because it makes integer values unnecessarily complex (consider what values they would have to use to define NaN in short, byte and long as well, and how these values have to be converted when casting to another type).

Simply put, it's too complex and it's barely useful.

There is also another really good reason why twos complement is designed the way it is.

At a logic level, operations are identical to its unsigned counterparts.... meaning if you take two signed numbers, and look at the bit pattens (using twos complement); then treating those bit patterns as unsigned numbers, and performing operations on them; the resultant bit pattern based on operations of those unsigned numbers are the same bit patterns that would have resulted, if you had did the operations using signed operations (using twos complement representation).

This is very important to a CPU, as it means that it can have a ALU that can process both signed and unsigned numbers, using a lot less die space -- as the same logic can be shared by both set of operations. This is very cool -- at least to a geek such as myself...

Henry

Stephan van Hulst
Bartender
Posts: 5381
52
Haha, yeah, it is. While in the back of my head I know it works like that, I never stood still to appreciate it.