Path: ...!feeds.phibee-telecom.net!2.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: "Fred. Zwarts" <F.Zwarts@HetNet.nl>
Newsgroups: comp.theory
Subject: Re: Defining a correct simulating halt decider
Date: Sat, 7 Sep 2024 12:39:23 +0200
Organization: A noiseless patient Spider
Lines: 99
Message-ID: <vbhags$1aru4$6@dont-email.me>
References: <vb4plc$2tqeg$1@dont-email.me> <vb6o5t$3a95s$1@dont-email.me>
 <vb71a3$3b4ub$4@dont-email.me> <vbbmuc$8nbb$1@dont-email.me>
 <vbcbe4$bdtb$3@dont-email.me>
 <cb6a625f1737dafed130e2bdad14395d95566ba1@i2pn2.org>
 <vbcl61$d8p0$1@dont-email.me>
 <e097e72a4319eb72e8663d055aa54d69af610831@i2pn2.org>
 <vbcnjk$dr54$1@dont-email.me>
 <5d7b0659450f58aec28d4f49b1b59982cedfc694@i2pn2.org>
 <vbcp2d$e330$1@dont-email.me> <vbeho8$om7b$3@dont-email.me>
 <vbepjd$punj$5@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 07 Sep 2024 12:39:24 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="a1d6656c1a26d4db193354f7a3d64b24";
	logging-data="1404868"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/g5iqaHrAbATg5hQYtOUEk"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:kpXyD5kPAwGysAVsRODlZE7HlfY=
In-Reply-To: <vbepjd$punj$5@dont-email.me>
Content-Language: nl
Bytes: 6082

Op 06.sep.2024 om 13:38 schreef olcott:
> On 9/6/2024 4:24 AM, Fred. Zwarts wrote:
>> Op 05.sep.2024 om 19:17 schreef olcott:
>>> On 9/5/2024 11:56 AM, joes wrote:
>>>> Am Thu, 05 Sep 2024 11:52:04 -0500 schrieb olcott:
>>>>> On 9/5/2024 11:34 AM, joes wrote:
>>>>>> Am Thu, 05 Sep 2024 11:10:40 -0500 schrieb olcott:
>>>>>>> On 9/5/2024 10:57 AM, joes wrote:
>>>>>>>> Am Thu, 05 Sep 2024 08:24:20 -0500 schrieb olcott:
>>>>>>>>> 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:
>>>>>>
>>>>>>>>> Show the details of how DDD emulated by HHH reaches its own 
>>>>>>>>> machine
>>>>>>>>> address 0000217f.
>>>>>>>> By HHH returning, which we are guaranteed from its definition as a
>>>>>>>> decider.
>>>>>>> How the F--- Does the emulated HHH return?
>>>>>> I don’t know, you claim it’s a decider!
>>>>> You KEEP TRYING TO CHEAT by erasing the context !!!
>>>> It is very well known by this point.
>>>>
>>>>> DDD emulated by HHH CANNOT POSSIBLY reach its own machine address
>>>>> 0000217f.
>>>> Only HHH can’t simulate it.
>>>>
>>>>> The directly executed HHH correctly determines that its emulated DDD
>>>>> must be aborted because DDD keeps *THE EMULATED HHH* stuck in 
>>>>> recursive
>>>>> emulation.
>>>> Why doesn’t the simulated HHH abort?
>>>>
>>>
>>> The first HHH cannot wait for its HHH to abort
>>> which is waiting for its HHH to abort on and on
>>> with no HHH ever aborting.
>>>
>>
>> Indeed! There is no way to make HHH correct for all inputs, in 
>> particular not for the input that uses HHH's algorithm.
> 
> CORRECT MEANS DO WHATEVER THE X86 CODE SAYS
> 
> _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]
> 
> Show the details of how DDD emulated by HHH
> reaches its own machine address 0000217f.
> 
> 00002172, 00002173, 00002175, 0000217a calls HHH(DDD)
> then
> 00002172, 00002173, 00002175, 0000217a calls HHH(DDD)...
> 
> WHAT SHOULD THE NEXT STEPS BE?
> 
That has been told now several times. A correct simulation (as by HHH1, 
or the unmodified world class simulator) show that the next instruction 
is at 000015d2 (in HHH) and when HHH returns the next instruction in DDD 
is 0000217f, 00002182, 00002183 and DDD halts.
But, indeed, HHH fails to reach that part of the simulation, because it 
decided to stop the simulation too soon.
The problem is the code that tries to detect an infinite recursion. It 
fails to see that there are only two recursion for each HHH.
Olcott is still dreaming of a HHH that will not see this 'special 
condition'. He does not realise that by adding the code to recognize 
this 'special condition' and stop the simulation, the other HHH, that 
does not see this 'special condition', disappeared and remains only in 
his dreams. HHH, when simulating *itself* should now decide about the 
DDD that uses this new HHH that sees this 'special condition' and aborts.
*That code* is where the problem is, not the incomplete simulation itself.
In fact, if Olcott would have found a solution for the halting problem, 
then it would not be in the simulation, but in the detection of the 
'special condition'. The correctness of the simulation is only relevant 
because it is used as input for the code to detect the 'special 
condition'. The proof that the halting problem cannot be solved with a 
computation implies that Olcott's detection of the 'special condition' 
cannot be correct.
It is probable that Olcott understands that it cannot be correct and 
therefore he hides the code for the recognition of this 'special condition'.
He probably knows that if he would publish this part of the decider, 
people would spot many errors in it immediately.
He has only shown some trivial examples as evidence that this detection 
of the 'special condition' is correct, such as Infinite_Loop and 
Infinite_Recursion, but, of course, a few trivial examples do not prove 
the correctness of this algorithm.
Therefore, he keeps pulling the attention away from the correctness of 
the detection of the 'special condition', to the correctness of the 
simulation.