Re: Is Richard a Liar?

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.

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. The prior state-of-the-art
is that both YES and NO are the wrong answer from TM H regarding the
behavior of input D. I provide a counter-example that PROVES that YES
is the correct answer.

Consequently, when you introduced that possibility were
not discussing Turing machines. A language decined for Turing
mahihes is not sufficient for non-Turing machines.
 

*A Turing machine that transitions through a specific*
*state and never stops running IS A TURING MACHINE*
*Every specific type of Turing Machine <is> a Turing Machine*

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.

 The specification of the halt decider requires that the halt status
value is indicated by the final state.
 

Going from both YES and NO are the wrong answer from H about D
to YES is the correct answer about D is an incremental improvement.
The least that we can say about this is that H KNOWS the correct
answer yet cannot SAY the correct answer in the conventional way.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer