Re: Yet another Attempt at Disproving the Halting Problem

[Alan Morgan]

In sci.logic, Peter Olcott
<[email protected]>
wrote


Actually, it's possible to determine whether most programs halt,
using various heuristics. Just not all of them.

I suspect that "most" in this case means the same as "most" in the
setence "we can compress most files", i.e. it actually means "most
of the ones in which we are interested, but actually just a tiny
fraction of all possible ones".

Alan

 

[>parr\(*>]

|
| The only reason that not everyone
| has agreed with everything
| that I have said is that they don't
| bother to examine what I am
| saying at the same level detail that
| makes what I say become true.
| I a very subtle level of detail
| nearly everything that I have said
| is fully true.

A. Above, you provided a number of assertions:

1. "nearly everything I have said is fully true"

2. "Not everyone has agreed with everything I have
said"

I understand both those, and I agree with them, and the second one
naturally follows from the first.

3. "they don't ... examine what I am saying"

Up to a point, most of us have examined what you have been saying.
In sci.logic, some have reeled back in disgust from the illogical way
you present your case. If you don't believe me, reread the replies
you have been receiving. In comp.theory they have examined what you
write and have found it wanting in computer theory. If you don't
believe me, reread the replies you have been reading. In
comp.lang.c++, to be quite honest, I haven't analysed their reaction,
so you're off the hook on that one.

Regardless of the above, my observation is that _you_, Peter Olcott,
are the one who doesn't bother to examine what others are saying.

B. Let's now examine the more subtle points you bring out:

4. "what I am saying has a [implied from 'at the same'] level [of]
detail that
makes what I am saying become true"

How are we to understand this? My understanding follows.
If you statements are not examined in a sufficient level of detail by
everyone, they remain untrue.
If everyone examines what you are saying in sufficient detail, they
change from being false to true.

5. The only reason [2.] is [that] [3.]

In other words, ignoring the qualifying stuff relating to subtlety,
you are saying people don't understand because they don't examine.

You do not seem to be taking into account the number of times, the
content, and the extent to which people have demonstrated (e.g., by
rephrasing, by asking for clarification, by showing you exactly where
your errors are, and why).

I beg to suggest that people do not understand what you are saying is
because it is so confusing that, even assuming correctness, it would
be incomprehensible.


6. "I[n] a very subtle level of detail, [1.]"

How are we to understand this? Is there some unsubtle level of
detail which causes [1.] to be inverted? If so, is the inversion of
'fully', or of 'nearly everything'? To put it another way, is it the
case that:
"at an unsubtle level of detail, nearly everything you have said is
fully untrue"
or
"at an unsubtle level of detail, nearly nothing of what you have
said is fully true"
?

I trust the distinction between the above given alternatives is not
too subtle for you to understand.

Whichever way it is to be interpreted, your own words say that,
unsubtly, what you say is untrue.

At last we seem to have found some common ground again.
~~~~~~~~~
I trust I have done justice to what you wrote. I have examined it
extreme and careful detail. I have searched for the subtleties of
meaning.

By doing so, I find what you said above, while not fully true (as you
yourself admit) is, in part, subtly true.

 

[>parr\(*>]

| Well, but now we come back to the famous cautionary note, whose
| author I knew once upon a time, but have now forgotten, but which
| _I_ first saw quoted by Jay Maynard:
|
| Never attribute to malice that which can be adequately
| explained by stupidity.

Seems to have no identified originator:
--"Hanlon's Razor"; variations variously attributed to Goethe,
Napoleon
http://en.wikiquote.org/wiki/Stupidity

But worry not, that page has 30 odd relevant quotes, many attributed,
the first of which brought a tear to my eye:
A man learns to skate by staggering about and making a fool of
himself; indeed, he progresses in all things by making a fool of
himself. --George Bernard Shaw

Perhaps we should revise our opinions of Peter. It could be that
he's a very intelligent, and, for his age, exceedingly well read 8
year old.

 

[Kent Paul Dolan]

http://en.wikiquote.org/wiki/Stupidity

A more intellectually honest person than I am wouldn't
start using those in conversations with Polewka and
Sempsey.

I especially loved:

Genius may have its limitations,
but stupidity is not thus handicapped. --Elbert Hubbard

of which Usenet provides abundant examples.

I suppose I should also heed:

With the whole world full of fools, there is none who
thinks himself one, or even suspects it. --Unknown

but that is much harder.

Sempsey got encapsulated perfectly:

A stupid man's report of what a clever man says is never
accurate because he unconsciously translates what he
hears into something he can understand. --Bertrand Russell

As did the reason for George W. Bush's likely re-election:

Get all the fools on your side and you can be elected to
anything. --Frank Dane

Excellent URL, all in all.

xanthian.

 

[Peter Olcott]

Regardless of the above, my observation is that _you_, Peter Olcott,
are the one who doesn't bother to examine what others are saying.

I provide a very detailed step-by-step execution trace that completely
proves my point, and all I get is a bunch of rude comments from people
that have not yet grown up, despite their advanced age.

In other words, ignoring the qualifying stuff relating to subtlety,
you are saying people don't understand because they don't examine.

You do not seem to be taking into account the number of times, the
content, and the extent to which people have demonstrated (e.g., by
rephrasing, by asking for clarification, by showing you exactly where
your errors are, and why).

Most of this was purely unsupported claims filled with rhetoric.
Here is my next major point. The Halting Problem can be solved
by maintaining separate memory space.

bool WillHalt02() can see that LoopIfHalts will halt.

//
// All of the functions are assumed to be standard C++
//
void LoopIfHalts (string ProgramSourceFile, string InputData)
{
if WillHalt01(ProgramSourceFile, InputData)
while (true)
;
else // to make it easier for people who don't know C++
return;
}

bool WillHalt02(LoopIfHalts, LoopIfHalts)




)>==ss$$%PARR(º> Parr

 

[Robert Low]

I provide a very detailed step-by-step execution trace that completely
proves my point, and all I get is a bunch of rude comments from people
that have not yet grown up, despite their advanced age.

Maybe that's because we're naive enough to think
that you ought to have a program before you can have
an execution trace. Or because you consistently ignore
it when people politely point out your misconceptions.
(The rudeness generally comes later.)

 

[Peter Olcott]

A working WillHalt01 cannot exist. A working WillHalt02 cannot
exist. Therefore, there can be no result from invoking WillHalt02.
Which is sort of the point of the whole proof, actually.

You are not taking what I say at face value. The way that
you are reasoning, this could be proof that the Halting Problem
is incorrect, and since it violates you pre-conceived notions,
you won't be able to see it.

All that Alan Turing proved conclusively was that no halt
analyzer that always returns its result back to the program
being analyzed will always return correct results.

There are far more than zero loopholes in this proof.

 

[Peter Olcott]

Just remember: "nearly" is merely a polite way of saying "not."

Many of the most important things that I have said are completely true,
yet not acknowledged as true by anyone else. The execution trace of the
void WillHalt() function and the bool WillHalt() function producing different
results even though only the form of the output is changed from a return
value to being written on the screen.

This is 100% obviously true. If you don't return that value to the program
being analyzed, then it can't change the result of the analysis, If you do return
this value, then it can change the resulting analysis.

Normally changing only the form of the output would not change the resulting
value of the output, if both the program and the data are the same. The Halting
Problem is not the normal case. Normally there is not a feedback loop between
what is being analyzed, and the analyzer. In the case where there is such a
feedback loop, cutting off the data flow (by changing where the data is going)
changes the resulting analysis. Not a single person acknowledged the validity
of any of this.

 

[Peter Olcott]

Because in order to tell in advance the cases for which a Halt Analyzer
doesn't work, you must first solve the halting problem.

Ah so you can have no idea the the case that defined the Halting Problem
might be a problem, until after it is not a problem?

 

[Peter Olcott]

I still see no difference between the two claims, except that one makes a
guess at probability (without any justification to back up the guess), and
the other doesn't.

One example works 99.9999999999% of the time the other
example works 0.0% of the time. I guess that you are right
almost all and none are synonymous. Can I have 99.999%
(none) of your salary?

 

[Marc Goodman]

All that Alan Turing proved conclusively was that no halt
analyzer that always returns its result back to the program
being analyzed will always return correct results.

Wrong again. He showed no Halt Analyzer that correctly
decides all other Turing Machines will halt on given
input can be constructed. That whole "returning results
back to the program" thing is part of his _method_ for
proving this, not his conclusion.

 

[Peter Olcott]

Wrong again. He showed no Halt Analyzer that correctly
decides all other Turing Machines will halt on given
input can be constructed. That whole "returning results
back to the program" thing is part of his _method_ for
proving this, not his conclusion.

Yes, He showed that Y can not exist, and from this concluded
that X can not exist. Yet X and Y are not connected by logical
entailment.

 

[Howard]

Many of the most important things that I have said are completely true,
yet not acknowledged as true by anyone else. The execution trace of the
void WillHalt() function and the bool WillHalt() function producing different
results even though only the form of the output is changed from a return
value to being written on the screen.

This is 100% obviously true. If you don't return that value to the program
being analyzed, then it can't change the result of the analysis, If you do return
this value, then it can change the resulting analysis.

Normally changing only the form of the output would not change the resulting
value of the output, if both the program and the data are the same. The Halting
Problem is not the normal case. Normally there is not a feedback loop between
what is being analyzed, and the analyzer. In the case where there is such a
feedback loop, cutting off the data flow (by changing where the data is going)
changes the resulting analysis. Not a single person acknowledged the validity
of any of this.

Because it's a bunch of crap and everyone knows it.

A WillHalt algorithm that does not report its results is totally useless,
and determines exactly nothing. Saying that it can correctly analyze
anything is 100% meaningless if it does not return the results of that
analysis. It's like Schroedinger's cat. Maybe it's dead, maybe it's not.
If the observer (i.e., calling program) cannot determine the state of the
system, then there *is* no definite state! And the observer in this case is
NOT some computer operator staring at a screen... it is the calling program.
As far as the calling program is concerned, the success or failure of the
WIllHalt function is indeterminate. And an indeterminate state CANNOT be
considered a success state (unless it is ALSO considered a fail state,
simultaneously, but now we're getting into quantum physics!). A "void"
return value can only be considered "I don't know", not True or False.

Just because *you* know that the function *would have* returned True (or
False) if it could have, says nothing whatsoever, because *you* are not
relevant. Neither is your knowledge of the system state (whether by
observation, such as looking at the screen, or by logical conclusion that it
*must* be in such-and such as state). There is one and only one way for the
WillHalt test to be valid, and that is if it succeeds in answering the
question in the first place. However that answer gets from the WillHalt
function to the calling program, it MUST return that answer, or it has
FAILED to complete its analysis. And that is true whether you're talking
about a C++ function or any other form you might choose to consider for the
algorithm to take.

Your "void" function simply does not meet the requirements of determining
success or failure in the first place. I know you disagree, but hey, you're
simply wrong. Neener neener!

I must say however, that I've truly enjoyed watching you argue with everyone
else. There's only two kinds of people that could possibly continue to
argue the way you have, when absolutely everyone disagrees with you. Idiots
and Trolls. I'm not going to speculate which you are. But hey, thanks for
the entertainment!

-Howard

 

[Marc Goodman]

Yes, He showed that Y can not exist, and from this concluded
that X can not exist. Yet X and Y are not connected by logical
entailment.

Yes they are, as has been shown to you many times.

 

[Peter Olcott]

Maybe that's because we're naive enough to think
that you ought to have a program before you can have
an execution trace.

It was perfectly valid C++.

 

[stephen]

: Your "void" function simply does not meet the requirements of determining
: success or failure in the first place. I know you disagree, but hey, you're
: simply wrong. Neener neener!

The "void" function thing really does not matter. Even with that restriction
you can show that it does not alway print the correct value to the screen.
If WillHalt looks like

void WillHalt(string program, string input)
{
bool halt;
//
// do some calculations to compute halt;
cout << halt << endl;
}

it is guaranteed to print the wrong answer for the following program:

void f1(string program, string input)
{
bool halt;
//
// do some calculations to compute halt;
while (halt);
}

WillHalt has not been modified in any way, and it only prints its
value to the screen, but it is still trivial to show that there
are programs for which it will get the wrong answer.

Stephen

 

[Anonymous]

Nope. Back in Turing's day there was no such thing as being able to 'return
results back to a program' ... this is a convenience construct. What Turing
showed was that the diagonal machine

D(x) {
if halt(x, x) = 'Yes' then loop forever
else halt
}

is NOT a Turing Machine. He then looked at D to find out what was so
wretched about it that it is not a Turing Machine ...

Well the 'if' statement is sure fine ... it's easy to construct an if
statement. the 'loop forever' part is easy to do, just ... well ... loop
forever. An 'ELSE' clause is easy to execute at the appropriate time and we
can CERTAINLY halt any time we want. The only possibility is the halt
function ... the halt function must be the culprit ... the halt function
does NOT exist.

 

[Peter Olcott]

Nope. Back in Turing's day there was no such thing as being able to 'return
results back to a program' ... this is a convenience construct. What Turing
showed was that the diagonal machine

D(x) {
if halt(x, x) = 'Yes' then loop forever
else halt
}

is NOT a Turing Machine. He then looked at D to find out what was so
wretched about it that it is not a Turing Machine ...

Well the 'if' statement is sure fine ... it's easy to construct an if
statement. the 'loop forever' part is easy to do, just ... well ... loop
forever. An 'ELSE' clause is easy to execute at the appropriate time and we
can CERTAINLY halt any time we want. The only possibility is the halt
function ... the halt function must be the culprit ... the halt function
does NOT exist.

That sure sound like circular reasoning to me.
You start with the conclusion that the Halt function does not
exit, and golly gee, conclude that the halt function does not exist.
You don't think that you couldn't possibly show why the halt
function does not exist do you? I mean within the scope of how
I defined the separate memory space below. Within the assumption
of the separate memory space the typical, "whoops there is a
contradiction, thus is can't exist" can not occur.

 

[Peter Olcott]

: Your "void" function simply does not meet the requirements of determining
: success or failure in the first place. I know you disagree, but hey, you're
: simply wrong. Neener neener!

The "void" function thing really does not matter. Even with that restriction
you can show that it does not alway print the correct value to the screen.
If WillHalt looks like

void WillHalt(string program, string input)
{
bool halt;
//
// do some calculations to compute halt;
cout << halt << endl;
}

it is guaranteed to print the wrong answer for the following program:

void f1(string program, string input)
{
bool halt;
//
// do some calculations to compute halt;
while (halt);
}

WillHalt has not been modified in any way, and it only prints its
value to the screen, but it is still trivial to show that there
are programs for which it will get the wrong answer.

Stephen

If you provide any form of the original halting problem
as an example of this "wrong answer" I will be happy to
point out where you err.

 

[Peter Olcott]

Yes they are, as has been shown to you many times.

No, it has been assumed to be true, and stated as if it
was a fact, many times. It has never once been shown.