Re: Richard is proven to be incorrect on a key point

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

On 2024-05-18 01:07:17 +0000, Richard Damon said:
>

On 5/17/24 12:07 PM, olcott wrote:

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.

>
Nope, that IS the definition of REGULAR EXPRESSION, it isn't the definitoin of GLOBBING like is done at the command line.
>
Look at https://en.wikipedia.org/wiki/Regular_expression
>
>
The asterisk indicates zero or more occurrences of the preceding element. For example, ab*c matches "ac", "abc", "abbc", "abbbc", and so on.
>

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

>
Nope, Linz CLEARLY refers to H in the singular as a single machine.
>
The diagram is a requirements statement that H must meet, but H is not "at once" all machines that meet that requirement.
>

>

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.

>
Try it.
>

>

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

>
No, because Turing Machines don't "say" anything until they halt.

>
In Turing's original formulation they do. Turing had a special subset
of tape characters that could not be erased. His main focus was on
machines that never halt but keep producing more and more digits of
some real number or some other endless output.
>

 That is great, I knew that yet forgot about it.
I think he was calculating the digits of PI.