Hacker News new | past | comments | ask | show | jobs | submit login

> but not all instructions computed all of them correctly (https://www.infania.net/misc/coproc.html)

I failed to find which instructions weren't computed correctly in the text linked, and I'd like to know about that, that is, if it's something I wasn't aware of. Can you specify a bit more?




Search for “Accuracy of calculations performed by a coprocessor” in the article I linked to.

it says “Intel claims that maximum error in the 8087, 80287, and 80387 for all transcendental functions does not exceed two bits in the mantissa of the double extended format”. Typically, those reposts get rounded to double format, but that doesn’t guarantee that such errors get dropped.

Edit: http://www.math.utah.edu/~beebe/software/ieee/ has lots of links and code for testing floats.

http://li.mit.edu/Archive/Activities/Archive/CourseWork/Ju_L... gives quite a few corner cases, so it would be helpful when writing a test suite.

https://slixe.de/stash/projects/MAS/repos/libfirm/browse/ir/... has source code for a/the compliance checker

https://core.ac.uk/download/pdf/151193633.pdf describes what seems to be a Better version of that test framework (it adds “++” to the name). Unfortunately I couldn’t find its source code.


That statement that you refer to regarding the instructions for transcendental functions in 80 bits doubles is the result of the way the hardware and the microcode for these functions are implemented. Internally, out of 80 bits, 64 bits are available for mantissa and the steps for calculating the result accumulate the error, and then the last two bits in these transcendental functions are "noisy" which was still very good for its time. And it was documented.

But that's still only for the "convenient" input range for the implemented algorithm.

In practice, the programmers sometimes want to pass the values from the less convenient input range, and then it got much worse when the library functions in high level languages have expected too much from the implementation in the processor:

https://randomascii.wordpress.com/2014/10/09/intel-underesti...

The resulting problem in the high level implementation described described was blind belief in the wrong (in not correctly stating the input range) documentation by some that then implemented the C library functions for some environments, only a few years ago:

The Intel's documentation was "buggy. By claiming near-perfect accuracy across a huge domain and then only providing it in a tiny domain Intel has misled developers and caused them to make poor decisions."

And it was fixed in 2014:

https://software.intel.com/blogs/2014/10/09/fsin-documentati...




Consider applying for YC's W25 batch! Applications are open till Nov 12.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: