Refuting the Peter Linz Halting Problem Proof V4

What is the basis for reason? And mathematics?

Moderators: AMod, iMod

PeteOlcott
Posts: 1514
Joined: Mon Jul 25, 2016 6:55 pm

Re: Refuting the Peter Linz Halting Problem Proof V4

Post by PeteOlcott »

Library calls are not allowed because x86utm directly executes the Microsoft COFF object file before it has been linked.
I only elaborated the halt decider just enough to decide the HP "impossible" input.
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: Sun May 08, 2022 10:36 pm Library calls are not allowed because x86utm directly executes the Microsoft COFF object file before it has been linked.
I only elaborated the halt decider just enough to decide the HP "impossible" input.
You don't get to move the goal posts like that.

You said you've solved the halting problem. I've given you a valid program.

Now you telling me my program is not allowed. Funny guy.
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: Sun May 08, 2022 10:38 pm
PeteOlcott wrote: Sun May 08, 2022 10:36 pm Library calls are not allowed because x86utm directly executes the Microsoft COFF object file before it has been linked.
I only elaborated the halt decider just enough to decide the HP "impossible" input.
You don't get to move the goal posts like that.

You said you've solved the halting problem. I've given you a valid program.
I never said I solved the halting problem, that would take 10,000 man-years.
I correctly refuted the conventional proofs that show that the halting problem cannot be solved.
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: Sun May 08, 2022 10:47 pm I never said I solved the halting problem, that would take 10,000 man-years.
I correctly refuted the conventional proofs that show that the halting problem cannot be solved.
The most basic proof of the halting problem is by contradiction.

Assume halt(p,i) halts for ALL programs and ALL inputs.

Here is a well-crafted, devious C program which fails to halt if halt() halts.

Code: Select all

void halt(void (*a), void(*b)){
	if (a == b) {
		for(;;){}
	};
};

int main() {
	halt(halt, halt);
}
CONTRADICTION! Blah blah blah....
PeteOlcott
Posts: 1514
Joined: Mon Jul 25, 2016 6:55 pm

Re: Refuting the Peter Linz Halting Problem Proof V4

Post by PeteOlcott »

I spent 15,000 hours on this since 2004, I know how it works. You can see all of my work on USENET: comp.theory.
When a simulating halt decider simulates its input it never reaches the contradiction.
The simulated input gets stuck in infinite recursion before ever reaching the contradiction.
Please Read my paper.
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: Sun May 08, 2022 11:38 pm I spent 15,000 hours on this since 2004, I know how it works. You can see all of my work on USENET: comp.theory.
When a simulating halt decider simulates its input it never reaches the contradiction.
The simulated input gets stuck in infinite recursion before ever reaching the contradiction.
Please Read my paper.
Dude. Seriously?!?

YES! The halt(p,i) program (which is supposed to halt on ALL inputs) gets stuck in infinite recursion when you invoke it as halt(halt, halt)!

That is what non-halting means. Infinite recursion IS a failure to halt.

The contradiction is in the fact that the halting decider is supposed to halt on ALL program/input pairs.

It doesn't halt on THIS PARTICULAR program/input pair. It enters an infinite loop!

Code: Select all

int halt(void (*program), void(*input)){
	if ( program == input) {
		for(;;){}
	} else {
		return 1;
	};
};

int main() {
	halt(halt, halt);
}
Last edited by Skepdick on Mon May 09, 2022 12:08 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 does correctly decide the halt status of the conventional HP counter-example.

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)); 
}
https://www.researchgate.net/publicatio ... ulation_V5

You have to actually carefully study the first three pages of the paper to see this.
When you base you "rebuttal" on simply guessing what this paper says this is not a dialogue that I want to be involved with.
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 12:08 am H does correctly decide the halt status of the conventional HP counter-example.

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)); 
}
https://www.researchgate.net/publicatio ... ulation_V5

You have to actually carefully study the first three pages of the paper to see this.
When you base you "rebuttal" on simply guessing what this paper says this is not a dialogue that I want to be involved with.
Your function H() is undefined! That code won't even compile.

If you've written a paper about code that doesn't compile, I can confidently say that your paper is bullshit.
Last edited by Skepdick on Mon May 09, 2022 12:25 am, edited 2 times 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 »

I isn't undefined it is hundreds of pages (when all the x86 emulator code is included).
The execution trace showing H would be 237 pages long.
None of this is needed to analyze that H correctly rejects its input.

One must merely know that H emulates its input in pure x86 emulation
mode until it recognizes the infinitely repeating pattern on page 3:
P calls H from its same machine address with identical parameters
twice in a row.
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 12:23 am I isn't undefined it is hundreds of pages (when all the x86 emulator code is included).
The execution trace showing H would be 237 pages long.
None of this is needed to analyze that H correctly rejects its input.

One must merely know that H emulates its input in pure x86 emulation
mode until it recognizes the infinitely repeating pattern on page 3:
P calls H from its same machine address with identical parameters
twice in a row.
Dude, you said that Library calls are NOT allowed. I am not going crazy, these are your words, right?
PeteOlcott wrote: Sun May 08, 2022 10:36 pm Library calls are not allowed because x86utm directly executes the Microsoft COFF object file before it has been linked.
If H is undefined and x86utm executes code BEFORE linking that program doesn't work.

H doesn't reference a valid object.
Last edited by Skepdick on Mon May 09, 2022 12:29 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 »

The very excellent open source x86 emulator is directly integrated into the x86utm operating system.
Calls can be made to this operating system. Calls cannot be made to the C library .
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 12:28 am The very excellent open source x86 emulator is directly integrated into the x86utm operating system.
Calls can be made to this operating system. Calls cannot be made to the C library .
None of that matters.

If H() is a valid callable function you've defined it somewhere.

If H halts for ALL input pairs, then it doesn't halt for this input:

Code: Select all

void main(){

	if H(x, x) {
		for(;;){}
	}
}
Because if H halts then THIS program doesn't.
PeteOlcott
Posts: 1514
Joined: Mon Jul 25, 2016 6:55 pm

Re: Refuting the Peter Linz Halting Problem Proof V4

Post by PeteOlcott »

That won't compile and is otherwise equivalent to 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 12:45 am That won't compile and is otherwise equivalent to P.
Sigh. Stop being an idiot. It's pseudo-code because you refuse to show me this super-secret well-hidden function H() that you keep calling in your code.

Code: Select all

void main(){
	if H(main, main) {
		//if H halts - when checking our halting behavior then enter an infinite loop
		main()
	}
}
This will compile and won't terminate.
PeteOlcott
Posts: 1514
Joined: Mon Jul 25, 2016 6:55 pm

Re: Refuting the Peter Linz Halting Problem Proof V4

Post by PeteOlcott »

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.
Post Reply