Re: embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ where embedded_H is based on a UTM

On 5/18/24 10:50 AM, olcott wrote:

On 5/18/2024 5:33 AM, Mikko wrote:

On 2024-05-17 16:07:55 +0000, olcott said:
>

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.

>
If "wildcard" was not used then what term was used? And what method of
to find files maching a pattern was taught?
>
The theory of deterministic finite automatons does not specify
what words should be used when discussing Turing machines. That
must be determined from other considerations.
>

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.

>
Then you should know that AWK uses '.' as the wildcard metacharacter
(and uses some multicharacter symbols as restricted wildcards) and
does not use '*' as a wildcard metacharacter but as a repetition
operator. These symbols are shared with typical regular expression
languages. Some of AWK's symbols are less widely shared.
>

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.

>
The word "wildcard" does not mean "zero or more", which is a
common meaning of right superscript "*".
>

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.

>
When Linz says "Turing machine" that refers to a Turing machine,
not to a template. When Linz describes how to construct the counter
example that is a description of the construnction method and not
a reference to a template. The construction could be presented
as an application of a template but Linz doesn't do so.
>

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.

>
Every software engineer can understand Linz or some other author
that proves the same without your explanation. Or if someone can't,
it is easier to ask another sofware engineer. They rarely work
alone.
>

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.

>
Yes, but that is not relevant to my comment (quoted above without
much of the original context) that a language designed for traces
of Turing machine execution cannot handle parallel execution.
>

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.

>
To an ousider but not to any part of the same machine that is not
a part of the infinite loop.
>
Don't forget that the diecussion is about non-Turing machines where
disctinct parts can execute in parallel.
>

  When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
 The Turing Machine version has embedded_H as a UTM that also watches
every change of the state of its simulated ⟨Ĥ⟩ ⟨Ĥ⟩ and correctly detects
that ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by embedded_H cannot possibly reach its
own simulated final state of ⟨Ĥ.qn⟩
 

But if embedded_H is a UTM that never aborts, then H must be also, or you art just lying that you built H^ by the rules.
If H aborts its simulation, then so does embedded_H and thus H^ (H^) when embeddedd_H does so and go to qn just like H does, and H^ will reach a final state proving H going the qn is wrong for the Halting Problem.
Your H might be a correct POOP detector for this input, but no one actually cares about your POOP.