Refuting the Peter Linz Halting Problem Proof V4

[PeteOlcott]

OK so clearly the computer science is beyond your technical capacity.

No, it isn't.

It's beyond yours.

All deciders must compute the mapping from their inputs to an accept/reject state
on the basis of a property of these inputs thus

All halt deciders must compute the mapping from their inputs to an accept/reject state
on the basis of a the actual behavior specified by these actual inputs.

The above two things are verifiable facts (that you are unaware of) and my conclusion
logically follows as a necessary consequence these facts.

[Skepdick]

All deciders must compute the mapping from their inputs to an accept/reject state
on the basis of a property of these inputs thus

All halt deciders must compute the mapping from their inputs to an accept/reject state
on the basis of a the actual behavior specified by these actual inputs.

The above two things are verifiable facts (that you are unaware of) and my conclusion
logically follows from these facts.

None of that shit matters dude. You are bogged down in implementation details.

IF a universal halting decider H exists THEN the universal halting decider will (SOMEHOW, MAGIC!) map P to one of two states.

P halts.
P does not halt.

HOW H arrived at this mapping is neither interesting nor relevant. All that matters is that BY DEFINITION H is an algorithm which CORRECTLY computes whether arbitrary algorithms halts.

IF H is an algorithm which correctly computes whether P halts.
AND P is an algorithm which does the opposite of what H predicts.

You have yourself an impossible situation.

[PeteOlcott]

All deciders must compute the mapping from their inputs to an accept/reject state
on the basis of a property of these inputs thus

All halt deciders must compute the mapping from their inputs to an accept/reject state
on the basis of a the actual behavior specified by these actual inputs.

The above two things are verifiable facts (that you are unaware of) and my conclusion
logically follows from these facts.

None of that shit matters dude. You are bogged down in implementation details.

IF a universal halting decider H exists THEN the universal halting decider will (SOMEHOW, MAGIC!) map P to one of two states.

P halts.
P does not halt.

HOW H arrived at this mapping is neither interesting nor relevant. All that matters is that BY DEFINITION H is an algorithm which CORRECTLY computes whether arbitrary algorithms halts.

P is then defined such that whatever H computetes - P does the opposite.

You can't just bluff your way through the computer science of it.

[Skepdick]

You can't just bluff your way through the computer science of it.

I know. You've been bluffing for 15000+ hours and it's clearly not working.

[PeteOlcott]

You can't just bluff your way through the computer science of it.

I know. You've been bluffing for 15000+ hours. Have you considered stopping?

I have been working on the basis of trial-and-error.
I have made very many small mistakes yet have never been
wrong on the essential gist of Gödel's incompleteness, Tarski
undefinability, the halting problem, and the Liar Paradox.

I wish that you understood that the computer science of what
I just said is verifiably correct.

[Skepdick]

I have been working on the basis of trial-and-error.
I have made very many small mistakes yet have never been
wrong on the essential gist of Gödel's incompleteness, Tarski
undefinability, the halting problem, and the Liar Paradox.

I wish that you understood that the computer science of what
I just said is verifiably correct.

Nothing of what you are saying is correct because you are muddling up the program P with the evaluation of a program eval(P).

And this is confusing you because C doesn't have eval() !

Python does.
Bash does.
LISP does.
C doesn't.

So you cannot do things like this in C

Code: Select all

In [1]: x = 5

In [2]: program="x+x"

In [3]: eval(program)
Out[3]: 10

[PeteOlcott]

I have been working on the basis of trial-and-error.
I have made very many small mistakes yet have never been
wrong on the essential gist of Gödel's incompleteness, Tarski
undefinability, the halting problem, and the Liar Paradox.

I wish that you understood that the computer science of what
I just said is verifiably correct.

Nothing of what you are saying is correct because you are muddling up the program P with the evaluation of a program eval(P).

And this is confusing you because C doesn't have eval() !

Python does.
Bash does.
LISP does.
C doesn't.

So you cannot do things like this in C

Code: Select all

In [1]: x = 5

In [2]: program="x+x"

In [3]: eval(program)
Out[3]: 10

I wish that you understood that the computer science of what I just said is verifiably correct.
Apparently the one computer science professor that I know is the only one that can understand
these things.

[Skepdick]

I wish that you understood that the computer science of what I just said is verifiably correct.
Apparently the one computer science professor that I know is the only one that can understand
these things.

You can make it bolder and redder and you'll still be wrong.

You are unable to distinguish between P and eval(P).

And you are absolutely unable to comprehend self-interpretation e.g a language like LISP.


So things like this probably make absolutely no sense to you!

Code: Select all

In [1]: program="5+5"

In [2]: eval(program)
Out[2]: 10

In [3]: eval("eval(program)")
Out[3]: 10

In [4]: eval('eval("eval(program)")')
Out[4]: 10

[Skepdick]

I wish that you understood that the computer science of what I just said is verifiably correct.
Apparently the one computer science professor that I know is the only one that can understand
these things.

And then you are going to work out that the H() function which you keep talking about, and the x86 emulator you are using is is precisely the eval() function in LISP.

The way to determine if a program halts is to run it! And the H/eval function itself doesn't always halt.

https://en.wikipedia.org/wiki/Eval

[PeteOlcott]

I wish that you understood that the computer science of what I just said is verifiably correct.
Apparently the one computer science professor that I know is the only one that can understand
these things.

And then you are going to work out that the H() function which you keep talking about, and the x86 emulator you are using is is precisely the eval() function in LISP.

The way to determine if a program halts is to run it! And the H/eval function itself doesn't always halt.

https://en.wikipedia.org/wiki/Eval

The way to determine if a program halts is to run it!

OK, it seems that you may you be beginning to get what I am saying.

An H that simulates its input can see exactly what the behavior of this input is.
It would do this one step at a time to make sure that it does not get stuck.
I will leave the other steps out for now.

[PeteOlcott]

The way to determine if a program halts is to run it! And the H/eval function itself doesn't always halt.

I rewrote my reply much more clearly and used software engineering terms.

[Skepdick]

The way to determine if a program halts is to run it!

OK, it seems that you may you be beginning to get what I am saying.

An H that simulates its input can see exactly what the behavior of this input is.
It would do this one step at a time to make sure that it does not get stuck.
I will leave the other steps out for now.

You are not at all understanding this.

A debugger debugging itself cannot determine if it's going to halt IN FUTURE
Nor can a debugger debugging itself determine that it's "stuck"
An evaulator evaulating itself cannot determine if it's going to halt IN FUTURE.
Nor can an evaluator evaulating itself determine it's "stuck".

Both programs are DOING work!
DOING work is the opposite of halting.

A debugger debugging itself is susceptible to the exact same pathological pattern.

Code: Select all

def debug(p, i):
    if debug(debug, debug):
          # If the debugger halts while debugging itself...
          infinite_loop

[PeteOlcott]

The way to determine if a program halts is to run it!

OK, it seems that you may you be beginning to get what I am saying.

An H that simulates its input can see exactly what the behavior of this input is.
It would do this one step at a time to make sure that it does not get stuck.
I will leave the other steps out for now.

You are not at all understanding this.

A debugger debugging itself cannot determine if it's going to halt IN FUTURE
Nor can a debugger debugging itself determine that it's "stuck"
An evaulator evaulating itself cannot determine if it's going to halt IN FUTURE.
Nor can an evaluator evaulating itself determine it's "stuck".

Both programs are DOING work!
DOING work is the opposite of halting.

A debugger debugging itself is susceptible to the exact same pathological pattern.

Code: Select all

def debug(p, i):
    if debug(debug, debug):
          # If the debugger halts while debugging itself...
          infinite_loop

You keep incorrectly guessing what my paper says.
You have to actually read the paper,

[Skepdick]

You keep incorrectly guessing what my paper says.
You have to actually read the paper,

I have no intention doing so.

Refuting one proofs doesn't invalidate the implication of all the other proofs.

[PeteOlcott]

You keep incorrectly guessing what my paper says.
You have to actually read the paper,

I have no intention doing so.

Refuting one proofs doesn't invalidate the implication of all the other proofs.

I refute the whole class of proofs that are based on this trick:
For any program H that might determine if programs halt, a "pathological" program P, called with some input, can pass its own source and its input to H and then specifically do the opposite of what H predicts P will do. No H can exist that handles this case. https://en.wikipedia.org/wiki/Halting_problem

If you won't read the first three pages of my paper I will take this to mean that you don't want an honest dialogue.

https://www.researchgate.net/publicatio ... ulation_V5