On 8/1/2024 3:10 AM, Fred. Zwarts wrote:
Op 31.jul.2024 om 23:23 schreef olcott:
On 7/31/2024 3:01 PM, Fred. Zwarts wrote:
Op 31.jul.2024 om 17:14 schreef olcott:
On 7/31/2024 3:44 AM, Fred. Zwarts wrote:So, Sipser only agreed to a correct simulation, not with an
Op 31.jul.2024 om 06:09 schreef olcott:This algorithm is used by all the simulating termination analyzers:
  machine  stack    stack    machine   assembly >>>>>>>   address  address  data     code      language >>>>>>>   ======== ======== ======== ========= =============
[00002192][00103820][00000000] 55Â Â Â Â Â Â Â Â push ebp
[00002193][00103820][00000000] 8bec      mov ebp,esp
[00002195][0010381c][00002172] 6872210000 push 00002172 ; push DDD >>>>>>> [0000219a][00103818][0000219f] e833f4ffff call 000015d2 ; call
HHH(DDD)
New slave_stack at:1038c4
We don't show any of HHH and show the execution trace of
of just DDD assuming that HHH is an x86 emulator.
This assumption is incorrect if it means that HHH is an
unconditional simulator that does not abort.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>> Â Â Â Â *If simulating halt decider H correctly simulates its input D* >>>>> Â Â Â Â *until H correctly determines that its simulated D would never* >>>>> Â Â Â Â *stop running unless aborted* then
    H can abort its simulation of D and correctly report that D >>>>>     specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>
incorrect simulation that violates the semantics of the x86 language
by skipping the last few instructions of a halting program.
int DD()
{
  int Halt_Status = HHH(DD);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
int main()
{
  HHH(DD);
}
DD correctly emulated by HHH cannot possibly reach its own
second line. I switched to DDD correctly emulated by HHH
But it has been proven that no such HHH exists that simulates itself
correctly. So, talking about a correct simulation by HHH is vacuous
word salad.
because only C experts understood the above example and we
never had any of those here.
There are many C experts that looked at it, but you only got critic,
because you keep hiding important properties of HHH, which made the
conclusion impossible.
The following is all that is needed for 100% complete proof
that HHH did emulate DDD correctly according to the semantics
of the x86 language and did emulate itself emulating DDD
according to these same semantics.
_DDD()
[00002172] 55        push ebp     ; housekeeping
[00002173] 8bec      mov ebp,esp  ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404Â Â Â Â add esp,+04
[00002182] 5d        pop ebp
[00002183] c3Â Â Â Â Â Â Â Â ret
Size in bytes:(0018) [00002183]
Begin Local Halt Decider Simulation  Execution Trace Stored at:1138cc [00002172][001138bc][001138c0] 55        push ebp     ; housekeeping
[00002173][001138bc][001138c0] 8bec      mov ebp,esp  ; housekeeping
[00002175][001138b8][00002172] 6872210000 push 00002172 ; push DDD [0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)
New slave_stack at:14e2ec
[00002172][0015e2e4][0015e2e8] 55        push ebp     ; housekeeping
[00002173][0015e2e4][0015e2e8] 8bec      mov ebp,esp  ; housekeeping
[00002175][0015e2e0][00002172] 6872210000 push 00002172 ; push DDD [0000217a][0015e2dc][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
Now that we have established that HHH did emulate
DDD correctly the above is also 100% complete proof
that HHH must abort its correct emulation of DDD or
neither HHH nor DDD will ever stop running.
This has always been complete proof for anyone that knows
the semantics of the x86 language sufficiently well.
On 8/1/2024 8:12 AM, Fred. Zwarts wrote:
Op 01.aug.2024 om 14:20 schreef olcott:
On 8/1/2024 3:10 AM, Fred. Zwarts wrote:
Op 31.jul.2024 om 23:23 schreef olcott:
On 7/31/2024 3:01 PM, Fred. Zwarts wrote:
Op 31.jul.2024 om 17:14 schreef olcott:
On 7/31/2024 3:44 AM, Fred. Zwarts wrote:
Op 31.jul.2024 om 06:09 schreef olcott:This algorithm is used by all the simulating termination analyzers: >>>>>>> <MIT Professor Sipser agreed to ONLY these verbatim words
  machine  stack    stack    machine   assembly >>>>>>>>>   address  address  data     code      language >>>>>>>>>   ======== ======== ======== ========= ============= >>>>>>>>> [00002192][00103820][00000000] 55        push ebp
[00002193][00103820][00000000] 8bec      mov ebp,esp
[00002195][0010381c][00002172] 6872210000 push 00002172 ; push DDD >>>>>>>>> [0000219a][00103818][0000219f] e833f4ffff call 000015d2 ; call >>>>>>>>> HHH(DDD)
New slave_stack at:1038c4
We don't show any of HHH and show the execution trace of
of just DDD assuming that HHH is an x86 emulator.
This assumption is incorrect if it means that HHH is an
unconditional simulator that does not abort.
10/13/2022>
    *If simulating halt decider H correctly simulates its input D* >>>>>>>     *until H correctly determines that its simulated D would never*
    *stop running unless aborted* then
    H can abort its simulation of D and correctly report that D >>>>>>>     specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
So, Sipser only agreed to a correct simulation, not with an
incorrect simulation that violates the semantics of the x86
language by skipping the last few instructions of a halting program. >>>>>>
int DD()
{
  int Halt_Status = HHH(DD);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
int main()
{
  HHH(DD);
}
DD correctly emulated by HHH cannot possibly reach its own
second line. I switched to DDD correctly emulated by HHH
But it has been proven that no such HHH exists that simulates itself
correctly. So, talking about a correct simulation by HHH is vacuous
word salad.
because only C experts understood the above example and we
never had any of those here.
There are many C experts that looked at it, but you only got critic,
because you keep hiding important properties of HHH, which made the
conclusion impossible.
The following is all that is needed for 100% complete proof
that HHH did emulate DDD correctly according to the semantics
of the x86 language and did emulate itself emulating DDD
according to these same semantics.
You are repeating the same false claim with out any self-reflection.
It has been pointed out that there are many errors in this proof.
Why repeating such errors?
_DDD()
[00002172] 55        push ebp     ; housekeeping
[00002173] 8bec      mov ebp,esp  ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404Â Â Â Â add esp,+04
[00002182] 5d        pop ebp
[00002183] c3Â Â Â Â Â Â Â Â ret
Size in bytes:(0018) [00002183]
Begin Local Halt Decider Simulation  Execution Trace Stored at:1138cc >>> [00002172][001138bc][001138c0] 55        push ebp     ; housekeeping
[00002173][001138bc][001138c0] 8bec      mov ebp,esp  ; housekeeping
[00002175][001138b8][00002172] 6872210000 push 00002172 ; push DDD
[0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)
The trace stops and hides what happens when 000015d2 is called.
Olcott is hiding the conditional branch instructions in the recursion.
*Here is the full trace where nothing is hidden* https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
These next lines conclusively prove that DDD is being
correctly emulated by HHH after DDD calls HHH(DDD).
On 8/1/2024 9:23 AM, Fred. Zwarts wrote:
Op 01.aug.2024 om 15:29 schreef olcott:
On 8/1/2024 8:12 AM, Fred. Zwarts wrote:
Op 01.aug.2024 om 14:20 schreef olcott:
On 8/1/2024 3:10 AM, Fred. Zwarts wrote:
Op 31.jul.2024 om 23:23 schreef olcott:
On 7/31/2024 3:01 PM, Fred. Zwarts wrote:
Op 31.jul.2024 om 17:14 schreef olcott:
On 7/31/2024 3:44 AM, Fred. Zwarts wrote:
Op 31.jul.2024 om 06:09 schreef olcott:This algorithm is used by all the simulating termination
  machine  stack    stack    machine   assembly >>>>>>>>>>>   address  address  data     code      language
  ======== ======== ======== ========= ============= >>>>>>>>>>> [00002192][00103820][00000000] 55        push ebp >>>>>>>>>>> [00002193][00103820][00000000] 8bec      mov ebp,esp >>>>>>>>>>> [00002195][0010381c][00002172] 6872210000 push 00002172 ; >>>>>>>>>>> push DDD
[0000219a][00103818][0000219f] e833f4ffff call 000015d2 ; >>>>>>>>>>> call HHH(DDD)
New slave_stack at:1038c4
We don't show any of HHH and show the execution trace of >>>>>>>>>>> of just DDD assuming that HHH is an x86 emulator.
This assumption is incorrect if it means that HHH is an
unconditional simulator that does not abort.
analyzers:
<MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
    *If simulating halt decider H correctly simulates its >>>>>>>>> input D*
    *until H correctly determines that its simulated D would >>>>>>>>> never*
    *stop running unless aborted* then
    H can abort its simulation of D and correctly report that D >>>>>>>>>     specifies a non-halting sequence of configurations. >>>>>>>>> </MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
So, Sipser only agreed to a correct simulation, not with an
incorrect simulation that violates the semantics of the x86
language by skipping the last few instructions of a halting
program.
int DD()
{
  int Halt_Status = HHH(DD);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
int main()
{
  HHH(DD);
}
DD correctly emulated by HHH cannot possibly reach its own
second line. I switched to DDD correctly emulated by HHH
But it has been proven that no such HHH exists that simulates
itself correctly. So, talking about a correct simulation by HHH is >>>>>> vacuous word salad.
because only C experts understood the above example and we
never had any of those here.
There are many C experts that looked at it, but you only got
critic, because you keep hiding important properties of HHH, which >>>>>> made the conclusion impossible.
The following is all that is needed for 100% complete proof
that HHH did emulate DDD correctly according to the semantics
of the x86 language and did emulate itself emulating DDD
according to these same semantics.
You are repeating the same false claim with out any self-reflection.
It has been pointed out that there are many errors in this proof.
Why repeating such errors?
_DDD()
[00002172] 55        push ebp     ; housekeeping
[00002173] 8bec      mov ebp,esp  ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404Â Â Â Â add esp,+04
[00002182] 5d        pop ebp
[00002183] c3Â Â Â Â Â Â Â Â ret
Size in bytes:(0018) [00002183]
Begin Local Halt Decider Simulation  Execution Trace Stored at:1138cc >>>>> [00002172][001138bc][001138c0] 55        push ebp     ; housekeeping
[00002173][001138bc][001138c0] 8bec      mov ebp,esp  ; housekeeping
[00002175][001138b8][00002172] 6872210000 push 00002172 ; push DDD
[0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call
HHH(DDD)
The trace stops and hides what happens when 000015d2 is called.
Olcott is hiding the conditional branch instructions in the recursion. >>>>
*Here is the full trace where nothing is hidden*
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
These next lines conclusively prove that DDD is being
correctly emulated by HHH after DDD calls HHH(DDD).
It also shows that HHH when simulating itself, does not reach the end
of its own simulation.
If you weren't a clueless wonder you would understand
that DDD correctly emulated by HHH including HHH emulating
itself emulated DDD has no end of correct emulation.
On 8/1/2024 9:23 AM, Fred. Zwarts wrote:It does if the simulated HHH aborts, but its simulating copy preempts
Op 01.aug.2024 om 15:29 schreef olcott:
On 8/1/2024 8:12 AM, Fred. Zwarts wrote:
Op 01.aug.2024 om 14:20 schreef olcott:
On 8/1/2024 3:10 AM, Fred. Zwarts wrote:
Op 31.jul.2024 om 23:23 schreef olcott:
On 7/31/2024 3:01 PM, Fred. Zwarts wrote:
Op 31.jul.2024 om 17:14 schreef olcott:
On 7/31/2024 3:44 AM, Fred. Zwarts wrote:
Op 31.jul.2024 om 06:09 schreef olcott:
If you weren't a clueless wonder you would understand that DDD correctly emulated by HHH including HHH emulating itself emulated DDD has no endIt also shows that HHH when simulating itself, does not reach the endThe trace stops and hides what happens when 000015d2 is called.These next lines conclusively prove that DDD is being correctly
Olcott is hiding the conditional branch instructions in the
recursion.
emulated by HHH after DDD calls HHH(DDD).
of its own simulation.
of correct emulation.
On 8/1/2024 11:11 AM, joes wrote:
Am Thu, 01 Aug 2024 09:30:00 -0500 schrieb olcott:
On 8/1/2024 9:23 AM, Fred. Zwarts wrote:
Op 01.aug.2024 om 15:29 schreef olcott:
On 8/1/2024 8:12 AM, Fred. Zwarts wrote:
Op 01.aug.2024 om 14:20 schreef olcott:
On 8/1/2024 3:10 AM, Fred. Zwarts wrote:
Op 31.jul.2024 om 23:23 schreef olcott:
On 7/31/2024 3:01 PM, Fred. Zwarts wrote:
Op 31.jul.2024 om 17:14 schreef olcott:
On 7/31/2024 3:44 AM, Fred. Zwarts wrote:
Op 31.jul.2024 om 06:09 schreef olcott:
If you weren't a clueless wonder you would understand that DDD correctly >>> emulated by HHH including HHH emulating itself emulated DDD has no endIt also shows that HHH when simulating itself, does not reach the endThe trace stops and hides what happens when 000015d2 is called.These next lines conclusively prove that DDD is being correctly
Olcott is hiding the conditional branch instructions in the
recursion.
emulated by HHH after DDD calls HHH(DDD).
of its own simulation.
of correct emulation.
It does if the simulated HHH aborts, but its simulating copy preempts
that. Indeed, it has no choice, but if it didn't abort, the simulation
wouldn't abort either. Therefore it can't simulate itself.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
   If simulating halt decider H correctly simulates its input D
   until H correctly determines that its simulated D would never
   stop running unless aborted then
   H can abort its simulation of D and correctly report that D
   specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
I spent two years carefully composing the above before I even
asked professor Sipser to review it.
DDD is correctly emulated by HHH until HHH sees the same
never ending pattern that anyone else can see.
On 8/1/2024 9:36 AM, Fred. Zwarts wrote:
Op 01.aug.2024 om 16:30 schreef olcott:
On 8/1/2024 9:23 AM, Fred. Zwarts wrote:
Op 01.aug.2024 om 15:29 schreef olcott:
On 8/1/2024 8:12 AM, Fred. Zwarts wrote:
Op 01.aug.2024 om 14:20 schreef olcott:
On 8/1/2024 3:10 AM, Fred. Zwarts wrote:
Op 31.jul.2024 om 23:23 schreef olcott:
On 7/31/2024 3:01 PM, Fred. Zwarts wrote:
Op 31.jul.2024 om 17:14 schreef olcott:
On 7/31/2024 3:44 AM, Fred. Zwarts wrote:
Op 31.jul.2024 om 06:09 schreef olcott:This algorithm is used by all the simulating termination >>>>>>>>>>> analyzers:
  machine  stack    stack    machine   assembly
  address  address  data     code      language
  ======== ======== ======== ========= ============= >>>>>>>>>>>>> [00002192][00103820][00000000] 55        push ebp >>>>>>>>>>>>> [00002193][00103820][00000000] 8bec      mov ebp,esp >>>>>>>>>>>>> [00002195][0010381c][00002172] 6872210000 push 00002172 ; >>>>>>>>>>>>> push DDD
[0000219a][00103818][0000219f] e833f4ffff call 000015d2 ; >>>>>>>>>>>>> call HHH(DDD)
New slave_stack at:1038c4
We don't show any of HHH and show the execution trace of >>>>>>>>>>>>> of just DDD assuming that HHH is an x86 emulator.
This assumption is incorrect if it means that HHH is an >>>>>>>>>>>> unconditional simulator that does not abort.
<MIT Professor Sipser agreed to ONLY these verbatim words >>>>>>>>>>> 10/13/2022>
    *If simulating halt decider H correctly simulates its >>>>>>>>>>> input D*
    *until H correctly determines that its simulated D would >>>>>>>>>>> never*
    *stop running unless aborted* then
    H can abort its simulation of D and correctly report that D
    specifies a non-halting sequence of configurations. >>>>>>>>>>> </MIT Professor Sipser agreed to ONLY these verbatim words >>>>>>>>>>> 10/13/2022>
So, Sipser only agreed to a correct simulation, not with an >>>>>>>>>> incorrect simulation that violates the semantics of the x86 >>>>>>>>>> language by skipping the last few instructions of a halting >>>>>>>>>> program.
int DD()
{
  int Halt_Status = HHH(DD);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
int main()
{
  HHH(DD);
}
DD correctly emulated by HHH cannot possibly reach its own
second line. I switched to DDD correctly emulated by HHH
But it has been proven that no such HHH exists that simulates
itself correctly. So, talking about a correct simulation by HHH >>>>>>>> is vacuous word salad.
because only C experts understood the above example and we
never had any of those here.
There are many C experts that looked at it, but you only got
critic, because you keep hiding important properties of HHH,
which made the conclusion impossible.
The following is all that is needed for 100% complete proof
that HHH did emulate DDD correctly according to the semantics
of the x86 language and did emulate itself emulating DDD
according to these same semantics.
You are repeating the same false claim with out any
self-reflection. It has been pointed out that there are many
errors in this proof.
Why repeating such errors?
_DDD()
[00002172] 55        push ebp     ; housekeeping
[00002173] 8bec      mov ebp,esp  ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404Â Â Â Â add esp,+04
[00002182] 5d        pop ebp
[00002183] c3Â Â Â Â Â Â Â Â ret
Size in bytes:(0018) [00002183]
Begin Local Halt Decider Simulation  Execution Trace Stored
at:1138cc
[00002172][001138bc][001138c0] 55        push ebp     ; >>>>>>> housekeeping
[00002173][001138bc][001138c0] 8bec      mov ebp,esp  ; >>>>>>> housekeeping
[00002175][001138b8][00002172] 6872210000 push 00002172 ; push DDD >>>>>>> [0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call
HHH(DDD)
The trace stops and hides what happens when 000015d2 is called.
Olcott is hiding the conditional branch instructions in the
recursion.
*Here is the full trace where nothing is hidden*
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
These next lines conclusively prove that DDD is being
correctly emulated by HHH after DDD calls HHH(DDD).
It also shows that HHH when simulating itself, does not reach the
end of its own simulation.
If you weren't a clueless wonder you would understand
that DDD correctly emulated by HHH including HHH emulating
itself emulated DDD has no end of correct emulation.
You say that only, because you do not understand the difference
between two recursions and an infinite number of recursions.
I was the number one student out of 45 students in an advanced
computer science about the internals of operating systems. Three
of the students that I beat were instructors of other computer
science classes. The lack on knowledge is not on my side.
Not terminating recursive emulation is isomorphic to infinite
recursion.
The HHH that has no end is the one in your dreams, the one that does
not abort.
Therefore conclusively proving that it must abort jackass.
On 8/1/2024 2:30 PM, Fred. Zwarts wrote:
Op 01.aug.2024 om 18:32 schreef olcott:
On 8/1/2024 11:11 AM, joes wrote:
Am Thu, 01 Aug 2024 09:30:00 -0500 schrieb olcott:
On 8/1/2024 9:23 AM, Fred. Zwarts wrote:
Op 01.aug.2024 om 15:29 schreef olcott:
On 8/1/2024 8:12 AM, Fred. Zwarts wrote:
Op 01.aug.2024 om 14:20 schreef olcott:
On 8/1/2024 3:10 AM, Fred. Zwarts wrote:
Op 31.jul.2024 om 23:23 schreef olcott:
On 7/31/2024 3:01 PM, Fred. Zwarts wrote:
Op 31.jul.2024 om 17:14 schreef olcott:
On 7/31/2024 3:44 AM, Fred. Zwarts wrote:
Op 31.jul.2024 om 06:09 schreef olcott:
If you weren't a clueless wonder you would understand that DDDIt also shows that HHH when simulating itself, does not reach the end >>>>>> of its own simulation.The trace stops and hides what happens when 000015d2 is called. >>>>>>>> Olcott is hiding the conditional branch instructions in theThese next lines conclusively prove that DDD is being correctly
recursion.
emulated by HHH after DDD calls HHH(DDD).
correctly
emulated by HHH including HHH emulating itself emulated DDD has no end >>>>> of correct emulation.
It does if the simulated HHH aborts, but its simulating copy preempts
that. Indeed, it has no choice, but if it didn't abort, the simulation >>>> wouldn't abort either. Therefore it can't simulate itself.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
    If simulating halt decider H correctly simulates its input D
    until H correctly determines that its simulated D would never
    stop running unless aborted then
    H can abort its simulation of D and correctly report that D
    specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
Sipser agreed only to a correct simulation.
of N steps.
I spent two years carefully composing the above before I even
asked professor Sipser to review it.
DDD is correctly emulated by HHH until HHH sees the same
never ending pattern that anyone else can see.
The never ending pattern is there only in your dreams. The HHH that
halts after two cycles has a halting pattern.
In order for DDD correctly emulated by HHH to halt
DDD correctly emulated must reach its emulated "ret"
instruction. This <is> impossible.
Only HHH, when simulating itself, cannot see that after two cycles,
because it needs one more cycle.
Two is not infinite.
Dream are no substitute for facts, not for logic.
On 8/1/2024 8:12 AM, Fred. Zwarts wrote:
Op 01.aug.2024 om 14:20 schreef olcott:
On 8/1/2024 3:10 AM, Fred. Zwarts wrote:
Op 31.jul.2024 om 23:23 schreef olcott:
On 7/31/2024 3:01 PM, Fred. Zwarts wrote:
Op 31.jul.2024 om 17:14 schreef olcott:
On 7/31/2024 3:44 AM, Fred. Zwarts wrote:So, Sipser only agreed to a correct simulation, not with an incorrect >>>>>> simulation that violates the semantics of the x86 language by skipping >>>>>> the last few instructions of a halting program.
Op 31.jul.2024 om 06:09 schreef olcott:This algorithm is used by all the simulating termination analyzers: >>>>>>> <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>>>> Â Â Â Â *If simulating halt decider H correctly simulates its input D* >>>>>>> Â Â Â Â *until H correctly determines that its simulated D would never*
  machine  stack    stack    machine   assembly >>>>>>>>>   address  address  data     code      language >>>>>>>>>   ======== ======== ======== ========= ============= >>>>>>>>> [00002192][00103820][00000000] 55        push ebp
[00002193][00103820][00000000] 8bec      mov ebp,esp
[00002195][0010381c][00002172] 6872210000 push 00002172 ; push DDD >>>>>>>>> [0000219a][00103818][0000219f] e833f4ffff call 000015d2 ; call HHH(DDD)
New slave_stack at:1038c4
We don't show any of HHH and show the execution trace of
of just DDD assuming that HHH is an x86 emulator.
This assumption is incorrect if it means that HHH is an unconditional >>>>>>>> simulator that does not abort.
    *stop running unless aborted* then
    H can abort its simulation of D and correctly report that D >>>>>>>     specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>>>
int DD()
{
  int Halt_Status = HHH(DD);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
int main()
{
  HHH(DD);
}
DD correctly emulated by HHH cannot possibly reach its own
second line. I switched to DDD correctly emulated by HHH
But it has been proven that no such HHH exists that simulates itself
correctly. So, talking about a correct simulation by HHH is vacuous
word salad.
because only C experts understood the above example and we
never had any of those here.
There are many C experts that looked at it, but you only got critic,
because you keep hiding important properties of HHH, which made the
conclusion impossible.
The following is all that is needed for 100% complete proof
that HHH did emulate DDD correctly according to the semantics
of the x86 language and did emulate itself emulating DDD
according to these same semantics.
You are repeating the same false claim with out any self-reflection. It
has been pointed out that there are many errors in this proof.
Why repeating such errors?
_DDD()
[00002172] 55        push ebp     ; housekeeping
[00002173] 8bec      mov ebp,esp  ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404Â Â Â Â add esp,+04
[00002182] 5d        pop ebp
[00002183] c3Â Â Â Â Â Â Â Â ret
Size in bytes:(0018) [00002183]
Begin Local Halt Decider Simulation  Execution Trace Stored at:1138cc >>> [00002172][001138bc][001138c0] 55        push ebp     ; housekeeping
[00002173][001138bc][001138c0] 8bec      mov ebp,esp  ; housekeeping
[00002175][001138b8][00002172] 6872210000 push 00002172 ; push DDD
[0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)
The trace stops and hides what happens when 000015d2 is called.
Olcott is hiding the conditional branch instructions in the recursion.
*Here is the full trace where nothing is hidden* https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
On 8/1/2024 11:11 AM, joes wrote:
Am Thu, 01 Aug 2024 09:30:00 -0500 schrieb olcott:
On 8/1/2024 9:23 AM, Fred. Zwarts wrote:
Op 01.aug.2024 om 15:29 schreef olcott:
On 8/1/2024 8:12 AM, Fred. Zwarts wrote:
Op 01.aug.2024 om 14:20 schreef olcott:
On 8/1/2024 3:10 AM, Fred. Zwarts wrote:
Op 31.jul.2024 om 23:23 schreef olcott:
On 7/31/2024 3:01 PM, Fred. Zwarts wrote:
Op 31.jul.2024 om 17:14 schreef olcott:
On 7/31/2024 3:44 AM, Fred. Zwarts wrote:
Op 31.jul.2024 om 06:09 schreef olcott:
If you weren't a clueless wonder you would understand that DDD correctly >>> emulated by HHH including HHH emulating itself emulated DDD has no endIt also shows that HHH when simulating itself, does not reach the endThe trace stops and hides what happens when 000015d2 is called.These next lines conclusively prove that DDD is being correctly
Olcott is hiding the conditional branch instructions in the
recursion.
emulated by HHH after DDD calls HHH(DDD).
of its own simulation.
of correct emulation.
It does if the simulated HHH aborts, but its simulating copy preempts
that. Indeed, it has no choice, but if it didn't abort, the simulation
wouldn't abort either. Therefore it can't simulate itself.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its input D
until H correctly determines that its simulated D would never
stop running unless aborted then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
I spent two years carefully composing the above before I even
asked professor Sipser to review it.
DDD is correctly emulated by HHH until HHH sees the same
never ending pattern that anyone else can see.
On 2024-08-01 13:29:24 +0000, olcott said:
On 8/1/2024 8:12 AM, Fred. Zwarts wrote:
Op 01.aug.2024 om 14:20 schreef olcott:
On 8/1/2024 3:10 AM, Fred. Zwarts wrote:
Op 31.jul.2024 om 23:23 schreef olcott:
On 7/31/2024 3:01 PM, Fred. Zwarts wrote:
Op 31.jul.2024 om 17:14 schreef olcott:
On 7/31/2024 3:44 AM, Fred. Zwarts wrote:So, Sipser only agreed to a correct simulation, not with an incorrect simulation that
Op 31.jul.2024 om 06:09 schreef olcott:This algorithm is used by all the simulating termination analyzers: >>>>>>>> <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>>>>> *If simulating halt decider H correctly simulates its input D* >>>>>>>> *until H correctly determines that its simulated D would never* >>>>>>>> *stop running unless aborted* then
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[00002192][00103820][00000000] 55 push ebp
[00002193][00103820][00000000] 8bec mov ebp,esp
[00002195][0010381c][00002172] 6872210000 push 00002172 ; push DDD >>>>>>>>>> [0000219a][00103818][0000219f] e833f4ffff call 000015d2 ; call HHH(DDD)
New slave_stack at:1038c4
We don't show any of HHH and show the execution trace of
of just DDD assuming that HHH is an x86 emulator.
This assumption is incorrect if it means that HHH is an unconditional simulator that does
not abort.
H can abort its simulation of D and correctly report that D >>>>>>>> specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>>>>
violates the semantics of the x86 language by skipping the last few instructions of a halting
program.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
DD correctly emulated by HHH cannot possibly reach its own
second line. I switched to DDD correctly emulated by HHH
But it has been proven that no such HHH exists that simulates itself correctly. So, talking
about a correct simulation by HHH is vacuous word salad.
because only C experts understood the above example and we
never had any of those here.
There are many C experts that looked at it, but you only got critic, because you keep hiding
important properties of HHH, which made the conclusion impossible.
The following is all that is needed for 100% complete proof
that HHH did emulate DDD correctly according to the semantics
of the x86 language and did emulate itself emulating DDD
according to these same semantics.
You are repeating the same false claim with out any self-reflection. It has been pointed out that
there are many errors in this proof.
Why repeating such errors?
The trace stops and hides what happens when 000015d2 is called.
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
Begin Local Halt Decider Simulation Execution Trace Stored at:1138cc >>>> [00002172][001138bc][001138c0] 55 push ebp ; housekeeping >>>> [00002173][001138bc][001138c0] 8bec mov ebp,esp ; housekeeping >>>> [00002175][001138b8][00002172] 6872210000 push 00002172 ; push DDD
[0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD) >>>
Olcott is hiding the conditional branch instructions in the recursion.
*Here is the full trace where nothing is hidden*
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
On page 36 of that "trace"
[0000128c][0010379f][00000018] e8e6f4ffff call 00000777
is not followed by the trace of 00000777. Instead the trace continues
with the next instruction after the return without any comment about
the omission. Meaning of 00000777 is not told.
On 02/08/2024 11:12, Mikko wrote:
On 2024-08-01 13:29:24 +0000, olcott said:
On 8/1/2024 8:12 AM, Fred. Zwarts wrote:
Op 01.aug.2024 om 14:20 schreef olcott:
On 8/1/2024 3:10 AM, Fred. Zwarts wrote:
Op 31.jul.2024 om 23:23 schreef olcott:
On 7/31/2024 3:01 PM, Fred. Zwarts wrote:
Op 31.jul.2024 om 17:14 schreef olcott:
On 7/31/2024 3:44 AM, Fred. Zwarts wrote:
Op 31.jul.2024 om 06:09 schreef olcott:This algorithm is used by all the simulating termination
  machine  stack    stack    machine   assembly >>>>>>>>>>>   address  address  data     code      language
  ======== ======== ======== ========= ============= >>>>>>>>>>> [00002192][00103820][00000000] 55        push ebp >>>>>>>>>>> [00002193][00103820][00000000] 8bec      mov ebp,esp >>>>>>>>>>> [00002195][0010381c][00002172] 6872210000 push 00002172 ; >>>>>>>>>>> push DDD
[0000219a][00103818][0000219f] e833f4ffff call 000015d2 ; >>>>>>>>>>> call HHH(DDD)
New slave_stack at:1038c4
We don't show any of HHH and show the execution trace of >>>>>>>>>>> of just DDD assuming that HHH is an x86 emulator.
This assumption is incorrect if it means that HHH is an
unconditional simulator that does not abort.
analyzers:
<MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
    *If simulating halt decider H correctly simulates its >>>>>>>>> input D*
    *until H correctly determines that its simulated D would >>>>>>>>> never*
    *stop running unless aborted* then
    H can abort its simulation of D and correctly report that D >>>>>>>>>     specifies a non-halting sequence of configurations. >>>>>>>>> </MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
So, Sipser only agreed to a correct simulation, not with an
incorrect simulation that violates the semantics of the x86
language by skipping the last few instructions of a halting
program.
int DD()
{
  int Halt_Status = HHH(DD);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
int main()
{
  HHH(DD);
}
DD correctly emulated by HHH cannot possibly reach its own
second line. I switched to DDD correctly emulated by HHH
But it has been proven that no such HHH exists that simulates
itself correctly. So, talking about a correct simulation by HHH is >>>>>> vacuous word salad.
because only C experts understood the above example and we
never had any of those here.
There are many C experts that looked at it, but you only got
critic, because you keep hiding important properties of HHH, which >>>>>> made the conclusion impossible.
The following is all that is needed for 100% complete proof
that HHH did emulate DDD correctly according to the semantics
of the x86 language and did emulate itself emulating DDD
according to these same semantics.
You are repeating the same false claim with out any self-reflection.
It has been pointed out that there are many errors in this proof.
Why repeating such errors?
_DDD()
[00002172] 55        push ebp     ; housekeeping
[00002173] 8bec      mov ebp,esp  ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404Â Â Â Â add esp,+04
[00002182] 5d        pop ebp
[00002183] c3Â Â Â Â Â Â Â Â ret
Size in bytes:(0018) [00002183]
Begin Local Halt Decider Simulation  Execution Trace Stored at:1138cc >>>>> [00002172][001138bc][001138c0] 55        push ebp     ; housekeeping
[00002173][001138bc][001138c0] 8bec      mov ebp,esp  ; housekeeping
[00002175][001138b8][00002172] 6872210000 push 00002172 ; push DDD
[0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call
HHH(DDD)
The trace stops and hides what happens when 000015d2 is called.
Olcott is hiding the conditional branch instructions in the recursion. >>>>
*Here is the full trace where nothing is hidden*
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
On page 36 of that "trace"
   [0000128c][0010379f][00000018] e8e6f4ffff call 00000777
is not followed by the trace of 00000777. Instead the trace continues
with the next instruction after the return without any comment about
the omission. Meaning of 00000777 is not told.
777 is the address of Allocate, which is one of PO's "primative ops"
within his "computing model". (Similar to his DebugStep().)
It is implemented inside x86utm.exe (his COFF obj code runner), not in
the user code DDD/HHH/etc. in the obj file, and so we would not expect
to see any trace entries for its internals. When the op concludes, rax
has the address of the allocated memory, which is consistent with how a normal function would have returned the address.
You can say correctly that PO has not explained this, but then he
provided the full trace under protest, so it's understandable that he
has not previously explained everything in it. I'm surprised that his response to your post was both to ignore the question and accuse you of playing sadistic head games, as the question was perfectly sensible.
You can look up the 777 address in the listing at the start of the trace
and it's there along with a bunch of other routines which appear to just return without doing anything - those are all PO's primitive ops. If
you feel a need to understand exactly what they do, you'll need to check
his source code! (Although for Allocate there is no big surprise...)
So your observation isn't really a problem beyond not being properly explained. An actual problem seen in his trace data is that the
simulation of DDD does not track the behaviour of the unsimulated DDD.
I.e. his simulation is incorrect. (PO knows about that but claims it doesn't matter, although on other occasions he still claims the
simulation is correct.)
Mike.
Of course these traces don't support PO's overall case he is claiming, because the (various) logs show that DDD halts, and that HHH(DDD) reports
DDD as non-halting, exactly as Linz/Sipser argue. Er, that's about it!
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
Of course these traces don't support PO's overall case he is claiming,
because the (various) logs show that DDD halts, and that HHH(DDD) reports
DDD as non-halting, exactly as Linz/Sipser argue. Er, that's about it!
PO certainly used to claim that false (non-halting) is the correct
result "even though DDD halts" (I've edited the quote to reflect a name change). Unless he's changed this position, the traces do support his
claim that what everyone else calls the wrong answer is actually the
right one.
I don't think that is the shell game. PO really /has/ an H (it's...
trivial to do for this one case) that correctly determines that P(P)
*would* never stop running *unless* aborted.
But H determines (correctly) that D would not halt if it were not
halted. That much is a truism.
On 8/2/24 1:39 PM, Mike Terry wrote:
On 02/08/2024 11:12, Mikko wrote:
On 2024-08-01 13:29:24 +0000, olcott said:
On 8/1/2024 8:12 AM, Fred. Zwarts wrote:
Op 01.aug.2024 om 14:20 schreef olcott:
On 8/1/2024 3:10 AM, Fred. Zwarts wrote:
Op 31.jul.2024 om 23:23 schreef olcott:The following is all that is needed for 100% complete proof
On 7/31/2024 3:01 PM, Fred. Zwarts wrote:
Op 31.jul.2024 om 17:14 schreef olcott:
On 7/31/2024 3:44 AM, Fred. Zwarts wrote:
Op 31.jul.2024 om 06:09 schreef olcott:This algorithm is used by all the simulating termination analyzers: >>>>>>>>>> <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= ============= >>>>>>>>>>>> [00002192][00103820][00000000] 55 push ebp
[00002193][00103820][00000000] 8bec mov ebp,esp
[00002195][0010381c][00002172] 6872210000 push 00002172 ; push DDD >>>>>>>>>>>> [0000219a][00103818][0000219f] e833f4ffff call 000015d2 ; call HHH(DDD)
New slave_stack at:1038c4
We don't show any of HHH and show the execution trace of >>>>>>>>>>>> of just DDD assuming that HHH is an x86 emulator.
This assumption is incorrect if it means that HHH is an unconditional simulator that does
not abort.
*If simulating halt decider H correctly simulates its input D* >>>>>>>>>> *until H correctly determines that its simulated D would never* >>>>>>>>>> *stop running unless aborted* then
H can abort its simulation of D and correctly report that D >>>>>>>>>> specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
So, Sipser only agreed to a correct simulation, not with an incorrect simulation that
violates the semantics of the x86 language by skipping the last few instructions of a
halting program.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
DD correctly emulated by HHH cannot possibly reach its own
second line. I switched to DDD correctly emulated by HHH
But it has been proven that no such HHH exists that simulates itself correctly. So, talking
about a correct simulation by HHH is vacuous word salad.
because only C experts understood the above example and we
never had any of those here.
There are many C experts that looked at it, but you only got critic, because you keep hiding
important properties of HHH, which made the conclusion impossible. >>>>>>
that HHH did emulate DDD correctly according to the semantics
of the x86 language and did emulate itself emulating DDD
according to these same semantics.
You are repeating the same false claim with out any self-reflection. It has been pointed out
that there are many errors in this proof.
Why repeating such errors?
The trace stops and hides what happens when 000015d2 is called.
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
Begin Local Halt Decider Simulation Execution Trace Stored at:1138cc >>>>>> [00002172][001138bc][001138c0] 55 push ebp ; housekeeping >>>>>> [00002173][001138bc][001138c0] 8bec mov ebp,esp ; housekeeping >>>>>> [00002175][001138b8][00002172] 6872210000 push 00002172 ; push DDD >>>>>> [0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD) >>>>>
Olcott is hiding the conditional branch instructions in the recursion. >>>>>
*Here is the full trace where nothing is hidden*
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
On page 36 of that "trace"
[0000128c][0010379f][00000018] e8e6f4ffff call 00000777
is not followed by the trace of 00000777. Instead the trace continues
with the next instruction after the return without any comment about
the omission. Meaning of 00000777 is not told.
777 is the address of Allocate, which is one of PO's "primative ops" within his "computing model".
(Similar to his DebugStep().)
It is implemented inside x86utm.exe (his COFF obj code runner), not in the user code DDD/HHH/etc.
in the obj file, and so we would not expect to see any trace entries for its internals. When the
op concludes, rax has the address of the allocated memory, which is consistent with how a normal
function would have returned the address.
You can say correctly that PO has not explained this, but then he provided the full trace under
protest, so it's understandable that he has not previously explained everything in it. I'm
surprised that his response to your post was both to ignore the question and accuse you of playing
sadistic head games, as the question was perfectly sensible.
You can look up the 777 address in the listing at the start of the trace and it's there along with
a bunch of other routines which appear to just return without doing anything - those are all PO's
primitive ops. If you feel a need to understand exactly what they do, you'll need to check his
source code! (Although for Allocate there is no big surprise...)
So your observation isn't really a problem beyond not being properly explained. An actual problem
seen in his trace data is that the simulation of DDD does not track the behaviour of the
unsimulated DDD. I.e. his simulation is incorrect. (PO knows about that but claims it doesn't
matter, although on other occasions he still claims the simulation is correct.)
Mike.
But the bigger error that totally negates this trace is if you at where it begins, it is at program
address 00002197, which just the page before is shown to be the address of _main.
Since HHH was not given the address of main to start with, this can not be the trace that HHH itself
is generating and looking at, but is instead the trace of the running of that top level HHH.
Since that shows the trace isn't what he claims it is, nothing it says means anything for his argument.
In fact, the way the trace is produced, it is clear that the tracing code doesn't care about what
level of simulation it is working but calls to "DebugStep" just inject the data they trace as part
of the code that is being traced, which isn't actually what is happening in the processor.
This seems to be part of the source for his confusion, and the tool he uses to try to spread his lies.
such results should, at most, be inserted as a comment about what the results computed as meta-logic
of the code just emulated did.
But of course, noting that this second layer is just meta-results, and that the original emulator
always had the option of stopping its emulation ruins his argument that the recursion is necessarily
infinite.
On 02/08/2024 19:25, Richard Damon wrote:
On 8/2/24 1:39 PM, Mike Terry wrote:
On 02/08/2024 11:12, Mikko wrote:
On 2024-08-01 13:29:24 +0000, olcott said:
On 8/1/2024 8:12 AM, Fred. Zwarts wrote:
Op 01.aug.2024 om 14:20 schreef olcott:
On 8/1/2024 3:10 AM, Fred. Zwarts wrote:
Op 31.jul.2024 om 23:23 schreef olcott:
On 7/31/2024 3:01 PM, Fred. Zwarts wrote:
Op 31.jul.2024 om 17:14 schreef olcott:
On 7/31/2024 3:44 AM, Fred. Zwarts wrote:
Op 31.jul.2024 om 06:09 schreef olcott:This algorithm is used by all the simulating termination >>>>>>>>>>> analyzers:
  machine  stack    stack    machine   assembly
  address  address  data     code      language
  ======== ======== ======== ========= ============= >>>>>>>>>>>>> [00002192][00103820][00000000] 55        push ebp >>>>>>>>>>>>> [00002193][00103820][00000000] 8bec      mov ebp,esp >>>>>>>>>>>>> [00002195][0010381c][00002172] 6872210000 push 00002172 ; >>>>>>>>>>>>> push DDD
[0000219a][00103818][0000219f] e833f4ffff call 000015d2 ; >>>>>>>>>>>>> call HHH(DDD)
New slave_stack at:1038c4
We don't show any of HHH and show the execution trace of >>>>>>>>>>>>> of just DDD assuming that HHH is an x86 emulator.
This assumption is incorrect if it means that HHH is an >>>>>>>>>>>> unconditional simulator that does not abort.
<MIT Professor Sipser agreed to ONLY these verbatim words >>>>>>>>>>> 10/13/2022>
    *If simulating halt decider H correctly simulates its >>>>>>>>>>> input D*
    *until H correctly determines that its simulated D would >>>>>>>>>>> never*
    *stop running unless aborted* then
    H can abort its simulation of D and correctly report that D
    specifies a non-halting sequence of configurations. >>>>>>>>>>> </MIT Professor Sipser agreed to ONLY these verbatim words >>>>>>>>>>> 10/13/2022>
So, Sipser only agreed to a correct simulation, not with an >>>>>>>>>> incorrect simulation that violates the semantics of the x86 >>>>>>>>>> language by skipping the last few instructions of a halting >>>>>>>>>> program.
int DD()
{
  int Halt_Status = HHH(DD);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
int main()
{
  HHH(DD);
}
DD correctly emulated by HHH cannot possibly reach its own
second line. I switched to DDD correctly emulated by HHH
But it has been proven that no such HHH exists that simulates
itself correctly. So, talking about a correct simulation by HHH >>>>>>>> is vacuous word salad.
because only C experts understood the above example and we
never had any of those here.
There are many C experts that looked at it, but you only got
critic, because you keep hiding important properties of HHH,
which made the conclusion impossible.
The following is all that is needed for 100% complete proof
that HHH did emulate DDD correctly according to the semantics
of the x86 language and did emulate itself emulating DDD
according to these same semantics.
You are repeating the same false claim with out any
self-reflection. It has been pointed out that there are many
errors in this proof.
Why repeating such errors?
_DDD()
[00002172] 55        push ebp     ; housekeeping
[00002173] 8bec      mov ebp,esp  ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404Â Â Â Â add esp,+04
[00002182] 5d        pop ebp
[00002183] c3Â Â Â Â Â Â Â Â ret
Size in bytes:(0018) [00002183]
Begin Local Halt Decider Simulation  Execution Trace Stored
at:1138cc
[00002172][001138bc][001138c0] 55        push ebp     ; >>>>>>> housekeeping
[00002173][001138bc][001138c0] 8bec      mov ebp,esp  ; >>>>>>> housekeeping
[00002175][001138b8][00002172] 6872210000 push 00002172 ; push DDD >>>>>>> [0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call
HHH(DDD)
The trace stops and hides what happens when 000015d2 is called.
Olcott is hiding the conditional branch instructions in the
recursion.
*Here is the full trace where nothing is hidden*
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
On page 36 of that "trace"
   [0000128c][0010379f][00000018] e8e6f4ffff call 00000777
is not followed by the trace of 00000777. Instead the trace continues
with the next instruction after the return without any comment about
the omission. Meaning of 00000777 is not told.
777 is the address of Allocate, which is one of PO's "primative ops"
within his "computing model". (Similar to his DebugStep().)
It is implemented inside x86utm.exe (his COFF obj code runner), not
in the user code DDD/HHH/etc. in the obj file, and so we would not
expect to see any trace entries for its internals. When the op
concludes, rax has the address of the allocated memory, which is
consistent with how a normal function would have returned the address.
You can say correctly that PO has not explained this, but then he
provided the full trace under protest, so it's understandable that he
has not previously explained everything in it. I'm surprised that
his response to your post was both to ignore the question and accuse
you of playing sadistic head games, as the question was perfectly
sensible.
You can look up the 777 address in the listing at the start of the
trace and it's there along with a bunch of other routines which
appear to just return without doing anything - those are all PO's
primitive ops. If you feel a need to understand exactly what they
do, you'll need to check his source code! (Although for Allocate
there is no big surprise...)
So your observation isn't really a problem beyond not being properly
explained. An actual problem seen in his trace data is that the
simulation of DDD does not track the behaviour of the unsimulated
DDD. I.e. his simulation is incorrect. (PO knows about that but
claims it doesn't matter, although on other occasions he still claims
the simulation is correct.)
Mike.
But the bigger error that totally negates this trace is if you at
where it begins, it is at program address 00002197, which just the
page before is shown to be the address of _main.
Since HHH was not given the address of main to start with, this can
not be the trace that HHH itself is generating and looking at, but is
instead the trace of the running of that top level HHH.
Well, all PO's trace logs start with main! Something has to set up the required computation [aka the required TM + input tape]. That could be HHH(DDD), or maybe DDD() or whatever. PO might have done this through
extra invocation arguments to x86utm.exe, and then there would have been
no need to code a main() in his halt7.c user code file. But that would
be decidedly fiddly, so having a fixed entry function main() is an ok convenience I'd say. The main() is not really part of his computation model, but x86utm traces the lot.
Normally when PO gives code snippets, he includes the main() routine.
In this case it is main calling HHH(DDD), so HHH as you say is the outer level HHH. (Later on in the trace we see simulated HHH entries...)
Since that shows the trace isn't what he claims it is, nothing it says
means anything for his argument.
I can't see what PO claims the trace to be. That trace was taken and published some weeks ago, and doesn't match up exactly with todays
partial trace - e.g. the addresses of HHH/DDD don't match and so on. If it's just wrong through being out of date, or because it has the main()
trace on the front, that's not the worst of crimes...
I see upthread that someone pointed out that the filtered trace "..stops
and hides what happens when 000015d2 is called."Â Well, the full trace
does show the instructions of HHH being executed [even if the data is a
bit out of date], and of course there are loads of conditional
branches... so everyone should be happy! :)
In fact, the way the trace is produced, it is clear that the tracing
code doesn't care about what level of simulation it is working but
calls to "DebugStep" just inject the data they trace as part of the
code that is being traced, which isn't actually what is happening in
the processor.
That's correct. The full trace proceeds showing HHH executing its code
as we would expect, and after some time HHH (actually a routine called
by HHH) invokes a DebugStep op. We can see that the DebugStep op
stepped HHH's simulation one instruction, which also appears in trace.
Here is where that happens:
,,,
[000011eb][00103783][00103863] 8b4d1c mov ecx,[ebp+1c] [000011ee][00103783][00103863] 8b11 mov edx,[ecx] [000011f0][0010377f][00103827] 52 push edx
[000011f1][0010377f][00103827] e8b1f5ffff call 000007a7Â Â Â Â <=== DebugStep
[00002177][00113897][0011389b] 55 push ebp                 <===
simulated instruction
[000011f6][0010378b][90909090] 83c40c add esp,+0c          <=== next
instructin after DebugStep
[000011f9][0010378b][90909090] e8e9f5ffff call 000007e7
...
The "push ebp" above is the first simulated instruction, and just
appears in the trace straight after the call to DebugStep. [Note the apparent discontinuities in IP address and ESP (cols 1&2 resp.) Yeah I know, /why isn't there a simulation level column/ ?]
We could say that the trace as shown is a log of all the instructions
x86utm "executes" in succession, so it is a merge of entries from all simulation levels - certainly it's not the x86 "processor trace" it
might be taken to be.
Note - the "push ebp" instruction is the first simulated instruction of DDD(), which at least is the instruction we would expect it to be. In
PO's normal "filtered" log output, all the other instructions above
wouldn't appear as they're not from DDD.
Of course these traces don't support PO's overall case he is claiming, because the (various) logs show that DDD halts, and that HHH(DDD)
reports DDD as non-halting, exactly as Linz/Sipser argue. Er, that's
about it!
Whether it supports some minutia of what PO is currently arguing about - you'd have to explain to me exactly what he is claiming! (um, Please don't!)
This seems to be part of the source for his confusion, and the tool he
uses to try to spread his lies.
such results should, at most, be inserted as a comment about what the
results computed as meta-logic of the code just emulated did.
But of course, noting that this second layer is just meta-results, and
that the original emulator always had the option of stopping its
emulation ruins his argument that the recursion is necessarily infinite.
It's hard to pin down confusion sources. I agree PO doesn't need x86utm logs to argue his case, and including them doesn't /prove/ anything, especially when he admits the simulated code uses mutable static data to modify the behaviour of the simulation so that it does not match the unsimulated (outer) computation.
I think PO views x86utm as some kind of "ultra authority" he can appeal
to, to avoid having to actually prove his claims. [Which is funny,
because the logs don't support his claims, but for some reason that
passes him by...]
Mike.
On 8/2/2024 5:42 PM, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
Of course these traces don't support PO's overall case he is claiming,
because the (various) logs show that DDD halts, and that HHH(DDD)
reports
DDD as non-halting, exactly as Linz/Sipser argue. Er, that's about it!
PO certainly used to claim that false (non-halting) is the correct
result "even though DDD halts" (I've edited the quote to reflect a name
change). Unless he's changed this position, the traces do support his
claim that what everyone else calls the wrong answer is actually the
right one.
I had to simplify it into simpler steps because the
recent people don't seem to know the first thing
about programming.
Who here is too stupid to know that DDD correctly
simulated by HHH cannot possibly reach its own
return instruction?
void DDD()
{
 HHH(DDD);
 return;
}
*You are the only one that got this much correctly*
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
I don't think that is the shell game. PO really /has/ an H (it's...
trivial to do for this one case) that correctly determines that P(P) *would* never stop running *unless* aborted.
But H determines (correctly) that D would not halt if it were not halted. That much is a truism.
*Even Mike got much less that that*
On 8/2/2024 5:23 PM, Mike Terry wrote:
On 02/08/2024 19:25, Richard Damon wrote:
On 8/2/24 1:39 PM, Mike Terry wrote:
On 02/08/2024 11:12, Mikko wrote:
On 2024-08-01 13:29:24 +0000, olcott said:
On 8/1/2024 8:12 AM, Fred. Zwarts wrote:
Op 01.aug.2024 om 14:20 schreef olcott:
On 8/1/2024 3:10 AM, Fred. Zwarts wrote:
Op 31.jul.2024 om 23:23 schreef olcott:
On 7/31/2024 3:01 PM, Fred. Zwarts wrote:
Op 31.jul.2024 om 17:14 schreef olcott:
On 7/31/2024 3:44 AM, Fred. Zwarts wrote:
Op 31.jul.2024 om 06:09 schreef olcott:This algorithm is used by all the simulating termination >>>>>>>>>>>> analyzers:
  machine  stack    stack    machine   assembly
  address  address  data     code      language
  ======== ======== ======== ========= ============= >>>>>>>>>>>>>> [00002192][00103820][00000000] 55        push ebp >>>>>>>>>>>>>> [00002193][00103820][00000000] 8bec      mov ebp,esp >>>>>>>>>>>>>> [00002195][0010381c][00002172] 6872210000 push 00002172 ; >>>>>>>>>>>>>> push DDD
[0000219a][00103818][0000219f] e833f4ffff call 000015d2 ; >>>>>>>>>>>>>> call HHH(DDD)
New slave_stack at:1038c4
We don't show any of HHH and show the execution trace of >>>>>>>>>>>>>> of just DDD assuming that HHH is an x86 emulator.
This assumption is incorrect if it means that HHH is an >>>>>>>>>>>>> unconditional simulator that does not abort.
<MIT Professor Sipser agreed to ONLY these verbatim words >>>>>>>>>>>> 10/13/2022>
    *If simulating halt decider H correctly simulates its >>>>>>>>>>>> input D*
    *until H correctly determines that its simulated D >>>>>>>>>>>> would never*
    *stop running unless aborted* then
    H can abort its simulation of D and correctly report >>>>>>>>>>>> that D
    specifies a non-halting sequence of configurations. >>>>>>>>>>>> </MIT Professor Sipser agreed to ONLY these verbatim words >>>>>>>>>>>> 10/13/2022>
So, Sipser only agreed to a correct simulation, not with an >>>>>>>>>>> incorrect simulation that violates the semantics of the x86 >>>>>>>>>>> language by skipping the last few instructions of a halting >>>>>>>>>>> program.
int DD()
{
  int Halt_Status = HHH(DD);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
int main()
{
  HHH(DD);
}
DD correctly emulated by HHH cannot possibly reach its own >>>>>>>>>> second line. I switched to DDD correctly emulated by HHH
But it has been proven that no such HHH exists that simulates >>>>>>>>> itself correctly. So, talking about a correct simulation by HHH >>>>>>>>> is vacuous word salad.
because only C experts understood the above example and we >>>>>>>>>> never had any of those here.
There are many C experts that looked at it, but you only got >>>>>>>>> critic, because you keep hiding important properties of HHH, >>>>>>>>> which made the conclusion impossible.
The following is all that is needed for 100% complete proof
that HHH did emulate DDD correctly according to the semantics
of the x86 language and did emulate itself emulating DDD
according to these same semantics.
You are repeating the same false claim with out any self-
reflection. It has been pointed out that there are many errors in >>>>>>> this proof.
Why repeating such errors?
_DDD()
[00002172] 55        push ebp     ; housekeeping >>>>>>>> [00002173] 8bec      mov ebp,esp  ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404Â Â Â Â add esp,+04
[00002182] 5d        pop ebp
[00002183] c3Â Â Â Â Â Â Â Â ret
Size in bytes:(0018) [00002183]
Begin Local Halt Decider Simulation  Execution Trace Stored >>>>>>>> at:1138cc
[00002172][001138bc][001138c0] 55        push ebp     ; >>>>>>>> housekeeping
[00002173][001138bc][001138c0] 8bec      mov ebp,esp  ; >>>>>>>> housekeeping
[00002175][001138b8][00002172] 6872210000 push 00002172 ; push DDD >>>>>>>> [0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call >>>>>>>> HHH(DDD)
The trace stops and hides what happens when 000015d2 is called.
Olcott is hiding the conditional branch instructions in the
recursion.
*Here is the full trace where nothing is hidden*
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
On page 36 of that "trace"
   [0000128c][0010379f][00000018] e8e6f4ffff call 00000777
is not followed by the trace of 00000777. Instead the trace continues >>>>> with the next instruction after the return without any comment about >>>>> the omission. Meaning of 00000777 is not told.
777 is the address of Allocate, which is one of PO's "primative ops"
within his "computing model". (Similar to his DebugStep().)
It is implemented inside x86utm.exe (his COFF obj code runner), not
in the user code DDD/HHH/etc. in the obj file, and so we would not
expect to see any trace entries for its internals. When the op
concludes, rax has the address of the allocated memory, which is
consistent with how a normal function would have returned the address. >>>>
You can say correctly that PO has not explained this, but then he
provided the full trace under protest, so it's understandable that
he has not previously explained everything in it. I'm surprised
that his response to your post was both to ignore the question and
accuse you of playing sadistic head games, as the question was
perfectly sensible.
You can look up the 777 address in the listing at the start of the
trace and it's there along with a bunch of other routines which
appear to just return without doing anything - those are all PO's
primitive ops. If you feel a need to understand exactly what they
do, you'll need to check his source code! (Although for Allocate
there is no big surprise...)
So your observation isn't really a problem beyond not being properly
explained. An actual problem seen in his trace data is that the
simulation of DDD does not track the behaviour of the unsimulated
DDD. I.e. his simulation is incorrect. (PO knows about that but
claims it doesn't matter, although on other occasions he still
claims the simulation is correct.)
Mike.
But the bigger error that totally negates this trace is if you at
where it begins, it is at program address 00002197, which just the
page before is shown to be the address of _main.
Since HHH was not given the address of main to start with, this can
not be the trace that HHH itself is generating and looking at, but is
instead the trace of the running of that top level HHH.
Well, all PO's trace logs start with main! Something has to set up
the required computation [aka the required TM + input tape]. That
could be HHH(DDD), or maybe DDD() or whatever. PO might have done
this through extra invocation arguments to x86utm.exe, and then there
would have been no need to code a main() in his halt7.c user code
file. But that would be decidedly fiddly, so having a fixed entry
function main() is an ok convenience I'd say. The main() is not
really part of his computation model, but x86utm traces the lot.
Normally when PO gives code snippets, he includes the main() routine.
In this case it is main calling HHH(DDD), so HHH as you say is the
outer level HHH. (Later on in the trace we see simulated HHH entries...) >>
Since that shows the trace isn't what he claims it is, nothing it
says means anything for his argument.
I can't see what PO claims the trace to be. That trace was taken and
published some weeks ago, and doesn't match up exactly with todays
partial trace - e.g. the addresses of HHH/DDD don't match and so on.
If it's just wrong through being out of date, or because it has the
main() trace on the front, that's not the worst of crimes...
I see upthread that someone pointed out that the filtered trace
"..stops and hides what happens when 000015d2 is called."Â Well, the
full trace does show the instructions of HHH being executed [even if
the data is a bit out of date], and of course there are loads of
conditional branches... so everyone should be happy! :)
In fact, the way the trace is produced, it is clear that the tracing
code doesn't care about what level of simulation it is working but
calls to "DebugStep" just inject the data they trace as part of the
code that is being traced, which isn't actually what is happening in
the processor.
That's correct. The full trace proceeds showing HHH executing its
code as we would expect, and after some time HHH (actually a routine
called by HHH) invokes a DebugStep op. We can see that the DebugStep
op stepped HHH's simulation one instruction, which also appears in
trace. Here is where that happens:
,,,
[000011eb][00103783][00103863] 8b4d1c mov ecx,[ebp+1c]
[000011ee][00103783][00103863] 8b11 mov edx,[ecx]
[000011f0][0010377f][00103827] 52 push edx
[000011f1][0010377f][00103827] e8b1f5ffff call 000007a7Â Â Â Â <===
DebugStep
[00002177][00113897][0011389b] 55 push ebp                 <===
simulated instruction
[000011f6][0010378b][90909090] 83c40c add esp,+0c          <=== next
instructin after DebugStep
[000011f9][0010378b][90909090] e8e9f5ffff call 000007e7
...
The "push ebp" above is the first simulated instruction, and just
appears in the trace straight after the call to DebugStep. [Note the
apparent discontinuities in IP address and ESP (cols 1&2 resp.)Â Yeah
I know, /why isn't there a simulation level column/ ?]
We could say that the trace as shown is a log of all the instructions
x86utm "executes" in succession, so it is a merge of entries from all
simulation levels - certainly it's not the x86 "processor trace" it
might be taken to be.
Note - the "push ebp" instruction is the first simulated instruction
of DDD(), which at least is the instruction we would expect it to be.
In PO's normal "filtered" log output, all the other instructions above
wouldn't appear as they're not from DDD.
Of course these traces don't support PO's overall case he is claiming,
because the (various) logs show that DDD halts, and that HHH(DDD)
reports DDD as non-halting, exactly as Linz/Sipser argue. Er, that's
about it!
Whether it supports some minutia of what PO is currently arguing about
- you'd have to explain to me exactly what he is claiming! (um,
Please don't!)
This seems to be part of the source for his confusion, and the tool
he uses to try to spread his lies.
such results should, at most, be inserted as a comment about what the
results computed as meta-logic of the code just emulated did.
But of course, noting that this second layer is just meta-results,
and that the original emulator always had the option of stopping its
emulation ruins his argument that the recursion is necessarily infinite.
It's hard to pin down confusion sources. I agree PO doesn't need
x86utm logs to argue his case, and including them doesn't /prove/
anything, especially when he admits the simulated code uses mutable
static data to modify the behaviour of the simulation so that it does
not match the unsimulated (outer) computation.
I think PO views x86utm as some kind of "ultra authority" he can
appeal to, to avoid having to actually prove his claims. [Which is
funny, because the logs don't support his claims, but for some reason
that passes him by...]
Mike.
*No dumbo. The ultimate authority is the x86 semantics of DDD*
_DDD()
[00002172] 55        push ebp     ; housekeeping
[00002173] 8bec      mov ebp,esp  ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404Â Â Â Â add esp,+04
[00002182] 5d        pop ebp
[00002183] c3Â Â Â Â Â Â Â Â ret
Size in bytes:(0018) [00002183]
I have proved my point such that someone mostly clueless
about the semantics of the x86 language would have understood
that I have been correct all along with the original H/P
three years ago.
I have to simplify be proof so that anyone intentionally
misconstruing it looks ridiculously stupid even to themselves.
Who here is too stupid to know that DDD correctly simulated
by HHH cannot possibly reach its own return instruction?
void DDD()
{
 HHH(DDD);
 return;
}
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
Of course these traces don't support PO's overall case he is claiming,
because the (various) logs show that DDD halts, and that HHH(DDD) reports
DDD as non-halting, exactly as Linz/Sipser argue. Er, that's about it!
PO certainly used to claim that false (non-halting) is the correct
result "even though DDD halts" (I've edited the quote to reflect a name change). Unless he's changed this position, the traces do support his
claim that what everyone else calls the wrong answer is actually the
right one.
On 02/08/2024 23:42, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
Of course these traces don't support PO's overall case he is claiming,
because the (various) logs show that DDD halts, and that HHH(DDD)
reports
DDD as non-halting, exactly as Linz/Sipser argue. Er, that's about it!
PO certainly used to claim that false (non-halting) is the correct
result "even though DDD halts" (I've edited the quote to reflect a name
change). Unless he's changed this position, the traces do support his
claim that what everyone else calls the wrong answer is actually the
right one.
So, in your opinion, what do you believe is PO's criterion for "correct result", exactly? It would be handy if you can give a proper
mathematical definition so nobody will have any doubt what it is. Hey, I
know you're more than capable of getting a definition right, so let's
have that definition!
Definition:Â A TM P given input I is said to "halt" iff ?????
            or whatever...
It's easy enough to say "PO has his own criterion for halting, which is materially different from the HP condition, and so we all agree PO is
correct by his own criterion, but that does not say anything about the
HP theorem because it is different from the HP definition".
But is that /really/ something PO agrees with? I don't think so
somehow, because I'm pretty sure PO believes his claim "refutes" the HP result. He wouldn't say that if he freely acknowleded that he had
invented a completely different definition for halting. Also, for what you're saying to be the right way of looking at things, PO would have to admit that the HP proof with its standard definition of halting is
valid, and that there is nothing wrong with the Linz proof, other than
it not applying to his own favourite PO-halting definition.
I.e. I think your way of looking at it is a bit "too easy" - but I'd be
happy to be convinced! Personally I suspect PO has no such "new and
different definition" and that anything along those lines PO is thinking
of will be quite incoherent. No doubt you could make some definition
that is at least coherent but we have to ask ourselves - is that
definition /really/ what PO is thinking???
Nowadays, I think PO's position is more that:
-Â yes, DDD() halts when run directly
-Â but DDD() when it runs inside HHH simulator /really/ does not halt,
in some kind of
  sense that it /really/ has infinite recursion which would never end
  however far it was simulated (because it "exhibits" infinite
recursion in some way)
-Â and yes, DDD() /does/ halt when simulated within UTM(DDD),
- but the behaviour of DDD depends on who is simulating it. It
terminates when
  UTM simulates it, but doesn't terminate when HHH simulates it, due
to some
  kind of pathelogical relationship specifically with HHH. This difference in
  simulation is /more/ than one simulator aborting earlier than the other...
Mike.
On 8/2/24 6:23 PM, Mike Terry wrote:
On 02/08/2024 19:25, Richard Damon wrote:
On 8/2/24 1:39 PM, Mike Terry wrote:
On 02/08/2024 11:12, Mikko wrote:
On 2024-08-01 13:29:24 +0000, olcott said:
On 8/1/2024 8:12 AM, Fred. Zwarts wrote:
Op 01.aug.2024 om 14:20 schreef olcott:
On 8/1/2024 3:10 AM, Fred. Zwarts wrote:
Op 31.jul.2024 om 23:23 schreef olcott:
On 7/31/2024 3:01 PM, Fred. Zwarts wrote:
Op 31.jul.2024 om 17:14 schreef olcott:
On 7/31/2024 3:44 AM, Fred. Zwarts wrote:
Op 31.jul.2024 om 06:09 schreef olcott:This algorithm is used by all the simulating termination analyzers:
machine stack stack machine assembly >>>>>>>>>>>>>> address address data code language >>>>>>>>>>>>>> ======== ======== ======== ========= ============= >>>>>>>>>>>>>> [00002192][00103820][00000000] 55 push ebp >>>>>>>>>>>>>> [00002193][00103820][00000000] 8bec mov ebp,esp >>>>>>>>>>>>>> [00002195][0010381c][00002172] 6872210000 push 00002172 ; push DDD
[0000219a][00103818][0000219f] e833f4ffff call 000015d2 ; call HHH(DDD)
New slave_stack at:1038c4
We don't show any of HHH and show the execution trace of >>>>>>>>>>>>>> of just DDD assuming that HHH is an x86 emulator.
This assumption is incorrect if it means that HHH is an unconditional simulator that
does not abort.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
*If simulating halt decider H correctly simulates its input D*
*until H correctly determines that its simulated D would never*
*stop running unless aborted* then
H can abort its simulation of D and correctly report that D >>>>>>>>>>>> specifies a non-halting sequence of configurations. >>>>>>>>>>>> </MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
So, Sipser only agreed to a correct simulation, not with an incorrect simulation that
violates the semantics of the x86 language by skipping the last few instructions of a
halting program.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
DD correctly emulated by HHH cannot possibly reach its own >>>>>>>>>> second line. I switched to DDD correctly emulated by HHH
But it has been proven that no such HHH exists that simulates itself correctly. So, talking
about a correct simulation by HHH is vacuous word salad.
because only C experts understood the above example and we >>>>>>>>>> never had any of those here.
There are many C experts that looked at it, but you only got critic, because you keep
hiding important properties of HHH, which made the conclusion impossible.
The following is all that is needed for 100% complete proof
that HHH did emulate DDD correctly according to the semantics
of the x86 language and did emulate itself emulating DDD
according to these same semantics.
You are repeating the same false claim with out any self-reflection. It has been pointed out
that there are many errors in this proof.
Why repeating such errors?
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
Begin Local Halt Decider Simulation Execution Trace Stored at:1138cc >>>>>>>> [00002172][001138bc][001138c0] 55 push ebp ; housekeeping >>>>>>>> [00002173][001138bc][001138c0] 8bec mov ebp,esp ; housekeeping >>>>>>>> [00002175][001138b8][00002172] 6872210000 push 00002172 ; push DDD >>>>>>>> [0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)
The trace stops and hides what happens when 000015d2 is called.
Olcott is hiding the conditional branch instructions in the recursion. >>>>>>>
*Here is the full trace where nothing is hidden*
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
On page 36 of that "trace"
[0000128c][0010379f][00000018] e8e6f4ffff call 00000777
is not followed by the trace of 00000777. Instead the trace continues >>>>> with the next instruction after the return without any comment about >>>>> the omission. Meaning of 00000777 is not told.
777 is the address of Allocate, which is one of PO's "primative ops" within his "computing
model". (Similar to his DebugStep().)
It is implemented inside x86utm.exe (his COFF obj code runner), not in the user code
DDD/HHH/etc. in the obj file, and so we would not expect to see any trace entries for its
internals. When the op concludes, rax has the address of the allocated memory, which is
consistent with how a normal function would have returned the address. >>>>
You can say correctly that PO has not explained this, but then he provided the full trace under
protest, so it's understandable that he has not previously explained everything in it. I'm
surprised that his response to your post was both to ignore the question and accuse you of
playing sadistic head games, as the question was perfectly sensible.
You can look up the 777 address in the listing at the start of the trace and it's there along
with a bunch of other routines which appear to just return without doing anything - those are
all PO's primitive ops. If you feel a need to understand exactly what they do, you'll need to
check his source code! (Although for Allocate there is no big surprise...)
So your observation isn't really a problem beyond not being properly explained. An actual
problem seen in his trace data is that the simulation of DDD does not track the behaviour of the
unsimulated DDD. I.e. his simulation is incorrect. (PO knows about that but claims it doesn't
matter, although on other occasions he still claims the simulation is correct.)
Mike.
But the bigger error that totally negates this trace is if you at where it begins, it is at
program address 00002197, which just the page before is shown to be the address of _main.
Since HHH was not given the address of main to start with, this can not be the trace that HHH
itself is generating and looking at, but is instead the trace of the running of that top level HHH.
Well, all PO's trace logs start with main! Something has to set up the required computation [aka
the required TM + input tape]. That could be HHH(DDD), or maybe DDD() or whatever. PO might have
done this through extra invocation arguments to x86utm.exe, and then there would have been no need
to code a main() in his halt7.c user code file. But that would be decidedly fiddly, so having a
fixed entry function main() is an ok convenience I'd say. The main() is not really part of his
computation model, but x86utm traces the lot.
Normally when PO gives code snippets, he includes the main() routine. In this case it is main
calling HHH(DDD), so HHH as you say is the outer level HHH. (Later on in the trace we see
simulated HHH entries...)
Since that shows the trace isn't what he claims it is, nothing it says means anything for his
argument.
I can't see what PO claims the trace to be. That trace was taken and published some weeks ago,
and doesn't match up exactly with todays partial trace - e.g. the addresses of HHH/DDD don't match
and so on. If it's just wrong through being out of date, or because it has the main() trace on
the front, that's not the worst of crimes...
I see upthread that someone pointed out that the filtered trace "..stops and hides what happens
when 000015d2 is called." Well, the full trace does show the instructions of HHH being executed
[even if the data is a bit out of date], and of course there are loads of conditional branches...
so everyone should be happy! :)
In fact, the way the trace is produced, it is clear that the tracing code doesn't care about what
level of simulation it is working but calls to "DebugStep" just inject the data they trace as
part of the code that is being traced, which isn't actually what is happening in the processor.
That's correct. The full trace proceeds showing HHH executing its code as we would expect, and
after some time HHH (actually a routine called by HHH) invokes a DebugStep op. We can see that
the DebugStep op stepped HHH's simulation one instruction, which also appears in trace. Here is
where that happens:
,,,
[000011eb][00103783][00103863] 8b4d1c mov ecx,[ebp+1c]
[000011ee][00103783][00103863] 8b11 mov edx,[ecx]
[000011f0][0010377f][00103827] 52 push edx
[000011f1][0010377f][00103827] e8b1f5ffff call 000007a7 <=== DebugStep >> [00002177][00113897][0011389b] 55 push ebp <=== simulated instruction
[000011f6][0010378b][90909090] 83c40c add esp,+0c <=== next instructin after DebugStep
[000011f9][0010378b][90909090] e8e9f5ffff call 000007e7
...
The "push ebp" above is the first simulated instruction, and just appears in the trace straight
after the call to DebugStep. [Note the apparent discontinuities in IP address and ESP (cols 1&2
resp.) Yeah I know, /why isn't there a simulation level column/ ?]
We could say that the trace as shown is a log of all the instructions x86utm "executes" in
succession, so it is a merge of entries from all simulation levels - certainly it's not the x86
"processor trace" it might be taken to be.
Note - the "push ebp" instruction is the first simulated instruction of DDD(), which at least is
the instruction we would expect it to be. In PO's normal "filtered" log output, all the other
instructions above wouldn't appear as they're not from DDD.
Of course these traces don't support PO's overall case he is claiming, because the (various) logs
show that DDD halts, and that HHH(DDD) reports DDD as non-halting, exactly as Linz/Sipser argue.
Er, that's about it!
Whether it supports some minutia of what PO is currently arguing about - you'd have to explain to
me exactly what he is claiming! (um, Please don't!)
This seems to be part of the source for his confusion, and the tool he uses to try to spread his
lies.
such results should, at most, be inserted as a comment about what the results computed as
meta-logic of the code just emulated did.
But of course, noting that this second layer is just meta-results, and that the original emulator
always had the option of stopping its emulation ruins his argument that the recursion is
necessarily infinite.
It's hard to pin down confusion sources. I agree PO doesn't need x86utm logs to argue his case,
and including them doesn't /prove/ anything, especially when he admits the simulated code uses
mutable static data to modify the behaviour of the simulation so that it does not match the
unsimulated (outer) computation.
I think PO views x86utm as some kind of "ultra authority" he can appeal to, to avoid having to
actually prove his claims. [Which is funny, because the logs don't support his claims, but for
some reason that passes him by...]
Mike.
The problem is that he calls them traces of the emulation that HHH does, and it should never see
that main, as it isn't part of what he has defined as the input.
It is clear that this output is the output generated by x86utm,
NOT just his HHH. As such, it is not
the output he claims.
It seems clear that he can't figure out how to get the x86UTM program to create just the trace of
what HHH sees,
He *CLAIMS* that HHH actually works on the full trace of DDD going into HHH, but apparently there is
no way for him to show such a trace.
WHen I last look in detail at the code, his H didn't actually trace into the decider itself, but
just assumed that the decider was a emulator and started a nested emulation of it, just like he is
currently showing. THe key point is he doesn't consider that the decider is a decider, but thinks of
it as just an unconditional emuator, which is of course, and incorrect assumption.
The problem he had with the version that tried to actually emulate the emulator but he needed the
"illegal" static memory to let the decider know the recursion happened, so I suspect he just knows
that he isn't actually doing what he claims, but is still using his old tricks, and just trying to
hide it.
The code does still appear to detecting if it is the "root" decider or not, but I am not sure if the
code actually is doing anything.
On 8/2/2024 3:13 AM, Fred. Zwarts wrote:
Op 01.aug.2024 om 23:03 schreef olcott:
On 8/1/2024 2:30 PM, Fred. Zwarts wrote:
Op 01.aug.2024 om 18:32 schreef olcott:
On 8/1/2024 11:11 AM, joes wrote:Sipser agreed only to a correct simulation.
Am Thu, 01 Aug 2024 09:30:00 -0500 schrieb olcott:
On 8/1/2024 9:23 AM, Fred. Zwarts wrote:
Op 01.aug.2024 om 15:29 schreef olcott:
On 8/1/2024 8:12 AM, Fred. Zwarts wrote:
Op 01.aug.2024 om 14:20 schreef olcott:
On 8/1/2024 3:10 AM, Fred. Zwarts wrote:
Op 31.jul.2024 om 23:23 schreef olcott:
On 7/31/2024 3:01 PM, Fred. Zwarts wrote:
Op 31.jul.2024 om 17:14 schreef olcott:
On 7/31/2024 3:44 AM, Fred. Zwarts wrote:
Op 31.jul.2024 om 06:09 schreef olcott:
If you weren't a clueless wonder you would understand that DDDIt also shows that HHH when simulating itself, does not reachThe trace stops and hides what happens when 000015d2 is called. >>>>>>>>>> Olcott is hiding the conditional branch instructions in the >>>>>>>>>> recursion.These next lines conclusively prove that DDD is being correctly >>>>>>>>> emulated by HHH after DDD calls HHH(DDD).
the end
of its own simulation.
correctly
emulated by HHH including HHH emulating itself emulated DDD has
no end
of correct emulation.
It does if the simulated HHH aborts, but its simulating copy preempts >>>>>> that. Indeed, it has no choice, but if it didn't abort, the
simulation
wouldn't abort either. Therefore it can't simulate itself.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>> Â Â Â Â If simulating halt decider H correctly simulates its input D >>>>> Â Â Â Â until H correctly determines that its simulated D would never >>>>> Â Â Â Â stop running unless aborted then
    H can abort its simulation of D and correctly report that D >>>>>     specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>
of N steps.
Without skipping M steps of a halting program.
THAT IS WRONG. IT IS MAKING SURE TO SKIP ALL THE STEPS AFTER
H correctly determines that its simulated D would never
stop running unless aborted
I spent two years carefully composing the above before I even
asked professor Sipser to review it.
DDD is correctly emulated by HHH until HHH sees the same
never ending pattern that anyone else can see.
The never ending pattern is there only in your dreams. The HHH that
halts after two cycles has a halting pattern.
In order for DDD correctly emulated by HHH to halt
DDD correctly emulated must reach its emulated "ret"
instruction. This <is> impossible.
Indeed! HHH cannot possibly simulate itself correctly.
You are a damned liar about how correct emulation is defined.
On 8/2/2024 3:13 AM, Fred. Zwarts wrote:
Op 01.aug.2024 om 23:03 schreef olcott:
On 8/1/2024 2:30 PM, Fred. Zwarts wrote:
Op 01.aug.2024 om 18:32 schreef olcott:
On 8/1/2024 11:11 AM, joes wrote:Sipser agreed only to a correct simulation.
Am Thu, 01 Aug 2024 09:30:00 -0500 schrieb olcott:
On 8/1/2024 9:23 AM, Fred. Zwarts wrote:
Op 01.aug.2024 om 15:29 schreef olcott:
On 8/1/2024 8:12 AM, Fred. Zwarts wrote:
Op 01.aug.2024 om 14:20 schreef olcott:
On 8/1/2024 3:10 AM, Fred. Zwarts wrote:
Op 31.jul.2024 om 23:23 schreef olcott:
On 7/31/2024 3:01 PM, Fred. Zwarts wrote:
Op 31.jul.2024 om 17:14 schreef olcott:
On 7/31/2024 3:44 AM, Fred. Zwarts wrote:
Op 31.jul.2024 om 06:09 schreef olcott:
If you weren't a clueless wonder you would understand that DDD correctlyIt also shows that HHH when simulating itself, does not reach the end >>>>>>>> of its own simulation.The trace stops and hides what happens when 000015d2 is called. >>>>>>>>>> Olcott is hiding the conditional branch instructions in the >>>>>>>>>> recursion.These next lines conclusively prove that DDD is being correctly >>>>>>>>> emulated by HHH after DDD calls HHH(DDD).
emulated by HHH including HHH emulating itself emulated DDD has no end >>>>>>> of correct emulation.
It does if the simulated HHH aborts, but its simulating copy preempts >>>>>> that. Indeed, it has no choice, but if it didn't abort, the simulation >>>>>> wouldn't abort either. Therefore it can't simulate itself.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>> Â Â Â Â If simulating halt decider H correctly simulates its input D >>>>> Â Â Â Â until H correctly determines that its simulated D would never >>>>> Â Â Â Â stop running unless aborted then
    H can abort its simulation of D and correctly report that D >>>>>     specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>
of N steps.
Without skipping M steps of a halting program.
THAT IS WRONG. IT IS MAKING SURE TO SKIP ALL THE STEPS AFTER
H correctly determines that its simulated D would never
stop running unless aborted
I spent two years carefully composing the above before I even
asked professor Sipser to review it.
DDD is correctly emulated by HHH until HHH sees the same
never ending pattern that anyone else can see.
The never ending pattern is there only in your dreams. The HHH that
halts after two cycles has a halting pattern.
In order for DDD correctly emulated by HHH to halt
DDD correctly emulated must reach its emulated "ret"
instruction. This <is> impossible.
Indeed! HHH cannot possibly simulate itself correctly.
You are a damned liar about how correct emulation is defined.
On 8/2/2024 5:19 AM, Mikko wrote:
On 2024-08-01 16:32:23 +0000, olcott said:
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
    If simulating halt decider H correctly simulates its input D
    until H correctly determines that its simulated D would never
    stop running unless aborted then
    H can abort its simulation of D and correctly report that D
    specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
I spent two years carefully composing the above before I even
asked professor Sipser to review it.
DDD is correctly emulated by HHH until HHH sees the same
never ending pattern that anyone else can see.
Maybe HHH really sees a never ending pattern but that pattern is not
contained in the behaviour specified by DDD and therefore not relevant.
When DDD correctly emulated by HHH keep repeating
its first four instructions because it calls HHH(DDD)
this does prove that DDD cannot possibly reach its
own "ret" instruction and halt, thus DDD correctly
emulated by HHH <is> non-halting even when it stops
running.
On 8/2/2024 5:12 AM, Mikko wrote:
On 2024-08-01 13:29:24 +0000, olcott said:
*Here is the full trace where nothing is hidden*
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
On page 36 of that "trace"
  [0000128c][0010379f][00000018] e8e6f4ffff call 00000777
is not followed by the trace of 00000777. Instead the trace continues
with the next instruction after the return without any comment about
the omission. Meaning of 00000777 is not told.
The bottom line has always been (for three years now) that the
fact that the next lines of DDD, (and DD) have always been the
next lines that a correct x86 emulator would correctly emulate
proves that HHH (and HH) did emulate these lines correctly
*EVEN IF IT DID THIS BY WILD GUESS*
Because of this all of the requests for a full execution trace
have never been more than sadistic trollish head games.
On 02/08/2024 11:12, Mikko wrote:
On 2024-08-01 13:29:24 +0000, olcott said:
On 8/1/2024 8:12 AM, Fred. Zwarts wrote:
Op 01.aug.2024 om 14:20 schreef olcott:
On 8/1/2024 3:10 AM, Fred. Zwarts wrote:
Op 31.jul.2024 om 23:23 schreef olcott:
On 7/31/2024 3:01 PM, Fred. Zwarts wrote:
Op 31.jul.2024 om 17:14 schreef olcott:
On 7/31/2024 3:44 AM, Fred. Zwarts wrote:
Op 31.jul.2024 om 06:09 schreef olcott:This algorithm is used by all the simulating termination analyzers: >>>>>>>>> <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>>>>>> Â Â Â Â *If simulating halt decider H correctly simulates its input D*
  machine  stack    stack    machine   assembly >>>>>>>>>>>   address  address  data     code      language
  ======== ======== ======== ========= ============= >>>>>>>>>>> [00002192][00103820][00000000] 55        push ebp >>>>>>>>>>> [00002193][00103820][00000000] 8bec      mov ebp,esp >>>>>>>>>>> [00002195][0010381c][00002172] 6872210000 push 00002172 ; push DDD >>>>>>>>>>> [0000219a][00103818][0000219f] e833f4ffff call 000015d2 ; call HHH(DDD)
New slave_stack at:1038c4
We don't show any of HHH and show the execution trace of >>>>>>>>>>> of just DDD assuming that HHH is an x86 emulator.
This assumption is incorrect if it means that HHH is an unconditional
simulator that does not abort.
    *until H correctly determines that its simulated D would never*
    *stop running unless aborted* then
    H can abort its simulation of D and correctly report that D >>>>>>>>>     specifies a non-halting sequence of configurations. >>>>>>>>> </MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
So, Sipser only agreed to a correct simulation, not with an incorrect >>>>>>>> simulation that violates the semantics of the x86 language by skipping >>>>>>>> the last few instructions of a halting program.
int DD()
{
  int Halt_Status = HHH(DD);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
int main()
{
  HHH(DD);
}
DD correctly emulated by HHH cannot possibly reach its own
second line. I switched to DDD correctly emulated by HHH
But it has been proven that no such HHH exists that simulates itself >>>>>> correctly. So, talking about a correct simulation by HHH is vacuous >>>>>> word salad.
because only C experts understood the above example and we
never had any of those here.
There are many C experts that looked at it, but you only got critic, >>>>>> because you keep hiding important properties of HHH, which made the >>>>>> conclusion impossible.
The following is all that is needed for 100% complete proof
that HHH did emulate DDD correctly according to the semantics
of the x86 language and did emulate itself emulating DDD
according to these same semantics.
You are repeating the same false claim with out any self-reflection. It >>>> has been pointed out that there are many errors in this proof.
Why repeating such errors?
The trace stops and hides what happens when 000015d2 is called.
_DDD()
[00002172] 55        push ebp     ; housekeeping
[00002173] 8bec      mov ebp,esp  ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404Â Â Â Â add esp,+04
[00002182] 5d        pop ebp
[00002183] c3Â Â Â Â Â Â Â Â ret
Size in bytes:(0018) [00002183]
Begin Local Halt Decider Simulation  Execution Trace Stored at:1138cc >>>>> [00002172][001138bc][001138c0] 55        push ebp     ; housekeeping
[00002173][001138bc][001138c0] 8bec      mov ebp,esp  ; housekeeping
[00002175][001138b8][00002172] 6872210000 push 00002172 ; push DDD
[0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD) >>>>
Olcott is hiding the conditional branch instructions in the recursion. >>>>
*Here is the full trace where nothing is hidden*
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
On page 36 of that "trace"
  [0000128c][0010379f][00000018] e8e6f4ffff call 00000777
is not followed by the trace of 00000777. Instead the trace continues
with the next instruction after the return without any comment about
the omission. Meaning of 00000777 is not told.
777 is the address of Allocate, which is one of PO's "primative ops"
within his "computing model". (Similar to his DebugStep().)
On 8/2/24 6:23 PM, Mike Terry wrote:
On 02/08/2024 19:25, Richard Damon wrote:
On 8/2/24 1:39 PM, Mike Terry wrote:
On 02/08/2024 11:12, Mikko wrote:
On 2024-08-01 13:29:24 +0000, olcott said:
On 8/1/2024 8:12 AM, Fred. Zwarts wrote:
Op 01.aug.2024 om 14:20 schreef olcott:
On 8/1/2024 3:10 AM, Fred. Zwarts wrote:
Op 31.jul.2024 om 23:23 schreef olcott:
On 7/31/2024 3:01 PM, Fred. Zwarts wrote:
Op 31.jul.2024 om 17:14 schreef olcott:
On 7/31/2024 3:44 AM, Fred. Zwarts wrote:
Op 31.jul.2024 om 06:09 schreef olcott:This algorithm is used by all the simulating termination analyzers:
  machine  stack    stack    machine   assembly
  address  address  data     code      language
  ======== ======== ======== ========= ============= >>>>>>>>>>>>>> [00002192][00103820][00000000] 55        push ebp >>>>>>>>>>>>>> [00002193][00103820][00000000] 8bec      mov ebp,esp >>>>>>>>>>>>>> [00002195][0010381c][00002172] 6872210000 push 00002172 ; push DDD
[0000219a][00103818][0000219f] e833f4ffff call 000015d2 ; call HHH(DDD)
New slave_stack at:1038c4
We don't show any of HHH and show the execution trace of >>>>>>>>>>>>>> of just DDD assuming that HHH is an x86 emulator.
This assumption is incorrect if it means that HHH is an unconditional
simulator that does not abort.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
    *If simulating halt decider H correctly simulates its input D*
    *until H correctly determines that its simulated D would never*
    *stop running unless aborted* then
    H can abort its simulation of D and correctly report that D
    specifies a non-halting sequence of configurations. >>>>>>>>>>>> </MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
So, Sipser only agreed to a correct simulation, not with an incorrect
simulation that violates the semantics of the x86 language by skipping
the last few instructions of a halting program.
int DD()
{
  int Halt_Status = HHH(DD);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
int main()
{
  HHH(DD);
}
DD correctly emulated by HHH cannot possibly reach its own >>>>>>>>>> second line. I switched to DDD correctly emulated by HHH
But it has been proven that no such HHH exists that simulates itself >>>>>>>>> correctly. So, talking about a correct simulation by HHH is vacuous >>>>>>>>> word salad.
because only C experts understood the above example and we >>>>>>>>>> never had any of those here.
There are many C experts that looked at it, but you only got critic, >>>>>>>>> because you keep hiding important properties of HHH, which made the >>>>>>>>> conclusion impossible.
The following is all that is needed for 100% complete proof
that HHH did emulate DDD correctly according to the semantics
of the x86 language and did emulate itself emulating DDD
according to these same semantics.
You are repeating the same false claim with out any self-reflection. It >>>>>>> has been pointed out that there are many errors in this proof.
Why repeating such errors?
_DDD()
[00002172] 55        push ebp     ; housekeeping >>>>>>>> [00002173] 8bec      mov ebp,esp  ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404Â Â Â Â add esp,+04
[00002182] 5d        pop ebp
[00002183] c3Â Â Â Â Â Â Â Â ret
Size in bytes:(0018) [00002183]
Begin Local Halt Decider Simulation  Execution Trace Stored at:1138cc
[00002172][001138bc][001138c0] 55        push ebp     ; housekeeping
[00002173][001138bc][001138c0] 8bec      mov ebp,esp  ; housekeeping
[00002175][001138b8][00002172] 6872210000 push 00002172 ; push DDD >>>>>>>> [0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)
The trace stops and hides what happens when 000015d2 is called.
Olcott is hiding the conditional branch instructions in the recursion. >>>>>>>
*Here is the full trace where nothing is hidden*
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
On page 36 of that "trace"
   [0000128c][0010379f][00000018] e8e6f4ffff call 00000777
is not followed by the trace of 00000777. Instead the trace continues >>>>> with the next instruction after the return without any comment about >>>>> the omission. Meaning of 00000777 is not told.
777 is the address of Allocate, which is one of PO's "primative ops"
within his "computing model". (Similar to his DebugStep().)
It is implemented inside x86utm.exe (his COFF obj code runner), not in >>>> the user code DDD/HHH/etc. in the obj file, and so we would not expect >>>> to see any trace entries for its internals. When the op concludes, rax >>>> has the address of the allocated memory, which is consistent with how a >>>> normal function would have returned the address.
You can say correctly that PO has not explained this, but then he
provided the full trace under protest, so it's understandable that he
has not previously explained everything in it. I'm surprised that his >>>> response to your post was both to ignore the question and accuse you of >>>> playing sadistic head games, as the question was perfectly sensible.
You can look up the 777 address in the listing at the start of the
trace and it's there along with a bunch of other routines which appear >>>> to just return without doing anything - those are all PO's primitive
ops. If you feel a need to understand exactly what they do, you'll
need to check his source code! (Although for Allocate there is no big >>>> surprise...)
So your observation isn't really a problem beyond not being properly
explained. An actual problem seen in his trace data is that the
simulation of DDD does not track the behaviour of the unsimulated DDD. >>>> I.e. his simulation is incorrect. (PO knows about that but claims it >>>> doesn't matter, although on other occasions he still claims the
simulation is correct.)
Mike.
But the bigger error that totally negates this trace is if you at where
it begins, it is at program address 00002197, which just the page
before is shown to be the address of _main.
Since HHH was not given the address of main to start with, this can not
be the trace that HHH itself is generating and looking at, but is
instead the trace of the running of that top level HHH.
Well, all PO's trace logs start with main! Something has to set up the
required computation [aka the required TM + input tape]. That could be
HHH(DDD), or maybe DDD() or whatever. PO might have done this through
extra invocation arguments to x86utm.exe, and then there would have
been no need to code a main() in his halt7.c user code file. But that
would be decidedly fiddly, so having a fixed entry function main() is
an ok convenience I'd say. The main() is not really part of his
computation model, but x86utm traces the lot.
Normally when PO gives code snippets, he includes the main() routine.
In this case it is main calling HHH(DDD), so HHH as you say is the
outer level HHH. (Later on in the trace we see simulated HHH
entries...)
Since that shows the trace isn't what he claims it is, nothing it says
means anything for his argument.
I can't see what PO claims the trace to be. That trace was taken and
published some weeks ago, and doesn't match up exactly with todays
partial trace - e.g. the addresses of HHH/DDD don't match and so on.Â
If it's just wrong through being out of date, or because it has the
main() trace on the front, that's not the worst of crimes...
I see upthread that someone pointed out that the filtered trace
"..stops and hides what happens when 000015d2 is called."Â Well, the
full trace does show the instructions of HHH being executed [even if
the data is a bit out of date], and of course there are loads of
conditional branches... so everyone should be happy! :)
In fact, the way the trace is produced, it is clear that the tracing
code doesn't care about what level of simulation it is working but
calls to "DebugStep" just inject the data they trace as part of the
code that is being traced, which isn't actually what is happening in
the processor.
That's correct. The full trace proceeds showing HHH executing its code
as we would expect, and after some time HHH (actually a routine called
by HHH) invokes a DebugStep op. We can see that the DebugStep op
stepped HHH's simulation one instruction, which also appears in trace.
Here is where that happens:
,,,
[000011eb][00103783][00103863] 8b4d1c mov ecx,[ebp+1c]
[000011ee][00103783][00103863] 8b11 mov edx,[ecx]
[000011f0][0010377f][00103827] 52 push edx
[000011f1][0010377f][00103827] e8b1f5ffff call 000007a7Â Â Â Â <=== DebugStep
[00002177][00113897][0011389b] 55 push ebp                 <===
simulated instruction
[000011f6][0010378b][90909090] 83c40c add esp,+0c          <=== next
instructin after DebugStep
[000011f9][0010378b][90909090] e8e9f5ffff call 000007e7
...
The "push ebp" above is the first simulated instruction, and just
appears in the trace straight after the call to DebugStep. [Note the
apparent discontinuities in IP address and ESP (cols 1&2 resp.)Â Yeah I
know, /why isn't there a simulation level column/ ?]
We could say that the trace as shown is a log of all the instructions
x86utm "executes" in succession, so it is a merge of entries from all
simulation levels - certainly it's not the x86 "processor trace" it
might be taken to be.
Note - the "push ebp" instruction is the first simulated instruction of
DDD(), which at least is the instruction we would expect it to be. In
PO's normal "filtered" log output, all the other instructions above
wouldn't appear as they're not from DDD.
Of course these traces don't support PO's overall case he is claiming,
because the (various) logs show that DDD halts, and that HHH(DDD)
reports DDD as non-halting, exactly as Linz/Sipser argue. Er, that's
about it!
Whether it supports some minutia of what PO is currently arguing about
- you'd have to explain to me exactly what he is claiming! (um, Please
don't!)
This seems to be part of the source for his confusion, and the tool he
uses to try to spread his lies.
such results should, at most, be inserted as a comment about what the
results computed as meta-logic of the code just emulated did.
But of course, noting that this second layer is just meta-results, and
that the original emulator always had the option of stopping its
emulation ruins his argument that the recursion is necessarily infinite.
It's hard to pin down confusion sources. I agree PO doesn't need
x86utm logs to argue his case, and including them doesn't /prove/
anything, especially when he admits the simulated code uses mutable
static data to modify the behaviour of the simulation so that it does
not match the unsimulated (outer) computation.
I think PO views x86utm as some kind of "ultra authority" he can appeal
to, to avoid having to actually prove his claims. [Which is funny,
because the logs don't support his claims, but for some reason that
passes him by...]
Mike.
The problem is that he calls them traces of the emulation that HHH
does, and it should never see that main, as it isn't part of what he
has defined as the input.
It is clear that this output is the output generated by x86utm, NOT
just his HHH. As such, it is not the output he claims.
It seems clear that he can't figure out how to get the x86UTM program
to create just the trace of what HHH sees,
He *CLAIMS* that HHH actually works on the full trace of DDD going into
HHH, but apparently there is no way for him to show such a trace.
On 02/08/2024 23:42, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
Of course these traces don't support PO's overall case he is claiming,PO certainly used to claim that false (non-halting) is the correct
because the (various) logs show that DDD halts, and that HHH(DDD) reports >>> DDD as non-halting, exactly as Linz/Sipser argue. Er, that's about it!
result "even though DDD halts" (I've edited the quote to reflect a name
change). Unless he's changed this position, the traces do support his
claim that what everyone else calls the wrong answer is actually the
right one.
So, in your opinion, what do you believe is PO's criterion for "correct result", exactly? It would be handy if you can give a proper mathematical definition so nobody will have any doubt what it is. Hey, I know you're
more than capable of getting a definition right, so let's have that definition!
Definition: A TM P given input I is said to "halt" iff ?????
or whatever...
It's easy enough to say "PO has his own criterion for halting, which is materially different from the HP condition, and so we all agree PO is
correct by his own criterion, but that does not say anything about the HP theorem because it is different from the HP definition".
But is that /really/ something PO agrees with?
I don't think so somehow,
because I'm pretty sure PO believes his claim "refutes" the HP result.
He
wouldn't say that if he freely acknowleded that he had invented a
completely different definition for halting.
Also, for what you're saying
to be the right way of looking at things, PO would have to admit that the
HP proof with its standard definition of halting is valid, and that there
is nothing wrong with the Linz proof, other than it not applying to his own favourite PO-halting definition.
I.e. I think your way of looking at it is a bit "too easy" - but I'd be
happy to be convinced! Personally I suspect PO has no such "new and
different definition" and that anything along those lines PO is thinking of will be quite incoherent. No doubt you could make some definition that is
at least coherent but we have to ask ourselves - is that definition
/really/ what PO is thinking???
Nowadays, I think PO's position is more that:
- yes, DDD() halts when run directly
- but DDD() when it runs inside HHH simulator /really/ does not halt, in some kind of
sense that it /really/ has infinite recursion which would never end
however far it was simulated (because it "exhibits" infinite recursion in some way)
- and yes, DDD() /does/ halt when simulated within UTM(DDD),
- but the behaviour of DDD depends on who is simulating it. It terminates when
UTM simulates it, but doesn't terminate when HHH simulates it, due to some
kind of pathelogical relationship specifically with HHH. This difference in
simulation is /more/ than one simulator aborting earlier than the other...
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
On 02/08/2024 23:42, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
Of course these traces don't support PO's overall case he is claiming, >>>> because the (various) logs show that DDD halts, and that HHH(DDD) reports >>>> DDD as non-halting, exactly as Linz/Sipser argue. Er, that's about it!PO certainly used to claim that false (non-halting) is the correct
result "even though DDD halts" (I've edited the quote to reflect a name
change). Unless he's changed this position, the traces do support his
claim that what everyone else calls the wrong answer is actually the
right one.
So, in your opinion, what do you believe is PO's criterion for "correct
result", exactly? It would be handy if you can give a proper mathematical >> definition so nobody will have any doubt what it is. Hey, I know you're
more than capable of getting a definition right, so let's have that
definition!
You are joking right?
PO has no idea what he's talking about. I mean that more literally than
you might think. The starting point is a gut feeling ("If God can not
solve the Halting Problem, then there is something wrong with the
problem") shored up by a basic axiom
produces a endless sequence of nonsense statements, like
"the fact that a computation halts does not entail that it is a
halting computation" [May 2021]
"The fact [that] a computation stops running does not prove that it
halts" [Apr 2021]
and
"The same halt decider can have different behavior on the same input"
[Jan 2021]
Definition: A TM P given input I is said to "halt" iff ?????
or whatever...
Do you really think I can fathom what PO considers to be the "correct
result" in formal terms? He certainly doesn't know (in general) and I
can't even hazard a guess.
It's easy enough to say "PO has his own criterion for halting, which is
materially different from the HP condition, and so we all agree PO is
correct by his own criterion, but that does not say anything about the HP
theorem because it is different from the HP definition".
He's been very, very clear about this:
"A non-halting computation is every computation that never halts
unless its simulation is aborted. This maps to every element of the
conventional halting problem set of non-halting computations and a few
more."
There is something called the "conventional halting problem" and then
there is there is the PO-halting problem.
He's even explained in detail at least one of these "few more" cases.
He sketched the simulator and explained that false (non-halting) is
correct because of what would happen if line 15 (the check for "needs to
be aborted") were commented out. The "few more" cases are halting computations that would not halt if the code where a bit different -- if
the "decider" did not stop the simulation.
That was in 2020. The last four years have all been about fleshing out
this sketch of a decider for this "other" halting condition. I am
staggered that people are still talking about it. Until he repudiates
the claim that false is the correct answer for some halting
computations, there is nothing more to discuss.
But is that /really/ something PO agrees with?
Does he really agree with what he said? Does he agree that there is
"the conventional halting problem" and also his own non-halting that
includes "a few more" computations? Does he agree with himself when he stated, in Oct 2021, that "Yes that is the correct answer even though
P(P) halts" when asked "do you still assert that H(P,P) == false is the "correct" answer even though P(P) halts?"?
I don't think so somehow,
because I'm pretty sure PO believes his claim "refutes" the HP result.
I am sure he still agrees with what he has said, and I am equally sure
he still thinks he has refuted a theorem about something else. He, literally, has no idea what he is talking about.
He
wouldn't say that if he freely acknowleded that he had invented a
completely different definition for halting.
Why do you say that? Are you assuming he is sane? Remember he has
published a website intended to bring new scripture to the world (https://the-pete.org/) and has asserted in a court of law (through
lawyers, maybe) that he is God.
Also, for what you're saying
to be the right way of looking at things, PO would have to admit that the
HP proof with its standard definition of halting is valid, and that there
is nothing wrong with the Linz proof, other than it not applying to his own >> favourite PO-halting definition.
Only if you assume his mind functions like yours or mine. Take this
quote on the point you make example:
"My current proof simply shows exactly how the exact Peter Linz H
would correctly decide not halting on the exact Peter Linz Ĥ.
This definition of halting circumvents the pathological self-reference
error for every simulating halt decider:
An input is decided to be halting only if its simulation never needs
to be stopped by any simulating halt decider anywhere in its entire
invocation chain." [May 2021]
He clearly thinks that having a different definition of halting
invalidates Linz's proof.
I.e. I think your way of looking at it is a bit "too easy" - but I'd be
happy to be convinced! Personally I suspect PO has no such "new and
different definition" and that anything along those lines PO is thinking of >> will be quite incoherent. No doubt you could make some definition that is >> at least coherent but we have to ask ourselves - is that definition
/really/ what PO is thinking???
There is no doubt that he has a different definition. How could he have
been more clear? There is the conventional halting problem and then
there is what he is considering that includes "a few more" cases. He
clearly tells us that false is the correct answer for some halting computations. He gives a (flabby) definition of PO-halting and states
that it "circumvents" the proof.
Nowadays, I think PO's position is more that:
- yes, DDD() halts when run directly
- but DDD() when it runs inside HHH simulator /really/ does not halt, in some kind of
sense that it /really/ has infinite recursion which would never end
however far it was simulated (because it "exhibits" infinite recursion in some way)
- and yes, DDD() /does/ halt when simulated within UTM(DDD),
- but the behaviour of DDD depends on who is simulating it. It terminates when
UTM simulates it, but doesn't terminate when HHH simulates it, due to some
kind of pathelogical relationship specifically with HHH. This difference in
simulation is /more/ than one simulator aborting earlier than the other...
I fear you have got sucked into the PO tar-pit. Until he categorically repudiates the claim that H(P,P) == false is the correct answer even
though P(P) halts, I would say that there is nothing more to say.
Obviously his position "evolves" because he has to keep people talking
to him (has is a narcissist and needs the attention). But cranks are
never wrong so he is stuck with what he's said in the past. All of the
last four years has been about layering piles of detail on the basic
notion that if the decider were not to halt the computation, the result
would be a non-halting computation so saying "does not halt" is correct
even though the computation halts.
On 8/4/2024 9:33 PM, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
On 02/08/2024 23:42, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
Of course these traces don't support PO's overall case he is claiming, >>>>> because the (various) logs show that DDD halts, and that HHH(DDD)result "even though DDD halts" (I've edited the quote to reflect a name >>>> change). Unless he's changed this position, the traces do support his >>>> claim that what everyone else calls the wrong answer is actually the
reports
DDD as non-halting, exactly as Linz/Sipser argue. Er, that's about it! >>>> PO certainly used to claim that false (non-halting) is the correct
right one.
So, in your opinion, what do you believe is PO's criterion for "correct
result", exactly? It would be handy if you can give a proper
mathematical
definition so nobody will have any doubt what it is. Hey, I know you're
more than capable of getting a definition right, so let's have that
definition!
You are joking right?
PO has no idea what he's talking about. I mean that more literally than
you might think. The starting point is a gut feeling ("If God can not
solve the Halting Problem, then there is something wrong with the
problem") shored up by a basic axiom
The equivalent paraphrase of this has always been:
The inability to do the logically impossible places
no actual limit on computation.
https://www.cs.toronto.edu/~hehner/OSS.pdf
Professor Hehner and I perfectly agree on this
and he agrees that it is an accurate summary
of the result of his above paper.
*I humbly apologize for my harsh words to you*
A stranger that I met last night convinced me that I
should love my enemies. I have no enemies yet can refrain
from ever using harsh words towards my adversaries.
-- that PO is never wrong. This
Never meant that at all ever. I have always been
fully aware that I make many mistakes every day.
produces a endless sequence of nonsense statements, like
  "the fact that a computation halts does not entail that it is a
  halting computation" [May 2021]
  "The fact [that] a computation stops running does not prove that it
  halts" [Apr 2021]
and
  "The same halt decider can have different behavior on the same input" >>   [Jan 2021]
That does sound stupid.
*As far as effective communication goes I am somewhat of a moron*
void DDD()
{
 HHH(DDD);
 return;
}
*Here is a better way to phrase what I have been saying*
DDD correctly emulated by any HHH that can possibly
exist never reaches its "return" instruction halt state.
Definition:Â A TM P given input I is said to "halt" iff ?????
             or whatever...
Do you really think I can fathom what PO considers to be the "correct
result" in formal terms? He certainly doesn't know (in general) and I
can't even hazard a guess.
HHH computes the mapping from the finite string of the x86
machine code of DDD to to the above specified behavior.
It's easy enough to say "PO has his own criterion for halting, which is
materially different from the HP condition, and so we all agree PO is
correct by his own criterion, but that does not say anything about
the HP
theorem because it is different from the HP definition".
He's been very, very clear about this:
  "A non-halting computation is every computation that never halts
  unless its simulation is aborted. This maps to every element of the >>   conventional halting problem set of non-halting computations and a few >>   more."
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
   If *simulating halt decider H correctly simulates its input D*
   *until H correctly determines that its simulated D would never*
   *stop running unless aborted* then
   H can abort its simulation of D and correctly report that D
   specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
You have agreed that the first part of that has been met showing
that your understanding has always been better than anyone else.
There is something called the "conventional halting problem" and then
there is there is the PO-halting problem.
The conventional halting problem has the implied false assumption
that a decider must report on the behavior of the computation that
contains itself rather than computing the mapping from its finite
string input to the behavior that this finite string specifies.
He's even explained in detail at least one of these "few more" cases.
He sketched the simulator and explained that false (non-halting) is
correct because of what would happen if line 15 (the check for "needs to
be aborted") were commented out. The "few more" cases are halting
computations that would not halt if the code where a bit different -- if
the "decider" did not stop the simulation.
My above example is as simple as I can possibly make it.
That is a far cry from the x86 assembly language trace that
I discussed extensively with the former editor in chief of
CASM Professor Moshe Vardi. He eventually gave up because
he did not understand the x86 language.
That was in 2020. The last four years have all been about fleshing out
this sketch of a decider for this "other" halting condition. I am
staggered that people are still talking about it. Until he repudiates
the claim that false is the correct answer for some halting
computations, there is nothing more to discuss.
I explained it much better above in terms of DDD emulated by HHH.
But is that /really/ something PO agrees with?
Does he really agree with what he said? Does he agree that there is
"the conventional halting problem" and also his own non-halting that
includes "a few more" computations? Does he agree with himself when he
stated, in Oct 2021, that "Yes that is the correct answer even though
P(P) halts" when asked "do you still assert that H(P,P) == false is the
"correct" answer even though P(P) halts?"?
I don't think so somehow,
because I'm pretty sure PO believes his claim "refutes" the HP result.
I am sure he still agrees with what he has said, and I am equally sure
he still thinks he has refuted a theorem about something else. He,
literally, has no idea what he is talking about.
You are the only one that understood that the first half of the
Sipser approved criteria has been met.
He
wouldn't say that if he freely acknowleded that he had invented a
completely different definition for halting.
Why do you say that? Are you assuming he is sane? Remember he has
published a website intended to bring new scripture to the world
(https://the-pete.org/) and has asserted in a court of law (through
lawyers, maybe) that he is God.
That has no bearing on the points that I made above.
Also, for what you're saying
to be the right way of looking at things, PO would have to admit that
the
HP proof with its standard definition of halting is valid, and that
there
is nothing wrong with the Linz proof, other than it not applying to
his own
favourite PO-halting definition.
Only if you assume his mind functions like yours or mine. Take this
quote on the point you make example:
  "My current proof simply shows exactly how the exact Peter Linz H
  would correctly decide not halting on the exact Peter Linz Ĥ.
  This definition of halting circumvents the pathological self-reference >>   error for every simulating halt decider:
  An input is decided to be halting only if its simulation never needs
  to be stopped by any simulating halt decider anywhere in its entire
  invocation chain." [May 2021]
This last part is correct and Professor Sipser agreed that
it is correct.
That you have not yet understood the second halt of the Sipser
approved criteria yet do understand the first part puts you
ahead of everyone else.
He clearly thinks that having a different definition of halting
invalidates Linz's proof.
I.e. I think your way of looking at it is a bit "too easy" - but I'd be
happy to be convinced! Personally I suspect PO has no such "new and
different definition" and that anything along those lines PO is
thinking of
will be quite incoherent. No doubt you could make some definition
that is
at least coherent but we have to ask ourselves - is that definition
/really/ what PO is thinking???
There is no doubt that he has a different definition. How could he have
been more clear? There is the conventional halting problem and then
there is what he is considering that includes "a few more" cases. He
clearly tells us that false is the correct answer for some halting
computations. He gives a (flabby) definition of PO-halting and states
that it "circumvents" the proof.
It is an empirically verified fact that DDD correctly emulated
by any HHH that can possibly exist cannot possibly reach its
"return" instruction halt state. Every expert in C know this.
Nowadays, I think PO's position is more that:
-Â yes, DDD() halts when run directly
-Â but DDD() when it runs inside HHH simulator /really/ does not
halt, in some kind of
   sense that it /really/ has infinite recursion which would never end >>>    however far it was simulated (because it "exhibits" infinite
recursion in some way)
I just provided the details of that.
-Â and yes, DDD() /does/ halt when simulated within UTM(DDD),
- but the behaviour of DDD depends on who is simulating it. It
terminates when
   UTM simulates it, but doesn't terminate when HHH simulates it,
due to some
   kind of pathelogical relationship specifically with HHH. This
difference in
   simulation is /more/ than one simulator aborting earlier than the >>> other...
When the halting problem is understood to be that
no halt decider can provide the correct halt status
of any input defined to do the opposite of whatever
value it returns this is impossible to solve.
This also requires the false assumption that a halt
decider must report on the computation that itself
is contained within rather than compute the mapping
from its input finite string.
I fear you have got sucked into the PO tar-pit. Until he categorically
repudiates the claim that H(P,P) == false is the correct answer even
though P(P) halts, I would say that there is nothing more to say.
It is an empirically verified fact that DDD correctly emulated
by any HHH that can possibly exist cannot possibly reach its
"return" instruction halt state.
Every expert in C knows this.
Four experts affirmed it, two with MSCS.
Everyone here denies that.
Obviously his position "evolves" because he has to keep people talking
to him (has is a narcissist and needs the attention). But cranks are
never wrong so he is stuck with what he's said in the past. All of the
last four years has been about layering piles of detail on the basic
notion that if the decider were not to halt the computation, the result
would be a non-halting computation so saying "does not halt" is correct
even though the computation halts.
The issue that I have know that I am correct the whole
time and terribly awful at explaining this clearly.
On 02/08/2024 23:42, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
Of course these traces don't support PO's overall case he is claiming,
because the (various) logs show that DDD halts, and that HHH(DDD)
reports
DDD as non-halting, exactly as Linz/Sipser argue. Er, that's about it!
PO certainly used to claim that false (non-halting) is the correct
result "even though DDD halts" (I've edited the quote to reflect a name
change). Unless he's changed this position, the traces do support his
claim that what everyone else calls the wrong answer is actually the
right one.
So, in your opinion, what do you believe is PO's criterion for "correct result", exactly? It would be handy if you can give a proper
mathematical definition so nobody will have any doubt what it is. Hey, I
know you're more than capable of getting a definition right, so let's
have that definition!
Definition:Â A TM P given input I is said to "halt" iff ?????
            or whatever...
It's easy enough to say "PO has his own criterion for halting, which is materially different from the HP condition, and so we all agree PO is
correct by his own criterion,
but that does not say anything about the
HP theorem because it is different from the HP definition".
But is that /really/ something PO agrees with? I don't think so
somehow, because I'm pretty sure PO believes his claim "refutes" the HP result. He wouldn't say that if he freely acknowleded that he had
invented a completely different definition for halting. Also, for what you're saying to be the right way of looking at things, PO would have to admit that the HP proof with its standard definition of halting is
valid, and that there is nothing wrong with the Linz proof, other than
it not applying to his own favourite PO-halting definition.
I.e. I think your way of looking at it is a bit "too easy" - but I'd be
happy to be convinced! Personally I suspect PO has no such "new and
different definition" and that anything along those lines PO is thinking
of will be quite incoherent. No doubt you could make some definition
that is at least coherent but we have to ask ourselves - is that
definition /really/ what PO is thinking???
Nowadays, I think PO's position is more that:
-Â yes, DDD() halts when run directly
-Â but DDD() when it runs inside HHH simulator /really/ does not halt,
in some kind of
  sense that it /really/ has infinite recursion which would never end
  however far it was simulated (because it "exhibits" infinite
recursion in some way)
-Â and yes, DDD() /does/ halt when simulated within UTM(DDD),
- but the behaviour of DDD depends on who is simulating it. It
terminates when
  UTM simulates it, but doesn't terminate when HHH simulates it, due
to some
  kind of pathelogical relationship specifically with HHH. This difference in
  simulation is /more/ than one simulator aborting earlier than the other...
Mike.
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
On 02/08/2024 23:42, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
Of course these traces don't support PO's overall case he is claiming, >>>> because the (various) logs show that DDD halts, and that HHH(DDD) reports >>>> DDD as non-halting, exactly as Linz/Sipser argue. Er, that's about it!PO certainly used to claim that false (non-halting) is the correct
result "even though DDD halts" (I've edited the quote to reflect a name
change). Unless he's changed this position, the traces do support his
claim that what everyone else calls the wrong answer is actually the
right one.
So, in your opinion, what do you believe is PO's criterion for "correct
result", exactly? It would be handy if you can give a proper mathematical >> definition so nobody will have any doubt what it is. Hey, I know you're
more than capable of getting a definition right, so let's have that
definition!
You are joking right?
PO has no idea what he's talking about. I mean that more literally than
you might think. The starting point is a gut feeling ("If God can not
solve the Halting Problem, then there is something wrong with the
problem") shored up by a basic axiom -- that PO is never wrong. This produces a endless sequence of nonsense statements, like
"the fact that a computation halts does not entail that it is a
halting computation" [May 2021]
"The fact [that] a computation stops running does not prove that it
halts" [Apr 2021]
and
"The same halt decider can have different behavior on the same input"
[Jan 2021]
Definition: A TM P given input I is said to "halt" iff ?????
or whatever...
Do you really think I can fathom what PO considers to be the "correct
result" in formal terms? He certainly doesn't know (in general) and I
can't even hazard a guess.
It's easy enough to say "PO has his own criterion for halting, which is
materially different from the HP condition, and so we all agree PO is
correct by his own criterion, but that does not say anything about the HP
theorem because it is different from the HP definition".
He's been very, very clear about this:
"A non-halting computation is every computation that never halts
unless its simulation is aborted. This maps to every element of the
conventional halting problem set of non-halting computations and a few
more."
There is something called the "conventional halting problem" and then
there is there is the PO-halting problem.
He's even explained in detail at least one of these "few more" cases.
He sketched the simulator and explained that false (non-halting) is
correct because of what would happen if line 15 (the check for "needs to
be aborted") were commented out. The "few more" cases are halting computations that would not halt if the code where a bit different -- if
the "decider" did not stop the simulation.
That was in 2020. The last four years have all been about fleshing out
this sketch of a decider for this "other" halting condition. I am
staggered that people are still talking about it. Until he repudiates
the claim that false is the correct answer for some halting
computations, there is nothing more to discuss.
But is that /really/ something PO agrees with?
Does he really agree with what he said? Does he agree that there is
"the conventional halting problem" and also his own non-halting that
includes "a few more" computations? Does he agree with himself when he stated, in Oct 2021, that "Yes that is the correct answer even though
P(P) halts" when asked "do you still assert that H(P,P) == false is the "correct" answer even though P(P) halts?"?
I don't think so somehow,
because I'm pretty sure PO believes his claim "refutes" the HP result.
I am sure he still agrees with what he has said, and I am equally sure
he still thinks he has refuted a theorem about something else. He, literally, has no idea what he is talking about.
He
wouldn't say that if he freely acknowleded that he had invented a
completely different definition for halting.
Why do you say that? Are you assuming he is sane? Remember he has
published a website intended to bring new scripture to the world (https://the-pete.org/) and has asserted in a court of law (through
lawyers, maybe) that he is God.
Also, for what you're saying
to be the right way of looking at things, PO would have to admit that the
HP proof with its standard definition of halting is valid, and that there
is nothing wrong with the Linz proof, other than it not applying to his own >> favourite PO-halting definition.
Only if you assume his mind functions like yours or mine. Take this
quote on the point you make example:
"My current proof simply shows exactly how the exact Peter Linz H
would correctly decide not halting on the exact Peter Linz Ĥ.
This definition of halting circumvents the pathological self-reference
error for every simulating halt decider:
An input is decided to be halting only if its simulation never needs
to be stopped by any simulating halt decider anywhere in its entire
invocation chain." [May 2021]
He clearly thinks that having a different definition of halting
invalidates Linz's proof.
I.e. I think your way of looking at it is a bit "too easy" - but I'd be
happy to be convinced! Personally I suspect PO has no such "new and
different definition" and that anything along those lines PO is thinking of >> will be quite incoherent. No doubt you could make some definition that is >> at least coherent but we have to ask ourselves - is that definition
/really/ what PO is thinking???
There is no doubt that he has a different definition. How could he have
been more clear? There is the conventional halting problem and then
there is what he is considering that includes "a few more" cases. He
clearly tells us that false is the correct answer for some halting computations. He gives a (flabby) definition of PO-halting and states
that it "circumvents" the proof.
Nowadays, I think PO's position is more that:
- yes, DDD() halts when run directly
- but DDD() when it runs inside HHH simulator /really/ does not halt, in some kind of
sense that it /really/ has infinite recursion which would never end
however far it was simulated (because it "exhibits" infinite recursion in some way)
- and yes, DDD() /does/ halt when simulated within UTM(DDD),
- but the behaviour of DDD depends on who is simulating it. It terminates when
UTM simulates it, but doesn't terminate when HHH simulates it, due to some
kind of pathelogical relationship specifically with HHH. This difference in
simulation is /more/ than one simulator aborting earlier than the other...
I fear you have got sucked into the PO tar-pit. Until he categorically repudiates the claim that H(P,P) == false is the correct answer even
though P(P) halts, I would say that there is nothing more to say.
Obviously his position "evolves" because he has to keep people talking
to him (has is a narcissist and needs the attention). But cranks are
never wrong so he is stuck with what he's said in the past. All of the
last four years has been about layering piles of detail on the basic
notion that if the decider were not to halt the computation, the result
would be a non-halting computation so saying "does not halt" is correct
even though the computation halts.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 166:55:39 |
| Calls: | 10,385 |
| Calls today: | 2 |
| Files: | 14,057 |
| Messages: | 6,416,529 |