Computers and Infallibility

[Amtran]

My friend and I were having a discussion, and an interesting question came up. Neither one of us could prove it, but my friend said that computers are infallible. Any error, any miscalculation, are all the programmer's or builder's fault. A computer will never do something wrong, rather it will do something that the programmer told it to do, that was in fact wrong.

Any thoughts?
NOTE: Hardware malfunctions don't count as the computer being wrong.

EDIT: Whoops, meant to put this in the computer science forum. Sorry!

[MrBlueSky]

If whatever wrong answers come out of the machine are the programmer's fault, then it follows that whatever right answers that come out of the machine are also the programmer's fault.

Computers are just tools. You might as well argue that a hammer is infallible because if it misses the nail it's the carpenter's fault, not the hammer's.

[oxy]

Rounding errors? But I suppose that the failure to take them into account is a programming error.

[qbg]

Do you count cosmic ray bit flips as a hardware malfunction?

[Amtran]

Do you count cosmic ray bit flips as a hardware malfunction?

hahahaha

So whenever you get an error, is it always a programming (or hardware) error? Can a computer ever just screw up on its own?

[thoughtfully]

Looks like those poor cosmic rays have been getting a bad rap!
It's actually alpha emission from materials in the computer. Actually, in the exact chip that is affected, since alphas don't penetrate worth a damn.

[Area Man]

So whenever you get an error, is it always a programming (or hardware) error? Can a computer ever just screw up on its own?

Despite the common terminology, a computer never "decides" anything - it is not sentient, only sends signals (input) through gates to output; the operation rules are rigidly set.
So it's like asking if a piece of copper wire conductor can ever be "wrong", not counting physical damage. It does not have ability to conduct or not conduct at its pleasure.

Indeed, one of the hardest things to do on a computer is generating truly random values.

[bieber]

In general, no, there's no chance that a computer will randomly do something "wrong." As a poster above mentioned, the laws of physics rigidly govern what goes on inside the machine. It is worth noting, however, that there are more than enough steps where something can go wrong outside of your control that it's easy for incorrect results to appear random. For instance, there could be an issue with the CPU itself (here's looking at you, Pentium), or there could be a bug in your compiler that's causing perfect looking code to execute incorrectly.

Or, on a less sophisticated level, I once had corrupt data keep turning up on a hard disk. I replaced the disk twice before I finally discovered that it was, in fact, faulty RAM that was responsible for the corruption. In the face of factors beyond our control that make things go wrong even when we're certain that we've got everything in order, it's understandable that people would perceive computers as "fallible." Remember, that machine humming away underneath your desk is orders of magnitude more complicated than probably any other piece of equipment you'll work with on a day-to-day basis; getting its pieces to work together flawlessly can be quite a task, and people can and will mess it up at a lot of different stages.

[Berengal]

A CPU might give wrong answers without having a bug, and without hardware failure. Under normal circumstances this can't happen, but if you've ever overclocked your pc you'll know there's a point where your computer starts becoming unstable. You've either turned the clock up too much, causing synchronization to fail and signals to be mixed, or the voltage up too much causing electricity to spill outside its intended paths (or it's become too hot, which brings down the limit on both the clock and voltage). It's not a programmer error, but nor is it a hardware error; the CPU still works as expected without any cracks, breaks or fractures. While it's possible the CPU might be damaged this way it's certainly not guaranteed, and the instability alone is not an indication that it is.

In short, failures may be caused by operational parameters that are outside the spec of the hardware without there being anything wrong with either the hardware or the code itself. Indeed, CPUs aren't all alike, and chips intended to be identical may be sold as different classes because some of them weren't stable enough at the intended settings, but are stable at lower settings.

Indeed, one of the hardest things to do on a computer is generating truly random values.

In my experience, user input is indistinguishable from true random values.

[Indefinity]

Indeed, one of the hardest things to do on a computer is generating truly random values.

In my experience, user input is indistinguishable from true random values.

Code: Select all

// JavaScript random number function that is guaranteed to produce a random number or an angry user, or possibly both
randomInt = function() {
  var x = null;
  while (!x) {
    x = Number(prompt("Enter a random number", 4));
  }
  return x;
}

Well that was easy.

All kidding aside, I like the hammer analogy the best.

And to wander off topic just slightly, we can prove (with a lot of work) that software components can be absolutely correct. I assume that we can prove (with a lot of work) that hardware components are absolutely correct. Given both of these assumptions (and no overclocking), is it possible to create a program that cannot fail? Or will there always be small outside forces acting on the computer that can throw things off?
And to wander off topic just slightly, we can prove (with a lot of work) that software components can be absolutely correct. I assume that we can prove (with a lot of work) that hardware components are absolutely correct. Given both of these assumptions (and no overclocking), is it possible to create a program that cannot fail? Or will there always be small outside forces acting on the computer that can throw things off?

[Cleverbeans]

I think the Pentium FPU problems are proof enough that computers can indeed be fallible without a software error.

[octonion]

To paraphrase Dijkstra: "The question of whether a computer can think make mistakes is no more interesting than the question of whether a submarine can swim."

Right now it's easy to trace bugs back to human programmers whose code did not match the behavior they had in mind. Some future computer that could intelligently modify its own behavior might be seen as having more responsibility for its "mistakes".

[Area Man]

I think the Pentium FPU problems are proof enough that computers can indeed be fallible without a software error.

The cause of the problem traces itself to a few missing entries in a lookup table used in the hardware implementation algorithm for the divide operation.

Sounds like a builder error to me.
High-k gates and EMI shielding have their limits, and are engineered for such, including various error detection/correction/coding procedures.

A computer that doesn't follow instructions precisely is broken by definition.

In my experience, user input is indistinguishable from true random values.

User input is _user_. Put. In.
...besides other problems. But that's probably off topic.

To err is human, and so forth.

[Cleverbeans]

A computer that doesn't follow instructions precisely is broken by definition.

If we're going to exclude hardware and software errors then I guess the question reduces to "Are Turing Machines ever wrong?" and the answer is... only when asked to do something incomputable? I'm forced to agree with the swimming submarine analogy at this point.

[Area Man]

If we're going to exclude hardware and software errors then I guess the question reduces to [ ... ]

Scroll up to read Amtran's question.

[Yakk]

When designing hardware, the designers accept a certain level of error.

They may use error correction, but even that only is against a certain level of error.

In general, hardware is expected to fail, by design. It is just expected to fail rarely. One way to make it 'rare enough' is to design your hardware such that expected time between failures is on the order of the heat death of the universe (or some other ridiculous duration), then wash your hands of the problem.

[ttnarg]

Computer Errors do happen but User/coder errors are far more common. the best example are networks we link computers together with a very long cable and try to crame as much data down the cable as possable. When we put so much down we have problems reading it 100% of the time we add checksums at the other end to tell if we read it right. but if some of out data is croupted by noise on the line there is a random chance that the checksum would look right. Is this a computer error or a user error? Its the same inside the computer the faster we make computer the more we have to be carfull about this stuff but 99.9999% of the time its the human problem.

PS is the dead pixal on my screen a computer error?

[not baby Newt]

One aspect of programming error is that there are a LOT of programmers who have to be fairly close to correct for a computer to do what you want. Various OS components and such could in theory spoil your pie.

[Rockberry]

No, computers are not infallible.

[You, sir, name?]

There's always the off chance that sufficient electron tunneling occurs for a bit to randomly flip in such a manner that the program is wrong. It shouldn't be a common occurrence, but it's not entirely preposterous to suggest either. Probably about as common as cosmic rays.

[WarDaft]

Deterministic computation is tautologically infallible, because if it could make a mistake at some point, it wouldn't be deterministic. The question then becomes how close is a physical computer to a theoretical computer, and the answer is pretty close.

[Daniel Newby]

Computers are fallible by design!

<EE lecture mode>

One way they can break is metastability. Suppose your computer is sampling an external binary signal (say, USB cable), and the sampling clock happens to align with a change on the input. The sampling circuit can end up storing neither zero nor one, but some intermediate voltage, a metastable state. The downstream logic circuits can do just about anything when presented with a crazy signal like that. Like a pencil balanced on its point, pretty soon the stored value will tip one way or the other due to random environmental influences, but "pretty soon" turns out to be a long time when the clock ticks a billion times a second. You can do use things like a chain of sampling circuits (flip-flops) to reduce the failure rate to microscopic levels, but the failure rate is never exactly zero.

Another way they can break is random noise. These days, hard drives and wireless cards don't even pretend to use strong signals. Instead they keep packing in more bits until the noise is a major fraction of the signal, then fix it later with an error correcting code. Since you have to put in an error correcting code anyway, you might as well pack in three times the data while you're at it. The thing is, the correction only work statistically. You can make the failure rate extremely low, but never zero.

</EE lecture mode>

[ttnarg]

random fact:

When they make the PS3 they make it with 8 'cores' co-prossecssers but the odds the all of them are going to work is low*. the odds that 7 of them work is much higher so the all PS3 games have to work on a PS3 with 7 cores... inface if all 8 work they disable one.


* what low meens I dont know maybe 1 in 4 not working is too low to be proftiable

[You, sir, name?]

random fact:

When they make the PS3 they make it with 8 'cores' co-prossecssers but the odds the all of them are going to work is low*. the odds that 7 of them work is much higher so the all PS3 games have to work on a PS3 with 7 cores... inface if all 8 work they disable one.^{[citation needed]}


* what low meens I dont know maybe 1 in 4 not working is too low to be proftiable

Fix'd.

[Xanthir]

I wish you'd fixed the rest of it.

[hintss]

here:

*overclock
*hammer
*lN2
*memory overflow error due to hardware limitation
*butterfly
*dust in manufacturing
*if the computer is a lone transistor. hooked up backwards
*Woz's knight's tour program(froze computer due to hardware speed limitation
*complaining about slow virtualisation when you don't have a virtualisation chip
*complaining about bad gaming when on an Altair with no terminal or teletype