3 ms·

(Note the "couple hours" to get one number.) Perfectly suitable. But they did have a couple of hours to come up with the right numbers, and they did have slid

(Note the "couple hours" to get one number.) Perfectly suitable. But they did have a couple of hours to come up with the right numbers, and they did have slide rules and graphical methods as backup. That is what allows evolution, you can't believe a computer right from the start and instantly abandon older methods. Those methods have a place. In fact if an African student wanted to be a mathematician, a slide rule--due to its analog nature would--set him ahead and allow him faster results than his peers. Whereas a calculator you don't know where you've got it wrong.

WalterBright 4y ago
Of course. The speedup wasn't in writing the program to do the calculations. The speedup was in being able to run the program repeatedly as the design got tweaked. There was also the fact that once the program proved correct, the iterations were also free of error. For example, if I write a program to compute sin(x), I only need to check a few points to verify it. Doing it graphically or by hand can introduce error for every use.
- operator-name 4y ago
  > once a program proved correct Now that's the incredibly difficult part, as bugs are no stranger to code, let alone code that tries to model the real world with assumptions. The sin function is actually incredibly incredibly complex (https://stackoverflow.com/questions/2284860/how-does-c-compute-sin-and-other-math-functions https://stackoverflow.com/questions/2284860/how-does-c-compu...) and implimentation are full of implicit and imperfect assumptions (like floating point). Under normal use these errors are silently propogated, and the floating point model well designed enough that for the majority it doesn't matter at all. Being able to run a model whilst iterating is great, but at the end of the day it's still a model, and could break down.
  - WalterBright 4y ago
    I'm painfully aware of that. My biggest enemy was accumulating roundoff error. I'd check the results by running the reverse algorithm to see if the outputs reproduced the inputs. For example, I'd check the matrix inversion by multiplying the input by the inverse and seeing how close it got to the identity matrix.

WalterBright 4y ago

Of course. The speedup wasn't in writing the program to do the calculations. The speedup was in being able to run the program repeatedly as the design got tweaked. There was also the fact that once the program proved correct, the iterations were also free of error. For example, if I write a program to compute sin(x), I only need to check a few points to verify it. Doing it graphically or by hand can introduce error for every use.

operator-name 4y ago
> once a program proved correct Now that's the incredibly difficult part, as bugs are no stranger to code, let alone code that tries to model the real world with assumptions. The sin function is actually incredibly incredibly complex (https://stackoverflow.com/questions/2284860/how-does-c-compute-sin-and-other-math-functions https://stackoverflow.com/questions/2284860/how-does-c-compu...) and implimentation are full of implicit and imperfect assumptions (like floating point). Under normal use these errors are silently propogated, and the floating point model well designed enough that for the majority it doesn't matter at all. Being able to run a model whilst iterating is great, but at the end of the day it's still a model, and could break down.
- WalterBright 4y ago
  I'm painfully aware of that. My biggest enemy was accumulating roundoff error. I'd check the results by running the reverse algorithm to see if the outputs reproduced the inputs. For example, I'd check the matrix inversion by multiplying the input by the inverse and seeing how close it got to the identity matrix.