Re: Defining a correct simulating halt decider --- Ridiculously stupid

On 9/11/2024 11:06 AM, Mike Terry wrote:

[Repost due to Giganews server problems. Sorry if post eventually appears multiple times...]
On 10/09/2024 12:50, Fred. Zwarts wrote:

Op 09.sep.2024 om 20:19 schreef olcott:

On 9/8/2024 9:53 AM, Mikko wrote:

On 2024-09-07 13:57:00 +0000, olcott said:
>

On 9/7/2024 3:29 AM, Mikko wrote:

On 2024-09-07 05:12:19 +0000, joes said:
>

Am Fri, 06 Sep 2024 06:42:48 -0500 schrieb olcott:

On 9/6/2024 6:19 AM, Mikko wrote:

On 2024-09-05 13:24:20 +0000, olcott said:

On 9/5/2024 2:34 AM, Mikko wrote:

On 2024-09-03 13:00:50 +0000, olcott said:

On 9/3/2024 5:25 AM, Mikko wrote:

On 2024-09-02 16:38:03 +0000, olcott said:
>

A halt decider is a Turing machine that computes the mapping from
its finite string input to the behavior that this finite string
specifies.

>
A halt decider needn't compute the full behaviour, only whether
that behaviour is finite or infinite.
>

New slave_stack at:1038c4 Begin Local Halt Decider Simulation

>

Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>
Hence  HHH(DDD)==0 is correct

>
Nice to see that you don't disagree with what said.
Unvortunately I can't agree with what you say.
HHH terminates,
os DDD obviously terminates, too. No valid

>
DDD emulated by HHH never reaches it final halt state.

>
If that iis true it means that HHH called by DDD does not return and
therefore is not a ceicder.

The directly executed HHH is a decider.

What does simulating it change about that?

>
If the simulation is incorrect it may change anything.
>

PATHOLOGICAL RELATIONSHIPS CHANGE BEHAVIOR
PATHOLOGICAL RELATIONSHIPS CHANGE BEHAVIOR
PATHOLOGICAL RELATIONSHIPS CHANGE BEHAVIOR
PATHOLOGICAL RELATIONSHIPS CHANGE BEHAVIOR
PATHOLOGICAL RELATIONSHIPS CHANGE BEHAVIOR

>
However, a correct simultation faithfully imitates the original
behaviour.
>

>
_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]
>
A correct emulation obeys the x86 machine code even
if this machine code catches the machine on fire.
>
It is impossible for an emulation of DDD by HHH to
reach machine address 00002183 AND YOU KNOW IT!!!
>

>
It seems olcott also knows that HHH fails to reach the machine address 00002183, because it stop the simulation too soon. A correct simulation by the unmodified world class simulator shows that it does reach machine address 00002183. Even HHH1 shows it. But HHH fails to machine address 00002183.
Why does olcott ignore this truth? The evidence is overwhelming.

 Because his HHH has correctly identified his "Infinite recursive simulation" pattern in the behaviour of DDD.  To PO, that means DDD is non-halting, EOD.
 PO is aware that the /full/ simulation of DDD() (e.g. as shown by HHH1 simulating) shows DDD terminating -

Ridiculously stupid to simply ignore that DDD calls
HHH(DDD) in recursive emulation and does not call HHH1
in recursive emulation.
I saw your identical twin brother Bill rob the liquor
store thus proving that you (John) robbed the liquor store.
This is true even though I could see that Bill has a
mole on his right cheek that you (John) do not have.

so how can it be that when HHH spots its infamous pattern, DDD is "exhibiting non-halting behaviour", despite its "actual" behaviour being halting PLAINLY VISIBLE IN THE SIMULATION TRACE FROM HHH1?   Hmmm.
 This is a dilemma for PO and he has no sensible answer to this.  It is demonstrated that DDD() halts (e.g. using HHH1 to simulate), and yet it is also "demonstrated" that DDD "exhibits non-halting behaviour" by matching his "non-halting" pattern (EOD).  The ONLY POSSIBILITY (in PO's mind) is that the behaviour must somehow be /different/ between HHH1 simulating DDD (=halts) and HHH simulating DDD (="exhibits non-halting behaviour").  It does not matter to PO that the traces show that the behaviour is EXACTLY THE SAME regardless of the simulator (..up to the point where one simulator chooses to abort of course..).  Even when the two traces are displayed for him side by side and match x86 instruction for x86 instruction, PO is not convinced.
 The more obvious explanation that PO is simply Wrong about his "Infinite recursive simulation" pattern never occurs to him, and yet he also never seriously attempts any proof that the rule is sound.  The only attempt I recall started by PO stipulating an axiom that said that when a trace satisfies the test conditions, it can never halt!  (Yeah, this despite the HHH1 trace output showing that the pattern matching [*] AND the simulated DDD proceding to halt some time later.  TBF that output may not have been published at that point...)
 This was the state of play 2 or 3 years ago, and absolutely nothing has progressed since then, other than the passing of 100000(?) posts arguing the same points over and over!
 Regards,
Mike.
 [*] the pattern occurs in HHH1's simulated DDD trace and is visible in the published output, although HHH1 was /not checking/ for that pattern due to miscodings on PO's part, which is why HHH1 did not abort the simulation, despite supposedly being a copy of HHH.
 

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