On making engineering calculations with slide rules:
Digital computers tend to hide the fact that most often values aren’t actually known to better than 2-3 digits of accuracy. Slide rules kept this fact at the forefront, and sometimes you had to sequence the order of operations carefully in order to preserve the accuracy.
In certain cases, the presumed superiority of digital computers actually masks and or causes errors, and here is an actual example:
This involves the control system for a water treatment system. It was desired to keep track of the operating time. So that the operator could easily verify that the timer was working, it was desired that the display have 1 second resolution and be updated every second. The system was intended to operate for decades, and the timer should not overflow for at least 50 years.
The original programmer decided to use a Float32 variable to represent the seconds of operation, allowing for up to somevalue * 10^^38 seconds. So the seconds counter would not overflow for something * 10^^30 years, thus overflow would never be a problem.
But hold on a second! (get it?). The precision of that 32 bit floating point is only a little over 7 decimal digits. So after about 4 months, when it adds 1 second to say 1.000000 *10^^7 seconds the answer as 1.000000 * 10^^7 (The same). The timer has stopped, because it has reached the point that one second is below the available precision. You can add 10 to that number, but you can’t add 1. The timer that was intended to work well beyond the expected lifetime of the universe will fail after ~4 months, and it did exactly that, which is how I got hired to fix it.
I recoded this to use a 32bit integer for the seconds counter. This will overflow after “only” 96 years of operation, by which time it will not be my problem. (but it will warn the operator if/when it gets close…cause after Y2K I am anal that way.)
There was a similar issue that involved integrating the reading from a flow meter to indicate volume. The programmer had not accounted properly for rounding error in a division, so it was under-reporting gallons by about 5-10%. This was also recoded to integer math, keeping track of and recycling the remainder to eliminate all accumulated error.
Now another option could have been to go to 64 bit floating point variables, but that was not an option on this PLC based system, and it would have only reduced the errors (OK, reduced them a LOT), while the integer solution reduced the math errors to zero in both cases, for half the memory resources (somewhat limited on a PLC)
Since then I have used the experience to avoid these sort of problems on other projects. It takes a while to make younger programmers see the issue, but those old enough to have used a slide rule only need a hint to get it.
On days when I yell at kids to get off my lawn, I worry that kids today are not only not learning how to do calculations, they are also failing to learn how calculations work.
Note: Float32 representation limitations are exact in binary. I used decimal approximations I know off the top of my head to illustrate the problem, because I’m too lazy to work out or research the exact numbers.