Simplified Halting Problem Proof Rebuttal

[PeteOlcott]

Computer science deciders are only allowed to take actions that
are equivalent to a Boolean return value. Every other action is
stipulated to be incorrect.

Nowhere does it stipulate that I can't encapsulate a Boolean in a Maybe monad.

I have proven that your statement is counter-factual.

Deciders process Decision Problems
a decision problem is a computational problem that can be posed as a yes–no
question of the input values. https://en.wikipedia.org/wiki/Decision_problem

Until you acknowledge that I have proven that your statement
is counter-factual I have proven that you are not interested
in any honest dialogue and prefer to play Trollish head games.

[Skepdick]

Computer science deciders are only allowed to take actions that
are equivalent to a Boolean return value. Every other action is
stipulated to be incorrect.

Nowhere does it stipulate that I can't encapsulate a Boolean in a Maybe monad.

I have proven that your statement is counter-factual.

Deciders process Decision Problems
a decision problem is a computational problem that can be posed as a yes–no
question of the input values. https://en.wikipedia.org/wiki/Decision_problem

Until you acknowledge that I have proven that your statement
is counter-factual I have proven that you are not interested
in any honest dialogue and prefer to play Trollish head games.

Liar liar, pants on fire

Proofs are programs.

Either the program below is a Boolean; or it isn't.

Until you provide the decider which determines the correct answer you've "proven" nothing.

Code: Select all

def isGreaterThanOne(x):
	while True: pass
	return x > 1

[PeteOlcott]

Nowhere does it stipulate that I can't encapsulate a Boolean in a Maybe monad.

I have proven that your statement is counter-factual.

Deciders process Decision Problems
a decision problem is a computational problem that can be posed as a yes–no
question of the input values. https://en.wikipedia.org/wiki/Decision_problem

Until you acknowledge that I have proven that your statement
is counter-factual I have proven that you are not interested
in any honest dialogue and prefer to play Trollish head games.

Liar liar, pants on fire

Proofs are programs.

Either the program below is a Boolean; or it isn't.

Until you provide the decider which determines the correct answer you've "proven" nothing.

Code: Select all

def isGreaterThanOne(x):
	while True: pass
	return x > 1

Rewrite it in C++ as a bool function I don't know that language.

[Skepdick]

I have proven that your statement is counter-factual.

Deciders process Decision Problems
a decision problem is a computational problem that can be posed as a yes–no
question of the input values. https://en.wikipedia.org/wiki/Decision_problem

Until you acknowledge that I have proven that your statement
is counter-factual I have proven that you are not interested
in any honest dialogue and prefer to play Trollish head games.

Liar liar, pants on fire

Proofs are programs.

Either the program below is a Boolean; or it isn't.

Until you provide the decider which determines the correct answer you've "proven" nothing.

Code: Select all

def isGreaterThanOne(x):
	while True: pass
	return x > 1

Rewrite it in C++ as a bool function I don't know that language.

How the fuck have you been doing this for 20+ years and you can't just switch languages ?!?

Code: Select all

bool isGreaterThanOne(int x) {
    while (true) {};
    return x > 1;
}

[PeteOlcott]

Liar liar, pants on fire

Proofs are programs.

Either the program below is a Boolean; or it isn't.

Until you provide the decider which determines the correct answer you've "proven" nothing.

Code: Select all

def isGreaterThanOne(x):
	while True: pass
	return x > 1

Rewrite it in C++ as a bool function I don't know that language.

How the fuck have you been doing this for 20+ years and you can't just switch languages ?!?

Code: Select all

bool isGreaterThanOne(int x) {
    while (true) {};
    return x > 1;
}

I say that all deciders must always halt so you post a program
with an infinite loop and ask is this a decider?

[Skepdick]

Rewrite it in C++ as a bool function I don't know that language.

How the fuck have you been doing this for 20+ years and you can't just switch languages ?!?

Code: Select all

bool isGreaterThanOne(int x) {
    while (true) {};
    return x > 1;
}

I say that all deciders must always halt so you post a program
with an infinite loop and ask is this a decider?

Of course!

Is it a decider? Yes or no.
Write me a decider.

[PeteOlcott]

Is it a decider? Yes or no.
Write me a decider.

I just told you that it is not a decider and you simply ignored my aswer.

Contains several fully operational termination analyzers
and the inputs that they correctly process.

https://github.com/plolcott/x86utm/blob/master/Halt7.c
It took two man years to develop.

[Skepdick]

I just told you that it is not a decider and you simply ignored my aswer.

I didn't ask you for your answer. I asked your decider's answer.

Contains several fully operational termination analyzers
and the inputs that they correctly process.

https://github.com/plolcott/x86utm/blob/master/Halt7.c
It took two man years to develop.

Nothing interesting there. Everyone knows particular cases are solvable.

[PeteOlcott]

Contains several fully operational termination analyzers
and the inputs that they correctly process.

https://github.com/plolcott/x86utm/blob/master/Halt7.c
It took two man years to develop.

Nothing interesting there. Everyone knows particular cases are solvable.

It shows the details of exactly how termination analyzer H can
correctly determine the halt status of any input D that does the
opposite of whatever Boolean value that H returns.

[Skepdick]

It shows the details of exactly how termination analyzer H can
correctly determine the halt status of any input D that does the
opposite of whatever Boolean value that H returns.

And back into the idiotic rabbit hole you go.

In what amount of time does your analyzer do this? Prove that it always halts. Otherwise it's not a decider (according to you).

[PeteOlcott]

// The following is written in C
//
01 typedef int (*ptr)(); // pointer to int function
02 int H(ptr x, ptr y) // uses x86 emulator to simulate its input
03
04 int D(ptr x)
05 {
06 int Halt_Status = H(x, x);
07 if (Halt_Status)
08 HERE: goto HERE;
09 return Halt_Status;
10 }
11
12 void main()
13 {
14 H(D,D);
15 }

Execution Trace
Line 14: main() invokes H(D,D);

keeps repeating (unless aborted)
Line 06: simulated D(D) invokes simulated H(D,D) that simulates D(D)

Simulation invariant:
D correctly simulated by H cannot possibly reach past its own line 06.

MIT Professor Michael Sipser has agreed that the following verbatim paragraph is correct:
(a) If simulating halt decider H correctly simulates its input D until H
correctly determines that its simulated D would never stop running unless
aborted then
(b) H can abort its simulation of D and correctly report that D specifies a
non-halting sequence of configurations.

[Skepdick]

// The following is written in C
//
01 typedef int (*ptr)(); // pointer to int function
02 int H(ptr x, ptr y) // uses x86 emulator to simulate its input
03
04 int D(ptr x)
05 {
06 int Halt_Status = H(x, x);
07 if (Halt_Status)
08 HERE: goto HERE;
09 return Halt_Status;
10 }
11
12 void main()
13 {
14 H(D,D);
15 }

Execution Trace
Line 14: main() invokes H(D,D);

keeps repeating (unless aborted)
Line 06: simulated D(D) invokes simulated H(D,D) that simulates D(D)

Simulation invariant:
D correctly simulated by H cannot possibly reach past its own line 06.

MIT Professor Michael Sipser has agreed that the following verbatim paragraph is correct:
(a) If simulating halt decider H correctly simulates its input D until H
correctly determines that its simulated D would never stop running unless
aborted then
(b) H can abort its simulation of D and correctly report that D specifies a
non-halting sequence of configurations.

Yes. You've said this only a million times.

Nobody cares about execution traces - that's architecture-specific implementation detail.

There are any number of ways to implement infinite loops. One of them (which your decider can't detect) is the use of the CPU's Real-time clock to trigger an interrupt/callback. You can't detect that. Because you can never know if the interrupt-event will ever arrive.

This is equivalent to the break statement in a for-loop. You don't know if the break condition is ever satisfied. Maybe. Eventually. After a billion years.

[PeteOlcott]

// The following is written in C
//
01 typedef int (*ptr)(); // pointer to int function
02 int H(ptr x, ptr y) // uses x86 emulator to simulate its input
03
04 int D(ptr x)
05 {
06 int Halt_Status = H(x, x);
07 if (Halt_Status)
08 HERE: goto HERE;
09 return Halt_Status;
10 }
11
12 void main()
13 {
14 H(D,D);
15 }

Execution Trace
Line 14: main() invokes H(D,D);

keeps repeating (unless aborted)
Line 06: simulated D(D) invokes simulated H(D,D) that simulates D(D)

Simulation invariant:
D correctly simulated by H cannot possibly reach past its own line 06.

MIT Professor Michael Sipser has agreed that the following verbatim paragraph is correct:
(a) If simulating halt decider H correctly simulates its input D until H
correctly determines that its simulated D would never stop running unless
aborted then
(b) H can abort its simulation of D and correctly report that D specifies a
non-halting sequence of configurations.

Yes. You've said this only a million times.

Nobody cares about execution traces - that's architecture-specific implementation detail.

It is exactly the same execution trace for every input D that
does the opposite of whatever Boolean value that decider
H returns in all of the conventional HP proofs.

I show this on pages 2-3 of this paper that examines the
Linz Turing machine based halting problem proof.

Termination Analyzer H is Not Fooled by Pathological Input D
https://www.researchgate.net/publicatio ... al_Input_D

I have refuted the conventional halting problem proofs
two different ways.

Many people form a strawman rebuttal to a different
claim that I am not making.

[Skepdick]

// The following is written in C
//
01 typedef int (*ptr)(); // pointer to int function
02 int H(ptr x, ptr y) // uses x86 emulator to simulate its input
03
04 int D(ptr x)
05 {
06 int Halt_Status = H(x, x);
07 if (Halt_Status)
08 HERE: goto HERE;
09 return Halt_Status;
10 }
11
12 void main()
13 {
14 H(D,D);
15 }

Execution Trace
Line 14: main() invokes H(D,D);

keeps repeating (unless aborted)
Line 06: simulated D(D) invokes simulated H(D,D) that simulates D(D)

Simulation invariant:
D correctly simulated by H cannot possibly reach past its own line 06.

Yes. You've said this only a million times.

Nobody cares about execution traces - that's architecture-specific implementation detail.

It is exactly the same execution trace for every input D that
does the opposite of whatever Boolean value that decider
H returns in all of the conventional HP proofs.

I show this on pages 2-3 of this paper that examines the
Linz Turing machine based halting problem proof.

Termination Analyzer H is Not Fooled by Pathological Input D
https://www.researchgate.net/publicatio ... al_Input_D

I have refuted the conventional halting problem proofs
two different ways.

Many people form a strawman rebuttal to a different
claim that I am not making.

Nobody cares. Loops are just a compiler optimizations for making binaries smaller.

All I have to do to defeat your "analyzer" is to compile the program with -funroll-all-loops.
The executable will become infinite in size, but so what? A Turing machine has infinite tape

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

[PeteOlcott]

I have refuted the conventional halting problem proofs
two different ways.

Nobody cares. Loops are just a compiler optimizations for making binaries smaller.

You just don't have an actual clue do you?
I NEVER mentioned ANYTHING about loops.