4 ms·
I can think of a few ways: - Hardware dies, logical or physical storage needs to be reloaded - Algorithm is challenged as incorrect, needs to be tested - Und
by tomrod 4y ago
I can think of a few ways:
- Hardware dies, logical or physical storage needs to be reloaded
- Algorithm is challenged as incorrect, needs to be tested
- Underlying hardware infrastructure adjusts to 64-bit hardware, and returns different values
- Intel decides to muck with the sine function near 0 (https://news.ycombinator.com/item?id=8434128 https://news.ycombinator.com/item?id=8434128, https://www.cs.earlham.edu/~dusko/cs63/fdiv.html https://www.cs.earlham.edu/~dusko/cs63/fdiv.html, https://github.com/torvalds/linux/blob/v5.9/arch/x86/kernel/fpu/bugs.c https://github.com/torvalds/linux/blob/v5.9/arch/x86/kernel/...)
and so on
- taeric 4y agoI don't want this to get distracted by chasing examples. If any of these are systemic, I'm curious. That said, my assertion was that evidence is the algorithms in question are still valid. Usually, they are still champions in speed. Certainly, folks have had to port and maintain the fortran compilers. Especially so to add targets. But the very stability of fortran, the language, is a big boon to those implementations not having bit rot. And while I know they could be reimplemented, in what language? And to what real advantage?