This is both brilliant and profoundly stupid.Report
Many years ago I was hired to port a large complex piece of nonlinear optimization Fortran code from an IBM mainframe system to a CDC system. In those days before IEEE 754, CDC’s floating point unit included a special bit pattern that represented the value “indefinite”. There was still a sign bit, so both positive and negative indefinite were things. Executing an instruction that produced an indefinite result — most commonly, dividing by zero — didn’t generate a hardware error. Attempting to do something with an indefinite value — say, executing 1+indefinite — did generate a hardware error. One other difference between the IBM and CDC machines was important. IBM zero-filled memory and then loaded the program, so uninitialized floating point data had the value zero. CDC filled memory with negative indefinite and then loaded the program, so uninitialized floating point data had the value negative indefinite.
Did I mention that the code had been buggy as hell on the IBM hardware? So not only was I porting it, I was trying to debug it as well. After I got it to compile, I tried running it on the first of the collection of test problems. Hardware fault, attempt to use negative indefinite. Working my way backwards, I eventually found how that particular variable had been set to negative indefinite: several pages away in the code, there was a divide-by-zero that only manifested later. There were a whole raft of odd little errors in the code that produced indefinite values that were only exposed in a completely different place. Many of the errors would have been obvious on inspection if the graduate students who had written the code originally had used any sort of decent practices. But, those were still the days of “cowboy coding”.
The algorithm, and originally some of the code base, ended up in the Solver tool in Microsoft Excel. I still have the nonlinear programming textbook that had the test problems I was supposed to solve. A few years ago I set it up one of the problems that gave the code fits when I was working on it. Still failed in the same way that it had failed so long ago.Report
This type of discussion always reminds me of demonstrations about JavaScript and its (occasionally) absurd automatic type-casting:
linux> node
> '11' + 1
'111'
> '11' - 1
10
> [] + {}
'[object Object]'
> {} + []
0
>{} - {}
NaN
> Report
If you enjoyed this video, you might also like a book called Mathematics Made Difficult, by Carl E
Linderholm, which explains simple arithmetic by appealing to category theory. Unfortunately, it’s out of print and the cheapest copies I see go for about $100.Report
PDF copies are floating around the internet. Rather large, since they are basically a collection of pictures of the individual pages.Report
This is both brilliant and profoundly stupid.Report
Many years ago I was hired to port a large complex piece of nonlinear optimization Fortran code from an IBM mainframe system to a CDC system. In those days before IEEE 754, CDC’s floating point unit included a special bit pattern that represented the value “indefinite”. There was still a sign bit, so both positive and negative indefinite were things. Executing an instruction that produced an indefinite result — most commonly, dividing by zero — didn’t generate a hardware error. Attempting to do something with an indefinite value — say, executing 1+indefinite — did generate a hardware error. One other difference between the IBM and CDC machines was important. IBM zero-filled memory and then loaded the program, so uninitialized floating point data had the value zero. CDC filled memory with negative indefinite and then loaded the program, so uninitialized floating point data had the value negative indefinite.
Did I mention that the code had been buggy as hell on the IBM hardware? So not only was I porting it, I was trying to debug it as well. After I got it to compile, I tried running it on the first of the collection of test problems. Hardware fault, attempt to use negative indefinite. Working my way backwards, I eventually found how that particular variable had been set to negative indefinite: several pages away in the code, there was a divide-by-zero that only manifested later. There were a whole raft of odd little errors in the code that produced indefinite values that were only exposed in a completely different place. Many of the errors would have been obvious on inspection if the graduate students who had written the code originally had used any sort of decent practices. But, those were still the days of “cowboy coding”.
The algorithm, and originally some of the code base, ended up in the Solver tool in Microsoft Excel. I still have the nonlinear programming textbook that had the test problems I was supposed to solve. A few years ago I set it up one of the problems that gave the code fits when I was working on it. Still failed in the same way that it had failed so long ago.Report
“What number did it produce?”
“N(ot)AN(umber).”
“Oh, I thought the output was a number.”
“It is. Its an IEE745 floating-point number.”
“OK, what number is it?”
“N(ot)AN(umber).”
“Whatever. You know, I don’t give a darn.”
“What?”
“I don’t give a darn.”
“Oh, that’s our shortstop!”Report
This type of discussion always reminds me of demonstrations about JavaScript and its (occasionally) absurd automatic type-casting:
linux> node
> '11' + 1
'111'
> '11' - 1
10
> [] + {}
'[object Object]'
> {} + []
0
>{} - {}
NaN
>
If you enjoyed this video, you might also like a book called Mathematics Made Difficult, by Carl E
Linderholm, which explains simple arithmetic by appealing to category theory. Unfortunately, it’s out of print and the cheapest copies I see go for about $100.Report
PDF copies are floating around the internet. Rather large, since they are basically a collection of pictures of the individual pages.Report