Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: olcott <polcott333@gmail.com>
Newsgroups: comp.theory
Subject: Re: Is Richard a Liar?
Date: Fri, 17 May 2024 11:07:55 -0500
Organization: A noiseless patient Spider
Lines: 150
Message-ID: <v27vct$290md$1@dont-email.me>
References: <v18e32$1vbql$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>
 <v24mcu$1gm7h$1@dont-email.me> <v255o9$1k6kv$1@dont-email.me>
 <v277ve$24e3g$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 17 May 2024 18:07:57 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="269f5d410d08e21225230cab72194d27";
	logging-data="2392781"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18XSZKNv0zxDpJCD05OiI/a"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:70MverARic7nYRVVE2y9uej46sI=
In-Reply-To: <v277ve$24e3g$1@dont-email.me>
Content-Language: en-US
Bytes: 7749

On 5/17/2024 4:28 AM, Mikko wrote:
> On 2024-05-16 14:37:59 +0000, olcott said:
> 
>> On 5/16/2024 5:15 AM, Mikko wrote:
>>> On 2024-05-15 15:03:20 +0000, olcott said:
>>>
>>>> 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
>>>
>>> That still has the problem that "wildcard" has no well known meaning
>>> that could be applicable in that context.
>>>
>>>> *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.
>>>
>>> I.e., a sequence of moves.
>>>
>>
>> Not as easy for software engineers.
>> Wildcard as * was one of the first things that I learned.
>> It is well known in the field of regular expressions.
> 
> In the usual language of regular expressions the wildcard
> metacharecter is point "." and the metacaracters "*", "+"
> denote repetition, "+" at least once.
> 

That is not the term used when computer science students are taught
how to find files matching a pattern. I know a lot about deterministic
finite automatons having two issued patents on them.

I know a lot about regular expressions because I used regular
expressions in the AWK programming language to search a massive
code-base of millions of lines to analyze the system that required
maintenance.

> That a "wildcard" is a well known word is one of the reasons
> why the term should not be used when the same meaning is not
> applicable.
> 

It does include zero or more state transitions in a sequence of state
transitions. Linz calls this moves to also include tape head actions.

> Another reason is that one should never use a word where it
> does not affect the meaning of the containing expression. As
> "⊢*" means 'a sequence of moves' you shold not use more words
> to express its meaning.
> 

Several of my reviewers took a very long time to understand that
the Linz proof refers to Turing machine description templates and
not a single Turing machine. We had to go over this exact same
thing many hundreds of times.

> Yeat another reason is that when one borrows a notation one
> should also borrow the terms used in discussion of the notation
> unles they conflict with terms borrowed from elsewhere.
> 

It might be best if I simply directly quote Linz and then explain his
words in terms that software engineers can understand.

>>>>> 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.
>>>
>>> Yes, but a machine were one part of a machine gives its result to
>>> aonter part and then both continue their exection is not a Truing
>>> machine.
>>
>> Sure it is. A Turing machine that transitions through a specific state
>> and never stops running IS A TURING MACHINE.
> 
> No, it is not. A machine where several parts are executed at the same
> time is not a Turing machine. 

(1)--->(2)--->(3) is a DFA that transitions through its state (2).
A TM can transition through a specific state because a TM is more
powerful than a DFA.

> If a part of a Turing machine never
> stops it execution it perevents all execution of other parts.
> 

If a machine is stuck in an infinite loop it can say
"I am stuck in an infinite loop" infinitely.

-- 
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer