How Java's floating-point hurts everyone everywhere
-
This is interesting: http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf. I wonder how MS stacks up against this?
-
This is interesting: http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf. I wonder how MS stacks up against this?
Does the new MS sponsorship package includes Java bashing too? Regards, Paul. Paul Selormey, Bsc (Elect Eng), MSc (Mobile Communication) is currently Windows open source developer in Japan, and open for day job or programming contract anywhere!
-
Does the new MS sponsorship package includes Java bashing too? Regards, Paul. Paul Selormey, Bsc (Elect Eng), MSc (Mobile Communication) is currently Windows open source developer in Japan, and open for day job or programming contract anywhere!
If you're claiming that only people paid by Micro$oft bash Java, you should check out some of Bjarne Stroustrups comments on the subject. He calls Java a solution in search of a problem, and that's his kindest comment. Christian The content of this post is not necessarily the opinion of my yadda yadda yadda. To understand recursion, we must first understand recursion.
-
If you're claiming that only people paid by Micro$oft bash Java, you should check out some of Bjarne Stroustrups comments on the subject. He calls Java a solution in search of a problem, and that's his kindest comment. Christian The content of this post is not necessarily the opinion of my yadda yadda yadda. To understand recursion, we must first understand recursion.
i always knew bjarne was smarter than the average language inventor :cool: --- "every year we invent better idiot proof systems and every year they invent better idiots"
-
Does the new MS sponsorship package includes Java bashing too? Regards, Paul. Paul Selormey, Bsc (Elect Eng), MSc (Mobile Communication) is currently Windows open source developer in Japan, and open for day job or programming contract anywhere!
Thanks for that Paul. In the interest of providing a balanced view (and because I actually enjoyed reading the link that masked person sent in) I did a quick search. I found the following: http://www.geocrawler.com/archives/3/1329/2000/10/0/4488162/
Discussion of possible IEEE 754 weirdness in VC++
http://www.statsdirect.com/_disc1/00000005.htm
"Numerical algorithms written in Microsoft Visual Basic, Microsoft Visual C++ and Compaq Visual FORTRAN comply with both single (32 bit) and double (64 bit) precision IEEE Standard Floating-Point Representation (Microsoft Corporation, 1998; Compaq Corporation, 2000; IEEE, 1985)."
http://mail-index.netbsd.org/netbsd-bugs/1998/03/12/0007.html
"I've been told that Microsoft C compilers are known to have problems with this and other IEEE 754 tests."
http://support.microsoft.com/support/kb/articles/Q36/0/68.ASP
"Microsoft is consistent with the IEEE numeric standards"
http://www.javaworld.com/javaworld/jw-10-1996/jw-10-hood.html
"The JVM's floating-point support adheres to the IEEE-754 1985 floating-point standard."
http://sunsite.dcc.uchile.cl/hotjava/doc/javaspec/javaspec_10.html#HEADING74
Summary of IEEE-754 Differences in Java
If anyone has a definitive answer on what adheres to what, then it would make an interesting read. You can read up on the IEEE 754 standard here. cheers, Chris Maunder
-
This is interesting: http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf. I wonder how MS stacks up against this?
Very nice article. Thanks for telling us about it. This reminds me of a question that I have never received a satisfactory answer to. The documented behavior of VC++ 6 is (according to the MSDN documentation for the numeric_limits sample program):
29 Representation of quiet NaN for float -1.#IND ... 40 How does a float represent a signaling NaN? -1.#INFI am not the greatest IEEE-754 guru, but shouldn't a signaling NaN be represented as "1.#NaN"? Can anyone here explain this to me? The behavior seems to be by design, so I hesitate to call it a bug or noncompliance, but I have not managed to get a definitive answer from anyone about where I am mistaken in my understanding of 754 signaling NaNs. For detailed and knowledgeable description of how MS has consistently undermined the intentions of the IEEE-754 standard, see the 1997 Dr. Dobbs interview with William Kahan, who was the principal architect of the IEEE-754 standard and who contributed significantly to the design of the original 8087. An excerpt:
If I understand what the Microsoft C compiler does, it allows overflow to occur at run time, and then you get a run-time message, "Your expression is too complicated, go back rewrite it in simpler pieces and recompile." To do this, they have to test the invalid flag, which indicates either an invalid arithmetic operation or a stack overflow, depending on the state of another bit in the condition code. The trouble is, to detect this, they clear the flag after every statement, therefore you the programmer can't use it. You can't find out if an invalid operation has occurred, because Microsoft has cleared the flag before the code returns. DDJ: So you have to write your own libraries? WK: It's not the libraries. The compiler generates code that blitzes the invalid flag before you see it. You disable the trap on invalid because you want to test it. The compiler reenables the trap, you do your arithmetic operation, it traps, the compiler resets the invalid flag, and if the trap wasn't caused by stack overflow, it just continues. ... Numerics can be a lot simpler than they are, but they are not as simple as Java thinks, and they are not as simple as Microsoft thin