5/0.0 = Infinity : NO error is thrown

[fullofquestions]

Hello everyone. I have encountered an issue that perhaps is related to
my setup. I am running NetBeans 6.0, jre1.6.04 and at the moment I was
going through a java book to document a whole bunch of topics. Anyway,
I created an extremely simple class to go over exception handling. The
issue is that I can't find a way for the instance to throw a
'java.lang.ArithmeticException: / by zero.' The following file

public class index {
public static void main( String args[] )
{
Scanner scanner = new Scanner( System.in ); // scanner for input
System.out.println("5/0.0 = " + 5/0.0);
System.out.println("5/0.0 = " + 5/0);
}
}

Produces the following output:

5/0.0 = Infinity
Exception in thread "main" java.lang.ArithmeticException: / by zero

What is the difference between dividing by 0(int) and 0.0(double)? If
I have a bunch of calculations involving doubles where I want to check
for div by zero, how shoud I go about it?

Why isn't my program throwing

 

[Arne Vajhøj]

Hello everyone. I have encountered an issue that perhaps is related to
my setup. I am running NetBeans 6.0, jre1.6.04 and at the moment I was
going through a java book to document a whole bunch of topics. Anyway,
I created an extremely simple class to go over exception handling. The
issue is that I can't find a way for the instance to throw a
'java.lang.ArithmeticException: / by zero.' The following file

public class index {
public static void main( String args[] )
{
Scanner scanner = new Scanner( System.in ); // scanner for input
System.out.println("5/0.0 = " + 5/0.0);
System.out.println("5/0.0 = " + 5/0);
}
}

Produces the following output:

5/0.0 = Infinity
Exception in thread "main" java.lang.ArithmeticException: / by zero

What is the difference between dividing by 0(int) and 0.0(double)? If
I have a bunch of calculations involving doubles where I want to check
for div by zero, how shoud I go about it?

There exist a standard for floating point operations IEEE 754.

It says that division by zero return infinite instead of faulting.

Most CPU's follow that standard.

Java had to use the available hardware support for floating point
for obvious performance reasons.

The short answer is that it is just this way.

You can test for infinite.

Integer arithmetic is different from floating point.

Arne

 

[Patricia Shanahan]

Arne Vajhøj wrote:
....

There exist a standard for floating point operations IEEE 754.

It says that division by zero return infinite instead of faulting.

Don't blame the floating point standard for this one. It strongly
recommends that users should be able to request a trap on division by 0.
The infinite result is only required if there is no trap.

ANSI/IEEE std. 754-1985 lists five exceptions, including "Division by
Zero" (section 7.2) "If the divisor is zero and the dividend is a finite
nonzero number, then the division by zero exception shall be signaled.
The result, when no trap occurs, shall be a correctly signed [infinity
symbol]."

Section 8, "Traps", begins with "A user should be able to request a trap
on any of the five exceptions by specifying a handler for it."

There is a subtle distinction between "shall" and "should". "The use of
the word shall signifies that which is obligatory for any conforming
implementation.". "The use of the word should signifies that which is
strongly recommended as being in keeping with the intent of the
standard, although architectural or other constraints beyond the scope
of this standard may on occasion render the recommendations impractical."

The decision not to provide any way to trap floating point exceptions is
a matter of Java language design, contrary to the floating point
standard's strong recommendation.

Patricia

 

[Wayne]

> ...
System.out.println("5/0.0 = " + 5/0.0);
System.out.println("5/0.0 = " + 5/0);
}
}

Produces the following output:

5/0.0 = Infinity
Exception in thread "main" java.lang.ArithmeticException: / by zero

What is the difference between dividing by 0(int) and 0.0(double)?

Computer arithmetic is not the same as you might be used to.
"Real" numbers are represented in a computer as floating point numbers,
which don't always work as real numbers would. In this case, the
IEEE standard for floating point division states it is not an
error to divide by zero. Integer division by zero does cause
the Exception but for float and double numbers you need to
manually check the denominator. Depending on the program's
semantics this may or may not be something to throw an Exception
for. If it is, you can use an if statement to check and
throw an ArithemeticException or IllegalArgumentException.
If not consider using an assertion to check.

(I have always found it amusing that on Unix systems, the
signal (low-level OS exception) is called "SIGFPE", which
stands for "floating point exception", and you only get
this with ingeter division by zero, not floating point
division.)

There are many resources to help you understand the peculiarities
of computer arithmetic on the Internet you can search for. I
have collected some examples on a web page at
http://www.hccfl.edu/pollock/Java/MathOddities.htm
that may help clarify some of the issues for you.

-Wayne

 

[Patricia Shanahan]

Computer arithmetic is not the same as you might be used to.
"Real" numbers are represented in a computer as floating point numbers,
which don't always work as real numbers would. In this case, the
IEEE standard for floating point division states it is not an
error to divide by zero. ...

See my longer reply earlier in this thread. The lack of any way to
request a trap on floating point divide by zero is not only not required
by the IEEE floating point standard, it is contrary to its strong
recommendation.

Patricia

 

[fullofquestions]

See my longer reply earlier in this thread. The lack of any way to
request a trap on floating point divide by zero is not only not required
by the IEEE floating point standard, it is contrary to its strong
recommendation.

Patricia- Hide quoted text -

- Show quoted text -

Thank you all for the responses. Also, thanks for the MathOddity link.
So, in the future, the handle for the double div by zero should be
something along the lines?...

if(Double.compare(0.0, denominator) == 0)
throw new ArithmeticException();

 

[Patricia Shanahan]

Thank you all for the responses. Also, thanks for the MathOddity link.
So, in the future, the handle for the double div by zero should be
something along the lines?...

if(Double.compare(0.0, denominator) == 0)
throw new ArithmeticException();

Why not:

if(denominator == 0.0)

Positive and negative floating point zero compare equal in Java.

Patricia

 

[Roedy Green]

What is the difference between dividing by 0(int) and 0.0(double)? If
I have a bunch of calculations involving doubles where I want to check
for div by zero, how shoud I go about it?

That example about nails it. In floating point there are various
magic values that propagate through calculations. See
http://mindprod.com/jgloss/floatingpoint.html
for details, (point 13).

For int, divide by 0 raises an exception.

IEEE made up the floating point rules. The int ones are traditional.

 

[Roedy Green]

See my longer reply earlier in this thread. The lack of any way to
request a trap on floating point divide by zero is not only not required
by the IEEE floating point standard, it is contrary to its strong
recommendation.

Because the IEEE made it optional, that meant some manufacturers made
it optional. For WORA, that meant Java could not support it.

 

[Mark Space]

Don't blame the floating point standard for this one. It strongly
recommends that users should be able to request a trap on division by 0.
The infinite result is only required if there is no trap.

Interesting. I wonder if Sun could be induced to support traps for both
floating point and integer math. I'd like to see at least an option for
integer operation to throw overflow exceptions. (Actually I'd like to
see it be the default case.)

I imagine this might affect the JIT. This could be a boon (the JIT
could emit different code depending on whether traps were installed or
not) but it could also be a pain (cached JIT code could be invalid if
the trap options were changed). Something to think about anyway....

 

[Martin Gregorie]

Interesting. I wonder if Sun could be induced to support traps for both
floating point and integer math. I'd like to see at least an option for
integer operation to throw overflow exceptions. (Actually I'd like to
see it be the default case.)

If I understand Patricia correctly, this would introduce nasty
dependencies to Java.

Imagine you write a program that depends on the overflow exception and
test it on your hardware, which implements FP overflow trapping. All
tests are passed: its apparently bullet-proof. Now, somebody else runs
it on hardware that *doesn't* implement FP overflow traps. Suddenly your
program fails in unexpected ways because it trips over FP overflows that
no longer generate exceptions and you get loads of bug reports.

Sun's solution at least gives consistent results on any hardware.

I imagine this might affect the JIT. This could be a boon (the JIT
could emit different code depending on whether traps were installed or
not) but it could also be a pain (cached JIT code could be invalid if
the trap options were changed). Something to think about anyway....
>

The effects would be visible all the way up to application level. See above.

 

[Roedy Green]

Interesting. I wonder if Sun could be induced to support traps for both
floating point and integer math. I'd like to see at least an option for
integer operation to throw overflow exceptions. (Actually I'd like to
see it be the default case.)

But if the hardware does not support it? You then have the overhead
of checking after every operation, even when you are not interested.

 

[Patricia Shanahan]

But if the hardware does not support it? You then have the overhead
of checking after every operation, even when you are not interested.

In any case, integer overflow presents serious problems unless it is
built-in from the start, especially considering the lack of unsigned
integer types for most of the common widths.

Patricia

 

[John W. Kennedy]

The decision not to provide any way to trap floating point exceptions is
a matter of Java language design, contrary to the floating point
standard's strong recommendation.

Perhaps there isn't a decent lowest-common-denominator semantic model
for Java to implement. (Per thread? Per loaded module? Dynamically
changed at will?)

 

[John W. Kennedy]

Why not:

if(denominator == 0.0)

Positive and negative floating point zero compare equal in Java.

Wouldn't

if (Double.isInfinite(quotient))

be safer?

--
John W. Kennedy
"The whole modern world has divided itself into Conservatives and
Progressives. The business of Progressives is to go on making mistakes.
The business of the Conservatives is to prevent the mistakes from being
corrected."
-- G. K. Chesterton

 

[Arne Vajhøj]

Thank you all for the responses. Also, thanks for the MathOddity link.
So, in the future, the handle for the double div by zero should be
something along the lines?...

if(Double.compare(0.0, denominator) == 0)
throw new ArithmeticException();

Or use Double.isInfinite after ...

Arne

 

[Arne Vajhøj]

Interesting. I wonder if Sun could be induced to support traps for both
floating point and integer math.

strongly recommend != mandate
=>
problem assuming it is there

Arne

 

[Patricia Shanahan]

Patricia Shanahan wrote: ....

Wouldn't

if (Double.isInfinite(quotient))

be safer?

Depends on how you want to treat 0.0/0.0.

Patricia

 

[Dr J R Stockton]

In comp.lang.java.programmer message <e7d05044-b484-47ce-a696-c2872c91c6
(e-mail address removed)>, Sun, 13 Jan 2008 21:37:16,

Thank you all for the responses. Also, thanks for the MathOddity link.
So, in the future, the handle for the double div by zero should be
something along the lines?...

if(Double.compare(0.0, denominator) == 0)
throw new ArithmeticException();

Dividing a very large number by a very small non-zero number is also
liable to require a result value which is outside the finite-and-
representable range.

 

[Mark Space]

But if the hardware does not support it? You then have the overhead
of checking after every operation, even when you are not interested.

There's lots of things that hardware supports today, which it didn't ten
years ago.

First make it correct, then make it fast.