Path: ...!news.misty.com!weretis.net!feeder9.news.weretis.net!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory
Subject: =?UTF-8?B?UmU6IGVtYmVkZGVkX0ggYXBwbGllZCB0byDin6jEpOKfqSDin6jEpA==?=
 =?UTF-8?Q?=E2=9F=A9_incorrectly_computes_the_mapping_from_its_input_to_?=
 =?UTF-8?B?xKQucW4=?=
Date: Fri, 2 Aug 2024 10:41:37 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <0e1890d61dd8c1e7786a2799bd6f6fd4e4dcdc08@i2pn2.org>
References: <v6rg65$32o1o$3@dont-email.me> <v75u22$19j7l$4@dont-email.me>
 <fde630817c49562bc765bdbc98e16a1582bcad53@i2pn2.org>
 <v78mda$1smtm$2@dont-email.me> <v7d5cl$2t3ja$1@dont-email.me>
 <v7ds0o$30pvh$3@dont-email.me> <v7fs29$3f4g7$1@dont-email.me>
 <v7gd17$3hlc2$2@dont-email.me> <v7ikn4$1jv5$1@dont-email.me>
 <v7j2pg$3o7r$3@dont-email.me> <v7l3di$idv1$1@dont-email.me>
 <v7lnrf$luh0$1@dont-email.me> <v7niqp$13ghd$1@dont-email.me>
 <v7obbn$17h8r$1@dont-email.me> <v7qfm6$1m5ce$1@dont-email.me>
 <v7qvs3$1onhe$2@dont-email.me> <v7vnnn$2os1v$1@dont-email.me>
 <v80akb$2rabc$5@dont-email.me> <v82751$39qck$1@dont-email.me>
 <v82v0a$3dftr$4@dont-email.me> <v84tv8$3rmit$1@dont-email.me>
 <v88f8e$i7kl$1@dont-email.me> <v8a1o6$tvll$1@dont-email.me>
 <v8asjm$12hr3$1@dont-email.me> <v8cpaf$1g7h6$1@dont-email.me>
 <v8ds65$1mg72$1@dont-email.me> <v8fecc$22lpn$1@dont-email.me>
 <v8fsnp$24rl1$4@dont-email.me> <v8huaf$2mfmf$1@dont-email.me>
 <v8ikh2$2qpnq$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 2 Aug 2024 14:41:37 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="1215790"; 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: <v8ikh2$2qpnq$1@dont-email.me>
Bytes: 6981
Lines: 118

On 8/2/24 8:47 AM, olcott wrote:
> On 8/2/2024 1:28 AM, Mikko wrote:
>> On 2024-08-01 11:49:13 +0000, olcott said:
>>
>>> On 8/1/2024 2:44 AM, Mikko wrote:
>>>> On 2024-07-31 17:27:33 +0000, olcott said:
>>>>
>>>>> On 7/31/2024 2:32 AM, Mikko wrote:
>>>>>> On 2024-07-30 14:16:20 +0000, olcott said:
>>>>>>
>>>>>>> On 7/30/2024 1:37 AM, Mikko wrote:
>>>>>>>> On 2024-07-29 16:16:13 +0000, olcott said:
>>>>>>>>
>>>>>>>>> On 7/28/2024 3:02 AM, Mikko wrote:
>>>>>>>>>> On 2024-07-27 14:08:10 +0000, olcott said:
>>>>>>>>>>
>>>>>>>>>>> On 7/27/2024 2:21 AM, Mikko wrote:
>>>>>>>>>>>> On 2024-07-26 14:08:11 +0000, olcott said:
>>>>>>>>>>>>
>>>>>>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The above is merely simplified syntax for the top of page 3
>>>>>>>>>>> https://www.liarparadox.org/Linz_Proof.pdf
>>>>>>>>>>> The above is the whole original Linz proof.
>>>>>>>>>>
>>>>>>>>>> And even more simplified semantics.
>>>>>>>>>>
>>>>>>>>>>> (a) Ĥ copies its input ⟨Ĥ⟩
>>>>>>>>>>> (b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>>>>> (c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>>>>> (d) simulated ⟨Ĥ⟩ copies its input ⟨Ĥ⟩
>>>>>>>>>>> (e) simulated ⟨Ĥ⟩ invokes simulated embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>>>>> (f) simulated embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>>>>> (g) goto (d) with one more level of simulation
>>>>>>>>>>>
>>>>>>>>>>> You are supposed to evaluate the above as a contiguous
>>>>>>>>>>> sequence of moves such that non-halting behavior is
>>>>>>>>>>> identified.
>>>>>>>>>>
>>>>>>>>>> The above is an obvious tight loop of (d), (e), (f), and (g).
>>>>>>>>>> Its relevance (it any) to the topic of the discussion is not
>>>>>>>>>> obvious.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> When we compute the mapping from the input to embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>>> to the behavior specified by this input we know that embedded_H
>>>>>>>>> is correct to transition to Ĥ.qn.
>>>>>>>>
>>>>>>>> The meaning of "correct" in this context is that if the 
>>>>>>>> transition of
>>>>>>>> embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qn is correct if H ⟨Ĥ⟩ ⟨Ĥ⟩ transitions 
>>>>>>>> to H.qn but
>>>>>>>> incorrect otherwise.
>>>>>>>
>>>>>>> No you are wrong.
>>>>>>
>>>>>> Which dictionary (or other authority) disagrees?
>>>>>
>>>>> Computable functions are the formalized analogue of the
>>>>> intuitive notion of algorithms, in the sense that a function
>>>>> is computable if there exists an algorithm that can do the
>>>>> job of the function, i.e. *given an input of the function*
>>>>> *domain it can return the corresponding output*
>>>>> https://en.wikipedia.org/wiki/Computable_function
>>>>>
>>>>> The common knowledge that a decider computes the mapping
>>>>> from its input finite string...
>>>>>
>>>>> This is almost always the same as the direct execution of
>>>>> the machine represented by this finite string.
>>>>
>>>> None of above indicates any disagreement by any authority.
>>>>
>>>
>>> Everyone (even Linz) has the wrong headed idea that a halt
>>> decider must report on the behavior of the computation that
>>> itself is contained within. This has always been wrong.
>>
>> What does "must" mean above? How does that relate to what Linz
>> really says?
>>
> 
> A decider computes the mapping from a finite string.
> A decider does not compute the mapping from an execution machine.
> 
>>> A halt decider must always report on the behavior that its
>>> finite string specifies. This is different only when an
>>> input invokes its own decider.
>>
>> The input string cannot "invoke". It only specifies.
>>
> 
> In the x86 language emulated DDD calls and emulated HHH(DDD).
> The same thing occurs when Linz Ĥ ⟨Ĥ⟩ transitions to embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩.
> 
> This is repeated with simulated ⟨Ĥ⟩ instances transitioning to
> simulated instances of embedded_H.
> 

And, since embedded_H and HHH will decide to abort their emulations and 
return, a correct emulation of them will show that, even if the PARTIAL 
emulation done by them can not reach that point.

The routines are what they are and the correct emulation will show that 
behavior. A version of HHH looking at an input that calls itself, but 
treating it as a non-aborting version of itself isn't looking at the 
input given to it.

If HHH properly emulates the code of HHH that it sees, it will see the 
conditional instructions that tells it there is at least a possibility 
of this program terminating, so it can't just use the loop with no 
conditional rule for non-termination.

Your attempting to do so just proves your utter stupidity, and the fact 
you repeat the error after it has been pointed out makes you a 
pathological liar.