Re: Olcott is a Liar!

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.