XPost: comp.theory, comp.lang.c, comp.lang.c++

This post assumes that you already know my work, otherwise please read
the linked paper provided below. This work is based on the x86utm
operating system that was created so that every detail of the halting
problem could be directly examined in C/x86.

void Infinite_Loop()
{
HERE: goto HERE;
}

int main()
{
Output("Input_Halts = ", H0(Infinite_Loop));
}

_Infinite_Loop()
[00001342](01) 55 push ebp
[00001343](02) 8bec mov ebp,esp
[00001345](02) ebfe jmp 00001345
[00001347](01) 5d pop ebp
[00001348](01) c3 ret
Size in bytes:(0007) [00001348]

It is totally obvious that the _Infinite_Loop() would never halt
(meaning that it terminates normally by reaching its "ret" instruction).

Equally obvious is the fact that a partial x86 emulation of this input conclusively proves that its complete x86 emulation would never halt.

Begin Local Halt Decider Simulation Execution Trace Stored at:212343 [00001342][00212333][00212337] 55 push ebp [00001343][00212333][00212337] 8bec mov ebp,esp [00001345][00212333][00212337] ebfe jmp 00001345 [00001345][00212333][00212337] ebfe jmp 00001345
Local Halt Decider: Infinite Loop Detected Simulation Stopped

The exact same reasoning applies to the correctly emulated input to H(P,P):

_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]

It is completely obvious that when H(P,P) correctly emulates its input
that it must emulate the first seven instructions of P.

Because the seventh instruction repeats this process we can know with
complete certainty that the emulated P never reaches its final “ret” instruction, thus never halts.



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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.theory, sci.logic

On 6/3/22 6:17 PM, olcott wrote:

This post assumes that you already know my work, otherwise please read
the linked paper provided below. This work is based on the x86utm
operating system that was created so that every detail of the halting
problem could be directly examined in C/x86.

void Infinite_Loop()
{
  HERE: goto HERE;
}

int main()
{
  Output("Input_Halts = ", H0(Infinite_Loop));
}

_Infinite_Loop()
[00001342](01)  55              push ebp
[00001343](02)  8bec            mov ebp,esp
[00001345](02)  ebfe            jmp 00001345
[00001347](01)  5d              pop ebp
[00001348](01)  c3              ret
Size in bytes:(0007) [00001348]

It is totally obvious that the _Infinite_Loop() would never halt
(meaning that it terminates normally by reaching its "ret" instruction).

Equally obvious is the fact that a partial x86 emulation of this input conclusively proves that its complete x86 emulation would never halt.

Begin Local Halt Decider Simulation   Execution Trace Stored at:212343 [00001342][00212333][00212337] 55         push ebp [00001343][00212333][00212337] 8bec       mov ebp,esp [00001345][00212333][00212337] ebfe       jmp 00001345 [00001345][00212333][00212337] ebfe       jmp 00001345
Local Halt Decider: Infinite Loop Detected Simulation Stopped

The exact same reasoning applies to the correctly emulated input to H(P,P):

_P()
[00001352](01)  55              push ebp
[00001353](02)  8bec            mov ebp,esp
[00001355](03)  8b4508          mov eax,[ebp+08]
[00001358](01)  50              push eax      // push P [00001359](03)  8b4d08          mov ecx,[ebp+08]
[0000135c](01)  51              push ecx      // push P [0000135d](05)  e840feffff      call 000011a2 // call H [00001362](03)  83c408          add esp,+08
[00001365](02)  85c0            test eax,eax
[00001367](02)  7402            jz 0000136b
[00001369](02)  ebfe            jmp 00001369
[0000136b](01)  5d              pop ebp
[0000136c](01)  c3              ret
Size in bytes:(0027) [0000136c]

It is completely obvious that when H(P,P) correctly emulates its input
that it must emulate the first seven instructions of P.

Maybe, but then it needs to emulate the eight instruction of the program
P which is at 000011a2, which you never show.

Because the seventh instruction repeats this process we can know with complete certainty that the emulated P never reaches its final “ret” instruction, thus never halts.

Nope. You NEVER have actually shown a correct simulation of the program.

At least, the second "round" of simulation needs to be marked as "a
conditional simulation of the simulation of" the code you list.

Your example with Infinite_Loop doesn't translate to the simulation of
P(P) as there is no actual correct "infinite behavior" pattern that H
has seen, inpart because you ignore that the later rounds of simulation
are ALL conditional based on the simulated H doing its simulation
conditionally based on its halt decision rules.

This means that there actually is NO correct non-halting pattern in the simulation it sees, so when it does abort, it does so incorrectly, or if
it never aborts, it fails to answer.

This has been explained to you many times, but you seem incapable of
actually learning by your mistakes, maybe because you have made yoursef intentionally ignorant of the actual rules of logic, or maybe because
you are just a pathological liar.

FAIL.

Halting problem undecidability and infinitely nested simulation (V5)

https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.theory, sci.logic, comp.software-eng

On Fri, 3 Jun 2022 17:17:12 -0500
olcott <NoOne@NoWhere.com> wrote:

This post assumes that you already know my work, otherwise please
read the linked paper provided below. This work is based on the
x86utm operating system that was created so that every detail of the
halting problem could be directly examined in C/x86.

void Infinite_Loop()
{
HERE: goto HERE;
}

int main()
{
Output("Input_Halts = ", H0(Infinite_Loop));
}

_Infinite_Loop()
[00001342](01) 55 push ebp
[00001343](02) 8bec mov ebp,esp
[00001345](02) ebfe jmp 00001345
[00001347](01) 5d pop ebp
[00001348](01) c3 ret
Size in bytes:(0007) [00001348]

It is totally obvious that the _Infinite_Loop() would never halt
(meaning that it terminates normally by reaching its "ret"
instruction).

Equally obvious is the fact that a partial x86 emulation of this
input conclusively proves that its complete x86 emulation would never
halt.

Begin Local Halt Decider Simulation Execution Trace Stored at:212343 [00001342][00212333][00212337] 55 push ebp [00001343][00212333][00212337] 8bec mov ebp,esp [00001345][00212333][00212337] ebfe jmp 00001345 [00001345][00212333][00212337] ebfe jmp 00001345
Local Halt Decider: Infinite Loop Detected Simulation Stopped

The exact same reasoning applies to the correctly emulated input to
H(P,P):

_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]

It is completely obvious that when H(P,P) correctly emulates its
input that it must emulate the first seven instructions of P.

Because the seventh instruction repeats this process we can know with complete certainty that the emulated P never reaches its final “ret” instruction, thus never halts.

Halting problem undecidability and infinitely nested simulation (V5)

https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5

Unfortunately your logic is such that the decision as to whether or not
to enter the infinite loop is predicated on an infinite recursion (call
H) that is not present in the Halting Problem proofs you are attempting
to refute.

/Flibble

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.theory, sci.logic, comp.software-eng

On Fri, 3 Jun 2022 17:17:12 -0500
olcott <NoOne@NoWhere.com> wrote:

This post assumes that you already know my work, otherwise please
read the linked paper provided below. This work is based on the
x86utm operating system that was created so that every detail of the
halting problem could be directly examined in C/x86.

void Infinite_Loop()
{
HERE: goto HERE;
}

int main()
{
Output("Input_Halts = ", H0(Infinite_Loop));
}

_Infinite_Loop()
[00001342](01) 55 push ebp
[00001343](02) 8bec mov ebp,esp
[00001345](02) ebfe jmp 00001345
[00001347](01) 5d pop ebp
[00001348](01) c3 ret
Size in bytes:(0007) [00001348]

It is totally obvious that the _Infinite_Loop() would never halt
(meaning that it terminates normally by reaching its "ret"
instruction).

Equally obvious is the fact that a partial x86 emulation of this
input conclusively proves that its complete x86 emulation would never
halt.

Begin Local Halt Decider Simulation Execution Trace Stored at:212343 [00001342][00212333][00212337] 55 push ebp [00001343][00212333][00212337] 8bec mov ebp,esp [00001345][00212333][00212337] ebfe jmp 00001345 [00001345][00212333][00212337] ebfe jmp 00001345
Local Halt Decider: Infinite Loop Detected Simulation Stopped

The exact same reasoning applies to the correctly emulated input to
H(P,P):

_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]

It is completely obvious that when H(P,P) correctly emulates its
input that it must emulate the first seven instructions of P.

Because the seventh instruction repeats this process we can know with complete certainty that the emulated P never reaches its final “ret” instruction, thus never halts.

Halting problem undecidability and infinitely nested simulation (V5)

https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5

Unfortunately your logic is such that the decision as to whether or not
to enter the infinite loop is predicated on an infinite recursion (call
H) that is not present in the Halting Problem proofs you are attempting
to refute.

/Flibble

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.theory, sci.logic, comp.software-eng

On 6/3/2022 6:35 PM, Mr Flibble wrote:

On Fri, 3 Jun 2022 17:17:12 -0500
olcott <NoOne@NoWhere.com> wrote:

This post assumes that you already know my work, otherwise please
read the linked paper provided below. This work is based on the
x86utm operating system that was created so that every detail of the
halting problem could be directly examined in C/x86.

void Infinite_Loop()
{
HERE: goto HERE;
}

int main()
{
Output("Input_Halts = ", H0(Infinite_Loop));
}

_Infinite_Loop()
[00001342](01) 55 push ebp
[00001343](02) 8bec mov ebp,esp
[00001345](02) ebfe jmp 00001345
[00001347](01) 5d pop ebp
[00001348](01) c3 ret
Size in bytes:(0007) [00001348]

It is totally obvious that the _Infinite_Loop() would never halt
(meaning that it terminates normally by reaching its "ret"
instruction).

Equally obvious is the fact that a partial x86 emulation of this
input conclusively proves that its complete x86 emulation would never
halt.

Begin Local Halt Decider Simulation Execution Trace Stored at:212343
[00001342][00212333][00212337] 55 push ebp
[00001343][00212333][00212337] 8bec mov ebp,esp
[00001345][00212333][00212337] ebfe jmp 00001345
[00001345][00212333][00212337] ebfe jmp 00001345
Local Halt Decider: Infinite Loop Detected Simulation Stopped

The exact same reasoning applies to the correctly emulated input to
H(P,P):

_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]

It is completely obvious that when H(P,P) correctly emulates its
input that it must emulate the first seven instructions of P.

Because the seventh instruction repeats this process we can know with
complete certainty that the emulated P never reaches its final “ret”
instruction, thus never halts.



Halting problem undecidability and infinitely nested simulation (V5)

https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5

Unfortunately your logic is such that the decision as to whether or not
to enter the infinite loop is predicated on an infinite recursion (call
H) that is not present in the Halting Problem proofs you are attempting
to refute.

/Flibble

It is when a simulating halt decider is assumed.

No one ever bothered to think the otherwise "impossible" input being
analyzed by a simulating halt decider ALL THE WAY THROUGH EVER BEFORE!

On 6/2/2022 1:12 PM, Andy Walker wrote:

http://www.cuboid.me.uk/anw/G12FCO/lect18.html

At any given moment as the emulation proceeds, we are in one of not two
but three states: the program has halted, or it is looping, or it is
still running and has not yet entered a loop. It's the third case that
kills us -- we just have to keep going, and wait for one of the other
two things to happen. The trouble is that it may be that neither of them
ever happens -- which is why `it must be in a loop' was in quotes above.

Andy Walker did provide a fundamentally flawed and totally shallow
analysis of an simulating halt decider.

At any given moment as the emulation proceeds,
we are in one of not two but three states:
(a) The program has halted,
(b) It is still running.
(c) IT HAS MATCHED AN INFINITE BEHAVIOR PATTERN

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

The above matches (c) for infinitely nested simulation.

--
Copyright 2022 Pete Olcott

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.theory, sci.logic

On 6/3/22 7:56 PM, olcott wrote:

On 6/3/2022 6:35 PM, Mr Flibble wrote:

On Fri, 3 Jun 2022 17:17:12 -0500
olcott <NoOne@NoWhere.com> wrote:

This post assumes that you already know my work, otherwise please
read the linked paper provided below. This work is based on the
x86utm operating system that was created so that every detail of the
halting problem could be directly examined in C/x86.

void Infinite_Loop()
{
    HERE: goto HERE;
}

int main()
{
    Output("Input_Halts = ", H0(Infinite_Loop));
}

_Infinite_Loop()
[00001342](01)  55              push ebp
[00001343](02)  8bec            mov ebp,esp
[00001345](02)  ebfe            jmp 00001345
[00001347](01)  5d              pop ebp
[00001348](01)  c3              ret
Size in bytes:(0007) [00001348]

It is totally obvious that the _Infinite_Loop() would never halt
(meaning that it terminates normally by reaching its "ret"
instruction).

Equally obvious is the fact that a partial x86 emulation of this
input conclusively proves that its complete x86 emulation would never
halt.

Begin Local Halt Decider Simulation   Execution Trace Stored at:212343 >>> [00001342][00212333][00212337] 55         push ebp
[00001343][00212333][00212337] 8bec       mov ebp,esp
[00001345][00212333][00212337] ebfe       jmp 00001345
[00001345][00212333][00212337] ebfe       jmp 00001345
Local Halt Decider: Infinite Loop Detected Simulation Stopped

The exact same reasoning applies to the correctly emulated input to
H(P,P):

_P()
[00001352](01)  55              push ebp
[00001353](02)  8bec            mov ebp,esp
[00001355](03)  8b4508          mov eax,[ebp+08]
[00001358](01)  50              push eax      // push P >>> [00001359](03)  8b4d08          mov ecx,[ebp+08]
[0000135c](01)  51              push ecx      // push P >>> [0000135d](05)  e840feffff      call 000011a2 // call H
[00001362](03)  83c408          add esp,+08
[00001365](02)  85c0            test eax,eax
[00001367](02)  7402            jz 0000136b
[00001369](02)  ebfe            jmp 00001369
[0000136b](01)  5d              pop ebp
[0000136c](01)  c3              ret
Size in bytes:(0027) [0000136c]

It is completely obvious that when H(P,P) correctly emulates its
input that it must emulate the first seven instructions of P.

Because the seventh instruction repeats this process we can know with
complete certainty that the emulated P never reaches its final “ret” >>> instruction, thus never halts.



Halting problem undecidability and infinitely nested simulation (V5)

https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5

Unfortunately your logic is such that the decision as to whether or not
to enter the infinite loop is predicated on an infinite recursion (call
H) that is not present in the Halting Problem proofs you are attempting
to refute.

/Flibble

It is when a simulating halt decider is assumed.

But you can not assume that an actual simulating Halt Decider actually
exists.

No one ever bothered to think the otherwise "impossible" input being
analyzed by a simulating halt decider ALL THE WAY THROUGH EVER BEFORE!

On 6/2/2022 1:12 PM, Andy Walker wrote:

  http://www.cuboid.me.uk/anw/G12FCO/lect18.html

At any given moment as the emulation proceeds, we are in one of not two
but three states: the program has halted, or it is looping, or it is
still running and has not yet entered a loop. It's the third case that
kills us -- we just have to keep going, and wait for one of the other
two things to happen. The trouble is that it may be that neither of them
ever happens -- which is why `it must be in a loop' was in quotes above.

Andy Walker did provide a fundamentally flawed and totally shallow
analysis of an simulating halt decider.

At any given moment as the emulation proceeds,
we are in one of not two but three states:
(a) The program has halted,
(b) It is still running.
(c) IT HAS MATCHED AN INFINITE BEHAVIOR PATTERN

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

The above matches (c) for infinitely nested simulation.

Nope, you NEVER get to (C) if H can abort its simulation, since if
H(P,P) will abort its simulation and return 0, then BY DEFINITON P(P) is Halting, and thus the CORRECT answer for H(P,P) is 1.


You can show you get to (c) if H is defined to never abort, but if H is
defined to never abort, it can't then abort and return the answer.

The problem is that when H is defined to abort on ANY finite pattern you
might imagine to be a "correct infinite behavior pattern", then that
pattern is actually proved to not be correct.

The problem is you need to do the analysis looking at the H(P,P) called
by P(P) as being able to what it actually ends up doing. Thus, if you
postulate the top level H(P,P) aborting its simulation for detecting a
pattern, you need to show that pattern actually does exist when the H
that it is simulating will do the same thing.

The pattern you are think of doesn't consider that case, but assumes
that H NEVER (and not just "Not yet") aborts its simulation, and thus is
not applicable here.

The problem appears because the trace you "show" isn't correct, but is
edited and removes the evidence of the conditionality of the "nested" simulations.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.theory, sci.logic

On 6/3/2022 7:20 PM, Richard Damon wrote:

On 6/3/22 7:56 PM, olcott wrote:

On 6/3/2022 6:35 PM, Mr Flibble wrote:

On Fri, 3 Jun 2022 17:17:12 -0500
olcott <NoOne@NoWhere.com> wrote:

This post assumes that you already know my work, otherwise please
read the linked paper provided below. This work is based on the
x86utm operating system that was created so that every detail of the
halting problem could be directly examined in C/x86.

void Infinite_Loop()
{
    HERE: goto HERE;
}

int main()
{
    Output("Input_Halts = ", H0(Infinite_Loop));
}

_Infinite_Loop()
[00001342](01)  55              push ebp
[00001343](02)  8bec            mov ebp,esp
[00001345](02)  ebfe            jmp 00001345
[00001347](01)  5d              pop ebp
[00001348](01)  c3              ret
Size in bytes:(0007) [00001348]

It is totally obvious that the _Infinite_Loop() would never halt
(meaning that it terminates normally by reaching its "ret"
instruction).

Equally obvious is the fact that a partial x86 emulation of this
input conclusively proves that its complete x86 emulation would never
halt.

Begin Local Halt Decider Simulation   Execution Trace Stored at:212343 >>>> [00001342][00212333][00212337] 55         push ebp
[00001343][00212333][00212337] 8bec       mov ebp,esp
[00001345][00212333][00212337] ebfe       jmp 00001345
[00001345][00212333][00212337] ebfe       jmp 00001345
Local Halt Decider: Infinite Loop Detected Simulation Stopped

The exact same reasoning applies to the correctly emulated input to
H(P,P):

_P()
[00001352](01)  55              push ebp
[00001353](02)  8bec            mov ebp,esp
[00001355](03)  8b4508          mov eax,[ebp+08]
[00001358](01)  50              push eax      // push P >>>> [00001359](03)  8b4d08          mov ecx,[ebp+08]
[0000135c](01)  51              push ecx      // push P >>>> [0000135d](05)  e840feffff      call 000011a2 // call H
[00001362](03)  83c408          add esp,+08
[00001365](02)  85c0            test eax,eax
[00001367](02)  7402            jz 0000136b
[00001369](02)  ebfe            jmp 00001369
[0000136b](01)  5d              pop ebp
[0000136c](01)  c3              ret
Size in bytes:(0027) [0000136c]

It is completely obvious that when H(P,P) correctly emulates its
input that it must emulate the first seven instructions of P.

Because the seventh instruction repeats this process we can know with
complete certainty that the emulated P never reaches its final “ret” >>>> instruction, thus never halts.



Halting problem undecidability and infinitely nested simulation (V5)

https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5

Unfortunately your logic is such that the decision as to whether or not
to enter the infinite loop is predicated on an infinite recursion (call
H) that is not present in the Halting Problem proofs you are attempting
to refute.

/Flibble

It is when a simulating halt decider is assumed.

But you can not assume that an actual simulating Halt Decider actually exists.

I proved that H(P,P)==0 is correct.

--
Copyright 2022 Pete Olcott

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.theory, sci.logic

On 6/3/22 11:51 PM, olcott wrote:

On 6/3/2022 7:20 PM, Richard Damon wrote:

On 6/3/22 7:56 PM, olcott wrote:

On 6/3/2022 6:35 PM, Mr Flibble wrote:

On Fri, 3 Jun 2022 17:17:12 -0500
olcott <NoOne@NoWhere.com> wrote:

This post assumes that you already know my work, otherwise please
read the linked paper provided below. This work is based on the
x86utm operating system that was created so that every detail of the >>>>> halting problem could be directly examined in C/x86.

void Infinite_Loop()
{
    HERE: goto HERE;
}

int main()
{
    Output("Input_Halts = ", H0(Infinite_Loop));
}

_Infinite_Loop()
[00001342](01)  55              push ebp
[00001343](02)  8bec            mov ebp,esp
[00001345](02)  ebfe            jmp 00001345
[00001347](01)  5d              pop ebp
[00001348](01)  c3              ret
Size in bytes:(0007) [00001348]

It is totally obvious that the _Infinite_Loop() would never halt
(meaning that it terminates normally by reaching its "ret"
instruction).

Equally obvious is the fact that a partial x86 emulation of this
input conclusively proves that its complete x86 emulation would never >>>>> halt.

Begin Local Halt Decider Simulation   Execution Trace Stored at:212343 >>>>> [00001342][00212333][00212337] 55         push ebp
[00001343][00212333][00212337] 8bec       mov ebp,esp
[00001345][00212333][00212337] ebfe       jmp 00001345
[00001345][00212333][00212337] ebfe       jmp 00001345
Local Halt Decider: Infinite Loop Detected Simulation Stopped

The exact same reasoning applies to the correctly emulated input to
H(P,P):

_P()
[00001352](01)  55              push ebp
[00001353](02)  8bec            mov ebp,esp
[00001355](03)  8b4508          mov eax,[ebp+08]
[00001358](01)  50              push eax      // push P
[00001359](03)  8b4d08          mov ecx,[ebp+08]
[0000135c](01)  51              push ecx      // push P
[0000135d](05)  e840feffff      call 000011a2 // call H
[00001362](03)  83c408          add esp,+08
[00001365](02)  85c0            test eax,eax
[00001367](02)  7402            jz 0000136b
[00001369](02)  ebfe            jmp 00001369
[0000136b](01)  5d              pop ebp
[0000136c](01)  c3              ret
Size in bytes:(0027) [0000136c]

It is completely obvious that when H(P,P) correctly emulates its
input that it must emulate the first seven instructions of P.

Because the seventh instruction repeats this process we can know with >>>>> complete certainty that the emulated P never reaches its final “ret” >>>>> instruction, thus never halts.



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

Unfortunately your logic is such that the decision as to whether or not >>>> to enter the infinite loop is predicated on an infinite recursion (call >>>> H) that is not present in the Halting Problem proofs you are attempting >>>> to refute.

/Flibble

It is when a simulating halt decider is assumed.

But you can not assume that an actual simulating Halt Decider actually
exists.

I proved that H(P,P)==0 is correct.

No, not for the ACTUAL halting problem.

You have shown that H(P,P) == 0 is correct if the problem is can H
simulate its input to a final state, not does that input, when actually
run (or correctly simulate by the actual definition of correct
simulation) reach a final state.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.theory, sci.logic, sci.math

On 6/4/2022 5:01 AM, Malcolm McLean wrote:

On Saturday, 4 June 2022 at 04:51:16 UTC+1, olcott wrote:

On 6/3/2022 7:20 PM, Richard Damon wrote:

On 6/3/22 7:56 PM, olcott wrote:

On 6/3/2022 6:35 PM, Mr Flibble wrote:

On Fri, 3 Jun 2022 17:17:12 -0500
olcott <No...@NoWhere.com> wrote:

This post assumes that you already know my work, otherwise please
read the linked paper provided below. This work is based on the
x86utm operating system that was created so that every detail of the >>>>>> halting problem could be directly examined in C/x86.

void Infinite_Loop()
{
HERE: goto HERE;
}

int main()
{
Output("Input_Halts = ", H0(Infinite_Loop));
}

_Infinite_Loop()
[00001342](01) 55 push ebp
[00001343](02) 8bec mov ebp,esp
[00001345](02) ebfe jmp 00001345
[00001347](01) 5d pop ebp
[00001348](01) c3 ret
Size in bytes:(0007) [00001348]

It is totally obvious that the _Infinite_Loop() would never halt
(meaning that it terminates normally by reaching its "ret"
instruction).

Equally obvious is the fact that a partial x86 emulation of this
input conclusively proves that its complete x86 emulation would never >>>>>> halt.

Begin Local Halt Decider Simulation Execution Trace Stored at:212343 >>>>>> [00001342][00212333][00212337] 55 push ebp
[00001343][00212333][00212337] 8bec mov ebp,esp
[00001345][00212333][00212337] ebfe jmp 00001345
[00001345][00212333][00212337] ebfe jmp 00001345
Local Halt Decider: Infinite Loop Detected Simulation Stopped

The exact same reasoning applies to the correctly emulated input to >>>>>> H(P,P):

_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]

It is completely obvious that when H(P,P) correctly emulates its
input that it must emulate the first seven instructions of P.

Because the seventh instruction repeats this process we can know with >>>>>> complete certainty that the emulated P never reaches its final “ret” >>>>>> instruction, thus never halts.



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

Unfortunately your logic is such that the decision as to whether or not >>>>> to enter the infinite loop is predicated on an infinite recursion (call >>>>> H) that is not present in the Halting Problem proofs you are attempting >>>>> to refute.

/Flibble

It is when a simulating halt decider is assumed.

But you can not assume that an actual simulating Halt Decider actually
exists.

I proved that H(P,P)==0 is correct.

You've got nested simulations.
If H detects them as infinitely nested, and aborts, they are no longer infinitely
nested, so it gets the wrong answer (as happens here).

I can't understand how you can be so wrong about this. It is like you
make sure to never read anything that I say before spouting off a canned rebuttal.

void Infinite_Loop()
{
HERE: goto HERE;
}

int main()
{
Output("Input_Halts = ", H0(Infinite_Loop));
}

_Infinite_Loop()
[00001342](01) 55 push ebp
[00001343](02) 8bec mov ebp,esp
[00001345](02) ebfe jmp 00001345
[00001347](01) 5d pop ebp
[00001348](01) c3 ret
Size in bytes:(0007) [00001348]

In the same way that H0 detects that the complete x86 emulation of _Infinite_Loop() would never reach its final "ret" instruction H(P,P) on
the basis of a partial simulation H(P,P) detects that the complete x86 emulation of its input would never reach its final "ret" instruction.

Did you notice that I said this 500 times already?
Did you notice that I said this 500 times already?
Did you notice that I said this 500 times already?

HALTING DOES NOT MEAN STOPS RUNNING
HALTING DOES NOT MEAN STOPS RUNNING
HALTING DOES NOT MEAN STOPS RUNNING

HALTING MEANS TERMINATED NORMALLY
HALTING MEANS TERMINATED NORMALLY
HALTING MEANS TERMINATED NORMALLY

If H doesn't detects them as infinitely nested, and never aborts, H simulates forever, because they are infinitely nested.

Either way, H gets it wrong.

So you are saying that it is impossible for H0 to correctly detect that _Infinite_Loop() would never reach its final "ret" instruction because
as soon _Infinite_Loop() has had its simulation aborted it magically
leaps to its "ret" instruction.

My own view is that you've actually got something interesting here. That isn't
shared by other posters, probably because you've put them off by claims to have
"solved the halting problem", repeated at great length.

--
Copyright 2022 Pete Olcott

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.theory, sci.logic

On 6/4/2022 5:27 AM, Richard Damon wrote:

On 6/3/22 11:51 PM, olcott wrote:

On 6/3/2022 7:20 PM, Richard Damon wrote:

On 6/3/22 7:56 PM, olcott wrote:

On 6/3/2022 6:35 PM, Mr Flibble wrote:

On Fri, 3 Jun 2022 17:17:12 -0500
olcott <NoOne@NoWhere.com> wrote:

This post assumes that you already know my work, otherwise please
read the linked paper provided below. This work is based on the
x86utm operating system that was created so that every detail of the >>>>>> halting problem could be directly examined in C/x86.

void Infinite_Loop()
{
    HERE: goto HERE;
}

int main()
{
    Output("Input_Halts = ", H0(Infinite_Loop));
}

_Infinite_Loop()
[00001342](01)  55              push ebp
[00001343](02)  8bec            mov ebp,esp
[00001345](02)  ebfe            jmp 00001345
[00001347](01)  5d              pop ebp
[00001348](01)  c3              ret
Size in bytes:(0007) [00001348]

It is totally obvious that the _Infinite_Loop() would never halt
(meaning that it terminates normally by reaching its "ret"
instruction).

Equally obvious is the fact that a partial x86 emulation of this
input conclusively proves that its complete x86 emulation would never >>>>>> halt.

Begin Local Halt Decider Simulation   Execution Trace Stored
at:212343
[00001342][00212333][00212337] 55         push ebp
[00001343][00212333][00212337] 8bec       mov ebp,esp
[00001345][00212333][00212337] ebfe       jmp 00001345
[00001345][00212333][00212337] ebfe       jmp 00001345
Local Halt Decider: Infinite Loop Detected Simulation Stopped

The exact same reasoning applies to the correctly emulated input to >>>>>> H(P,P):

_P()
[00001352](01)  55              push ebp
[00001353](02)  8bec            mov ebp,esp
[00001355](03)  8b4508          mov eax,[ebp+08]
[00001358](01)  50              push eax      // push P
[00001359](03)  8b4d08          mov ecx,[ebp+08]
[0000135c](01)  51              push ecx      // push P
[0000135d](05)  e840feffff      call 000011a2 // call H
[00001362](03)  83c408          add esp,+08
[00001365](02)  85c0            test eax,eax
[00001367](02)  7402            jz 0000136b
[00001369](02)  ebfe            jmp 00001369
[0000136b](01)  5d              pop ebp
[0000136c](01)  c3              ret
Size in bytes:(0027) [0000136c]

It is completely obvious that when H(P,P) correctly emulates its
input that it must emulate the first seven instructions of P.

Because the seventh instruction repeats this process we can know with >>>>>> complete certainty that the emulated P never reaches its final “ret” >>>>>> instruction, thus never halts.



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

Unfortunately your logic is such that the decision as to whether or
not
to enter the infinite loop is predicated on an infinite recursion
(call
H) that is not present in the Halting Problem proofs you are
attempting
to refute.

/Flibble

It is when a simulating halt decider is assumed.

But you can not assume that an actual simulating Halt Decider
actually exists.

I proved that H(P,P)==0 is correct.

No, not for the ACTUAL halting problem.

You have shown that H(P,P) == 0 is correct if the problem is can H
simulate its input to a final state,

THIS IS THE ACTUAL CORRECT PROBLEM DEFINITION
H computes the mapping from its input finite strings to its accept or
reject state on the basis of the actual behavior specified by the actual
input as measured by the correct x86 emulation of this input by H.

not does that input, when actually
run (or correctly simulate by the actual definition of correct
simulation) reach a final state.

int sum(int x, int y)
{
return x + y;
}

It as is nutty to say that H(P,P) must return a value that does not
correspond to its input as it is to expect sum(3,4) to return 23.

--
Copyright 2022 Pete Olcott

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.theory, sci.logic

On 6/4/22 11:28 AM, olcott wrote:

On 6/4/2022 5:27 AM, Richard Damon wrote:

On 6/3/22 11:51 PM, olcott wrote:

On 6/3/2022 7:20 PM, Richard Damon wrote:

On 6/3/22 7:56 PM, olcott wrote:

On 6/3/2022 6:35 PM, Mr Flibble wrote:

On Fri, 3 Jun 2022 17:17:12 -0500
olcott <NoOne@NoWhere.com> wrote:

This post assumes that you already know my work, otherwise please >>>>>>> read the linked paper provided below. This work is based on the
x86utm operating system that was created so that every detail of the >>>>>>> halting problem could be directly examined in C/x86.

void Infinite_Loop()
{
    HERE: goto HERE;
}

int main()
{
    Output("Input_Halts = ", H0(Infinite_Loop));
}

_Infinite_Loop()
[00001342](01)  55              push ebp
[00001343](02)  8bec            mov ebp,esp
[00001345](02)  ebfe            jmp 00001345
[00001347](01)  5d              pop ebp
[00001348](01)  c3              ret
Size in bytes:(0007) [00001348]

It is totally obvious that the _Infinite_Loop() would never halt >>>>>>> (meaning that it terminates normally by reaching its "ret"
instruction).

Equally obvious is the fact that a partial x86 emulation of this >>>>>>> input conclusively proves that its complete x86 emulation would
never
halt.

Begin Local Halt Decider Simulation   Execution Trace Stored
at:212343
[00001342][00212333][00212337] 55         push ebp
[00001343][00212333][00212337] 8bec       mov ebp,esp
[00001345][00212333][00212337] ebfe       jmp 00001345
[00001345][00212333][00212337] ebfe       jmp 00001345
Local Halt Decider: Infinite Loop Detected Simulation Stopped

The exact same reasoning applies to the correctly emulated input to >>>>>>> H(P,P):

_P()
[00001352](01)  55              push ebp
[00001353](02)  8bec            mov ebp,esp
[00001355](03)  8b4508          mov eax,[ebp+08]
[00001358](01)  50              push eax      // push P
[00001359](03)  8b4d08          mov ecx,[ebp+08]
[0000135c](01)  51              push ecx      // push P
[0000135d](05)  e840feffff      call 000011a2 // call H
[00001362](03)  83c408          add esp,+08
[00001365](02)  85c0            test eax,eax
[00001367](02)  7402            jz 0000136b
[00001369](02)  ebfe            jmp 00001369
[0000136b](01)  5d              pop ebp
[0000136c](01)  c3              ret
Size in bytes:(0027) [0000136c]

It is completely obvious that when H(P,P) correctly emulates its >>>>>>> input that it must emulate the first seven instructions of P.

Because the seventh instruction repeats this process we can know >>>>>>> with
complete certainty that the emulated P never reaches its final “ret”
instruction, thus never halts.



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

Unfortunately your logic is such that the decision as to whether
or not
to enter the infinite loop is predicated on an infinite recursion
(call
H) that is not present in the Halting Problem proofs you are
attempting
to refute.

/Flibble

It is when a simulating halt decider is assumed.

But you can not assume that an actual simulating Halt Decider
actually exists.

I proved that H(P,P)==0 is correct.

No, not for the ACTUAL halting problem.

You have shown that H(P,P) == 0 is correct if the problem is can H
simulate its input to a final state,

THIS IS THE ACTUAL CORRECT PROBLEM DEFINITION
H computes the mapping from its input finite strings to its accept or
reject state on the basis of the actual behavior specified by the actual input as measured by the correct x86 emulation of this input by H.

Ok, since your problem statement NEVER mentions the Halting Property, I
guess that means you are admitting you aren't actually working on the
Halting Property.

Also, since the only valid defintion of a "correct x86 emulation" must
behave exactly the same that input when run by an x86 processor, the
ONLY way that H can actually DO that is to never abort until it reaches
the final state, even if that takes forever.

H also needs to be a DEFINITE piece of code, so at can only have a
single behavior for a given input.

Thus, you definition is just shown to be flawed, as H CAN'T both create
a "correct x86 emulation" of the input P,P and also compute a mapping in
finite time,

Either you H fails to correctly emulate its input by deciding early that
its input would not halt, (this can be shown by an actual correct
emulation of that input reaching the halting state), or your H fails to
map this input to an acccept or reject state.

Thus, your definition is just like the Liar's Paradox, it doesn't
actually have a truth value because it just can't exist as stated.

not does that input, when actually run (or correctly simulate by the
actual definition of correct simulation) reach a final state.

int sum(int x, int y)
{
  return x + y;
}

It as is nutty to say that H(P,P) must return a value that does not correspond to its input as it is to expect sum(3,4) to return 23.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.theory, sci.logic, sci.math

On 6/4/22 11:11 AM, olcott wrote:

On 6/4/2022 5:01 AM, Malcolm McLean wrote:

On Saturday, 4 June 2022 at 04:51:16 UTC+1, olcott wrote:

On 6/3/2022 7:20 PM, Richard Damon wrote:

On 6/3/22 7:56 PM, olcott wrote:

On 6/3/2022 6:35 PM, Mr Flibble wrote:

On Fri, 3 Jun 2022 17:17:12 -0500
olcott <No...@NoWhere.com> wrote:

This post assumes that you already know my work, otherwise please >>>>>>> read the linked paper provided below. This work is based on the
x86utm operating system that was created so that every detail of the >>>>>>> halting problem could be directly examined in C/x86.

void Infinite_Loop()
{
     HERE: goto HERE;
}

int main()
{
     Output("Input_Halts = ", H0(Infinite_Loop));
}

_Infinite_Loop()
[00001342](01)  55              push ebp
[00001343](02)  8bec            mov ebp,esp
[00001345](02)  ebfe            jmp 00001345
[00001347](01)  5d              pop ebp
[00001348](01)  c3              ret
Size in bytes:(0007) [00001348]

It is totally obvious that the _Infinite_Loop() would never halt >>>>>>> (meaning that it terminates normally by reaching its "ret"
instruction).

Equally obvious is the fact that a partial x86 emulation of this >>>>>>> input conclusively proves that its complete x86 emulation would
never
halt.

Begin Local Halt Decider Simulation   Execution Trace Stored
at:212343
[00001342][00212333][00212337] 55         push ebp
[00001343][00212333][00212337] 8bec       mov ebp,esp
[00001345][00212333][00212337] ebfe       jmp 00001345
[00001345][00212333][00212337] ebfe       jmp 00001345
Local Halt Decider: Infinite Loop Detected Simulation Stopped

The exact same reasoning applies to the correctly emulated input to >>>>>>> H(P,P):

_P()
[00001352](01)  55              push ebp
[00001353](02)  8bec            mov ebp,esp
[00001355](03)  8b4508          mov eax,[ebp+08]
[00001358](01)  50              push eax      // push P
[00001359](03)  8b4d08          mov ecx,[ebp+08]
[0000135c](01)  51              push ecx      // push P
[0000135d](05)  e840feffff      call 000011a2 // call H
[00001362](03)  83c408          add esp,+08
[00001365](02)  85c0            test eax,eax
[00001367](02)  7402            jz 0000136b
[00001369](02)  ebfe            jmp 00001369
[0000136b](01)  5d              pop ebp
[0000136c](01)  c3              ret
Size in bytes:(0027) [0000136c]

It is completely obvious that when H(P,P) correctly emulates its >>>>>>> input that it must emulate the first seven instructions of P.

Because the seventh instruction repeats this process we can know >>>>>>> with
complete certainty that the emulated P never reaches its final “ret”
instruction, thus never halts.



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

Unfortunately your logic is such that the decision as to whether
or not
to enter the infinite loop is predicated on an infinite recursion
(call
H) that is not present in the Halting Problem proofs you are
attempting
to refute.

/Flibble

It is when a simulating halt decider is assumed.

But you can not assume that an actual simulating Halt Decider actually >>>> exists.

I proved that H(P,P)==0 is correct.

You've got nested simulations.
If H detects them as infinitely nested, and aborts, they are no longer
infinitely
nested, so it gets the wrong answer (as happens here).

I can't understand how you can be so wrong about this. It is like you
make sure to never read anything that I say before spouting off a canned rebuttal.

void Infinite_Loop()
{
  HERE: goto HERE;
}

int main()
{
  Output("Input_Halts = ", H0(Infinite_Loop));
}

_Infinite_Loop()
[00001342](01)  55              push ebp
[00001343](02)  8bec            mov ebp,esp
[00001345](02)  ebfe            jmp 00001345
[00001347](01)  5d              pop ebp
[00001348](01)  c3              ret
Size in bytes:(0007) [00001348]

In the same way that H0 detects that the complete x86 emulation of _Infinite_Loop() would never reach its final "ret" instruction H(P,P) on
the basis of a partial simulation H(P,P) detects that the complete x86 emulation of its input would never reach its final "ret" instruction.

Did you notice that I said this 500 times already?
Did you notice that I said this 500 times already?
Did you notice that I said this 500 times already?

HALTING DOES NOT MEAN STOPS RUNNING
HALTING DOES NOT MEAN STOPS RUNNING
HALTING DOES NOT MEAN STOPS RUNNING

Right, and for the simulation of H(P,P), that is all that happen

HALTING MEANS TERMINATED NORMALLY
HALTING MEANS TERMINATED NORMALLY
HALTING MEANS TERMINATED NORMALLY

And the input to H(P,P) does TERMINATE NORMALLY when correct simulated.

If H doesn't detects them as infinitely nested, and never aborts, H
simulates
forever, because they are infinitely nested.

Either way, H gets it wrong.

So you are saying that it is impossible for H0 to correctly detect that _Infinite_Loop() would never reach its final "ret" instruction because
as soon _Infinite_Loop() has had its simulation aborted it magically
leaps to its "ret" instruction.

Nope, he NEVER said that. You apparently just can't read, and thus prove
your stupidity.

You keep on making this mistake, that when people say your H can't do
one thing about P, that you say "Are you saying it can't do it for this
other trivial program?"

You are a great example of someone using many different logical
fallicies in their arguement.

You use them SO well, it really seems to be deliberate.

All you have proved so far is that you just don't understand how to do
proper logical arguments, and are appatently way out of your depth in
what you are talking about.

My own view is that you've actually got something interesting here.
That isn't
shared by other posters, probably because you've put them off by
claims to have
"solved the halting problem", repeated at great length.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.lang.c, comp.lang.c++

On 6/4/2022 3:12 AM, Muttley@dastardlyhq.com wrote:

On Fri, 3 Jun 2022 17:17:12 -0500
olcott <NoOne@NoWhere.com> wrote:

This post assumes that you already know my work, otherwise please read
the linked paper provided below. This work is based on the x86utm

Thanks, but I need to go watch some paint dry. Maybe next time.

Until the notion of truth itself is formalized research in artificial intelligence is hobbled.

A correct refutation of the halting problem proofs also refutes the
Tarski undefinability theorem by proxy, thus enabling the notion of
truth to be formalized.

This anchors the basis of Davidson's truth conditional semantics. This
creates the roadmap for artificial intelligence with unlimited potential.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.theory, sci.logic, sci.math

[ Followup-To: set ]

In comp.theory olcott <NoOne@nowhere.com> wrote:

On 6/4/2022 5:01 AM, Malcolm McLean wrote:

On Saturday, 4 June 2022 at 04:51:16 UTC+1, olcott wrote:

On 6/3/2022 7:20 PM, Richard Damon wrote:

On 6/3/22 7:56 PM, olcott wrote:

On 6/3/2022 6:35 PM, Mr Flibble wrote:

On Fri, 3 Jun 2022 17:17:12 -0500
olcott <No...@NoWhere.com> wrote:

[ .... ]

You've got nested simulations.
If H detects them as infinitely nested, and aborts, they are no longer
infinitely nested, so it gets the wrong answer (as happens here).

I can't understand how you can be so wrong about this. It is like you
make sure to never read anything that I say before spouting off a canned rebuttal.

I frequently read what you say. It's dull and repetitive. And wrong.

void Infinite_Loop()
{
HERE: goto HERE;
}

int main()
{
Output("Input_Halts = ", H0(Infinite_Loop));
}

_Infinite_Loop()
[00001342](01) 55 push ebp
[00001343](02) 8bec mov ebp,esp
[00001345](02) ebfe jmp 00001345
[00001347](01) 5d pop ebp
[00001348](01) c3 ret
Size in bytes:(0007) [00001348]

In the same way that H0 detects .....

We don't know what H0 detects, since its code is secret, and probably
doesn't exist.

.... that the complete x86 emulation of _Infinite_Loop() would never
reach its final "ret" instruction H(P,P) on the basis of a partial
simulation H(P,P) detects that the complete x86 emulation of its input
would never reach its final "ret" instruction.

Did you notice that I said this 500 times already?
Did you notice that I said this 500 times already?
Did you notice that I said this 500 times already?

Yes. It's dull and repetitive and wrong. If it were correct, you would
only need to say it once, and it would be accepted and acknowledged by
the experts in this group.

HALTING DOES NOT MEAN STOPS RUNNING
HALTING DOES NOT MEAN STOPS RUNNING
HALTING DOES NOT MEAN STOPS RUNNING

In this context, it does.

HALTING MEANS TERMINATED NORMALLY
HALTING MEANS TERMINATED NORMALLY
HALTING MEANS TERMINATED NORMALLY

A turing machine runs until it halts. Terminated "normally" has no
meaning. That is one reason you avoid turing machines. They make things
too clear and well defined, leaving you no room to argue stupidities like "halting doesn't mean stops running".

If H doesn't detects them as infinitely nested, and never aborts, H
simulates forever, because they are infinitely nested.

Either way, H gets it wrong.

So you are saying that it is impossible for H0 to correctly detect that _Infinite_Loop() would never reach its final "ret" instruction because
as soon _Infinite_Loop() has had its simulation aborted it magically
leaps to its "ret" instruction.

Wrong. That is not what he is saying. He is saying that H gets it
wrong, explaining why.

[ .... ]

--
Copyright 2022 Pete Olcott

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

--
Alan Mackenzie (Nuremberg, Germany).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.theory, sci.logic, sci.math

On 6/4/22 3:28 PM, olcott wrote:

On 6/4/2022 1:17 PM, Alan Mackenzie wrote:

[ Followup-To: set ]

In comp.theory olcott <NoOne@nowhere.com> wrote:

On 6/4/2022 5:01 AM, Malcolm McLean wrote:

On Saturday, 4 June 2022 at 04:51:16 UTC+1, olcott wrote:

On 6/3/2022 7:20 PM, Richard Damon wrote:

On 6/3/22 7:56 PM, olcott wrote:

On 6/3/2022 6:35 PM, Mr Flibble wrote:

On Fri, 3 Jun 2022 17:17:12 -0500
olcott <No...@NoWhere.com> wrote:

[ .... ]

You've got nested simulations.
If H detects them as infinitely nested, and aborts, they are no longer >>>> infinitely nested, so it gets the wrong answer (as happens here).

I can't understand how you can be so wrong about this. It is like you
make sure to never read anything that I say before spouting off a canned >>> rebuttal.

I frequently read what you say.  It's dull and repetitive.  And wrong.

void Infinite_Loop()
{
   HERE: goto HERE;
}

int main()
{
   Output("Input_Halts = ", H0(Infinite_Loop));
}

_Infinite_Loop()
[00001342](01)  55              push ebp
[00001343](02)  8bec            mov ebp,esp
[00001345](02)  ebfe            jmp 00001345
[00001347](01)  5d              pop ebp
[00001348](01)  c3              ret
Size in bytes:(0007) [00001348]

In the same way that H0 detects .....

We don't know what H0 detects, since its code is secret, and probably
doesn't exist.

.... that the complete x86 emulation of _Infinite_Loop() would never
reach its final "ret" instruction H(P,P) on the basis of a partial
simulation H(P,P) detects that the complete x86 emulation of its input
would never reach its final "ret" instruction.

Did you notice that I said this 500 times already?
Did you notice that I said this 500 times already?
Did you notice that I said this 500 times already?

Yes.  It's dull and repetitive and wrong.  If it were correct, you would >> only need to say it once, and it would be accepted and acknowledged by
the experts in this group.

HALTING DOES NOT MEAN STOPS RUNNING
HALTING DOES NOT MEAN STOPS RUNNING
HALTING DOES NOT MEAN STOPS RUNNING

In this context, it does.

HALTING MEANS TERMINATED NORMALLY
HALTING MEANS TERMINATED NORMALLY
HALTING MEANS TERMINATED NORMALLY

A turing machine runs until it halts.  Terminated "normally" has no
meaning.

A Turing machine is said to halt whenever it reaches a configuration for which δ is not defined; this is possible because δ is a partial
function. In fact, we will assume that no transitions are defined for
any final state so 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.

Yes, it appears that Linz is using the notation that any unspecified
transition is the signal that the machine halts where it is, as opposed
to the notation with a defined set of final states (which have no
transitions specified, and all other states have ALL transitions
specified). These are "equivalent" descriptions in terms of computing
power unless you are playing Turing Golf and scoring based on the "size"
of the Turing Machine.

When translated into ordinary software engineering terms this means terminated normally. In a C function this means reaching the "ret" instruction.

That is one reason you avoid turing machines.  They make things
too clear and well defined, leaving you no room to argue stupidities like
"halting doesn't mean stops running".

The reason that I avoid Turing machines is that 99% of the most
important details cannot be fully expressed or analyzed. After all of
these details are fully understood then it is very easy to apply the
same reasoning to the Linz proof as I have done in my paper.

No, you avoid them because you can't pull the shenanagians with them
that you do with your x86 code. The key here is that a Turing Machine,
by its very nature, can only be a computation, while x86 code fragments
can easily be non-computations. By all appearances, you decider H is NOT actually a computation, and the only way for you to actually prove it is
would be to let others inspect your code, but that would let the cat out
of the bag (which you will probably call a dog).


I suspect that also, you just don't understand how a Turing Machine
actually works, because you are such a poor programmer you can't deal
with a machine that won't take your dirty tricks. Maybe the issue is you
have tried to code your trick as a Turing Machine, and because you can't
make a non-computation out of one, you just failed and don't want to
admit that you are just being a cheater.

Halting problem undecidability and infinitely nested simulation (V5)

https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.theory, sci.logic, sci.math

On 6/4/2022 1:17 PM, Alan Mackenzie wrote:

[ Followup-To: set ]

In comp.theory olcott <NoOne@nowhere.com> wrote:

On 6/4/2022 5:01 AM, Malcolm McLean wrote:

On Saturday, 4 June 2022 at 04:51:16 UTC+1, olcott wrote:

On 6/3/2022 7:20 PM, Richard Damon wrote:

On 6/3/22 7:56 PM, olcott wrote:

On 6/3/2022 6:35 PM, Mr Flibble wrote:

On Fri, 3 Jun 2022 17:17:12 -0500
olcott <No...@NoWhere.com> wrote:

[ .... ]

You've got nested simulations.
If H detects them as infinitely nested, and aborts, they are no longer
infinitely nested, so it gets the wrong answer (as happens here).

I can't understand how you can be so wrong about this. It is like you
make sure to never read anything that I say before spouting off a canned
rebuttal.

I frequently read what you say. It's dull and repetitive. And wrong.

void Infinite_Loop()
{
HERE: goto HERE;
}

int main()
{
Output("Input_Halts = ", H0(Infinite_Loop));
}

_Infinite_Loop()
[00001342](01) 55 push ebp
[00001343](02) 8bec mov ebp,esp
[00001345](02) ebfe jmp 00001345
[00001347](01) 5d pop ebp
[00001348](01) c3 ret
Size in bytes:(0007) [00001348]

In the same way that H0 detects .....

We don't know what H0 detects, since its code is secret, and probably
doesn't exist.

.... that the complete x86 emulation of _Infinite_Loop() would never
reach its final "ret" instruction H(P,P) on the basis of a partial
simulation H(P,P) detects that the complete x86 emulation of its input
would never reach its final "ret" instruction.

Did you notice that I said this 500 times already?
Did you notice that I said this 500 times already?
Did you notice that I said this 500 times already?

Yes. It's dull and repetitive and wrong. If it were correct, you would
only need to say it once, and it would be accepted and acknowledged by
the experts in this group.

HALTING DOES NOT MEAN STOPS RUNNING
HALTING DOES NOT MEAN STOPS RUNNING
HALTING DOES NOT MEAN STOPS RUNNING

In this context, it does.

HALTING MEANS TERMINATED NORMALLY
HALTING MEANS TERMINATED NORMALLY
HALTING MEANS TERMINATED NORMALLY

A turing machine runs until it halts. Terminated "normally" has no
meaning.

A Turing machine is said to halt whenever it reaches a configuration for
which δ is not defined; this is possible because δ is a partial
function. In fact, we will assume that no transitions are defined for
any final state so 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.

When translated into ordinary software engineering terms this means
terminated normally. In a C function this means reaching the "ret"
instruction.

That is one reason you avoid turing machines. They make things
too clear and well defined, leaving you no room to argue stupidities like "halting doesn't mean stops running".

The reason that I avoid Turing machines is that 99% of the most
important details cannot be fully expressed or analyzed. After all of
these details are fully understood then it is very easy to apply the
same reasoning to the Linz proof as I have done in my paper.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.theory, sci.logic, sci.math

On 6/4/2022 2:05 PM, Richard Damon wrote:

<SNIP>

Yes, it appears that Linz is using the notation that any unspecified transition is the signal that the machine halts where it is, as opposed
to the notation with a defined set of final states (which have no
transitions specified, and all other states have ALL transitions
specified). These are "equivalent" descriptions in terms of computing
power unless you are playing Turing Golf and scoring based on the "size"
of the Turing Machine.

The normal game is scored by the product of the number of states and the
size of the tape (as opposed to the input) alphabet.
--
Jeff Barnett

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.lang.c, comp.lang.c++

On Sat, 4 Jun 2022 11:14:19 -0500
olcott <NoOne@NoWhere.com> wrote:

On 6/4/2022 3:12 AM, Muttley@dastardlyhq.com wrote:

On Fri, 3 Jun 2022 17:17:12 -0500
olcott <NoOne@NoWhere.com> wrote:

This post assumes that you already know my work, otherwise please read
the linked paper provided below. This work is based on the x86utm

Thanks, but I need to go watch some paint dry. Maybe next time.

Until the notion of truth itself is formalized research in artificial >intelligence is hobbled.

A correct refutation of the halting problem proofs also refutes the
Tarski undefinability theorem by proxy, thus enabling the notion of
truth to be formalized.

This anchors the basis of Davidson's truth conditional semantics. This >creates the roadmap for artificial intelligence with unlimited potential.

Halting problem undecidability and infinitely nested simulation (V5)

You sound like the output of a simple markov chain chat bot thats been fed
some doctorate level CS papers.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.lang.c, comp.lang.c++

On 6/5/2022 9:58 AM, Muttley@dastardlyhq.com wrote:

On Sat, 4 Jun 2022 11:14:19 -0500
olcott <NoOne@NoWhere.com> wrote:

On 6/4/2022 3:12 AM, Muttley@dastardlyhq.com wrote:

On Fri, 3 Jun 2022 17:17:12 -0500
olcott <NoOne@NoWhere.com> wrote:

This post assumes that you already know my work, otherwise please read >>>> the linked paper provided below. This work is based on the x86utm

Thanks, but I need to go watch some paint dry. Maybe next time.

Until the notion of truth itself is formalized research in artificial
intelligence is hobbled.

A correct refutation of the halting problem proofs also refutes the
Tarski undefinability theorem by proxy, thus enabling the notion of
truth to be formalized.

This anchors the basis of Davidson's truth conditional semantics. This
creates the roadmap for artificial intelligence with unlimited potential.

Halting problem undecidability and infinitely nested simulation (V5)

You sound like the output of a simple markov chain chat bot thats been fed some doctorate level CS papers.

I posted to this group because I have boiled down a key computer science problem into ordinary software engineering in C/x86.

In computability theory, the halting problem is the problem of determining,
from a description of an arbitrary computer program and an input,
whether
the program will finish running, or continue to run forever. Alan
Turing proved
in 1936 that a general algorithm to solve the halting problem for
all possible
program-input pairs cannot exist.

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



#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));
}

_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]

It is completely obvious that when H(P,P) correctly emulates its input
that it must emulate the first seven instructions of P. Because the
seventh instruction of P repeats this process we can know with complete certainty that the emulated P never reaches its final “ret” instruction, thus never halts.

Because we can easily see that H(P,P)==0 is correct we can know that the otherwise "impossible" input to the halting problem proofs is correctly rejected as non-halting.



--
Copyright 2022 Pete Olcott

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.lang.c, comp.lang.c++

On 05.06.22 22:05, olcott wrote:

On 6/5/2022 9:58 AM, Muttley@dastardlyhq.com wrote:

On Sat, 4 Jun 2022 11:14:19 -0500
olcott <NoOne@NoWhere.com> wrote:

On 6/4/2022 3:12 AM, Muttley@dastardlyhq.com wrote:

On Fri, 3 Jun 2022 17:17:12 -0500
olcott <NoOne@NoWhere.com> wrote:

This post assumes that you already know my work, otherwise please read >>>>> the linked paper provided below. This work is based on the x86utm

Thanks, but I need to go watch some paint dry. Maybe next time.

Until the notion of truth itself is formalized research in artificial
intelligence is hobbled.

A correct refutation of the halting problem proofs also refutes the
Tarski undefinability theorem by proxy, thus enabling the notion of
truth to be formalized.

This anchors the basis of Davidson's truth conditional semantics. This
creates the roadmap for artificial intelligence with unlimited
potential.

Halting problem undecidability and infinitely nested simulation (V5)

You sound like the output of a simple markov chain chat bot thats been
fed
some doctorate level CS papers.

I posted to this group because I have boiled down a key computer science problem into ordinary software engineering in C/x86.

     In computability theory, the halting problem is the problem of determining,
     from a description of an arbitrary computer program and an input, whether
     the program will finish running, or continue to run forever. Alan Turing proved
     in 1936 that a general algorithm to solve the halting problem for all possible
     program-input pairs cannot exist.

     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

#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));
}

_P()
[00001352](01)  55              push ebp
[00001353](02)  8bec            mov ebp,esp
[00001355](03)  8b4508          mov eax,[ebp+08]
[00001358](01)  50              push eax      // push P [00001359](03)  8b4d08          mov ecx,[ebp+08]
[0000135c](01)  51              push ecx      // push P [0000135d](05)  e840feffff      call 000011a2 // call H [00001362](03)  83c408          add esp,+08
[00001365](02)  85c0            test eax,eax
[00001367](02)  7402            jz 0000136b
[00001369](02)  ebfe            jmp 00001369
[0000136b](01)  5d              pop ebp
[0000136c](01)  c3              ret
Size in bytes:(0027) [0000136c]

It is completely obvious that when H(P,P) correctly emulates its input
that it must emulate the first seven instructions of P. Because the
seventh instruction of P repeats this process we can know with complete certainty that the emulated P never reaches its final “ret” instruction, thus never halts.

Because we can easily see that H(P,P)==0 is correct we can know that the otherwise "impossible" input to the halting problem proofs is correctly rejected as non-halting.

What about the opposite: can you make a program that always correctly
predicts that another program will halt? It doesn't seem to me that this
case is included in what you did, but I must admit, computer science is
not my major.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.lang.c, comp.lang.c++

On 6/5/2022 3:24 PM, Freethinker wrote:

On 05.06.22 22:05, olcott wrote:

On 6/5/2022 9:58 AM, Muttley@dastardlyhq.com wrote:

On Sat, 4 Jun 2022 11:14:19 -0500
olcott <NoOne@NoWhere.com> wrote:

On 6/4/2022 3:12 AM, Muttley@dastardlyhq.com wrote:

On Fri, 3 Jun 2022 17:17:12 -0500
olcott <NoOne@NoWhere.com> wrote:

This post assumes that you already know my work, otherwise please
read
the linked paper provided below. This work is based on the x86utm

Thanks, but I need to go watch some paint dry. Maybe next time.

Until the notion of truth itself is formalized research in artificial
intelligence is hobbled.

A correct refutation of the halting problem proofs also refutes the
Tarski undefinability theorem by proxy, thus enabling the notion of
truth to be formalized.

This anchors the basis of Davidson's truth conditional semantics. This >>>> creates the roadmap for artificial intelligence with unlimited
potential.

Halting problem undecidability and infinitely nested simulation (V5)

You sound like the output of a simple markov chain chat bot thats
been fed
some doctorate level CS papers.

I posted to this group because I have boiled down a key computer
science problem into ordinary software engineering in C/x86.

      In computability theory, the halting problem is the problem of
determining,
      from a description of an arbitrary computer program and an
input, whether
      the program will finish running, or continue to run forever.
Alan Turing proved
      in 1936 that a general algorithm to solve the halting problem
for all possible
      program-input pairs cannot exist.

      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



#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));
}

_P()
[00001352](01)  55              push ebp
[00001353](02)  8bec            mov ebp,esp
[00001355](03)  8b4508          mov eax,[ebp+08]
[00001358](01)  50              push eax      // push P >> [00001359](03)  8b4d08          mov ecx,[ebp+08]
[0000135c](01)  51              push ecx      // push P >> [0000135d](05)  e840feffff      call 000011a2 // call H
[00001362](03)  83c408          add esp,+08
[00001365](02)  85c0            test eax,eax
[00001367](02)  7402            jz 0000136b
[00001369](02)  ebfe            jmp 00001369
[0000136b](01)  5d              pop ebp
[0000136c](01)  c3              ret
Size in bytes:(0027) [0000136c]

It is completely obvious that when H(P,P) correctly emulates its input
that it must emulate the first seven instructions of P. Because the
seventh instruction of P repeats this process we can know with
complete certainty that the emulated P never reaches its final “ret”
instruction, thus never halts.

Because we can easily see that H(P,P)==0 is correct we can know that
the otherwise "impossible" input to the halting problem proofs is
correctly rejected as non-halting.

What about the opposite: can you make a program that always correctly predicts that another program will halt? It doesn't seem to me that this
case is included in what you did, but I must admit, computer science is
not my major.

The whole scope of my investigation was to simply correctly refute the conventional halting problem proofs, thus proving that a universal halt
decider is possible. Actually making a a universal halt decider would
take at least 1000 labor years.

--
Copyright 2022 Pete Olcott

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.theory, sci.logic

On 6/5/2022 7:40 PM, Ben wrote:

Jeff Barnett <jbb@notatt.com> writes:

On 6/5/2022 5:59 PM, Mike Terry wrote:

The question right now is what you would call a TM which evaluates
the first 10 steps of a computation, and then does something else.
What is it doing while evaluating those 10 steps?

What would I call it? POOP! It just goes to show the accuracy and
flexibility of Ben's acronym for any Peter-related concept.

Credit where it's due... POOP is Richard's. Mine was not as good.

That was the initial incorrect rebuttal that claimed the concept of a simulating halt decider is inherently invalid.

When a simulating halt decider H correctly predicts that its complete simulation of its input finite string would never reach the final state
of this machine description then H has correctly rejected this input as non-halting.

--
Copyright 2022 Pete Olcott

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.theory, sci.logic

On 6/5/2022 8:59 PM, Richard Damon wrote:

On 6/5/22 9:03 PM, olcott wrote:

On 6/5/2022 7:40 PM, Ben wrote:

Jeff Barnett <jbb@notatt.com> writes:

On 6/5/2022 5:59 PM, Mike Terry wrote:

The question right now is what you would call a TM which evaluates
the first 10 steps of a computation, and then does something else.
What is it doing while evaluating those 10 steps?

What would I call it? POOP! It just goes to show the accuracy and
flexibility of Ben's acronym for any Peter-related concept.

Credit where it's due... POOP is Richard's.  Mine was not as good.

That was the initial incorrect rebuttal that claimed the concept of a
simulating halt decider is inherently invalid.

When a simulating halt decider H correctly predicts that its complete
simulation of its input finite string would never reach the final
state of this machine description then H has correctly rejected this
input as non-halting.

No, its based on the fact that you are trying to define the "correct"
answer for H to be something different than what the Halting Problem Requires.

If that was true then one of these facts wold not be verified:
(1) The relationship between H and P matches the pattern specified below:

(2) H does correctly compute the mapping from the x86 machine code to
its reject state on the basis

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

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

int main()
{
Output("Input_Halts = ", H1((u32)P, (u32)P));
}

_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]



--
Copyright 2022 Pete Olcott

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.theory, sci.logic, sci.math

On 6/5/2022 8:58 PM, Mike Terry wrote:

On 06/06/2022 01:24, Jeff Barnett wrote:

On 6/5/2022 5:59 PM, Mike Terry wrote:

<..snip..>>>

Sure.
The question right now is what you would call a TM which evaluates
the first 10 steps of a computation, and then does something else.
What is it doing while evaluating those 10 steps?

What would I call it? POOP! It just goes to show the accuracy and
flexibility of Ben's acronym for any Peter-related concept.

But PO didn't invent the concept of (partially) simulating a computation
in order to compute certain properties of that computation!  It's been around since Turing's days, and is very useful.

Mike.

That is true. I am apparently the first one that ever thought this
through well enough so that machine descriptions matching the following
pattern could be correctly determined to be non-halting:

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

In that a partial simulation does correctly predict the behavior of a
complete simulation it can be used to recognize infinite behavior patterns.

--
Copyright 2022 Pete Olcott

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.theory, sci.logic

On 6/5/22 9:03 PM, olcott wrote:

On 6/5/2022 7:40 PM, Ben wrote:

Jeff Barnett <jbb@notatt.com> writes:

On 6/5/2022 5:59 PM, Mike Terry wrote:

The question right now is what you would call a TM which evaluates
the first 10 steps of a computation, and then does something else.
What is it doing while evaluating those 10 steps?

What would I call it? POOP! It just goes to show the accuracy and
flexibility of Ben's acronym for any Peter-related concept.

Credit where it's due... POOP is Richard's.  Mine was not as good.

That was the initial incorrect rebuttal that claimed the concept of a simulating halt decider is inherently invalid.

When a simulating halt decider H correctly predicts that its complete simulation of its input finite string would never reach the final state
of this machine description then H has correctly rejected this input as non-halting.

No, its based on the fact that you are trying to define the "correct"
answer for H to be something different than what the Halting Problem
Requires.

The DEFINITION of the Halting Problem is that

H applied to <M> w needs to accept the input if M applied to w Halts and
reject if M applied to w never halts.

You want to change that to being based on "The correct simulation of its
input by H reaching a final state", which is not equivalent.

The key point is that by the classical definition of what a "correct simulation" would be that actually shows non-halting, a simulator that
does that CAN'T answer non-halting, because the definition of a correct simulation of a non-halting machine is a non-halting simulation. (i.e.
the behavior of a UTM).

If your definition was based on "The correct simulation of its input by
a UTM", then it would be ok, but since that isn't what you mean, your definition is different than the original, so it is your "Other Problem".

It isn't that a simulating Halt Deicder is inherently invalid, but even
a simulating halt decider needs to use the original definition of
Halting, which means either looking that the behavior of the original
machine, or the UTM simulation of the representation of it.

Yes, this gives the decider an inherent problem, that it, like ALL Halt Deciders, needs to decide in finite time something that takes unbounded
time to directly prove, but that is the nature of the Halting Problem,
and what made it interesting. The hope initially was that there might be
some "trick" that could be done to analyise the machine/input and be
able to determine halting without needing to actually run the machine to
the halting state (or a point it was clear that it would never halt).
Turing showed that there could not be such a trick.

You keep on erring because you start with assumptions that implicitly
assume that a machine to give the answer is possible, when it isn't, and
this leads you to a false conclusion and an inconsistent logic system.

Many of your arguments actually boil down to, If I had a routine that
solved the Halting Problem, I could wrap it up in code to transform the
input into a somewhat different problem but with the same answer, and
ask that routine about this new problem.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.theory, sci.logic, sci.math

On 6/5/22 10:11 PM, olcott wrote:

On 6/5/2022 8:58 PM, Mike Terry wrote:

On 06/06/2022 01:24, Jeff Barnett wrote:

On 6/5/2022 5:59 PM, Mike Terry wrote:

<..snip..>>>

Sure.
The question right now is what you would call a TM which evaluates
the first 10 steps of a computation, and then does something else.
What is it doing while evaluating those 10 steps?

What would I call it? POOP! It just goes to show the accuracy and
flexibility of Ben's acronym for any Peter-related concept.

But PO didn't invent the concept of (partially) simulating a
computation in order to compute certain properties of that
computation!  It's been around since Turing's days, and is very useful.

Mike.

That is true. I am apparently the first one that ever thought this
through well enough so that machine descriptions matching the following pattern could be correctly determined to be non-halting:

     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

In that a partial simulation does correctly predict the behavior of a complete simulation it can be used to recognize infinite behavior patterns.

Except that it doesn't since P(P) Halts if H(P,P) returns 0, which, by
the DEFINITION of the requirements of the Halting Problem, H(P,P) needs
to accept (return 1) if P(P) Halts, thus H was incorrect for a Halting
Decider.

You just try to use twisted words to try and describe what H actually
did decide on to be close to words that could be used to descirbe the
Halting Problem. But the slight difference is important, even if you
don't think so.

That just shows your level (or lack thereof) of knowledge of the field.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.theory, sci.logic

On 6/5/22 10:14 PM, olcott wrote:

On 6/5/2022 8:59 PM, Richard Damon wrote:

On 6/5/22 9:03 PM, olcott wrote:

On 6/5/2022 7:40 PM, Ben wrote:

Jeff Barnett <jbb@notatt.com> writes:

On 6/5/2022 5:59 PM, Mike Terry wrote:

The question right now is what you would call a TM which evaluates >>>>>> the first 10 steps of a computation, and then does something else. >>>>>> What is it doing while evaluating those 10 steps?

What would I call it? POOP! It just goes to show the accuracy and
flexibility of Ben's acronym for any Peter-related concept.

Credit where it's due... POOP is Richard's.  Mine was not as good.

That was the initial incorrect rebuttal that claimed the concept of a
simulating halt decider is inherently invalid.

When a simulating halt decider H correctly predicts that its complete
simulation of its input finite string would never reach the final
state of this machine description then H has correctly rejected this
input as non-halting.

No, its based on the fact that you are trying to define the "correct"
answer for H to be something different than what the Halting Problem
Requires.

If that was true then one of these facts wold not be verified:
(1) The relationship between H and P matches the pattern specified below:

(2) H does correctly compute the mapping from the x86 machine code to
its reject state on the basis

No definition of what "Correct computes the mapping"

Remember the MAPPING that H needs to compute is that

H(<M>, w) accepts if M(w) Halts, and rejects if M(w) doesn't halt.
No mention of "simulations" here.

Since P(P) is shown to Halt if H(P,P) returns 0 (reject), that mapping
is NOT correctly computed.

     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

Since you H didn't handle the case, because H(P,P) results in a
rejection, while P(P) Halts, you haven't show correctly computing of the Halting Map.

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

int main()
{
  Output("Input_Halts = ", H1((u32)P, (u32)P));
}

_P()
[00001352](01)  55              push ebp
[00001353](02)  8bec            mov ebp,esp
[00001355](03)  8b4508          mov eax,[ebp+08]
[00001358](01)  50              push eax
[00001359](03)  8b4d08          mov ecx,[ebp+08]
[0000135c](01)  51              push ecx
[0000135d](05)  e840feffff      call 000011a2 // call H [00001362](03)  83c408          add esp,+08
[00001365](02)  85c0            test eax,eax
[00001367](02)  7402            jz 0000136b
[00001369](02)  ebfe            jmp 00001369
[0000136b](01)  5d              pop ebp
[0000136c](01)  c3              ret
Size in bytes:(0027) [0000136c]

Not even your broken trace?

Your slipping.

FAIL.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)