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

When the ultimate measure of correct simulation is that the execution
trace of the simulated input exactly matches the behavior that the input machine description specifies then:

*It is an easily verified fact that* Every counter-example input to the
halting theorem D cannot possibly reach its own simulated final state in
any finite number of steps when correctly simulated by simulating halt
decider H.

The halting theorem does not prove that a set of input pairs cannot be
divided into halting and not halting. It only proves that one criterion
measure for dividing these pairs does not always work.

*This same reasoning equally applies to the Turing machine based proofs*

int D(int (*x)())
{
int Halt_Status = H(x, x);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}

It is a verified fact that H correctly predicts that D correctly
simulated by H would never reach its own final state and terminate
normally, thus H does correctly decide halting for its input D.

Anyone with sufficient software engineering skill knows that
*D simulated by H cannot possibly correctly reach its ret instruction*
Everyone else lacks sufficient software engineering skill or lies

_D()
[00001d12] 55 push ebp
[00001d13] 8bec mov ebp,esp
[00001d15] 51 push ecx
[00001d16] 8b4508 mov eax,[ebp+08]
[00001d19] 50 push eax // push D
[00001d1a] 8b4d08 mov ecx,[ebp+08]
[00001d1d] 51 push ecx // push D
[00001d1e] e83ff8ffff call 00001562 // call H
[00001d23] 83c408 add esp,+08
[00001d26] 8945fc mov [ebp-04],eax
[00001d29] 837dfc00 cmp dword [ebp-04],+00
[00001d2d] 7402 jz 00001d31
[00001d2f] ebfe jmp 00001d2f
[00001d31] 8b45fc mov eax,[ebp-04]
[00001d34] 8be5 mov esp,ebp
[00001d36] 5d pop ebp
[00001d37] c3 ret

*Simulating Halt Deciders Defeat the Halting Theorem* https://www.researchgate.net/publication/368568464_Simulating_Halt_Deciders_Defeat_the_Halting_Theorem



--
Copyright 2023 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, comp.software-eng

On 2/21/2023 11:17 AM, olcott wrote:

When the ultimate measure of correct simulation is that the execution
trace of the simulated input exactly matches the behavior that the input machine description specifies then:

*It is an easily verified fact that* Every counter-example input to the halting theorem D cannot possibly reach its own simulated final state in
any finite number of steps when correctly simulated by simulating halt decider H.

The halting theorem does not prove that a set of input pairs cannot be divided into halting and not halting. It only proves that one criterion measure for dividing these pairs does not always work.

*This same reasoning equally applies to the Turing machine based proofs*

int D(int (*x)())
{
  int Halt_Status = H(x, x);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}

It is a verified fact that H correctly predicts that D correctly
simulated by H would never reach its own final state and terminate
normally, thus H does correctly decide halting for its input D.

Anyone with sufficient software engineering skill knows that
*D simulated by H cannot possibly correctly reach its ret instruction* Everyone else lacks sufficient software engineering skill or lies

_D()
 [00001d12] 55         push ebp
 [00001d13] 8bec       mov ebp,esp
 [00001d15] 51         push ecx
 [00001d16] 8b4508     mov eax,[ebp+08]
 [00001d19] 50         push eax       // push D
 [00001d1a] 8b4d08     mov ecx,[ebp+08]
 [00001d1d] 51         push ecx       // push D
 [00001d1e] e83ff8ffff call 00001562  // call H
 [00001d23] 83c408     add esp,+08
 [00001d26] 8945fc     mov [ebp-04],eax
 [00001d29] 837dfc00   cmp dword [ebp-04],+00
 [00001d2d] 7402       jz 00001d31
 [00001d2f] ebfe       jmp 00001d2f
 [00001d31] 8b45fc     mov eax,[ebp-04]
 [00001d34] 8be5       mov esp,ebp
 [00001d36] 5d         pop ebp
 [00001d37] c3         ret

*Simulating Halt Deciders Defeat the Halting Theorem* https://www.researchgate.net/publication/368568464_Simulating_Halt_Deciders_Defeat_the_Halting_Theorem

The only way that one can ascertain that they have proved their point to dishonest reviewers is that these dishonest reviewers change the subject instead of providing any rebuttal to these points.

--
Copyright 2023 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)

On Tuesday, February 21, 2023 at 11:31:37 AM UTC-6, olcott wrote:

On 2/21/2023 11:17 AM, olcott wrote:

When the ultimate measure of correct simulation is that the execution
trace of the simulated input exactly matches the behavior that the input machine description specifies then:

*It is an easily verified fact that* Every counter-example input to the halting theorem D cannot possibly reach its own simulated final state in any finite number of steps when correctly simulated by simulating halt decider H.

The halting theorem does not prove that a set of input pairs cannot be divided into halting and not halting. It only proves that one criterion measure for dividing these pairs does not always work.

*This same reasoning equally applies to the Turing machine based proofs*

int D(int (*x)())
{
int Halt_Status = H(x, x);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}

It is a verified fact that H correctly predicts that D correctly
simulated by H would never reach its own final state and terminate normally, thus H does correctly decide halting for its input D.

Anyone with sufficient software engineering skill knows that
*D simulated by H cannot possibly correctly reach its ret instruction* Everyone else lacks sufficient software engineering skill or lies

_D()
[00001d12] 55 push ebp
[00001d13] 8bec mov ebp,esp
[00001d15] 51 push ecx
[00001d16] 8b4508 mov eax,[ebp+08]
[00001d19] 50 push eax // push D
[00001d1a] 8b4d08 mov ecx,[ebp+08]
[00001d1d] 51 push ecx // push D
[00001d1e] e83ff8ffff call 00001562 // call H
[00001d23] 83c408 add esp,+08
[00001d26] 8945fc mov [ebp-04],eax
[00001d29] 837dfc00 cmp dword [ebp-04],+00
[00001d2d] 7402 jz 00001d31
[00001d2f] ebfe jmp 00001d2f
[00001d31] 8b45fc mov eax,[ebp-04]
[00001d34] 8be5 mov esp,ebp
[00001d36] 5d pop ebp
[00001d37] c3 ret

*Simulating Halt Deciders Defeat the Halting Theorem* https://www.researchgate.net/publication/368568464_Simulating_Halt_Deciders_Defeat_the_Halting_Theorem

The only way that one can ascertain that they have proved their point to dishonest reviewers is that these dishonest reviewers change the subject instead of providing any rebuttal to these points.
--
Copyright 2023 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

A halter will halt a horse.

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

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

On 2/21/23 12:31 PM, olcott wrote:

On 2/21/2023 11:17 AM, olcott wrote:

When the ultimate measure of correct simulation is that the execution
trace of the simulated input exactly matches the behavior that the
input machine description specifies then:

*It is an easily verified fact that* Every counter-example input to
the halting theorem D cannot possibly reach its own simulated final
state in any finite number of steps when correctly simulated by
simulating halt decider H.

The halting theorem does not prove that a set of input pairs cannot be
divided into halting and not halting. It only proves that one
criterion measure for dividing these pairs does not always work.

*This same reasoning equally applies to the Turing machine based proofs*

int D(int (*x)())
{
   int Halt_Status = H(x, x);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}

It is a verified fact that H correctly predicts that D correctly
simulated by H would never reach its own final state and terminate
normally, thus H does correctly decide halting for its input D.

Anyone with sufficient software engineering skill knows that
*D simulated by H cannot possibly correctly reach its ret instruction*
Everyone else lacks sufficient software engineering skill or lies

_D()
  [00001d12] 55         push ebp
  [00001d13] 8bec       mov ebp,esp
  [00001d15] 51         push ecx
  [00001d16] 8b4508     mov eax,[ebp+08]
  [00001d19] 50         push eax       // push D
  [00001d1a] 8b4d08     mov ecx,[ebp+08]
  [00001d1d] 51         push ecx       // push D
  [00001d1e] e83ff8ffff call 00001562  // call H
  [00001d23] 83c408     add esp,+08
  [00001d26] 8945fc     mov [ebp-04],eax
  [00001d29] 837dfc00   cmp dword [ebp-04],+00
  [00001d2d] 7402       jz 00001d31
  [00001d2f] ebfe       jmp 00001d2f
  [00001d31] 8b45fc     mov eax,[ebp-04]
  [00001d34] 8be5       mov esp,ebp
  [00001d36] 5d         pop ebp
  [00001d37] c3         ret

*Simulating Halt Deciders Defeat the Halting Theorem*
https://www.researchgate.net/publication/368568464_Simulating_Halt_Deciders_Defeat_the_Halting_Theorem

The only way that one can ascertain that they have proved their point to dishonest reviewers is that these dishonest reviewers change the subject instead of providing any rebuttal to these points.

And the only way that you try to get away with the honest rebuttals is
to ignore the facts and just repeat your lies.

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

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

On 2/21/23 12:17 PM, olcott wrote:

When the ultimate measure of correct simulation is that the execution
trace of the simulated input exactly matches the behavior that the input machine description specifies then:

And by that definition, a "Halt Decider" can "corrrectly" determine ANY
input to be non-halting as it gets aborted before it can reach a final
state.

*It is an easily verified fact that* Every counter-example input to the halting theorem D cannot possibly reach its own simulated final state in
any finite number of steps when correctly simulated by simulating halt decider H.

Nope.

The halting theorem does not prove that a set of input pairs cannot be divided into halting and not halting. It only proves that one criterion measure for dividing these pairs does not always work.

It proves that it can not be done byu the criteria that matters, the one
that is basd on the actual behavior of the machine given.

*This same reasoning equally applies to the Turing machine based proofs*

Except that with a Turing Machine H can not detect that the input
contains a copy of H.

int D(int (*x)())
{
  int Halt_Status = H(x, x);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}

It is a verified fact that H correctly predicts that D correctly
simulated by H would never reach its own final state and terminate
normally, thus H does correctly decide halting for its input D.

Nope, because you can't correctly predict a behavior that doesn't happen.

Anyone with sufficient software engineering skill knows that
*D simulated by H cannot possibly correctly reach its ret instruction* Everyone else lacks sufficient software engineering skill or lies

_D()
 [00001d12] 55         push ebp
 [00001d13] 8bec       mov ebp,esp
 [00001d15] 51         push ecx
 [00001d16] 8b4508     mov eax,[ebp+08]
 [00001d19] 50         push eax       // push D
 [00001d1a] 8b4d08     mov ecx,[ebp+08]
 [00001d1d] 51         push ecx       // push D
 [00001d1e] e83ff8ffff call 00001562  // call H
 [00001d23] 83c408     add esp,+08
 [00001d26] 8945fc     mov [ebp-04],eax
 [00001d29] 837dfc00   cmp dword [ebp-04],+00
 [00001d2d] 7402       jz 00001d31
 [00001d2f] ebfe       jmp 00001d2f
 [00001d31] 8b45fc     mov eax,[ebp-04]
 [00001d34] 8be5       mov esp,ebp
 [00001d36] 5d         pop ebp
 [00001d37] c3         ret

*Simulating Halt Deciders Defeat the Halting Theorem* https://www.researchgate.net/publication/368568464_Simulating_Halt_Deciders_Defeat_the_Halting_Theorem

The simulation by H might not, because it aborts its simulation before
it gets there, but an actual complete simulation of the input by a real
UTM will get there, showing that H is incorrect.

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

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

On 2/22/2023 10:41 AM, Fritz Feldhase wrote:

On Wednesday, February 22, 2023 at 4:18:56 AM UTC+1, olcott wrote:

On 2/21/2023 9:11 PM, Fritz Feldhase wrote:

H(D,D) cannot report on the [halting] behavior of D(D)

Huh?! What?!

H(D,D) cannot possibly report on the behavior of non inputs.

Huh?! Since when is your program/function D a "non input". What does this even mean?

Just invented a new term (weasel word) to say something silly?

int sum (int x, int y) { return x + y; }
sum(3,4) cannot return the sum of 7 + 5 and would be wrong to do so.

Simulating halt decider H is not allowed to analyze the behavior of the directly executed D(D) for the same reason that sum(3,4) is not allowed
to return the sum of 5 + 7.

Just a comment: H cannot correctly "determine" the halt status of D(D).

H is not allowed to "determine" the halt status of D(D).

All deciders compute the mapping from their inputs
All deciders compute the mapping from their inputs
All deciders compute the mapping from their inputs

*straw-man*
An intentionally misrepresented proposition that is set up because it is
easier to defeat than an opponent's real argument. https://www.lexico.com/en/definition/straw_man

You continue to ignore and erase the proof that H does correctly
determine the halt status of D. *This is the straw-man deception*



Anyone with sufficient software engineering skill knows that
*D simulated by H cannot possibly correctly reach its ret instruction*
Everyone else lacks sufficient software engineering skill or lies

_D()
[00001d12] 55 push ebp
[00001d13] 8bec mov ebp,esp
[00001d15] 51 push ecx
[00001d16] 8b4508 mov eax,[ebp+08] // move 1st argument to eax
[00001d19] 50 push eax // push D
[00001d1a] 8b4d08 mov ecx,[ebp+08] // move 1st argument to ecx
[00001d1d] 51 push ecx // push D
[00001d1e] e83ff8ffff call 00001562 // call H
[00001d23] 83c408 add esp,+08
[00001d26] 8945fc mov [ebp-04],eax
[00001d29] 837dfc00 cmp dword [ebp-04],+00
[00001d2d] 7402 jz 00001d31
[00001d2f] ebfe jmp 00001d2f
[00001d31] 8b45fc mov eax,[ebp-04]
[00001d34] 8be5 mov esp,ebp
[00001d36] 5d pop ebp
[00001d37] c3 ret

When D correctly simulated by H reaches machine address [00001d1e] H can simulate D again endlessly or abort the entire recursive chain of
simulations before any of them pass machine address [00001d1e].

*Are you clueless about how the x86 language works*
[00001d16] mov eax,[ebp+08] // move 1st argument to eax
[00001d19] push eax // push D
[00001d1a] mov ecx,[ebp+08] // move 1st argument to ecx
[00001d1d] push ecx // push D
[00001d1e] call 00001562 // call H
This is the same thing as this C: H(D,D);


--
Copyright 2023 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: sci.logic, comp.theory, comp.software-eng

On 2/22/23 12:06 PM, olcott wrote:

On 2/22/2023 10:41 AM, Fritz Feldhase wrote:

On Wednesday, February 22, 2023 at 4:18:56 AM UTC+1, olcott wrote:

On 2/21/2023 9:11 PM, Fritz Feldhase wrote:

  H(D,D) cannot report on the [halting] behavior of D(D)

Huh?! What?!

H(D,D) cannot possibly report on the behavior of non inputs.

Huh?! Since when is your program/function D a "non input". What does
this even mean?

Just invented a new term (weasel word) to say something silly?

int sum (int x, int y) { return x + y; }
sum(3,4) cannot return the sum of 7 + 5 and would be wrong to do so.

Right, just like Halt(D,D) can't return non-halting when D(D) Halts.

Simulating halt decider H is not allowed to analyze the behavior of the directly executed D(D) for the same reason that sum(3,4) is not allowed
to return the sum of 5 + 7.

Why not? That the problem it is supposed to be deciding.

sum of3,3) is 3+4 just as Ha;lt(D,D) is supposed to answer if D(D) Halts.

Just a comment: H cannot correctly "determine" the halt status of D(D).

H is not allowed to "determine" the halt status of D(D).

Why not, what is it supposed to do, guess? Maybe you don't know what
determine means.

All deciders compute the mapping from their inputs
All deciders compute the mapping from their inputs
All deciders compute the mapping from their inputs

Right, and to be a Foo decider, it needs to compute the Foo map.

*straw-man*
An intentionally misrepresented proposition that is set up because it is easier to defeat than an opponent's real argument. https://www.lexico.com/en/definition/straw_man

You continue to ignore and erase the proof that H does correctly
determine the halt status of D. *This is the straw-man deception*

I haven't erased anything.

Remember, teh DEFINITION of a Halt Decider comes from:

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.

So the answer/mapping that a Halt Decider is supposed to determine is
the behavior of the ACUTUAL machine.

Since D(D) Halts, the CORRECT answer for H(D,D) is Halting, so the fact
it says Non-Halting shows it to be incorrect as a Halt Decider.

It might "Correctly" answer some other question, but that just makes it
s correct POOP decider, not a Halt Decider.

Anyone with sufficient software engineering skill knows that
*D simulated by H cannot possibly correctly reach its ret instruction* Everyone else lacks sufficient software engineering skill or lies

Which isn't the question.

It has also been shown that the CORRECT SIMULATION 0f this input by a
simulator that actually completes its job shows that it does halt.

This just shows that H always just gives up too soon, and thus its
conclusion is incorrect. You can argue whether this is due to an
incorrect simulation, or incorrrctly determining, but it IS INCORRECT.

_D()
 [00001d12] 55         push ebp
 [00001d13] 8bec       mov ebp,esp
 [00001d15] 51         push ecx
 [00001d16] 8b4508     mov eax,[ebp+08] // move 1st argument to eax
 [00001d19] 50         push eax         // push D
 [00001d1a] 8b4d08     mov ecx,[ebp+08] // move 1st argument to ecx
 [00001d1d] 51         push ecx         // push D
 [00001d1e] e83ff8ffff call 00001562    // call H
 [00001d23] 83c408     add esp,+08
 [00001d26] 8945fc     mov [ebp-04],eax
 [00001d29] 837dfc00   cmp dword [ebp-04],+00
 [00001d2d] 7402       jz 00001d31
 [00001d2f] ebfe       jmp 00001d2f
 [00001d31] 8b45fc     mov eax,[ebp-04]
 [00001d34] 8be5       mov esp,ebp
 [00001d36] 5d         pop ebp
 [00001d37] c3         ret

When D correctly simulated by H reaches machine address [00001d1e] H can simulate D again endlessly or abort the entire recursive chain of
simulations before any of them pass machine address [00001d1e].

Nope, since H DOES abort its simulation at this point, you can't use
arguements about what whould happen when it doesn't.

That is just the fallacy of using a false premise.

*Are you clueless about how the x86 language works*
 [00001d16] mov eax,[ebp+08] // move 1st argument to eax
 [00001d19] push eax         // push D
 [00001d1a] mov ecx,[ebp+08] // move 1st argument to ecx
 [00001d1d] push ecx         // push D
 [00001d1e] call 00001562    // call H
This is the same thing as this C: H(D,D);

???

So you know how to write a call instruction.

DO you understand what this does?

It calls an H that WILL abort its simulation and return 0, at least that
is what all the code you have provided that has an H that supposedly "Correctly" returns 0 for H(D,D)

You don't seem to understand how computers actually work.

Since we have established that H(D,D) returns 0, the only thing that a
correct simulation of that code sequence can indicate is that eventually
we will get to the the next instruction with a 0 in the eax register.

Anything else is just proved to be an incorrect simulation.

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