33 ms·

Every time I hear people talking about ensuring software correctness, it reminds me of this story: https://horningtales.blogspot.com/2006/09/exhaustive-testing.

Every time I hear people talking about ensuring software correctness, it reminds me of this story: https://horningtales.blogspot.com/2006/09/exhaustive-testing.html https://horningtales.blogspot.com/2006/09/exhaustive-testing... A university group in the 1960s finds a vendor-supplied binary-to-BCD conversion function sometimes produces an off-by-one error. They devise a simple fix - but find it adds an extra 'drum revolution' and so write an even more refined fix, that produces the right answer without taking any extra time. Then they test it, over the course of several weeks, counting from 0 to 9,999,999, both in binary and in BCD, converting the binary to BCD, and comparing the results. They proudly send the perfected implementation to the vendor - who sends it on to other users of the machine. Soon after they receive a phone call: "Were you aware that your new routine drops the sign of negative numbers?"

pjdesno 1y ago
When I was an intern in the mid-80s we were cross-compiling for a 68000-based device (on a VAX, no less) but had our own version of the C library, supposedly because of some legal issues with the compiler vendor. Part of this library was the routine to divide 32-bit integers, since the only native divide was 16x16 -> 32. Our implementation was the textbook shift-and-subtract algorithm, which took something like 1000 cycles on that CPU. Our routing algorithm did enough division that this ended up being a big deal, so they asked their intern to optimize it. I came up with a version using the hardware instruction that was maybe 5-10x faster; they tested it a bit and sent a software update out to customers, after which the "phone home" monitoring (using real phone lines and modems in those days) started blowing up. If you divide by zero, naive shift-and-subtract will return MAXINT, while the hardware instruction will raise a divide-by-zero exception. On startup we had a bunch of averages that were default-initialized to zero, and we'd divide by some of them. Getting 32-bit MAXINT wasn't a really big deal - it put a big spike into some moving averages, which decayed pretty quickly. An unexpected exception, though, was a big problem...

pjdesno 1y ago

When I was an intern in the mid-80s we were cross-compiling for a 68000-based device (on a VAX, no less) but had our own version of the C library, supposedly because of some legal issues with the compiler vendor. Part of this library was the routine to divide 32-bit integers, since the only native divide was 16x16 -> 32. Our implementation was the textbook shift-and-subtract algorithm, which took something like 1000 cycles on that CPU. Our routing algorithm did enough division that this ended up being a big deal, so they asked their intern to optimize it. I came up with a version using the hardware instruction that was maybe 5-10x faster; they tested it a bit and sent a software update out to customers, after which the "phone home" monitoring (using real phone lines and modems in those days) started blowing up. If you divide by zero, naive shift-and-subtract will return MAXINT, while the hardware instruction will raise a divide-by-zero exception. On startup we had a bunch of averages that were default-initialized to zero, and we'd divide by some of them. Getting 32-bit MAXINT wasn't a really big deal - it put a big spike into some moving averages, which decayed pretty quickly. An unexpected exception, though, was a big problem...