Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Mikko <mikko.levanto@iki.fi>
Newsgroups: comp.theory
Subject: =?utf-8?B?UmU6IGVtYmVkZGVkX0ggYXBwbGllZCB0byDin6jEpOKfqSDin6jEpOKfqSBjb21wdXRlcyB0aGUgbWFwcGluZyBmcm9tIGl0cyBpbnB1dCB0byDEpC5xbg==?=
Date: Fri, 2 Aug 2024 09:28:31 +0300
Organization: -
Lines: 89
Message-ID: <v8huaf$2mfmf$1@dont-email.me>
References: <v6rg65$32o1o$3@dont-email.me> <v742r2$s48s$2@dont-email.me> <210383b2ee318f68a96d94aec314ee8b93f79b7f@i2pn2.org> <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 02 Aug 2024 08:28:32 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="091c507d5ae6612e3eb2a7bc86b072a3";
	logging-data="2834127"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19XLkz2IUMh+MUgrhnJEQ0p"
User-Agent: Unison/2.2
Cancel-Lock: sha1:24AnDKWzHeCiqwtj+Xh9kx1toos=
Bytes: 5371

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 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.

-- 
Mikko