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: Olcott is a Liar!
Date: Wed, 15 May 2024 20:24:22 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <v23jnm$15707$1@i2pn2.org>
References: <v18e32$1vbql$1@dont-email.me>
 <-5Gdnf-nQvstC6b7nZ2dnZfqnPadnZ2d@brightview.co.uk>
 <v1gid8$4ilc$1@dont-email.me> <v1h9eu$9faf$1@dont-email.me>
 <v1iqli$nsva$1@dont-email.me> <v1k0ts$iuna$1@i2pn2.org>
 <v1k381$14mbi$2@dont-email.me> <v1labh$kf53$1@i2pn2.org>
 <v1lfnq$1e7af$1@dont-email.me> <v1lh1g$kf52$4@i2pn2.org>
 <v1lmo1$1g1mj$1@dont-email.me> <v1luu1$lbo5$3@i2pn2.org>
 <v1lvuo$1i47i$1@dont-email.me> <v1m1bf$lbo5$4@i2pn2.org>
 <v1m2hc$1ijhr$1@dont-email.me> <v1m31m$lbo4$1@i2pn2.org>
 <v1m4et$1iv85$1@dont-email.me> <v1m5co$lbo4$2@i2pn2.org>
 <v1m71h$1jnpi$1@dont-email.me> <v1m7mh$lbo5$5@i2pn2.org>
 <v1mb8f$1kgpl$1@dont-email.me> <v1mkf8$lbo5$7@i2pn2.org>
 <v1mkmm$1q5ee$1@dont-email.me> <v1na6f$1ugl0$1@dont-email.me>
 <v1o67n$24f4c$1@dont-email.me> <v1q1ie$2l40t$1@dont-email.me>
 <v1q9fp$qb0p$1@i2pn2.org> <v1qmq8$2prs6$1@dont-email.me>
 <v1qouc$2qb2s$1@dont-email.me> <v1vbpd$3gbc$1@dont-email.me>
 <v1vs0m$7577$4@dont-email.me> <v21qac$oojb$1@dont-email.me>
 <v22irp$u8vi$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 16 May 2024 00:24:22 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="1219591"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
X-Spam-Checker-Version: SpamAssassin 4.0.0
Content-Language: en-US
In-Reply-To: <v22irp$u8vi$2@dont-email.me>
Bytes: 4840
Lines: 77

On 5/15/24 11:03 AM, olcott wrote:
> On 5/15/2024 3:04 AM, Mikko wrote:
>> On 2024-05-14 14:21:10 +0000, olcott said:
>>
>>> On 5/14/2024 4:44 AM, Mikko wrote:
>>>> On 2024-05-12 15:58:02 +0000, olcott said:
>>>>
>>>>> On 5/12/2024 10:21 AM, Mikko wrote:
>>>>>> On 2024-05-12 11:34:17 +0000, Richard Damon said:
>>>>>>
>>>>>>> On 5/12/24 5:19 AM, Mikko wrote:
>>>>>>>> On 2024-05-11 16:26:30 +0000, olcott said:
>>>>>>>>
>>>>>>>>> I am working on providing an academic quality definition of this
>>>>>>>>> term.
>>>>>>>>
>>>>>>>> The definition in Wikipedia is good enough.
>>>>>>>>
>>>>>>>
>>>>>>> I think he means, he is working on a definition that redefines 
>>>>>>> the field to allow him to claim what he wants.
>>>>>>
>>>>>> Here one can claim whatever one wants anysay.
>>>>>> In if one wants to present ones claims on some significant forum then
>>>>>> it is better to stick to usual definitions as much as possible.
>>>>>>
>>>>>>> Sort of like his new definition of H as an "unconventional" 
>>>>>>> machine that some how both returns an answer but also keeps on 
>>>>>>> running.
>>>>>>
>>>>>> There are systems where that is possible but unsolvable problems are
>>>>>> unsolvable even in those systems.
>>>>>>
>>>>>
>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>
>>>> This notation does not work with machines that can, or have parts
>>>> that can, return a value without (or before) termination.
>>>>
>>>
>>> ⊢* specifies a wildcard set of state transitions that could
>>> include a transition to a non-final state embedded_H.qn.
>>
>> The term "wildcard" is usually not used in this context. And the word
>> "set" is not sufficiently specific, so "sequence" should be used instead.
>>
> 
> Yes that is better.
> ⊢* specifies a wildcard sequence of state transitions
> 
> *Here is how Linz says it*
> The Linz term “move” means a state transition and its corresponding
> tape head action {move_left, move_right, read, write}.
> ⊢* indicates an arbitrary number of moves.
> 
>> Anyway, the language cannot handle a situation where one part of a
>> machine gives its result to another parts and then both continue their
>> execution.
>>
> 
> The language of Turing machine descriptions certainly can handle
> TM's that do not halt. It can also handle transitioning through
> a specific state to another state.
> 
> This specific state can encode a halt status value. New ideas are
> hard because there is no standard boiler-plate that can be applied
> to them.
> 

Except that Turing Machine "output" / "Answer" is specified as being 
given when the machine halts.

Thus, it can not "indicate" halt status by passing through a non-halting 
state, as that doesn't meet the definitions.

Of course, you problem is you just don't know what you are talking about.