Refuting the Peter Linz Halting Problem Proof V4
-
- Posts: 1514
- Joined: Mon Jul 25, 2016 6:55 pm
Re: Refuting the Peter Linz Halting Problem Proof V4
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.
I only elaborated the halt decider just enough to decide the HP "impossible" input.
Re: Refuting the Peter Linz Halting Problem Proof V4
You don't get to move the goal posts like that.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 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.
-
- Posts: 1514
- Joined: Mon Jul 25, 2016 6:55 pm
Re: Refuting the Peter Linz Halting Problem Proof V4
I never said I solved the halting problem, that would take 10,000 man-years.Skepdick wrote: ↑Sun May 08, 2022 10:38 pmYou don't get to move the goal posts like that.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 said you've solved the halting problem. I've given you a valid program.
I correctly refuted the conventional proofs that show that the halting problem cannot be solved.
Re: Refuting the Peter Linz Halting Problem Proof V4
The most basic proof of the halting problem is by contradiction.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.
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);
}
-
- Posts: 1514
- Joined: Mon Jul 25, 2016 6:55 pm
Re: Refuting the Peter Linz Halting Problem Proof V4
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.
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.
Re: Refuting the Peter Linz Halting Problem Proof V4
Dude. Seriously?!?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.
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.
-
- Posts: 1514
- Joined: Mon Jul 25, 2016 6:55 pm
Re: Refuting the Peter Linz Halting Problem Proof V4
H does correctly decide the halt status of the conventional HP counter-example.
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.
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));
}
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.
Re: Refuting the Peter Linz Halting Problem Proof V4
Your function H() is undefined! That code won't even compile.PeteOlcott wrote: ↑Mon May 09, 2022 12:08 am H does correctly decide the halt status of the conventional HP counter-example.
https://www.researchgate.net/publicatio ... ulation_V5Code: 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)); }
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.
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.
-
- Posts: 1514
- Joined: Mon Jul 25, 2016 6:55 pm
Re: Refuting the Peter Linz Halting Problem Proof V4
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.
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.
Re: Refuting the Peter Linz Halting Problem Proof V4
Dude, you said that Library calls are NOT allowed. I am not going crazy, these are your words, right?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.
If H is undefined and x86utm executes code BEFORE linking that program doesn't work.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.
H doesn't reference a valid object.
Last edited by Skepdick on Mon May 09, 2022 12:29 am, edited 1 time in total.
-
- Posts: 1514
- Joined: Mon Jul 25, 2016 6:55 pm
Re: Refuting the Peter Linz Halting Problem Proof V4
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 .
Calls can be made to this operating system. Calls cannot be made to the C library .
Re: Refuting the Peter Linz Halting Problem Proof V4
None of that matters.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 .
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(;;){}
}
}
-
- Posts: 1514
- Joined: Mon Jul 25, 2016 6:55 pm
Re: Refuting the Peter Linz Halting Problem Proof V4
That won't compile and is otherwise equivalent to P.
Re: Refuting the Peter Linz Halting Problem Proof V4
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()
}
}
-
- Posts: 1514
- Joined: Mon Jul 25, 2016 6:55 pm
Re: Refuting the Peter Linz Halting Problem Proof V4
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.
conventional HP proofs and it does not meet that pattern.