Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory
Subject: Re: Ben Bacarisse fails understand that deciders COMPUTE THE MAPPING
 FROM INPUTS
Date: Tue, 27 Aug 2024 21:28:29 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <16c7099fdd347526146c212ef435a995ab657c22@i2pn2.org>
References: <va104l$376ed$4@dont-email.me> <va13po$376ed$7@dont-email.me>
 <d42e5d30ea5f1c067283cb04d8a7293e2117188e@i2pn2.org>
 <va24hl$3cvgv$1@dont-email.me>
 <431deaa157cdae1cae73a1b24268a61cf8ec2c1c@i2pn2.org>
 <va38qh$3ia79$1@dont-email.me>
 <7a1c569a699e79bfa146affbbae3eac7b91cd263@i2pn2.org>
 <va3f7o$3ipp3$1@dont-email.me>
 <729cc551062c13875686d266a5453a488058e81c@i2pn2.org>
 <va3kac$3nd5c$1@dont-email.me>
 <148bf4dd91f32379a6d81a621fb7ec3fc1e00db0@i2pn2.org>
 <va3lai$3nd5c$2@dont-email.me> <va46sd$3pr24$1@dont-email.me>
 <va4mle$3s0hu$1@dont-email.me>
 <5591ff08ed8f7b4bdf33813681e156b775efe0ec@i2pn2.org>
 <va63uu$2fo9$1@dont-email.me>
 <b0a86b6a1343ebb5f9112ae757768a7cbbc770b2@i2pn2.org>
 <va65r8$6ht7$1@dont-email.me>
 <da75188ffa7677bd2b6979c8fc6ba82119404306@i2pn2.org>
 <878qwn0wyz.fsf@bsb.me.uk>
 <efacnfsQdv-ErlT7nZ2dnZfqnPadnZ2d@brightview.co.uk>
 <87le0jzc8f.fsf_-_@bsb.me.uk> <vaj1kd$2kvg9$1@dont-email.me>
 <vak4gc$2teq9$3@dont-email.me> <vakj1m$302rl$4@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 28 Aug 2024 01:28:29 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="4162071"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
Content-Language: en-US
X-Spam-Checker-Version: SpamAssassin 4.0.0
In-Reply-To: <vakj1m$302rl$4@dont-email.me>
Bytes: 8609
Lines: 154

On 8/27/24 9:07 AM, olcott wrote:
> On 8/27/2024 3:58 AM, Fred. Zwarts wrote:
>> Op 27.aug.2024 om 01:03 schreef olcott:
>>> On 8/26/2024 7:42 AM, Ben Bacarisse wrote:
>>>> Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
>>>>
>>>>> On 23/08/2024 22:07, Ben Bacarisse wrote:
>>>>>> joes <noreply@example.org> writes:
>>>>>>
>>>>>>> Am Wed, 21 Aug 2024 20:55:52 -0500 schrieb olcott:
>>>>>>
>>>>>>>> Professor Sipser clearly agreed that an H that does a finite 
>>>>>>>> simulation
>>>>>>>> of D is to predict the behavior of an unlimited simulation of D.
>>>>>>>
>>>>>>> If the simulator *itself* would not abort. The H called by D is,
>>>>>>> by construction, the same and *does* abort.
>>>>>> We don't really know what context Sipser was given.  I got in 
>>>>>> touch at
>>>>>> the time so do I know he had enough context to know that PO's 
>>>>>> ideas were
>>>>>> "wacky" and that had agreed to what he considered a "minor remark".
>>>>>> Since PO considers his words finely crafted and key to his so-called
>>>>>> work I think it's clear that Sipser did not take the "minor 
>>>>>> remark" he
>>>>>> agreed to to mean what PO takes it to mean!  My own take if that he
>>>>>> (Sipser) read it as a general remark about how to determine some 
>>>>>> cases,
>>>>>> i.e. that D names an input that H can partially simulate to determine
>>>>>> it's halting or otherwise.  We all know or could construct some such
>>>>>> cases.
>>>>>
>>>>> Exactly my reading.  It makes Sipser's agreement natural, because 
>>>>> it is
>>>>> both correct [with sensible interpretation of terms], and moreover
>>>>> describes an obvious strategy that a partial decider might use that 
>>>>> can
>>>>> decide halting for some specific cases.  No need for Sipser to be 
>>>>> deceptive
>>>>> or misleading here, when the truth suffices.  (In particular no 
>>>>> need to
>>>>> employ "tricksy" vacuous truth get out clauses just to get PO off 
>>>>> his back
>>>>> as some have suggested.)
>>>>
>>>> Yes, and it fits with his thinking it a "trivial remark".  Mind you I
>>>> can't help I feeling really annoyed that a respected academic is having
>>>> his name repeated dragged into this nonsense by PO.
>>>>
>>>> That aside, it's such an odd way to present an argument: "I managed to
>>>> trick X into saying 'yes' to something vague".  In any reasonable
>>>> collegiate exchange you'd go back and check: "So even when D is
>>>> constructed from H, H can return based on what /would/ happen if H did
>>>> not stop simulating so that H(D,D) == false is correct even though D(D)
>>>> halts?".  Just imagine what Sipser would say to that!
>>>>
>>>> Academic exchange thrives on clarity.  Cranks thrive on smoke and
>>>> mirrors.
>>>>
>>>
>>> Try to point to the tiniest lack of clarity in this fully
>>> specified concrete example.
>>>
>>> void DDD()
>>> {
>>>    HHH(DDD);
>>>    return;
>>> }
>>>
>>> _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]
>>>
>>> HHH computes the mapping from DDD to behavior that never reaches
>>> its "return" statement on the basis of the x86 emulation of DDD
>>> by HHH according to the semantics of the x86 language.
>>
>> Only, because the simulation stopped, so that it skipped the halting 
>> part.
>>
>>>
>>> For all the  years people said that this simulation is incorrect
>>> never realizing that they were disagreeing with the semantics
>>> of the x86 language.
>>
>> No, all these years you did not realise that the simulation deviated 
>> from the semantics of the x86 language by skipping the last few 
>> instructions of a halting program.
>>
> 
> *The abort code has been disabled*
> *The abort code has been disabled*
> *The abort code has been disabled*

Then HHH can't abort, not even the one that you will later ask to decide 
this, as then this DDD isn't the one that calls THAT HHH.

> 
> DDD()
> [00002162] 55         push ebp
> [00002163] 8bec       mov ebp,esp
> [00002165] 6862210000 push 00002162
> [0000216a] e853f4ffff call 000015c2
> [0000216f] 83c404     add esp,+04
> [00002172] 5d         pop ebp
> [00002173] c3         ret
> Size in bytes:(0018) [00002173]
> 
> *Limited to 20,000,000 total instructions*
> *Limited to 20,000,000 total instructions*
> *Limited to 20,000,000 total instructions*
> 
>   machine   stack     stack     machine     assembly
>   address   address   data      code        language
>   ========  ========  ========  ========== =============
> [00002182][00103806][00000000] 55         push ebp      ; begin main
> [00002183][00103806][00000000] 8bec       mov ebp,esp
> [00002185][00103802][00002162] 6862210000 push 00002162 ; push DDD
> [0000218a][001037fe][0000218f] e833f4ffff call 000015c2 ; call HHH
> New slave_stack at:1038aa

And the following is NOT a correct x86 emulation.

Sorry, it just isn't, so FAIL.

> 
> Begin Local Halt Decider Simulation   Execution Trace Stored at:1138b2
> [00002162][001138a2][001138a6] 55         push ebp
> [00002163][001138a2][001138a6] 8bec       mov ebp,esp
> [00002165][0011389e][00002162] 6862210000 push 00002162 ; push DDD
> [0000216a][0011389a][0000216f] e853f4ffff call 000015c2 ; call HHH
> New slave_stack at:14e2d2
> [00002162][0015e2ca][0015e2ce] 55         push ebp
> [00002163][0015e2ca][0015e2ce] 8bec       mov ebp,esp
> [00002165][0015e2c6][00002162] 6862210000 push 00002162 ; push DDD
> [0000216a][0015e2c2][0000216f] e853f4ffff call 000015c2 ; call HHH
> New slave_stack at:15e372
> [00002162][0016e36a][0016e36e] 55         push ebp
> [00002163][0016e36a][0016e36e] 8bec       mov ebp,esp
> [00002165][0016e366][00002162] 6862210000 push 00002162 ; push DDD
> [0000216a][0016e362][0000216f] e853f4ffff call 000015c2 ; call HHH
> New slave_stack at:16e412
> [00002162][0017e40a][0017e40e] 55         push ebp
> [00002163][0017e40a][0017e40e] 8bec       mov ebp,esp
> [00002165][0017e406][00002162] 6862210000 push 00002162 ; push DDD
> [0000216a][0017e402][0000216f] e853f4ffff call 000015c2 ; call HHH
> Number of Instructions Executed(20000000) == 298507 Pages
>