 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / January 20085/0.0 = Infinity : NO error is thrown
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 > 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 [quoted text clipped - 20 lines] > 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 ... >> 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 [quoted text clipped - 3 lines] > > 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 > 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.... > 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.  Signaturemartin@ | Martin Gregorie gregorie. | Essex, UK org | On Mon, 14 Jan 2008 17:58:21 GMT, Mark Space <markspace@sbc.global.net> wrote, quoted or indirectly quoted someone who said : >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. SignatureRoedy Green, Canadian Mind Products The Java Glossary, http://mindprod.com > On Mon, 14 Jan 2008 17:58:21 GMT, Mark Space > <markspace@sbc.global.net> wrote, quoted or indirectly quoted someone [quoted text clipped - 7 lines] > 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 > 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. >> But if the hardware does not support it? You then have the overhead >> of checking after every operation, even when you are not interested. [quoted text clipped - 3 lines] > > First make it correct, then make it fast. We are talking every floating point division here. Arne >>> But if the hardware does not support it? You then have the overhead >>> of checking after every operation, even when you are not interested. [quoted text clipped - 5 lines] > > We are talking every floating point division here. And? Seriously, maybe I need to explain a bit more, but I don't see the issue. First I said the JIT compiler could be involved to emit code to check, or not check, for divide by zero. That should involve setting or clearing a flag on the floating point unit. Or checking one flag afterwards. Not a big deal. If you don't care, emit code to ignore the flag. Easy. For byte-code, well you have to have the JVM check. But anything that isn't compiled by the JIT compiler shouldn't be used very often, so again the performance hit should be minimal. It might be worth while to install a trap in the fpu if the fpu supports them, and just ignore divides by zero when they happen, if that is the selected option. That takes NO time, other than the initial poke-the-address-in-here at start up. (Most of the time I'd expect the OS to do that for you.) I haven't looked at Intel's or AMD's specs lately, but this is 1990 technology. For ints, same deal. I think even the original 8086 had a hardware trap for integer divide by zero. No time during execution of code was needed to check for this error. I don't think these concepts are that hard. Are they being taught in school these days? Folks, hardware has always bent over backwards to accommodate the software. This overflow stuff is old old news. There are much more exciting issues with modern architecture than number overflow. >>>> But if the hardware does not support it? You then have the overhead >>>> of checking after every operation, even when you are not interested. [quoted text clipped - 9 lines] > > Seriously, maybe I need to explain a bit more, but I don't see the issue. There are other problems, specifically in hardware and operating-system support. Does all hardware support this? If not, is the overhead of simulating it acceptable? Do all OSs support toggling the option? If not, is the overhead of simulating it acceptable? How is the option controlled by the OS for native programs? At compile time? At link time? At process-start time? Dynamically, within a process? At thread-start time? Dynamically, within a thread? Is there an agreement? Is there even a consensus? Which models can be emulated on other models without unacceptable overhead? And, given all this, is it really worth it? In a great many cases, letting the result "Infinity" or "Not a Number" go through to the end is entirely satisfactory, producing correct and useful output (to the degree that the input allows), whereas checking and/or interrupt handling adds significant overhead, while also crippling machine-code optimization. IEEE-754 did not incorporate these features as a joke. If mere debugging is an issue, use assertions. SignatureJohn W. Kennedy If Bill Gates believes in "intelligent design", why can't he apply it to Windows? >>> But if the hardware does not support it? You then have the overhead >>> of checking after every operation, even when you are not interested. [quoted text clipped - 5 lines] > > We are talking every floating point division here. ...and some hardware used to support things better in the past. The first computer I used, an Elliott 503, was a British purpose designed scientific computer with 39 bit words. It was about 10-15% faster for floating point calculations than it was for integer. Signaturemartin@ | Martin Gregorie gregorie. | Essex, UK org | >> 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. strongly recommend != mandate => problem assuming it is there Arne > 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?) SignatureJohn W. Kennedy "...when you're trying to build a house of cards, the last thing you should do is blow hard and wave your hands like a madman." -- Rupert Goodwins > ... > System.out.println("5/0.0 = " + 5/0.0); [quoted text clipped - 8 lines] > > 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 > > ... >> System.out.println("5/0.0 = " + 5/0.0); [quoted text clipped - 14 lines] > 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 > > > ... > >> System.out.println("5/0.0 = " + 5/0.0); [quoted text clipped - 23 lines] > > - 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(); >>> > ... >>>> System.out.println("5/0.0 = " + 5/0.0); [quoted text clipped - 25 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 >>>> > ... >>>>> System.out.println("5/0.0 = " + 5/0.0); [quoted text clipped - 31 lines] > > Positive and negative floating point zero compare equal in Java. Wouldn't if (Double.isInfinite(quotient)) be safer? SignatureJohn 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 ... >> Why not: >> [quoted text clipped - 7 lines] > > be safer? Depends on how you want to treat 0.0/0.0. Patricia > 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 In comp.lang.java.programmer message <e7d05044-b484-47ce-a696-c2872c91c6 8c@d4g2000prg.googlegroups.com>, Sun, 13 Jan 2008 21:37:16, fullofquestions <fullofquestions@gmail.com> posted: >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. Signature(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 IE 6. Web <URL:http://www.merlyn.demon.co.uk/> - w. FAQish topics, links, acronyms PAS EXE etc : <URL:http://www.merlyn.demon.co.uk/programs/> - see 00index.htm Dates - miscdate.htm moredate.htm js-dates.htm pas-time.htm critdate.htm etc. >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. SignatureRoedy Green, Canadian Mind Products The Java Glossary, http://mindprod.com On Sun, 13 Jan 2008 19:27:07 -0800 (PST), fullofquestions <fullofquestions@gmail.com> wrote, quoted or indirectly quoted someone who said : >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. SignatureRoedy Green, Canadian Mind Products The Java Glossary, http://mindprod.com Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.