Miscomputation: Learning to live with errors
1–7 of 7 posts
Re: Miscomputation: Learning to live with errors
#2errors being acceptable is why the challenger disaster happened. Ok, not really, but you get the point.
Everyone has to evaluate the risk of the errors and act accordingly.
Re: Miscomputation: Learning to live with errors
#3errors being acceptable is why the challenger disaster happened. Ok, not really, but you get the point. Everyone has to evaluate the risk of the errors and act accordingly.
It's likely worth noting that the shuttle has a famously robust computer system. The Challenger was related to an engineering flaw in the mechanical design of the system.
I forget my source, but IIRC the computer system actually noticed the pressure drop from the fuel lines (what with the exploding) and started the shutdown process, spinning down the turbos before the system was forcefully disassembled. Takes a while to turn off the turbos; a few hundred milliseconds really isn't enough time...
[0] Obligatory link to the Feynman report
http://www.nasa.gov/mission_pages/shuttle/flyout/flyfeature_...
[1] A cool article on the software running the shuttle
Re: Miscomputation: Learning to live with errors
#4I suspect as Moore's law runs out we will see a rise in speculative computing, where we write our code to work off of fast estimates of slow calculations (ie, detectable mistakes), and then double-check the work before committing the answer at the end.
Video games already do something like this to hide latency in multi-player scenarios. A generalized solution would be interesting, although given our track record with shared state concurrency, it may prove too confusing for the average dev.
Re: Miscomputation: Learning to live with errors
#5errors being acceptable is why the challenger disaster happened. Ok, not really, but you get the point. Everyone has to evaluate the risk of the errors and act accordingly.
It's likely worth noting that the shuttle has a famously robust computer system. The Challenger was related to an engineering flaw in the mechanical design of the system. I forget my source, but IIRC the computer system actually noticed the pressure drop from the fuel lines (what with the exploding) and started the shutdown process, spinning down the turbos before the system was forcefully disassembled. Takes a while…
The flaw of the O-rings was known, but the risk was considered acceptable by management.
This is specifically why I couched my answer in terms of risk. This was not specifically about the computer system, this was about the mis-assessment of risk.
Re: Miscomputation: Learning to live with errors
#6Earlier quoted context omitted.
It's likely worth noting that the shuttle has a famously robust computer system. The Challenger was related to an engineering flaw in the mechanical design of the system. I forget my source, but IIRC the computer system actually noticed the pressure drop from the fuel lines (what with the exploding) and started the shutdown process, spinning down the turbos before the system was forcefully disassembled. Takes a while…
The flaw of the O-rings was known, but the risk was considered acceptable by management. This is specifically why I couched my answer in terms of risk. This was not specifically about the computer system, this was about the mis-assessment of risk.
So you're saying that we have a cult of unbounded precision due to our low confidence in appropriately assessing risk?
Re: Miscomputation: Learning to live with errors
#7errors being acceptable is why the challenger disaster happened. Ok, not really, but you get the point. Everyone has to evaluate the risk of the errors and act accordingly.
The article isn't saying that letting errors happen is the best way to go about things in all cases. There is certainly room for proof and extreme caution!
That said, you do not need to prove everything about your algorithm. I imagine that in the future, we'll write software with base runtime system that has some basic sanity properties (proved) and on top of that, there will be layer that handles things in a more flexible way. Kind of like having Challenger JVM which is provably correct and never crashes and lots of apps on top of that :-)