Refuting the Peter Linz Halting Problem Proof V4

What is the basis for reason? And mathematics?

Moderators: AMod, iMod

Skepdick
Posts: 14366
Joined: Fri Jun 14, 2019 11:16 am

Re: Refuting the Peter Linz Halting Problem Proof V4

Post by Skepdick »

PeteOlcott wrote: Mon May 09, 2022 1:05 am I can't get it to compile and it is off-topic because the topic is refuting the pattern of the
conventional HP proofs and it does not meet that pattern.
The conventional HP proofs use proof by contradiction.

You can craft input to yout halting-decider such that IF the decider halts on that particular input then the decider enters an infinite loop.

Which is the very reason why you won't show us this hidden function H().

Because you can't implement it!
PeteOlcott
Posts: 1514
Joined: Mon Jul 25, 2016 6:55 pm

Re: Refuting the Peter Linz Halting Problem Proof V4

Post by PeteOlcott »

I understand that I have proven that the "impossible" input is decided correctly, thus refuting all of the conventional proofs.

Code: Select all

#include <stdint.h> 
#define u32 uint32_t 

void P(u32 x) 
{
  if (H(x, x)) 
    HERE: goto HERE; 
  return; 
} 

int main() 
{ 
  Output("Input_Halts = ", H((u32)P, (u32)P)); 
}
Skepdick
Posts: 14366
Joined: Fri Jun 14, 2019 11:16 am

Re: Refuting the Peter Linz Halting Problem Proof V4

Post by Skepdick »

PeteOlcott wrote: Mon May 09, 2022 1:20 am I understand that I have proven that the "impossible" input is decided correctly, thus refuting all of the conventional proofs.

Code: Select all

#include <stdint.h> 
#define u32 uint32_t 

void P(u32 x) 
{
  if (H(x, x)) 
    HERE: goto HERE; 
  return; 
} 

int main() 
{ 
  Output("Input_Halts = ", H((u32)P, (u32)P)); 
}
But you haven't done what you claim to have done, you moron. You've wasted 15000 hours of your life being confused about the implications of the halting problem.

The implication of the original proof is that it's impossible is to devise a general/universal solution to the halting problem.
The proof DOES NOT imply that it's impossible to solve particular instances of the halting problem.
This is the fallacy of hasty generalization.

You are concluding that because your decider solves one case there must be a decider which solves all cases.
PeteOlcott
Posts: 1514
Joined: Mon Jul 25, 2016 6:55 pm

Re: Refuting the Peter Linz Halting Problem Proof V4

Post by PeteOlcott »

Skepdick wrote: Mon May 09, 2022 1:27 am
PeteOlcott wrote: Mon May 09, 2022 1:20 am I understand that I have proven that the "impossible" input is decided correctly, thus refuting all of the conventional proofs.

Code: Select all

#include <stdint.h> 
#define u32 uint32_t 

void P(u32 x) 
{
  if (H(x, x)) 
    HERE: goto HERE; 
  return; 
} 

int main() 
{ 
  Output("Input_Halts = ", H((u32)P, (u32)P)); 
}
But you haven't done what you claim to have done, you moron. You've wasted 15000 hours of your life being confused about the implications of the halting problem.

The implication of the original proof is that it's impossible is to devise a general/universal solution to the halting problem.
The proof DOES NOT imply that it's impossible to solve particular instances of the halting problem.
This is the fallacy of hasty generalization.

You are concluding that because your decider solves one case it will solve all cases.
I only changed this to my naming conventions:
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
Skepdick
Posts: 14366
Joined: Fri Jun 14, 2019 11:16 am

Re: Refuting the Peter Linz Halting Problem Proof V4

Post by Skepdick »

PeteOlcott wrote: Mon May 09, 2022 1:34 am
Skepdick wrote: Mon May 09, 2022 1:27 am
PeteOlcott wrote: Mon May 09, 2022 1:20 am I understand that I have proven that the "impossible" input is decided correctly, thus refuting all of the conventional proofs.

Code: Select all

#include <stdint.h> 
#define u32 uint32_t 

void P(u32 x) 
{
  if (H(x, x)) 
    HERE: goto HERE; 
  return; 
} 

int main() 
{ 
  Output("Input_Halts = ", H((u32)P, (u32)P)); 
}
But you haven't done what you claim to have done, you moron. You've wasted 15000 hours of your life being confused about the implications of the halting problem.

The implication of the original proof is that it's impossible is to devise a general/universal solution to the halting problem.
The proof DOES NOT imply that it's impossible to solve particular instances of the halting problem.
This is the fallacy of hasty generalization.

You are concluding that because your decider solves one case it will solve all cases.
I only changed this to my naming conventions:
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
Yes. So what is confusing you about this?

Any "universal" H can be undermined by a pathological P.

IF H decides that P will halt then P decides not to halt.
IF H decides that P won't halt then P decides to halt.

Because P has the advantage of knowing H's prediction about P's behavior, this gives P the opportunity to behave in a manner different to H's prediction.
Last edited by Skepdick on Mon May 09, 2022 1:45 am, edited 1 time in total.
PeteOlcott
Posts: 1514
Joined: Mon Jul 25, 2016 6:55 pm

Re: Refuting the Peter Linz Halting Problem Proof V4

Post by PeteOlcott »

Skepdick wrote: Mon May 09, 2022 1:35 am Any "universal" H can be undermined by a pathological P.

IF H predicts that P will halt then P won't halt.
IF H predicts that P won't halt then P will halt.

Because P has the advantage of knowing H's prediction about P's behavior, this gives P the opportunity to behave in a manner different to H's prediction.
I proved that H cannot be undermined by a pathological P by making this exact same P and showing exactly how H correctly decides its halt status.
Skepdick
Posts: 14366
Joined: Fri Jun 14, 2019 11:16 am

Re: Refuting the Peter Linz Halting Problem Proof V4

Post by Skepdick »

PeteOlcott wrote: Mon May 09, 2022 1:44 am I proved that H cannot be undermined by a pathological P by making this exact same P and showing exactly how H correctly decides its halt status.
Then you have absolutely made the wrong P.

The pathological P calls H and asks: "Will I halt?"

If H answers "Yes you will halt" then P decides not to halt.
If H answers "No, you won't halt" then P decides to halt.

I don't know how else to explain this to your dumb ass. Imagine two friends go to a pub. John asks Paul: hey Paul, do you think I am going to get drunk tonight?

John has already decided that If Paul says yes then John will stay sober; and if Paul says no then John will get drunk

Paul can NEVER guess correctly! Because it is precisely Paul's decision which determines the opposite outcome!
PeteOlcott
Posts: 1514
Joined: Mon Jul 25, 2016 6:55 pm

Re: Refuting the Peter Linz Halting Problem Proof V4

Post by PeteOlcott »

Skepdick wrote: Mon May 09, 2022 1:46 am
PeteOlcott wrote: Mon May 09, 2022 1:44 am I proved that H cannot be undermined by a pathological P by making this exact same P and showing exactly how H correctly decides its halt status.
Then you have absolutely made the wrong P.

The pathological P calls H and asks: "Will I halt?"

If H answers "Yes you will halt, then P decides not to halt.
If H answers "No, you won't halt" then P decides to halt.

I don't know how else to explain this to your dumb ass. Imagine two friends go to a pub. John asks Paul: hey Paul, do you think I am going to get drunk tonight?

If Paul says yes then John chooses to spite him and stay sober.
If Paul says no then John chooses spite him and get drunk.

Paul cannot win this game!
It is obvious that I did do that. Do you comprehend the C programming language?
It turns out that P never reaches the contradiction it is stuck in infinite recursion.

Please read my paper I am sick of correcting your incorrect guesses about what it says.
You only have to read the first three pages.
Skepdick
Posts: 14366
Joined: Fri Jun 14, 2019 11:16 am

Re: Refuting the Peter Linz Halting Problem Proof V4

Post by Skepdick »

PeteOlcott wrote: Mon May 09, 2022 1:59 am It is obvious that I did do that. Do you comprehend the C programming language?
It turns out that P never reaches the contradiction it is stuck in infinite recursion.
You fucking idiot.

Neither P nor N are supposed to reach a contradiction - you the idiot-human observing P and N are supposed to reach a contradiction.

When H says "P will halt" P does the OPPOSITE and gets stuck in infinite recursion.
When H says "P will get stuck in infinite recursion" P does the OPPOSITE and halts.

H is defined as ALWAYS being right.
H is ALWAYS wrong about P. Obviously! Because P ALWAYS does the OPPOSITE of what H says.

I am not reading your paper. Your inability to understand the notion of a pathological P specifically crafted to do the exact opposite of what H predicts is absolutely flabbergasting.

Even a child can intuit the basic urge of contrarian P just fucking with N.

If the halting problem had a universal solution then free will cannot exist. Because P will never be able to choose to do the opposite of what N predicted. If the halting provlem was solvable P will always do whatever N predicted.
Last edited by Skepdick on Mon May 09, 2022 2:38 am, edited 1 time in total.
PeteOlcott
Posts: 1514
Joined: Mon Jul 25, 2016 6:55 pm

Re: Refuting the Peter Linz Halting Problem Proof V4

Post by PeteOlcott »

H can easily see that P is stuck in infinite recursion when it continues to call P from
the same machine address with identical parameters.
It took me from 2004 to 2016 to notice this, so it is OK if it is hard for you to see.

Code: Select all

    
Begin Local Halt Decider Simulation of input to H(P,P)
    machine   stack     stack     machine    assembly
    address   address   data      code       language
    ========  ========  ========  =========  =============
...[000009d6][00211368][0021136c] 55         push ebp         // enter P
...[000009d7][00211368][0021136c] 8bec       mov ebp,esp
...[000009d9][00211368][0021136c] 8b4508     mov eax,[ebp+08]
...[000009dc][00211364][000009d6] 50         push eax         // Push P
...[000009dd][00211364][000009d6] 8b4d08     mov ecx,[ebp+08]
...[000009e0][00211360][000009d6] 51         push ecx         // Push P
...[000009e1][0021135c][000009e6] e840feffff call 00000826    // Call H
...[000009d6][0025bd90][0025bd94] 55         push ebp         // enter P
...[000009d7][0025bd90][0025bd94] 8bec       mov ebp,esp
...[000009d9][0025bd90][0025bd94] 8b4508     mov eax,[ebp+08]
...[000009dc][0025bd8c][000009d6] 50         push eax         // Push P
...[000009dd][0025bd8c][000009d6] 8b4d08     mov ecx,[ebp+08]
...[000009e0][0025bd88][000009d6] 51         push ecx         // Push P
...[000009e1][0025bd84][000009e6] e840feffff call 00000826    // Call H
Local Halt Decider: Infinite Recursion Detected Simulation Stopped 
Last edited by PeteOlcott on Mon May 09, 2022 2:41 am, edited 1 time in total.
Skepdick
Posts: 14366
Joined: Fri Jun 14, 2019 11:16 am

Re: Refuting the Peter Linz Halting Problem Proof V4

Post by Skepdick »

PeteOlcott wrote: Mon May 09, 2022 2:38 am H can easily see that P is stuck in infinite recursion when it continues to call P from
the same machine address with identical parameters.
That has nothing to do with anything.

### Scenario A
P asks H (ONCE): WIll I halt?
H answers (ONCE): NO! You won't halt.
P does the opposite and halts.

### Scenario B
P asks H (ONCE): WIll I halt?
H answers (ONCE): YES! You will halt.
P does the opposite and enters infinite loop.

There is no further interaction between P and H once the initial question is asked and answered, and throughout the entire game neither P nor H have any insight into each other's internals states.
PeteOlcott
Posts: 1514
Joined: Mon Jul 25, 2016 6:55 pm

Re: Refuting the Peter Linz Halting Problem Proof V4

Post by PeteOlcott »

This may be beyond your technical (computer science) capability:
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 actual behavior of the input to H(P,P) is non-halting in that the correctly
simulated P would never reach its final state at machine address [000009f0]
whether or not its simulation was aborted. Therefore H(P,P)==false is proven to be correct.
Skepdick
Posts: 14366
Joined: Fri Jun 14, 2019 11:16 am

Re: Refuting the Peter Linz Halting Problem Proof V4

Post by Skepdick »

PeteOlcott wrote: Mon May 09, 2022 2:49 am This may be beyond your technical (computer science) capability:
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 actual behavior of the input to H(P,P) is non-halting in that the correctly
simulated P would never reach its final state at machine address [000009f0]
whether or not its simulation was aborted. Therefore H(P,P)==false is proven to be correct.
Again. This has nothing to do with anything.

P asks H: WIll I halt?
H (being assumed to be a universal algorithm) arrives at an answer. SOMEHOW.
The answer is either Yes you will halt; or No, you won't halt.
Knowing what N said P proceeds to do the OPPOSITE thing.
PeteOlcott
Posts: 1514
Joined: Mon Jul 25, 2016 6:55 pm

Re: Refuting the Peter Linz Halting Problem Proof V4

Post by PeteOlcott »

Skepdick wrote: Mon May 09, 2022 2:53 am
PeteOlcott wrote: Mon May 09, 2022 2:49 am This may be beyond your technical (computer science) capability:
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 actual behavior of the input to H(P,P) is non-halting in that the correctly
simulated P would never reach its final state at machine address [000009f0]
whether or not its simulation was aborted. Therefore H(P,P)==false is proven to be correct.
Again. This has nothing to do with anything.

P asks H: WIll I halt?
H (being assumed to be a universal algorithm) arrives at an answer. SOMEHOW.
The answer is either Yes you will halt; or No, you won't halt.
Knowing what N said P proceeds to do the OPPOSITE thing.


OK so clearly the computer science is beyond your technical capacity.
Last edited by PeteOlcott on Mon May 09, 2022 2:57 am, edited 1 time in total.
Skepdick
Posts: 14366
Joined: Fri Jun 14, 2019 11:16 am

Re: Refuting the Peter Linz Halting Problem Proof V4

Post by Skepdick »

PeteOlcott wrote: Mon May 09, 2022 2:56 am OK so clearly the computer science is beyond your technical capacity.
You have this wrong. It's beyond yours.
Post Reply