Intel Corporation (INTC) Message Board

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : Intel Corporation (INTC)

INTC 48.23

+2.3%

3:59 PM EST

Public Reply Prvt Reply Mark as Last Read File

Previous 10 Next 10 Previous Next

To: Dan Spillane who wrote (20733)	5/8/1997 5:48:00 PM
From: Martin Atkinson-Barr	of 186894

Yes, my 15mins of fame! The issue comes to so-called casting of data types. The C runtime library has to throw an exception if the float won't fit into the int. As you rightly say C does not return an error from an int cast. It relies on the runtime detecting an exception (testing the IE bit). This would be missed for the range of floats described by "Dan" and no runtime error would result. The only way arount it is to do a range comparison before you do the cast. The second part of your question is taken somewhat out of context. Here I am talking about the PE bit, the one that is set erroneously by the FIST(P). That is set all the time and is an indication of loss of precision. It is s et for instance by doing 1./3. since the answer cannot be accurately represented 0.333333.... in decimal. PE is therefore not an error flag and would be ignored EXCEPT in some very specialized packages that require EXACT arithmetic. An example of this would be a program to test the Riemann Hypothesis which states that all zeros of the Zeta function are EXACTLY on the line s=1/2. Loss of precision cannot be tolerated in trying to refute this so you use the PE bit, not as an error but as a flag to accomodate the change in precision. PE would never cause a runtime error. The bottom line is that this bug can & will cause wrong answers not just wrong errors. Collins thought that the wrong type of error was being thrown. I saw that no error was being thrown. That's all - a trivial observation really. Also a few people are only saying that this bug only applies to 80-bit numbers are not floats or doubles. What they fail to realize is that all calculations in the FPU are done in 80-bit and therefore this bug applies to all floating point calculations. Hope this helps

Report TOU Violation

Share This Post

Public Reply Prvt Reply Mark as Last Read File

Previous 10 Next 10 Previous Next