u32 H(u32 P, u32 I)
{ HERE:
u32 End_Of_Code;
u32 Address_of_H; // 2022-06-17
u32 code_end = get_code_end(P);
Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
Allocate(sizeof(Decoded_Line_Of_Code));
Registers* master_state = (Registers*)
Allocate(sizeof(Registers));
Registers* slave_state = (Registers*)
Allocate(sizeof(Registers));
u32* slave_stack = Allocate(0x10000); // 64k;
u32 execution_trace = (u32)Allocate(sizeof(Decoded_Line_Of_Code) *
1000); // 1000 lines of x86 code

__asm lea eax, HERE // 2022-06-18
__asm sub eax, 6 // 2022-06-18
__asm mov Address_of_H, eax // 2022-06-18
__asm mov eax, END_OF_CODE
__asm mov End_Of_Code, eax

Output("Address_of_H:", Address_of_H); // 2022-06-11
Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
Output("\nBegin Simulation Execution Trace Stored at:",
execution_trace);
if (Decide_Halting(&execution_trace, &decoded, code_end, &master_state,
&slave_state, &slave_stack, Address_of_H, P, I))
goto END_OF_CODE;
return 0; // Does not halt
END_OF_CODE:
return 1; // Input has normally terminated
}

THIS IS THE BASIC PRINCIPLE OF A HALT DECIDER THAT REFUTES THE HALTING
PROBLEM PROOFS:
When a simulating halt decider rejects all inputs as non-halting
whenever it correctly detects (in a finite number of steps) that its
correct and complete simulation of its input would never reach a final
state of this input that all [these] inputs (including pathological
inputs) are decided correctly.

computation that halts … the Turing machine will halt whenever it enters
a final state. (Linz:1990:234)

Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company. (317-320)

This paper has not been updated since I converted H into a pure function
of its inputs. https://en.wikipedia.org/wiki/Pure_function
H no longer recursively calls itself, thus local memory is sufficient.

Halting problem undecidability and infinitely nested simulation (V5)
https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 6/18/22 8:00 PM, olcott wrote:
> u32 H(u32 P, u32 I)
> {
> HERE:
>   u32 End_Of_Code;
>   u32 Address_of_H;              // 2022-06-17
>   u32 code_end                  = get_code_end(P);
>   Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
> Allocate(sizeof(Decoded_Line_Of_Code));
>   Registers*  master_state      = (Registers*)
> Allocate(sizeof(Registers));
>   Registers*  slave_state       = (Registers*)
> Allocate(sizeof(Registers));
>   u32*        slave_stack       = Allocate(0x10000); // 64k;
>   u32  execution_trace = (u32)Allocate(sizeof(Decoded_Line_Of_Code) *
> 1000); // 1000 lines of x86 code
>
>   __asm lea eax, HERE             // 2022-06-18
>   __asm sub eax, 6                // 2022-06-18
>   __asm mov Address_of_H, eax     // 2022-06-18
>   __asm mov eax, END_OF_CODE
>   __asm mov End_Of_Code, eax
>
>   Output("Address_of_H:", Address_of_H); // 2022-06-11
>   Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
>   Output("\nBegin Simulation   Execution Trace Stored at:",
> execution_trace);
>   if (Decide_Halting(&execution_trace, &decoded, code_end, &master_state,
>                      &slave_state, &slave_stack, Address_of_H, P, I))
>       goto END_OF_CODE;
>   return 0;  // Does not halt
> END_OF_CODE:
>   return 1; // Input has normally terminated
> }
>
>
> THIS IS THE BASIC PRINCIPLE OF A HALT DECIDER THAT REFUTES THE HALTING
> PROBLEM PROOFS:
> When a simulating halt decider rejects all inputs as non-halting
> whenever it correctly detects (in a finite number of steps) that its
> correct and complete simulation of its input would never reach a final
> state of this input that all [these] inputs (including pathological
> inputs) are decided correctly.

Except that you haven't (and can't) show that your H actully does
correct dectect a non-halting pattern in P.

The problem is that H can not do both a correct and complete emulation
and at the same time decide in a finite number of steps and abort its
emulation.

This unsound logic is what results in your incorrect ansnwer.

>
> computation that halts … the Turing machine will halt whenever it enters
> a final state. (Linz:1990:234)

Right, and P(P) Halts if the H it is built on returns 0 for H(P,P).
Thus, since the DEFININTION of Halting refers to the ACTUAL computation,
not an emulation of it, H(P,P) returning 0 must be incorrect for the P
built on it.

Note, if H(P,P) is not intended to decide on P(P), then your P isn't
correct, as per Linz, P is supposed to ask H for what it will do when
applied to itself [that is to decide on the behavior or P(P)] so if that
input doesn't ask that, then you you are lying that you built P by the
requirements.

>
> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
> Lexington/Toronto: D. C. Heath and Company. (317-320)
>
>
>
> This paper has not been updated since I converted H into a pure function
> of its inputs. https://en.wikipedia.org/wiki/Pure_function
> H no longer recursively calls itself, thus local memory is sufficient.
>
> Halting problem undecidability and infinitely nested simulation (V5)
> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>
>

But it still gives an answer that is wrong BY DEFINITION.

On Sat, 18 Jun 2022 19:00:30 -0500
olcott <NoOne@NoWhere.com> wrote:

> u32 H(u32 P, u32 I)
> {
> HERE:
> u32 End_Of_Code;
> u32 Address_of_H; // 2022-06-17
> u32 code_end = get_code_end(P);
> Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
> Allocate(sizeof(Decoded_Line_Of_Code));
> Registers* master_state = (Registers*)
> Allocate(sizeof(Registers));
> Registers* slave_state = (Registers*)
> Allocate(sizeof(Registers));
> u32* slave_stack = Allocate(0x10000); // 64k;
> u32 execution_trace = (u32)Allocate(sizeof(Decoded_Line_Of_Code)
> * 1000); // 1000 lines of x86 code
>
> __asm lea eax, HERE // 2022-06-18
> __asm sub eax, 6 // 2022-06-18
> __asm mov Address_of_H, eax // 2022-06-18
> __asm mov eax, END_OF_CODE
> __asm mov End_Of_Code, eax
>
> Output("Address_of_H:", Address_of_H); // 2022-06-11
> Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
> Output("\nBegin Simulation Execution Trace Stored at:",
> execution_trace);
> if (Decide_Halting(&execution_trace, &decoded, code_end,
> &master_state, &slave_state, &slave_stack, Address_of_H, P, I))
> goto END_OF_CODE;
> return 0; // Does not halt
> END_OF_CODE:
> return 1; // Input has normally terminated
> }

The above source code is uninteresting as it doesn't actually tell us
anything apart from how you get the address of H; post the source code
of Decide_Halting.

/Flibble

On 6/18/22 8:00 PM, olcott wrote:
> u32 H(u32 P, u32 I)
> {
> HERE:
>   u32 End_Of_Code;
>   u32 Address_of_H;              // 2022-06-17
>   u32 code_end                  = get_code_end(P);
>   Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
> Allocate(sizeof(Decoded_Line_Of_Code));
>   Registers*  master_state      = (Registers*)
> Allocate(sizeof(Registers));
>   Registers*  slave_state       = (Registers*)
> Allocate(sizeof(Registers));
>   u32*        slave_stack       = Allocate(0x10000); // 64k;
>   u32  execution_trace = (u32)Allocate(sizeof(Decoded_Line_Of_Code) *
> 1000); // 1000 lines of x86 code
>
>   __asm lea eax, HERE             // 2022-06-18
>   __asm sub eax, 6                // 2022-06-18
>   __asm mov Address_of_H, eax     // 2022-06-18
>   __asm mov eax, END_OF_CODE
>   __asm mov End_Of_Code, eax
>
>   Output("Address_of_H:", Address_of_H); // 2022-06-11
>   Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
>   Output("\nBegin Simulation   Execution Trace Stored at:",
> execution_trace);
>   if (Decide_Halting(&execution_trace, &decoded, code_end, &master_state,
>                      &slave_state, &slave_stack, Address_of_H, P, I))
>       goto END_OF_CODE;
>   return 0;  // Does not halt
> END_OF_CODE:
>   return 1; // Input has normally terminated
> }
>
>
> THIS IS THE BASIC PRINCIPLE OF A HALT DECIDER THAT REFUTES THE HALTING
> PROBLEM PROOFS:
> When a simulating halt decider rejects all inputs as non-halting
> whenever it correctly detects (in a finite number of steps) that its
> correct and complete simulation of its input would never reach a final
> state of this input that all [these] inputs (including pathological
> inputs) are decided correctly.

And again, you haven't actually proven that it does this.

Note, since H(P,P) is defined to abort its emulation, it doesn't itself
do a correct emulation, so the test isn't that H didn't reach a final
halt state, but would an actual emulator, using the same input
(including that input calling the above H, and not this emulator) be
able to reach a finl state.

>
> computation that halts … the Turing machine will halt whenever it enters
> a final state. (Linz:1990:234)
>
> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
> Lexington/Toronto: D. C. Heath and Company. (317-320)
>
>
>
> This paper has not been updated since I converted H into a pure function
> of its inputs. https://en.wikipedia.org/wiki/Pure_function
> H no longer recursively calls itself, thus local memory is sufficient.
>
> Halting problem undecidability and infinitely nested simulation (V5)
> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>
>

One issue with this code is that it DOES have a hidden input, that
address that the code has been loaded at, so copies of H can behave
differently. I will leave it to someone with more expertise in this area
to indicate how fatal that error is to your argument. This does say that
if you DID implement this per the actual instructions of Linz, and put a
COPY of H into P, this difference would be enough to be a problem, as
well as breaking your H.

Note, you H only works in your broken computation model where H and the
program it tests are tied up into the same address space, and thus you
can not actually decide on an arbitrary program.

Also, from this code, the subroutines Init_slave_state, and
Decide_Halting must also be 'pure' functions of there inputs (which does
allow them to store information in the buffers provided, but not
anywhere else that might influence behavior.

In particular, those functions need to behave exactly the same when they
are evaluatd in the emulated context as when they are directly executed.

The the correct emuluation of H(P,P) by the actual correct and complete
emulator that is checking the truth that H claims, see the same results
as the direct execution.

You still need to show where that trace will deviate so that this
correct and complete emulation of the call to H(P,P) done by P(P) gets
stuck while the direct execution of H(P,P) when called by main didn't.

What it the first instruction executed that caused a different result.

Until you can actually show how the correct emulation of H(P,P) can
actually differ from the direct execution of H(P,P), you claim that they
differ is just an unsubstatiated claim of something known to be impossible.

You have NEVER actually provided anything like a proof of this claim,
just arguements where you wave your hands and say that the results you
get (after assuming it is possible) show that it happens, which is just
a simple fallacious arguement.

On Sunday, June 19, 2022 at 12:28:11 AM UTC-4, richar...@gmail.com wrote:
> On 6/18/22 8:00 PM, olcott wrote:
> > u32 H(u32 P, u32 I)
> > {
> > HERE:
> > u32 End_Of_Code;
> > u32 Address_of_H; // 2022-06-17
> > u32 code_end = get_code_end(P);
> > Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
> > Allocate(sizeof(Decoded_Line_Of_Code));
> > Registers* master_state = (Registers*)
> > Allocate(sizeof(Registers));
> > Registers* slave_state = (Registers*)
> > Allocate(sizeof(Registers));
> > u32* slave_stack = Allocate(0x10000); // 64k;
> > u32 execution_trace = (u32)Allocate(sizeof(Decoded_Line_Of_Code) *
> > 1000); // 1000 lines of x86 code
> >
> > __asm lea eax, HERE // 2022-06-18
> > __asm sub eax, 6 // 2022-06-18
> > __asm mov Address_of_H, eax // 2022-06-18
> > __asm mov eax, END_OF_CODE
> > __asm mov End_Of_Code, eax
> >
> > Output("Address_of_H:", Address_of_H); // 2022-06-11
> > Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
> > Output("\nBegin Simulation Execution Trace Stored at:",
> > execution_trace);
> > if (Decide_Halting(&execution_trace, &decoded, code_end, &master_state,
> > &slave_state, &slave_stack, Address_of_H, P, I))
> > goto END_OF_CODE;
> > return 0; // Does not halt
> > END_OF_CODE:
> > return 1; // Input has normally terminated
> > }
> >
> >
> > THIS IS THE BASIC PRINCIPLE OF A HALT DECIDER THAT REFUTES THE HALTING
> > PROBLEM PROOFS:
> > When a simulating halt decider rejects all inputs as non-halting
> > whenever it correctly detects (in a finite number of steps) that its
> > correct and complete simulation of its input would never reach a final
> > state of this input that all [these] inputs (including pathological
> > inputs) are decided correctly.
> And again, you haven't actually proven that it does this.
>
> Note, since H(P,P) is defined to abort its emulation, it doesn't itself
> do a correct emulation, so the test isn't that H didn't reach a final
> halt state, but would an actual emulator, using the same input
> (including that input calling the above H, and not this emulator) be
> able to reach a finl state.
> >
> > computation that halts … the Turing machine will halt whenever it enters
> > a final state. (Linz:1990:234)
> >
> > Linz, Peter 1990. An Introduction to Formal Languages and Automata.
> > Lexington/Toronto: D. C. Heath and Company. (317-320)
> >
> >
> >
> > This paper has not been updated since I converted H into a pure function
> > of its inputs. https://en.wikipedia.org/wiki/Pure_function
> > H no longer recursively calls itself, thus local memory is sufficient.
> >
> > Halting problem undecidability and infinitely nested simulation (V5)
> > https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
> >
> >
> One issue with this code is that it DOES have a hidden input, that
> address that the code has been loaded at, so copies of H can behave
> differently. I will leave it to someone with more expertise in this area
> to indicate how fatal that error is to your argument. This does say that
> if you DID implement this per the actual instructions of Linz, and put a
> COPY of H into P, this difference would be enough to be a problem, as
> well as breaking your H.
>
> Note, you H only works in your broken computation model where H and the
> program it tests are tied up into the same address space, and thus you
> can not actually decide on an arbitrary program.
>
> Also, from this code, the subroutines Init_slave_state, and
> Decide_Halting must also be 'pure' functions of there inputs (which does
> allow them to store information in the buffers provided, but not
> anywhere else that might influence behavior.
>
> In particular, those functions need to behave exactly the same when they
> are evaluatd in the emulated context as when they are directly executed.
>
> The the correct emuluation of H(P,P) by the actual correct and complete
> emulator that is checking the truth that H claims, see the same results
> as the direct execution.

Did you mean "the correct emulation of P(P) / the input to H(P,P)" here, as well as below?

>
> You still need to show where that trace will deviate so that this
> correct and complete emulation of the call to H(P,P) done by P(P) gets
> stuck while the direct execution of H(P,P) when called by main didn't.
>
> What it the first instruction executed that caused a different result.
>
> Until you can actually show how the correct emulation of H(P,P) can
> actually differ from the direct execution of H(P,P), you claim that they
> differ is just an unsubstatiated claim of something known to be impossible.
>
> You have NEVER actually provided anything like a proof of this claim,
> just arguements where you wave your hands and say that the results you
> get (after assuming it is possible) show that it happens, which is just
> a simple fallacious arguement.

On Sunday, June 19, 2022 at 12:37:26 AM UTC-4, Dennis Bush wrote:
> On Sunday, June 19, 2022 at 12:28:11 AM UTC-4, richar...@gmail.com wrote:
> > On 6/18/22 8:00 PM, olcott wrote:
> > > u32 H(u32 P, u32 I)
> > > {
> > > HERE:
> > > u32 End_Of_Code;
> > > u32 Address_of_H; // 2022-06-17
> > > u32 code_end = get_code_end(P);
> > > Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
> > > Allocate(sizeof(Decoded_Line_Of_Code));
> > > Registers* master_state = (Registers*)
> > > Allocate(sizeof(Registers));
> > > Registers* slave_state = (Registers*)
> > > Allocate(sizeof(Registers));
> > > u32* slave_stack = Allocate(0x10000); // 64k;
> > > u32 execution_trace = (u32)Allocate(sizeof(Decoded_Line_Of_Code) *
> > > 1000); // 1000 lines of x86 code
> > >
> > > __asm lea eax, HERE // 2022-06-18
> > > __asm sub eax, 6 // 2022-06-18
> > > __asm mov Address_of_H, eax // 2022-06-18
> > > __asm mov eax, END_OF_CODE
> > > __asm mov End_Of_Code, eax
> > >
> > > Output("Address_of_H:", Address_of_H); // 2022-06-11
> > > Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
> > > Output("\nBegin Simulation Execution Trace Stored at:",
> > > execution_trace);
> > > if (Decide_Halting(&execution_trace, &decoded, code_end, &master_state,
> > > &slave_state, &slave_stack, Address_of_H, P, I))
> > > goto END_OF_CODE;
> > > return 0; // Does not halt
> > > END_OF_CODE:
> > > return 1; // Input has normally terminated
> > > }
> > >
> > >
> > > THIS IS THE BASIC PRINCIPLE OF A HALT DECIDER THAT REFUTES THE HALTING
> > > PROBLEM PROOFS:
> > > When a simulating halt decider rejects all inputs as non-halting
> > > whenever it correctly detects (in a finite number of steps) that its
> > > correct and complete simulation of its input would never reach a final
> > > state of this input that all [these] inputs (including pathological
> > > inputs) are decided correctly.
> > And again, you haven't actually proven that it does this.
> >
> > Note, since H(P,P) is defined to abort its emulation, it doesn't itself
> > do a correct emulation, so the test isn't that H didn't reach a final
> > halt state, but would an actual emulator, using the same input
> > (including that input calling the above H, and not this emulator) be
> > able to reach a finl state.
> > >
> > > computation that halts … the Turing machine will halt whenever it enters
> > > a final state. (Linz:1990:234)
> > >
> > > Linz, Peter 1990. An Introduction to Formal Languages and Automata.
> > > Lexington/Toronto: D. C. Heath and Company. (317-320)
> > >
> > >
> > >
> > > This paper has not been updated since I converted H into a pure function
> > > of its inputs. https://en.wikipedia.org/wiki/Pure_function
> > > H no longer recursively calls itself, thus local memory is sufficient..
> > >
> > > Halting problem undecidability and infinitely nested simulation (V5)
> > > https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
> > >
> > >
> > One issue with this code is that it DOES have a hidden input, that
> > address that the code has been loaded at, so copies of H can behave
> > differently. I will leave it to someone with more expertise in this area
> > to indicate how fatal that error is to your argument. This does say that
> > if you DID implement this per the actual instructions of Linz, and put a
> > COPY of H into P, this difference would be enough to be a problem, as
> > well as breaking your H.
> >
> > Note, you H only works in your broken computation model where H and the
> > program it tests are tied up into the same address space, and thus you
> > can not actually decide on an arbitrary program.
> >
> > Also, from this code, the subroutines Init_slave_state, and
> > Decide_Halting must also be 'pure' functions of there inputs (which does
> > allow them to store information in the buffers provided, but not
> > anywhere else that might influence behavior.
> >
> > In particular, those functions need to behave exactly the same when they
> > are evaluatd in the emulated context as when they are directly executed..
> >
> > The the correct emuluation of H(P,P) by the actual correct and complete
> > emulator that is checking the truth that H claims, see the same results
> > as the direct execution.
> Did you mean "the correct emulation of P(P) / the input to H(P,P)" here, as well as below?

Strike that, I see what you're saying.

> >
> > You still need to show where that trace will deviate so that this
> > correct and complete emulation of the call to H(P,P) done by P(P) gets
> > stuck while the direct execution of H(P,P) when called by main didn't.
> >
> > What it the first instruction executed that caused a different result.
> >
> > Until you can actually show how the correct emulation of H(P,P) can
> > actually differ from the direct execution of H(P,P), you claim that they
> > differ is just an unsubstatiated claim of something known to be impossible.
> >
> > You have NEVER actually provided anything like a proof of this claim,
> > just arguements where you wave your hands and say that the results you
> > get (after assuming it is possible) show that it happens, which is just
> > a simple fallacious arguement.

On 6/18/2022 11:37 PM, Dennis Bush wrote:
> On Sunday, June 19, 2022 at 12:28:11 AM UTC-4, richar...@gmail.com wrote:
>> On 6/18/22 8:00 PM, olcott wrote:
>>> u32 H(u32 P, u32 I)
>>> {
>>> HERE:
>>> u32 End_Of_Code;
>>> u32 Address_of_H; // 2022-06-17
>>> u32 code_end = get_code_end(P);
>>> Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
>>> Allocate(sizeof(Decoded_Line_Of_Code));
>>> Registers* master_state = (Registers*)
>>> Allocate(sizeof(Registers));
>>> Registers* slave_state = (Registers*)
>>> Allocate(sizeof(Registers));
>>> u32* slave_stack = Allocate(0x10000); // 64k;
>>> u32 execution_trace = (u32)Allocate(sizeof(Decoded_Line_Of_Code) *
>>> 1000); // 1000 lines of x86 code
>>>
>>> __asm lea eax, HERE // 2022-06-18
>>> __asm sub eax, 6 // 2022-06-18
>>> __asm mov Address_of_H, eax // 2022-06-18
>>> __asm mov eax, END_OF_CODE
>>> __asm mov End_Of_Code, eax
>>>
>>> Output("Address_of_H:", Address_of_H); // 2022-06-11
>>> Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
>>> Output("\nBegin Simulation Execution Trace Stored at:",
>>> execution_trace);
>>> if (Decide_Halting(&execution_trace, &decoded, code_end, &master_state,
>>> &slave_state, &slave_stack, Address_of_H, P, I))
>>> goto END_OF_CODE;
>>> return 0; // Does not halt
>>> END_OF_CODE:
>>> return 1; // Input has normally terminated
>>> }
>>>
>>>
>>> THIS IS THE BASIC PRINCIPLE OF A HALT DECIDER THAT REFUTES THE HALTING
>>> PROBLEM PROOFS:
>>> When a simulating halt decider rejects all inputs as non-halting
>>> whenever it correctly detects (in a finite number of steps) that its
>>> correct and complete simulation of its input would never reach a final
>>> state of this input that all [these] inputs (including pathological
>>> inputs) are decided correctly.
>> And again, you haven't actually proven that it does this.
>>
>> Note, since H(P,P) is defined to abort its emulation, it doesn't itself
>> do a correct emulation, so the test isn't that H didn't reach a final
>> halt state, but would an actual emulator, using the same input
>> (including that input calling the above H, and not this emulator) be
>> able to reach a finl state.
>>>
>>> computation that halts … the Turing machine will halt whenever it enters
>>> a final state. (Linz:1990:234)
>>>
>>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
>>> Lexington/Toronto: D. C. Heath and Company. (317-320)
>>>
>>>
>>>
>>> This paper has not been updated since I converted H into a pure function
>>> of its inputs. https://en.wikipedia.org/wiki/Pure_function
>>> H no longer recursively calls itself, thus local memory is sufficient.
>>>
>>> Halting problem undecidability and infinitely nested simulation (V5)
>>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>>>
>>>
>> One issue with this code is that it DOES have a hidden input, that
>> address that the code has been loaded at, so copies of H can behave
>> differently. I will leave it to someone with more expertise in this area
>> to indicate how fatal that error is to your argument. This does say that
>> if you DID implement this per the actual instructions of Linz, and put a
>> COPY of H into P, this difference would be enough to be a problem, as
>> well as breaking your H.
>>
>> Note, you H only works in your broken computation model where H and the
>> program it tests are tied up into the same address space, and thus you
>> can not actually decide on an arbitrary program.
>>
>> Also, from this code, the subroutines Init_slave_state, and
>> Decide_Halting must also be 'pure' functions of there inputs (which does
>> allow them to store information in the buffers provided, but not
>> anywhere else that might influence behavior.
>>
>> In particular, those functions need to behave exactly the same when they
>> are evaluatd in the emulated context as when they are directly executed.
>>
>> The the correct emuluation of H(P,P) by the actual correct and complete
>> emulator that is checking the truth that H claims, see the same results
>> as the direct execution.
>
> Did you mean "the correct emulation of P(P) / the input to H(P,P)" here, as well as below?

That is just not the way it works.

When a simulating halt decider rejects all inputs as non-halting
whenever it correctly detects (in a finite number of steps) that its
correct and complete simulation of its input would never reach a final
state of this input that all [these] inputs (including pathological
inputs) are decided correctly.

computation that halts … the Turing machine will halt whenever it enters
a final state. (Linz:1990:234)

Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company. (317-320)

>
>>
>> You still need to show where that trace will deviate so that this
>> correct and complete emulation of the call to H(P,P) done by P(P) gets
>> stuck while the direct execution of H(P,P) when called by main didn't.
>>
>> What it the first instruction executed that caused a different result.
>>
>> Until you can actually show how the correct emulation of H(P,P) can
>> actually differ from the direct execution of H(P,P), you claim that they
>> differ is just an unsubstatiated claim of something known to be impossible.
>>
>> You have NEVER actually provided anything like a proof of this claim,
>> just arguements where you wave your hands and say that the results you
>> get (after assuming it is possible) show that it happens, which is just
>> a simple fallacious arguement.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 6/19/22 12:47 AM, olcott wrote:
> On 6/18/2022 11:37 PM, Dennis Bush wrote:
>> On Sunday, June 19, 2022 at 12:28:11 AM UTC-4, richar...@gmail.com wrote:
>>> On 6/18/22 8:00 PM, olcott wrote:
>>>> u32 H(u32 P, u32 I)
>>>> {
>>>> HERE:
>>>>    u32 End_Of_Code;
>>>>    u32 Address_of_H;              // 2022-06-17
>>>>    u32 code_end                  = get_code_end(P);
>>>>    Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
>>>> Allocate(sizeof(Decoded_Line_Of_Code));
>>>>    Registers*  master_state      = (Registers*)
>>>> Allocate(sizeof(Registers));
>>>>    Registers*  slave_state       = (Registers*)
>>>> Allocate(sizeof(Registers));
>>>>    u32*        slave_stack       = Allocate(0x10000); // 64k;
>>>>    u32  execution_trace = (u32)Allocate(sizeof(Decoded_Line_Of_Code) *
>>>> 1000); // 1000 lines of x86 code
>>>>
>>>>    __asm lea eax, HERE             // 2022-06-18
>>>>    __asm sub eax, 6                // 2022-06-18
>>>>    __asm mov Address_of_H, eax     // 2022-06-18
>>>>    __asm mov eax, END_OF_CODE
>>>>    __asm mov End_Of_Code, eax
>>>>
>>>>    Output("Address_of_H:", Address_of_H); // 2022-06-11
>>>>    Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
>>>>    Output("\nBegin Simulation   Execution Trace Stored at:",
>>>> execution_trace);
>>>>    if (Decide_Halting(&execution_trace, &decoded, code_end,
>>>> &master_state,
>>>>                       &slave_state, &slave_stack, Address_of_H, P, I))
>>>>        goto END_OF_CODE;
>>>>    return 0;  // Does not halt
>>>> END_OF_CODE:
>>>>    return 1; // Input has normally terminated
>>>> }
>>>>
>>>>
>>>> THIS IS THE BASIC PRINCIPLE OF A HALT DECIDER THAT REFUTES THE HALTING
>>>> PROBLEM PROOFS:
>>>> When a simulating halt decider rejects all inputs as non-halting
>>>> whenever it correctly detects (in a finite number of steps) that its
>>>> correct and complete simulation of its input would never reach a final
>>>> state of this input that all [these] inputs (including pathological
>>>> inputs) are decided correctly.
>>> And again, you haven't actually proven that it does this.
>>>
>>> Note, since H(P,P) is defined to abort its emulation, it doesn't itself
>>> do a correct emulation, so the test isn't that H didn't reach a final
>>> halt state, but would an actual emulator, using the same input
>>> (including that input calling the above H, and not this emulator) be
>>> able to reach a finl state.
>>>>
>>>> computation that halts … the Turing machine will halt whenever it
>>>> enters
>>>> a final state. (Linz:1990:234)
>>>>
>>>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
>>>> Lexington/Toronto: D. C. Heath and Company. (317-320)
>>>>
>>>>
>>>>
>>>> This paper has not been updated since I converted H into a pure
>>>> function
>>>> of its inputs. https://en.wikipedia.org/wiki/Pure_function
>>>> H no longer recursively calls itself, thus local memory is sufficient.
>>>>
>>>> Halting problem undecidability and infinitely nested simulation (V5)
>>>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>>>>
>>>>
>>>>
>>> One issue with this code is that it DOES have a hidden input, that
>>> address that the code has been loaded at, so copies of H can behave
>>> differently. I will leave it to someone with more expertise in this area
>>> to indicate how fatal that error is to your argument. This does say that
>>> if you DID implement this per the actual instructions of Linz, and put a
>>> COPY of H into P, this difference would be enough to be a problem, as
>>> well as breaking your H.
>>>
>>> Note, you H only works in your broken computation model where H and the
>>> program it tests are tied up into the same address space, and thus you
>>> can not actually decide on an arbitrary program.
>>>
>>> Also, from this code, the subroutines Init_slave_state, and
>>> Decide_Halting must also be 'pure' functions of there inputs (which does
>>> allow them to store information in the buffers provided, but not
>>> anywhere else that might influence behavior.
>>>
>>> In particular, those functions need to behave exactly the same when they
>>> are evaluatd in the emulated context as when they are directly executed.
>>>
>>> The the correct emuluation of H(P,P) by the actual correct and complete
>>> emulator that is checking the truth that H claims, see the same results
>>> as the direct execution.
>>
>> Did you mean "the correct emulation of P(P) / the input to H(P,P)"
>> here, as well as below?
>
> That is just not the way it works.
>
> When a simulating halt decider rejects all inputs as non-halting
> whenever it correctly detects (in a finite number of steps) that its
> correct and complete simulation of its input would never reach a final
> state of this input that all [these] inputs (including pathological
> inputs) are decided correctly.

Right, so H's answer must match what a CORRECT emulation if the TURING
MACHINE (or PROGRAM) that its input represents would do.

H(P,P) is asking about P(P).

Since P(P) Halts when H(P,P) returns 0, that can not be a correct answer.

It doesn't matter if you can show that if H didn't abort its simulation,
that the correct simulation would be non-halting, that is a DIFFERENT H
and thus a DIFFERENT input P then the one that the H that aborts is
actually being given.

It doesn't matter that it is the same source code / x86 assembly code
for the C function P, what matters is the the equivalkent Turing
Machine, and the computational function P are different, because they
include the algorithms of every thing they call, so different H's mean
different P's.

>
> computation that halts … the Turing machine will halt whenever it enters
> a final state. (Linz:1990:234)
>
> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
> Lexington/Toronto: D. C. Heath and Company. (317-320)
>
>>
>>>
>>> You still need to show where that trace will deviate so that this
>>> correct and complete emulation of the call to H(P,P) done by P(P) gets
>>> stuck while the direct execution of H(P,P) when called by main didn't.
>>>
>>> What it the first instruction executed that caused a different result.
>>>
>>> Until you can actually show how the correct emulation of H(P,P) can
>>> actually differ from the direct execution of H(P,P), you claim that they
>>> differ is just an unsubstatiated claim of something known to be
>>> impossible.
>>>
>>> You have NEVER actually provided anything like a proof of this claim,
>>> just arguements where you wave your hands and say that the results you
>>> get (after assuming it is possible) show that it happens, which is just
>>> a simple fallacious arguement.
>
>

On 6/19/2022 5:59 AM, Richard Damon wrote:
> On 6/19/22 12:47 AM, olcott wrote:
>> On 6/18/2022 11:37 PM, Dennis Bush wrote:
>>> On Sunday, June 19, 2022 at 12:28:11 AM UTC-4, richar...@gmail.com
>>> wrote:
>>>> On 6/18/22 8:00 PM, olcott wrote:
>>>>> u32 H(u32 P, u32 I)
>>>>> {
>>>>> HERE:
>>>>>    u32 End_Of_Code;
>>>>>    u32 Address_of_H;              // 2022-06-17
>>>>>    u32 code_end                  = get_code_end(P);
>>>>>    Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
>>>>> Allocate(sizeof(Decoded_Line_Of_Code));
>>>>>    Registers*  master_state      = (Registers*)
>>>>> Allocate(sizeof(Registers));
>>>>>    Registers*  slave_state       = (Registers*)
>>>>> Allocate(sizeof(Registers));
>>>>>    u32*        slave_stack       = Allocate(0x10000); // 64k;
>>>>>    u32  execution_trace = (u32)Allocate(sizeof(Decoded_Line_Of_Code) *
>>>>> 1000); // 1000 lines of x86 code
>>>>>
>>>>>    __asm lea eax, HERE             // 2022-06-18
>>>>>    __asm sub eax, 6                // 2022-06-18
>>>>>    __asm mov Address_of_H, eax     // 2022-06-18
>>>>>    __asm mov eax, END_OF_CODE
>>>>>    __asm mov End_Of_Code, eax
>>>>>
>>>>>    Output("Address_of_H:", Address_of_H); // 2022-06-11
>>>>>    Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
>>>>>    Output("\nBegin Simulation   Execution Trace Stored at:",
>>>>> execution_trace);
>>>>>    if (Decide_Halting(&execution_trace, &decoded, code_end,
>>>>> &master_state,
>>>>>                       &slave_state, &slave_stack, Address_of_H, P, I))
>>>>>        goto END_OF_CODE;
>>>>>    return 0;  // Does not halt
>>>>> END_OF_CODE:
>>>>>    return 1; // Input has normally terminated
>>>>> }
>>>>>
>>>>>
>>>>> THIS IS THE BASIC PRINCIPLE OF A HALT DECIDER THAT REFUTES THE HALTING
>>>>> PROBLEM PROOFS:
>>>>> When a simulating halt decider rejects all inputs as non-halting
>>>>> whenever it correctly detects (in a finite number of steps) that its
>>>>> correct and complete simulation of its input would never reach a final
>>>>> state of this input that all [these] inputs (including pathological
>>>>> inputs) are decided correctly.
>>>> And again, you haven't actually proven that it does this.
>>>>
>>>> Note, since H(P,P) is defined to abort its emulation, it doesn't itself
>>>> do a correct emulation, so the test isn't that H didn't reach a final
>>>> halt state, but would an actual emulator, using the same input
>>>> (including that input calling the above H, and not this emulator) be
>>>> able to reach a finl state.
>>>>>
>>>>> computation that halts … the Turing machine will halt whenever it
>>>>> enters
>>>>> a final state. (Linz:1990:234)
>>>>>
>>>>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
>>>>> Lexington/Toronto: D. C. Heath and Company. (317-320)
>>>>>
>>>>>
>>>>>
>>>>> This paper has not been updated since I converted H into a pure
>>>>> function
>>>>> of its inputs. https://en.wikipedia.org/wiki/Pure_function
>>>>> H no longer recursively calls itself, thus local memory is sufficient.
>>>>>
>>>>> Halting problem undecidability and infinitely nested simulation (V5)
>>>>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>>>>>
>>>>>
>>>>>
>>>> One issue with this code is that it DOES have a hidden input, that
>>>> address that the code has been loaded at, so copies of H can behave
>>>> differently. I will leave it to someone with more expertise in this
>>>> area
>>>> to indicate how fatal that error is to your argument. This does say
>>>> that
>>>> if you DID implement this per the actual instructions of Linz, and
>>>> put a
>>>> COPY of H into P, this difference would be enough to be a problem, as
>>>> well as breaking your H.
>>>>
>>>> Note, you H only works in your broken computation model where H and the
>>>> program it tests are tied up into the same address space, and thus you
>>>> can not actually decide on an arbitrary program.
>>>>
>>>> Also, from this code, the subroutines Init_slave_state, and
>>>> Decide_Halting must also be 'pure' functions of there inputs (which
>>>> does
>>>> allow them to store information in the buffers provided, but not
>>>> anywhere else that might influence behavior.
>>>>
>>>> In particular, those functions need to behave exactly the same when
>>>> they
>>>> are evaluatd in the emulated context as when they are directly
>>>> executed.
>>>>
>>>> The the correct emuluation of H(P,P) by the actual correct and complete
>>>> emulator that is checking the truth that H claims, see the same results
>>>> as the direct execution.
>>>
>>> Did you mean "the correct emulation of P(P) / the input to H(P,P)"
>>> here, as well as below?
>>
>> That is just not the way it works.
>>
>> When a simulating halt decider rejects all inputs as non-halting
>> whenever it correctly detects (in a finite number of steps) that its
>> correct and complete simulation of its input would never reach a final
>> state of this input that all [these] inputs (including pathological
>> inputs) are decided correctly.
>
> Right, so H's answer must match what a CORRECT emulation if the TURING
> MACHINE (or PROGRAM) that its input represents would do.
Yes and in the same way when a person that represents them (their
lawyer) commits a crime then the person must go to jail because we must
always maintain the indirect relationship.

The direct relationship where the person did not commit the crime so
they don't go to jail must always be superseded by the indirect
relationship.

A halt decider must compute the mapping from its inputs to an accept or
reject state on the basis of the actual behavior of the actual inputs,
not the behavior of some mere proxy representative.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 2022-06-19 08:33, olcott wrote:
> On 6/19/2022 5:59 AM, Richard Damon wrote:
>> On 6/19/22 12:47 AM, olcott wrote:

>> Right, so H's answer must match what a CORRECT emulation if the TURING
>> MACHINE (or PROGRAM) that its input represents would do.
> Yes and in the same way when a person that represents them (their
> lawyer) commits a crime then the person must go to jail because we must
> always maintain the indirect relationship.
>
> The direct relationship where the person did not commit the crime so
> they don't go to jail must always be superseded by the indirect
> relationship.

You do realize that the verb 'represent' means something entirely
different in legal contexts than it does in computer science?

André

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

On 6/19/2022 9:50 AM, André G. Isaak wrote:
> On 2022-06-19 08:33, olcott wrote:
>> On 6/19/2022 5:59 AM, Richard Damon wrote:
>>> On 6/19/22 12:47 AM, olcott wrote:
>
>>> Right, so H's answer must match what a CORRECT emulation if the
>>> TURING MACHINE (or PROGRAM) that its input represents would do.
>> Yes and in the same way when a person that represents them (their
>> lawyer) commits a crime then the person must go to jail because we
>> must always maintain the indirect relationship.
>>
>> The direct relationship where the person did not commit the crime so
>> they don't go to jail must always be superseded by the indirect
>> relationship.
>
> You do realize that the verb 'represent' means something entirely
> different in legal contexts than it does in computer science?
>
> André
>

It is the "indirect reference" proxy relationship that is the same that
I am referring to. When the judge orders the client to appear in court
often his proxy will suffice.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 6/19/22 10:33 AM, olcott wrote:
> On 6/19/2022 5:59 AM, Richard Damon wrote:
>> On 6/19/22 12:47 AM, olcott wrote:
>>> On 6/18/2022 11:37 PM, Dennis Bush wrote:
>>>> On Sunday, June 19, 2022 at 12:28:11 AM UTC-4, richar...@gmail.com
>>>> wrote:
>>>>> On 6/18/22 8:00 PM, olcott wrote:
>>>>>> u32 H(u32 P, u32 I)
>>>>>> {
>>>>>> HERE:
>>>>>>    u32 End_Of_Code;
>>>>>>    u32 Address_of_H;              // 2022-06-17
>>>>>>    u32 code_end                  = get_code_end(P);
>>>>>>    Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
>>>>>> Allocate(sizeof(Decoded_Line_Of_Code));
>>>>>>    Registers*  master_state      = (Registers*)
>>>>>> Allocate(sizeof(Registers));
>>>>>>    Registers*  slave_state       = (Registers*)
>>>>>> Allocate(sizeof(Registers));
>>>>>>    u32*        slave_stack       = Allocate(0x10000); // 64k;
>>>>>>    u32  execution_trace =
>>>>>> (u32)Allocate(sizeof(Decoded_Line_Of_Code) *
>>>>>> 1000); // 1000 lines of x86 code
>>>>>>
>>>>>>    __asm lea eax, HERE             // 2022-06-18
>>>>>>    __asm sub eax, 6                // 2022-06-18
>>>>>>    __asm mov Address_of_H, eax     // 2022-06-18
>>>>>>    __asm mov eax, END_OF_CODE
>>>>>>    __asm mov End_Of_Code, eax
>>>>>>
>>>>>>    Output("Address_of_H:", Address_of_H); // 2022-06-11
>>>>>>    Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
>>>>>>    Output("\nBegin Simulation   Execution Trace Stored at:",
>>>>>> execution_trace);
>>>>>>    if (Decide_Halting(&execution_trace, &decoded, code_end,
>>>>>> &master_state,
>>>>>>                       &slave_state, &slave_stack, Address_of_H, P,
>>>>>> I))
>>>>>>        goto END_OF_CODE;
>>>>>>    return 0;  // Does not halt
>>>>>> END_OF_CODE:
>>>>>>    return 1; // Input has normally terminated
>>>>>> }
>>>>>>
>>>>>>
>>>>>> THIS IS THE BASIC PRINCIPLE OF A HALT DECIDER THAT REFUTES THE
>>>>>> HALTING
>>>>>> PROBLEM PROOFS:
>>>>>> When a simulating halt decider rejects all inputs as non-halting
>>>>>> whenever it correctly detects (in a finite number of steps) that its
>>>>>> correct and complete simulation of its input would never reach a
>>>>>> final
>>>>>> state of this input that all [these] inputs (including pathological
>>>>>> inputs) are decided correctly.
>>>>> And again, you haven't actually proven that it does this.
>>>>>
>>>>> Note, since H(P,P) is defined to abort its emulation, it doesn't
>>>>> itself
>>>>> do a correct emulation, so the test isn't that H didn't reach a final
>>>>> halt state, but would an actual emulator, using the same input
>>>>> (including that input calling the above H, and not this emulator) be
>>>>> able to reach a finl state.
>>>>>>
>>>>>> computation that halts … the Turing machine will halt whenever it
>>>>>> enters
>>>>>> a final state. (Linz:1990:234)
>>>>>>
>>>>>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
>>>>>> Lexington/Toronto: D. C. Heath and Company. (317-320)
>>>>>>
>>>>>>
>>>>>>
>>>>>> This paper has not been updated since I converted H into a pure
>>>>>> function
>>>>>> of its inputs. https://en.wikipedia.org/wiki/Pure_function
>>>>>> H no longer recursively calls itself, thus local memory is
>>>>>> sufficient.
>>>>>>
>>>>>> Halting problem undecidability and infinitely nested simulation (V5)
>>>>>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>>>>>>
>>>>>>
>>>>>>
>>>>> One issue with this code is that it DOES have a hidden input, that
>>>>> address that the code has been loaded at, so copies of H can behave
>>>>> differently. I will leave it to someone with more expertise in this
>>>>> area
>>>>> to indicate how fatal that error is to your argument. This does say
>>>>> that
>>>>> if you DID implement this per the actual instructions of Linz, and
>>>>> put a
>>>>> COPY of H into P, this difference would be enough to be a problem, as
>>>>> well as breaking your H.
>>>>>
>>>>> Note, you H only works in your broken computation model where H and
>>>>> the
>>>>> program it tests are tied up into the same address space, and thus you
>>>>> can not actually decide on an arbitrary program.
>>>>>
>>>>> Also, from this code, the subroutines Init_slave_state, and
>>>>> Decide_Halting must also be 'pure' functions of there inputs (which
>>>>> does
>>>>> allow them to store information in the buffers provided, but not
>>>>> anywhere else that might influence behavior.
>>>>>
>>>>> In particular, those functions need to behave exactly the same when
>>>>> they
>>>>> are evaluatd in the emulated context as when they are directly
>>>>> executed.
>>>>>
>>>>> The the correct emuluation of H(P,P) by the actual correct and
>>>>> complete
>>>>> emulator that is checking the truth that H claims, see the same
>>>>> results
>>>>> as the direct execution.
>>>>
>>>> Did you mean "the correct emulation of P(P) / the input to H(P,P)"
>>>> here, as well as below?
>>>
>>> That is just not the way it works.
>>>
>>> When a simulating halt decider rejects all inputs as non-halting
>>> whenever it correctly detects (in a finite number of steps) that its
>>> correct and complete simulation of its input would never reach a
>>> final state of this input that all [these] inputs (including
>>> pathological inputs) are decided correctly.
>>
>> Right, so H's answer must match what a CORRECT emulation if the TURING
>> MACHINE (or PROGRAM) that its input represents would do.
> Yes and in the same way when a person that represents them (their
> lawyer) commits a crime then the person must go to jail because we must
> always maintain the indirect relationship.

And if H(P,P) doesn't ask about what P(P) does, then YOU have committed
perjury that you swear is following the Linz formula.

Remember, H needs to answer about the PROGRAM and INPUT it is given.

P needs to be given the input so that it asks about P applied to that input.

So, if H(P,P) doesn't ask that question, you hace LIED that your P is
the equivalent of Linz H^. Plain and simple.

>
> The direct relationship where the person did not commit the crime so
> they don't go to jail must always be superseded by the indirect
> relationship.

So, which way are you lying?

Does H(P,P) lie about what its input does since H(P,P) returns 0 and
P(P) Halts, or

Do you lie that you built P wrong, because H(P,P) isn't asking about P(P)?

>
> A halt decider must compute the mapping from its inputs to an accept or
> reject state on the basis of the actual behavior of the actual inputs,
> not the behavior of some mere proxy representative.
>
>

Right, and the actual behavior of the input that P gives must be the
behavior of the computation P(P), or your P isn't built right.

If you can't ask H about the P(P) for the P built on it, the H just
plain fails the universal requirement of a Halt Decider.

DEFINITIONS.

On Sunday, 19 June 2022 at 08:00:38 UTC+8, olcott wrote:
> u32 H(u32 P, u32 I)
> {
> HERE:
> u32 End_Of_Code;
> u32 Address_of_H; // 2022-06-17
> u32 code_end = get_code_end(P);
> Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
> Allocate(sizeof(Decoded_Line_Of_Code));
> Registers* master_state = (Registers*)
> Allocate(sizeof(Registers));
> Registers* slave_state = (Registers*)
> Allocate(sizeof(Registers));
> u32* slave_stack = Allocate(0x10000); // 64k;
> u32 execution_trace = (u32)Allocate(sizeof(Decoded_Line_Of_Code) *
> 1000); // 1000 lines of x86 code
>
> __asm lea eax, HERE // 2022-06-18
> __asm sub eax, 6 // 2022-06-18
> __asm mov Address_of_H, eax // 2022-06-18
> __asm mov eax, END_OF_CODE
> __asm mov End_Of_Code, eax
>
> Output("Address_of_H:", Address_of_H); // 2022-06-11
> Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
> Output("\nBegin Simulation Execution Trace Stored at:",
> execution_trace);
> if (Decide_Halting(&execution_trace, &decoded, code_end, &master_state,
> &slave_state, &slave_stack, Address_of_H, P, I))
> goto END_OF_CODE;
> return 0; // Does not halt
> END_OF_CODE:
> return 1; // Input has normally terminated
> }
>
>
> THIS IS THE BASIC PRINCIPLE OF A HALT DECIDER THAT REFUTES THE HALTING
> PROBLEM PROOFS:
> When a simulating halt decider rejects all inputs as non-halting
> whenever it correctly detects (in a finite number of steps) that its
> correct and complete simulation of its input would never reach a final
> state of this input that all [these] inputs (including pathological
> inputs) are decided correctly.
>
> computation that halts … the Turing machine will halt whenever it enters
> a final state. (Linz:1990:234)
>
> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
> Lexington/Toronto: D. C. Heath and Company. (317-320)
>
>
>
> This paper has not been updated since I converted H into a pure function
> of its inputs. https://en.wikipedia.org/wiki/Pure_function
> H no longer recursively calls itself, thus local memory is sufficient.
>
> Halting problem undecidability and infinitely nested simulation (V5)
> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>
>
> --
> Copyright 2022 Pete Olcott
>
> "Talent hits a target no one else can hit;
> Genius hits a target no one else can see."
> Arthur Schopenhauer

The H shown does not confirm anything you say, it is a fake one (no sign of a
emulator or a decider).
Whom you want to fool (or insult)? yourself? Do you really think reviewers are idiot?

GUR is REPEATEDLY proved by POOH: Halting decider cannot exist.
olcott has repeatedly shown that he cannot provide a real halting decider
except a verbal (or fake) one.

On 2022-06-20 01:19:12 +0000, wij said:

> The H shown does not confirm anything you say, it is a fake one (no sign
> of a emulator or a decider). Whom you want to fool (or insult)? yourself?
> Do you really think reviewers are idiot?

> GUR is REPEATEDLY proved by POOH: Halting decider cannot exist.
> olcott has repeatedly shown that he cannot provide a real halting
> deciderexcept a verbal (or fake) one.

Looks like the discussion is over with the conclusion quoted above.

Mikko