On 3/7/2024 7:35 PM, immibis wrote:
> On 7/03/24 18:05, olcott wrote:
>> On 3/7/2024 8:47 AM, immibis wrote:
>>> On 7/03/24 03:40, olcott wrote:
>>>> On 3/6/2024 8:22 PM, immibis wrote:
>>>>> On 7/03/24 01:12, olcott wrote:
>>>>>> On 3/6/2024 5:59 PM, immibis wrote:
>>>>>>> On 7/03/24 00:55, olcott wrote:
>>>>>>>> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn
>>>>>>>> Correctly reports that Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ must abort its simulation.
>>>>>>>>
>>>>>>>> H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>>>>>>> Correctly reports that H ⟨Ĥ⟩ ⟨Ĥ⟩ need not abort its simulation.
>>>>>>>
>>>>>>> What are the exact steps which the exact same program with the
>>>>>>> exact same input uses to get two different results?
>>>>>>> I saw x86utm. In x86utm there is a mistake because Ĥ.H is not
>>>>>>> defined to do exactly the same steps as H, which means you failed
>>>>>>> to do the Linz procedure.
>>>>>>
>>>>>> Both H(D,D) and H1(D,D) answer the exact same question:
>>>>>> Can I continue to simulate my input without ever aborting it?
>>>>>>
>>>>>
>>>>> Both H(D,D) and H1(D,D) are computer programs (or Turing machines).
>>>>> They execute instructions (or transitions) in sequence, determined
>>>>> by their programming and their input.
>>>>
>>>> Yet because they both know their own machine address
>>>> they can both correctly determine whether or not they
>>>> themselves are called in recursive simulation.
>>>
>>> They cannot do anything except for exactly what they are programmed
>>> to do.
>>
>> H1(D,D) and H(D,D) are programmed to do this.
>> Because H1(D,D) simulates D(D) that calls H(D,D) that
>> aborts its simulation of D(D). H1 can see that its
>> own simulated D(D) returns from its call to H(D,D).
>>
>>>>
>>>> An Olcott machine can perform an equivalent operation.
>>>>
>>>> Because Olcott machines are essentially nothing more than
>>>> conventional UTM's combined with Conventional Turing machine
>>>> descriptions their essence is already fully understood.
>>>>
>>>> The input to Olcott machines can simply be the conventional
>>>> space delimited Turing Machine input followed by four spaces.
>>>>
>>>> This is followed by the machine description of the machine
>>>> that the UTM is simulating followed by four more spaces.
>>>
>>> To make the Linz proof work properly with Olcott machines, Ĥ should
>>> search for 4 spaces, delete its own machine description, and then
>>> insert the description of the original H. Then the Linz proof works
>>> for Olcott machines.
>>
>> That someone can intentionally break an otherwise correct
>> halt decider
>
> It always gives exactly the same answer as the working one, so how is it
> possibly broken?
>

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy ∞ // Ĥ applied to ⟨Ĥ⟩ halts
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn // Ĥ applied to ⟨Ĥ⟩ does not halt

When this is executed in an Olcott machine then
Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> is a different computation than H ⟨Ĥ⟩ ⟨Ĥ⟩ <H>

No matter how Ĥ ⟨Ĥ⟩ screws itself up this can have no
effect on H ⟨Ĥ⟩ ⟨Ĥ⟩.

The Olcott machine H ⟨Ĥ⟩ ⟨Ĥ⟩ <H> can see that it does not
call itself in recursive simulation.

The Olcott machine Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> can see that it calls
itself in recursive simulation unless it discards this
ability. In either case it cannot fool H, it either halts
or fails to halt.

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

On 3/7/2024 7:36 PM, immibis wrote:
> On 7/03/24 18:14, olcott wrote:
>> It is an easily fact that a correct and complete simulation of
>> the input to H(D,D) and the input to Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ cannot possibly halt.
>
> It can if H(D,D) returns 0.

D simulated by H cannot possibly halt even if we simplify it to this:

void D(void (*x)())
{ H(x, x);
}

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

On 8/03/24 03:02, olcott wrote:
> On 3/7/2024 7:35 PM, immibis wrote:
>> On 7/03/24 18:05, olcott wrote:
>>> On 3/7/2024 8:47 AM, immibis wrote:
>>>> On 7/03/24 03:40, olcott wrote:
>>>>> On 3/6/2024 8:22 PM, immibis wrote:
>>>>>> On 7/03/24 01:12, olcott wrote:
>>>>>>> On 3/6/2024 5:59 PM, immibis wrote:
>>>>>>>> On 7/03/24 00:55, olcott wrote:
>>>>>>>>> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn
>>>>>>>>> Correctly reports that Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ must abort its simulation.
>>>>>>>>>
>>>>>>>>> H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>>>>>>>> Correctly reports that H ⟨Ĥ⟩ ⟨Ĥ⟩ need not abort its simulation.
>>>>>>>>
>>>>>>>> What are the exact steps which the exact same program with the
>>>>>>>> exact same input uses to get two different results?
>>>>>>>> I saw x86utm. In x86utm there is a mistake because Ĥ.H is not
>>>>>>>> defined to do exactly the same steps as H, which means you
>>>>>>>> failed to do the Linz procedure.
>>>>>>>
>>>>>>> Both H(D,D) and H1(D,D) answer the exact same question:
>>>>>>> Can I continue to simulate my input without ever aborting it?
>>>>>>>
>>>>>>
>>>>>> Both H(D,D) and H1(D,D) are computer programs (or Turing
>>>>>> machines). They execute instructions (or transitions) in sequence,
>>>>>> determined by their programming and their input.
>>>>>
>>>>> Yet because they both know their own machine address
>>>>> they can both correctly determine whether or not they
>>>>> themselves are called in recursive simulation.
>>>>
>>>> They cannot do anything except for exactly what they are programmed
>>>> to do.
>>>
>>> H1(D,D) and H(D,D) are programmed to do this.
>>> Because H1(D,D) simulates D(D) that calls H(D,D) that
>>> aborts its simulation of D(D). H1 can see that its
>>> own simulated D(D) returns from its call to H(D,D).
>>>
>>>>>
>>>>> An Olcott machine can perform an equivalent operation.
>>>>>
>>>>> Because Olcott machines are essentially nothing more than
>>>>> conventional UTM's combined with Conventional Turing machine
>>>>> descriptions their essence is already fully understood.
>>>>>
>>>>> The input to Olcott machines can simply be the conventional
>>>>> space delimited Turing Machine input followed by four spaces.
>>>>>
>>>>> This is followed by the machine description of the machine
>>>>> that the UTM is simulating followed by four more spaces.
>>>>
>>>> To make the Linz proof work properly with Olcott machines, Ĥ should
>>>> search for 4 spaces, delete its own machine description, and then
>>>> insert the description of the original H. Then the Linz proof works
>>>> for Olcott machines.
>>>
>>> That someone can intentionally break an otherwise correct
>>> halt decider
>>
>> It always gives exactly the same answer as the working one, so how is
>> it possibly broken?
>
> [non-answer removed]

Perhaps you didn't understand the question. How is a machine broken if
it always gives the right answer?

On 3/7/2024 7:37 PM, immibis wrote:
> On 8/03/24 00:04, olcott wrote:
>> On 3/7/2024 4:21 PM, Richard Damon wrote:
>>> On 3/7/24 12:20 PM, olcott wrote:
>>>> On 3/7/2024 1:59 PM, Richard Damon wrote:
>>>>> On 3/6/24 11:11 PM, olcott wrote:
>>>>>> On 3/7/2024 12:37 AM, Richard Damon wrote:
>>>>>>> On 3/6/24 10:17 PM, olcott wrote:
>>>>>
>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy ∞ // Ĥ applied to ⟨Ĥ⟩ halts
>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn     // Ĥ applied to ⟨Ĥ⟩ does
>>>>>>>> not halt
>>>>>>>>
>>>>>>>> The design of Olcott Machines makes quite easy for Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>> to get its abort criteria.
>>>>>>>>
>>>>>>>
>>>>>>> Which doesn't match the Halting Problem requirements,
>>>>>>
>>>>>> It does match the Halting Problem requirements, when
>>>>>> they are implemented indirectly as "abort criteria".
>>>>>>
>>>>>
>>>>> Which is a different criteria, so you are just admitting that you
>>>>> are using a strawman desception and thus INTENTIONALLY LYING.
>>>>>
>>>>> Somehow you think lies are ok if they help you prove your false
>>>>> statements.
>>>>
>>>> The Linz second ⊢* enables H to compute any damn
>>>> thing as long as this ends up computing halting.
>>>>
>>>
>>> Note quite, it is whatever the algorithm for H generates.
>>>
>>> That exact same algorithm exists in H^.H, so that WILL get the same
>>> answer, and since you logic says it doesn't, that means you are lying
>>> that H^ was built by the specification, or as to what H will actually
>>> do.
>>
>> *Already addressed in my reply to you here*
>> We finally know exactly how H1(D,D) derives a different result than
>> H(D,D)
>>
>
> We know it's because H and H1 are different programs, not copies.

*Even when we remove the infinite loop appended to Ĥ.Hqy*
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy // Ĥ applied to ⟨Ĥ⟩ halts
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn // Ĥ applied to ⟨Ĥ⟩ does not halt

An Olcott machine Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> could trivially determine
that it is calling itself in recursive simulation.

and Olcott machine H ⟨Ĥ⟩ ⟨Ĥ⟩ <H> could trivially determine
that it is NOT calling itself in recursive simulation.

This is true even when the embedded portion of H is
identical to <H>.

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

On 3/7/24 6:02 PM, olcott wrote:
> On 3/7/2024 7:35 PM, immibis wrote:
>> On 7/03/24 18:05, olcott wrote:
>>> On 3/7/2024 8:47 AM, immibis wrote:
>>>> On 7/03/24 03:40, olcott wrote:
>>>>> On 3/6/2024 8:22 PM, immibis wrote:
>>>>>> On 7/03/24 01:12, olcott wrote:
>>>>>>> On 3/6/2024 5:59 PM, immibis wrote:
>>>>>>>> On 7/03/24 00:55, olcott wrote:
>>>>>>>>> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn
>>>>>>>>> Correctly reports that Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ must abort its simulation.
>>>>>>>>>
>>>>>>>>> H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>>>>>>>> Correctly reports that H ⟨Ĥ⟩ ⟨Ĥ⟩ need not abort its simulation.
>>>>>>>>
>>>>>>>> What are the exact steps which the exact same program with the
>>>>>>>> exact same input uses to get two different results?
>>>>>>>> I saw x86utm. In x86utm there is a mistake because Ĥ.H is not
>>>>>>>> defined to do exactly the same steps as H, which means you
>>>>>>>> failed to do the Linz procedure.
>>>>>>>
>>>>>>> Both H(D,D) and H1(D,D) answer the exact same question:
>>>>>>> Can I continue to simulate my input without ever aborting it?
>>>>>>>
>>>>>>
>>>>>> Both H(D,D) and H1(D,D) are computer programs (or Turing
>>>>>> machines). They execute instructions (or transitions) in sequence,
>>>>>> determined by their programming and their input.
>>>>>
>>>>> Yet because they both know their own machine address
>>>>> they can both correctly determine whether or not they
>>>>> themselves are called in recursive simulation.
>>>>
>>>> They cannot do anything except for exactly what they are programmed
>>>> to do.
>>>
>>> H1(D,D) and H(D,D) are programmed to do this.
>>> Because H1(D,D) simulates D(D) that calls H(D,D) that
>>> aborts its simulation of D(D). H1 can see that its
>>> own simulated D(D) returns from its call to H(D,D).
>>>
>>>>>
>>>>> An Olcott machine can perform an equivalent operation.
>>>>>
>>>>> Because Olcott machines are essentially nothing more than
>>>>> conventional UTM's combined with Conventional Turing machine
>>>>> descriptions their essence is already fully understood.
>>>>>
>>>>> The input to Olcott machines can simply be the conventional
>>>>> space delimited Turing Machine input followed by four spaces.
>>>>>
>>>>> This is followed by the machine description of the machine
>>>>> that the UTM is simulating followed by four more spaces.
>>>>
>>>> To make the Linz proof work properly with Olcott machines, Ĥ should
>>>> search for 4 spaces, delete its own machine description, and then
>>>> insert the description of the original H. Then the Linz proof works
>>>> for Olcott machines.
>>>
>>> That someone can intentionally break an otherwise correct
>>> halt decider
>>
>> It always gives exactly the same answer as the working one, so how is
>> it possibly broken?
>>
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy ∞ // Ĥ applied to ⟨Ĥ⟩ halts
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn   // Ĥ applied to ⟨Ĥ⟩ does not halt
>
> When this is executed in an Olcott machine then
> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> is a different computation than H ⟨Ĥ⟩ ⟨Ĥ⟩ <H>

WHY?

The Master UTM will not change the usage at H^.H, because that is just
an internal state of the Machine H^

At that point we have the IDENTICAL set of transitions (with just an
equivalence mapping of state numbers) as H will have, and the EXACT same
input as H

>
> No matter how Ĥ ⟨Ĥ⟩ screws itself up this can have no
> effect on H ⟨Ĥ⟩ ⟨Ĥ⟩.
>
> The Olcott machine H ⟨Ĥ⟩ ⟨Ĥ⟩ <H> can see that it does not
> call itself in recursive simulation.

As will the machine at H^.H, since the description it thinks it is
doesn't match the machine that gets called.

>
> The Olcott machine Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> can see that it calls
> itself in recursive simulation unless it discards this
> ability. In either case it cannot fool H, it either halts
> or fails to halt.
>

But that isn't what H^.H gets called with.

The code between H^.q0 and H^.H removes the <H^> and replaces it with
<H>, so the copy of H at H^.H can't tell the difference.

You don't seem to understand what a Turing Machine CAN do.

On 3/7/24 6:05 PM, olcott wrote:
> On 3/7/2024 7:36 PM, immibis wrote:
>> On 7/03/24 18:14, olcott wrote:
>>> It is an easily fact that a correct and complete simulation of
>>> the input to H(D,D) and the input to Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ cannot possibly halt.
>>
>> It can if H(D,D) returns 0.
>
> D simulated by H cannot possibly halt even if we simplify it to this:
>
> void D(void (*x)())
> {
>   H(x, x);
> }
>

Nope, only if H actually does (or attempts to do) a complete simulation.

If H actually aborts its simulation and return 0, then a CORRECT
simulation of the input to H will halt.

So, you are stuck, because Computations are based on deterministic
algorithms. Either H's algorithm WILL continue to simulate through every
thing it sees in its simulation of D, and then neither machine will
halt, so H doesn't answer and is wrong.

Or H gives up and decides it needs to stop to give an answer, but then,
not seeing what D will do, is forced to "Guess", (and will always guess
this input the same way) and when we actually run D, it gets to see how
H guesses, and makes it wrong.

You keep on presuming that the H in D will be somehow different then the
H that is deciding on it, which is just a LIE.

On 3/7/2024 8:34 PM, Richard Damon wrote:
> On 3/7/24 6:02 PM, olcott wrote:
>> On 3/7/2024 7:35 PM, immibis wrote:
>>> On 7/03/24 18:05, olcott wrote:
>>>> On 3/7/2024 8:47 AM, immibis wrote:
>>>>> On 7/03/24 03:40, olcott wrote:
>>>>>> On 3/6/2024 8:22 PM, immibis wrote:
>>>>>>> On 7/03/24 01:12, olcott wrote:
>>>>>>>> On 3/6/2024 5:59 PM, immibis wrote:
>>>>>>>>> On 7/03/24 00:55, olcott wrote:
>>>>>>>>>> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn
>>>>>>>>>> Correctly reports that Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ must abort its simulation.
>>>>>>>>>>
>>>>>>>>>> H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>>>>>>>>> Correctly reports that H ⟨Ĥ⟩ ⟨Ĥ⟩ need not abort its simulation.
>>>>>>>>>
>>>>>>>>> What are the exact steps which the exact same program with the
>>>>>>>>> exact same input uses to get two different results?
>>>>>>>>> I saw x86utm. In x86utm there is a mistake because Ĥ.H is not
>>>>>>>>> defined to do exactly the same steps as H, which means you
>>>>>>>>> failed to do the Linz procedure.
>>>>>>>>
>>>>>>>> Both H(D,D) and H1(D,D) answer the exact same question:
>>>>>>>> Can I continue to simulate my input without ever aborting it?
>>>>>>>>
>>>>>>>
>>>>>>> Both H(D,D) and H1(D,D) are computer programs (or Turing
>>>>>>> machines). They execute instructions (or transitions) in
>>>>>>> sequence, determined by their programming and their input.
>>>>>>
>>>>>> Yet because they both know their own machine address
>>>>>> they can both correctly determine whether or not they
>>>>>> themselves are called in recursive simulation.
>>>>>
>>>>> They cannot do anything except for exactly what they are programmed
>>>>> to do.
>>>>
>>>> H1(D,D) and H(D,D) are programmed to do this.
>>>> Because H1(D,D) simulates D(D) that calls H(D,D) that
>>>> aborts its simulation of D(D). H1 can see that its
>>>> own simulated D(D) returns from its call to H(D,D).
>>>>
>>>>>>
>>>>>> An Olcott machine can perform an equivalent operation.
>>>>>>
>>>>>> Because Olcott machines are essentially nothing more than
>>>>>> conventional UTM's combined with Conventional Turing machine
>>>>>> descriptions their essence is already fully understood.
>>>>>>
>>>>>> The input to Olcott machines can simply be the conventional
>>>>>> space delimited Turing Machine input followed by four spaces.
>>>>>>
>>>>>> This is followed by the machine description of the machine
>>>>>> that the UTM is simulating followed by four more spaces.
>>>>>
>>>>> To make the Linz proof work properly with Olcott machines, Ĥ should
>>>>> search for 4 spaces, delete its own machine description, and then
>>>>> insert the description of the original H. Then the Linz proof works
>>>>> for Olcott machines.
>>>>
>>>> That someone can intentionally break an otherwise correct
>>>> halt decider
>>>
>>> It always gives exactly the same answer as the working one, so how is
>>> it possibly broken?
>>>
>>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy ∞ // Ĥ applied to ⟨Ĥ⟩ halts
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn   // Ĥ applied to ⟨Ĥ⟩ does not halt
>>
>> When this is executed in an Olcott machine then
>> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> is a different computation than H ⟨Ĥ⟩ ⟨Ĥ⟩ <H>
>
> WHY?
>
> The Master UTM will not change the usage at H^.H, because that is just
> an internal state of the Machine H^
>

The ONLY thing that the master UTM does differently is append
the TMD to the TMD's own tape.

> At that point we have the IDENTICAL set of transitions (with just an
> equivalence mapping of state numbers) as H will have, and the EXACT same
> input as H

it is stipulated by the definition of Olcott machines
Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> // last element is <Ĥ> (not H)
H ⟨Ĥ⟩ ⟨Ĥ⟩ <H> // last element is <H> (not Ĥ)
That the last element of the input to Ĥ.H and H <is> different.

>>
>> No matter how Ĥ ⟨Ĥ⟩ screws itself up this can have no
>> effect on H ⟨Ĥ⟩ ⟨Ĥ⟩.
>>
>> The Olcott machine H ⟨Ĥ⟩ ⟨Ĥ⟩ <H> can see that it does not
>> call itself in recursive simulation.
>
> As will the machine at H^.H, since the description it thinks it is
> doesn't match the machine that gets called.

A simply string comparison of the finite strings
⟨Ĥ⟩ and <Ĥ> proves that they are the same.

>>
>> The Olcott machine Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> can see that it calls
>> itself in recursive simulation unless it discards this
>> ability. In either case it cannot fool H, it either halts
>> or fails to halt.
>>
>
> But that isn't what H^.H gets called with.

Olcott machines always append the TMD to the end of the tape
of this TMD.

This means that they are an actual input to every TMD that
does not ignore them.

>
> The code between H^.q0 and H^.H removes the <H^> and replaces it with
> <H>, so the copy of H at H^.H can't tell the difference.
>

Ĥ cannot possibly do this because it has no access to nor
even knows the existence of any external ⟨H⟩.

> You don't seem to understand what a Turing Machine CAN do.
>

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

On 3/7/2024 8:45 PM, Richard Damon wrote:
> On 3/7/24 6:05 PM, olcott wrote:
>> On 3/7/2024 7:36 PM, immibis wrote:
>>> On 7/03/24 18:14, olcott wrote:
>>>> It is an easily fact that a correct and complete simulation of
>>>> the input to H(D,D) and the input to Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ cannot possibly halt.
>>>
>>> It can if H(D,D) returns 0.
>>
>> D simulated by H cannot possibly halt even if we simplify it to this:
>>
>> void D(void (*x)())
>> {
>>    H(x, x);
>> }
>>
>
> Nope, only if H actually does (or attempts to do) a complete simulation.
>

My point is that the infinite loop has no effect what-so-ever on
the ability of a termination analyzer to correctly analyze an
input such as either version of D.

> If H actually aborts its simulation and return 0, then a CORRECT
> simulation of the input to H will halt.
>

It is still the same paradox for a different reason.

> So, you are stuck, because Computations are based on deterministic
> algorithms. Either H's algorithm WILL continue to simulate through every
> thing it sees in its simulation of D, and then neither machine will
> halt, so H doesn't answer and is wrong.
>

Not at all. Olcott machines can do something that no Turing machine
can possibly do correctly determine that they themselves are called
in recursive simulation.

This same extra input that H(D,D) and H1(D,D) has is what enables
them to correctly compute different values.

> Or H gives up and decides it needs to stop to give an answer, but then,
> not seeing what D will do, is forced to "Guess", (and will always guess
> this input the same way) and when we actually run D, it gets to see how
> H guesses, and makes it wrong.
>
> You keep on presuming that the H in D will be somehow different then the
> H that is deciding on it, which is just a LIE.

I presume nothing and proved that Olcott machines have a power
that Turing machines do not have. They can (just like H and H1)
correctly determine when they themselves are called in recursive
simulation.

*It has taken me about two years to put this intuition into words*

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

On 3/7/24 7:29 PM, olcott wrote:
> On 3/7/2024 8:34 PM, Richard Damon wrote:
>> On 3/7/24 6:02 PM, olcott wrote:
>>> On 3/7/2024 7:35 PM, immibis wrote:
>>>> On 7/03/24 18:05, olcott wrote:
>>>>> On 3/7/2024 8:47 AM, immibis wrote:
>>>>>> On 7/03/24 03:40, olcott wrote:
>>>>>>> On 3/6/2024 8:22 PM, immibis wrote:
>>>>>>>> On 7/03/24 01:12, olcott wrote:
>>>>>>>>> On 3/6/2024 5:59 PM, immibis wrote:
>>>>>>>>>> On 7/03/24 00:55, olcott wrote:
>>>>>>>>>>> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn
>>>>>>>>>>> Correctly reports that Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ must abort its simulation.
>>>>>>>>>>>
>>>>>>>>>>> H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>>>>>>>>>> Correctly reports that H ⟨Ĥ⟩ ⟨Ĥ⟩ need not abort its simulation.
>>>>>>>>>>
>>>>>>>>>> What are the exact steps which the exact same program with the
>>>>>>>>>> exact same input uses to get two different results?
>>>>>>>>>> I saw x86utm. In x86utm there is a mistake because Ĥ.H is not
>>>>>>>>>> defined to do exactly the same steps as H, which means you
>>>>>>>>>> failed to do the Linz procedure.
>>>>>>>>>
>>>>>>>>> Both H(D,D) and H1(D,D) answer the exact same question:
>>>>>>>>> Can I continue to simulate my input without ever aborting it?
>>>>>>>>>
>>>>>>>>
>>>>>>>> Both H(D,D) and H1(D,D) are computer programs (or Turing
>>>>>>>> machines). They execute instructions (or transitions) in
>>>>>>>> sequence, determined by their programming and their input.
>>>>>>>
>>>>>>> Yet because they both know their own machine address
>>>>>>> they can both correctly determine whether or not they
>>>>>>> themselves are called in recursive simulation.
>>>>>>
>>>>>> They cannot do anything except for exactly what they are
>>>>>> programmed to do.
>>>>>
>>>>> H1(D,D) and H(D,D) are programmed to do this.
>>>>> Because H1(D,D) simulates D(D) that calls H(D,D) that
>>>>> aborts its simulation of D(D). H1 can see that its
>>>>> own simulated D(D) returns from its call to H(D,D).
>>>>>
>>>>>>>
>>>>>>> An Olcott machine can perform an equivalent operation.
>>>>>>>
>>>>>>> Because Olcott machines are essentially nothing more than
>>>>>>> conventional UTM's combined with Conventional Turing machine
>>>>>>> descriptions their essence is already fully understood.
>>>>>>>
>>>>>>> The input to Olcott machines can simply be the conventional
>>>>>>> space delimited Turing Machine input followed by four spaces.
>>>>>>>
>>>>>>> This is followed by the machine description of the machine
>>>>>>> that the UTM is simulating followed by four more spaces.
>>>>>>
>>>>>> To make the Linz proof work properly with Olcott machines, Ĥ
>>>>>> should search for 4 spaces, delete its own machine description,
>>>>>> and then insert the description of the original H. Then the Linz
>>>>>> proof works for Olcott machines.
>>>>>
>>>>> That someone can intentionally break an otherwise correct
>>>>> halt decider
>>>>
>>>> It always gives exactly the same answer as the working one, so how
>>>> is it possibly broken?
>>>>
>>>
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy ∞ // Ĥ applied to ⟨Ĥ⟩ halts
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn   // Ĥ applied to ⟨Ĥ⟩ does not halt
>>>
>>> When this is executed in an Olcott machine then
>>> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> is a different computation than H ⟨Ĥ⟩ ⟨Ĥ⟩ <H>
>>
>> WHY?
>>
>> The Master UTM will not change the usage at H^.H, because that is just
>> an internal state of the Machine H^
>>
>
> The ONLY thing that the master UTM does differently is append
> the TMD to the TMD's own tape.

Right, so it gives H and H^ that input.

H^ can erase that input and replace it.

>
>> At that point we have the IDENTICAL set of transitions (with just an
>> equivalence mapping of state numbers) as H will have, and the EXACT
>> same input as H
>
> it is stipulated by the definition of Olcott machines
> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> // last element is <Ĥ> (not H)

Nope.

H^.H isn't a "Olcott Machine" it is a sub-machine of H^

Your Master UTM can't touch the tape here or it totally breaks the system.

It can only add the description at the beginning, as it doesn't know
what state in that machine are "sub-machines" and what are just parts of
the machine running.

You don't seem to understand much about Turing machines.

I seem to remember you bailed out after like the first part of the first
lesson.

>   H ⟨Ĥ⟩ ⟨Ĥ⟩ <H> // last element is <H> (not Ĥ)
> That the last element of the input to Ĥ.H and H <is> different.
>

Until the code in H^ between q0 and H^.H changes it.

>>>
>>> No matter how Ĥ ⟨Ĥ⟩ screws itself up this can have no
>>> effect on H ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>
>>> The Olcott machine H ⟨Ĥ⟩ ⟨Ĥ⟩ <H> can see that it does not
>>> call itself in recursive simulation.
>>
>> As will the machine at H^.H, since the description it thinks it is
>> doesn't match the machine that gets called.
>
> A simply string comparison of the finite strings
> ⟨Ĥ⟩ and <Ĥ> proves that they are the same.
>
>>>
>>> The Olcott machine Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> can see that it calls
>>> itself in recursive simulation unless it discards this
>>> ability. In either case it cannot fool H, it either halts
>>> or fails to halt.
>>>
>>
>> But that isn't what H^.H gets called with.
>
> Olcott machines always append the TMD to the end of the tape
> of this TMD.
So H^ STARTS with <H^> at the end. The Tape, BY DEFINITION, is writable.

That is sort of one problem with your x86UTM, its "tape" equivalent was
Read Only since it was executable code space.

>
> This means that they are an actual input to every TMD that
> does not ignore them.

Right, and H^ can change it.

>
>>
>> The code between H^.q0 and H^.H removes the <H^> and replaces it with
>> <H>, so the copy of H at H^.H can't tell the difference.
>>
>
> Ĥ cannot possibly do this because it has no access to nor
> even knows the existence of any external ⟨H⟩.

Of course it know about the ONE H that it is on a mission to make wrong.

So that H, and only that H gets confonded.

You sure seem dumb about that.

>
>> You don't seem to understand what a Turing Machine CAN do.
>>
>

On 3/7/24 7:39 PM, olcott wrote:
> On 3/7/2024 8:45 PM, Richard Damon wrote:
>> On 3/7/24 6:05 PM, olcott wrote:
>>> On 3/7/2024 7:36 PM, immibis wrote:
>>>> On 7/03/24 18:14, olcott wrote:
>>>>> It is an easily fact that a correct and complete simulation of
>>>>> the input to H(D,D) and the input to Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ cannot possibly halt.
>>>>
>>>> It can if H(D,D) returns 0.
>>>
>>> D simulated by H cannot possibly halt even if we simplify it to this:
>>>
>>> void D(void (*x)())
>>> {
>>>    H(x, x);
>>> }
>>>
>>
>> Nope, only if H actually does (or attempts to do) a complete simulation.
>>
>
> My point is that the infinite loop has no effect what-so-ever on
> the ability of a termination analyzer to correctly analyze an
> input such as either version of D.

Right, but the fact that D uses a copy of H does. H CAN'T just simulate
the input to the decision point, as if that is what is coded, it runs
forever. (YOu have shown that).

So, it MUST abort its simulation at some point in its execution trace,
which is BEFORE the simulated machine has shown H what this copy of
itself will do.

>
>> If H actually aborts its simulation and return 0, then a CORRECT
>> simulation of the input to H will halt.
>>
>
> It is still the same paradox for a different reason.

Nope.

Correct Simulation of the input (not by the decider) ALWAYS has a
definite behavior for any definite machine.

The paradox occurs when trying to DESIGN H, so you don't even HAVE an H
to ask about until you come up with an (incorrect) resolution of the
Paradox.

>
>> So, you are stuck, because Computations are based on deterministic
>> algorithms. Either H's algorithm WILL continue to simulate through
>> every thing it sees in its simulation of D, and then neither machine
>> will halt, so H doesn't answer and is wrong.
>>
>
> Not at all. Olcott machines can do something that no Turing machine
> can possibly do correctly determine that they themselves are called
> in recursive simulation.

Nope. Since H^ can LIE to the copy of H at H^.H, that H can't tell if it
is actually simulating a copy of the machine it is part of.

>
> This same extra input that H(D,D) and H1(D,D) has is what enables
> them to correctly compute different values.

Right, a TOP LEVEL H can detect if it is given the exact same
description of itself. SInce D has an H with a different description
(since the states have been remaped to arbitrary new state number) H can
no tell the D is using a copy of H.

The copy of H used by D, can be given the Description of a top level H,
instead of the description of H^, and so it can't tell that it is
getting into the recursive loop.

Thus, none of the H's will EVER abort their simulation.

>
>> Or H gives up and decides it needs to stop to give an answer, but
>> then, not seeing what D will do, is forced to "Guess", (and will
>> always guess this input the same way) and when we actually run D, it
>> gets to see how H guesses, and makes it wrong.
>>
>> You keep on presuming that the H in D will be somehow different then
>> the H that is deciding on it, which is just a LIE.
>
> I presume nothing and proved that Olcott machines have a power
> that Turing machines do not have. They can (just like H and H1)
> correctly determine when they themselves are called in recursive
> simulation.

Nope. You have yet to say what is wrong with my ^ template that break
you H's

>
> *It has taken me about two years to put this intuition into words*
>

And you are still wrong.

On 3/7/2024 9:53 PM, Richard Damon wrote:
> On 3/7/24 7:29 PM, olcott wrote:
>> On 3/7/2024 8:34 PM, Richard Damon wrote:
>>> On 3/7/24 6:02 PM, olcott wrote:
>>>> On 3/7/2024 7:35 PM, immibis wrote:
>>>>> On 7/03/24 18:05, olcott wrote:
>>>>>> On 3/7/2024 8:47 AM, immibis wrote:
>>>>>>> On 7/03/24 03:40, olcott wrote:
>>>>>>>> On 3/6/2024 8:22 PM, immibis wrote:
>>>>>>>>> On 7/03/24 01:12, olcott wrote:
>>>>>>>>>> On 3/6/2024 5:59 PM, immibis wrote:
>>>>>>>>>>> On 7/03/24 00:55, olcott wrote:
>>>>>>>>>>>> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn
>>>>>>>>>>>> Correctly reports that Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ must abort its simulation.
>>>>>>>>>>>>
>>>>>>>>>>>> H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>>>>>>>>>>> Correctly reports that H ⟨Ĥ⟩ ⟨Ĥ⟩ need not abort its simulation.
>>>>>>>>>>>
>>>>>>>>>>> What are the exact steps which the exact same program with
>>>>>>>>>>> the exact same input uses to get two different results?
>>>>>>>>>>> I saw x86utm. In x86utm there is a mistake because Ĥ.H is not
>>>>>>>>>>> defined to do exactly the same steps as H, which means you
>>>>>>>>>>> failed to do the Linz procedure.
>>>>>>>>>>
>>>>>>>>>> Both H(D,D) and H1(D,D) answer the exact same question:
>>>>>>>>>> Can I continue to simulate my input without ever aborting it?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Both H(D,D) and H1(D,D) are computer programs (or Turing
>>>>>>>>> machines). They execute instructions (or transitions) in
>>>>>>>>> sequence, determined by their programming and their input.
>>>>>>>>
>>>>>>>> Yet because they both know their own machine address
>>>>>>>> they can both correctly determine whether or not they
>>>>>>>> themselves are called in recursive simulation.
>>>>>>>
>>>>>>> They cannot do anything except for exactly what they are
>>>>>>> programmed to do.
>>>>>>
>>>>>> H1(D,D) and H(D,D) are programmed to do this.
>>>>>> Because H1(D,D) simulates D(D) that calls H(D,D) that
>>>>>> aborts its simulation of D(D). H1 can see that its
>>>>>> own simulated D(D) returns from its call to H(D,D).
>>>>>>
>>>>>>>>
>>>>>>>> An Olcott machine can perform an equivalent operation.
>>>>>>>>
>>>>>>>> Because Olcott machines are essentially nothing more than
>>>>>>>> conventional UTM's combined with Conventional Turing machine
>>>>>>>> descriptions their essence is already fully understood.
>>>>>>>>
>>>>>>>> The input to Olcott machines can simply be the conventional
>>>>>>>> space delimited Turing Machine input followed by four spaces.
>>>>>>>>
>>>>>>>> This is followed by the machine description of the machine
>>>>>>>> that the UTM is simulating followed by four more spaces.
>>>>>>>
>>>>>>> To make the Linz proof work properly with Olcott machines, Ĥ
>>>>>>> should search for 4 spaces, delete its own machine description,
>>>>>>> and then insert the description of the original H. Then the Linz
>>>>>>> proof works for Olcott machines.
>>>>>>
>>>>>> That someone can intentionally break an otherwise correct
>>>>>> halt decider
>>>>>
>>>>> It always gives exactly the same answer as the working one, so how
>>>>> is it possibly broken?
>>>>>
>>>>
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy ∞ // Ĥ applied to ⟨Ĥ⟩ halts
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn   // Ĥ applied to ⟨Ĥ⟩ does not halt
>>>>
>>>> When this is executed in an Olcott machine then
>>>> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> is a different computation than H ⟨Ĥ⟩ ⟨Ĥ⟩ <H>
>>>
>>> WHY?
>>>
>>> The Master UTM will not change the usage at H^.H, because that is
>>> just an internal state of the Machine H^
>>>
>>
>> The ONLY thing that the master UTM does differently is append
>> the TMD to the TMD's own tape.
>
> Right, so it gives H and H^ that input.
>
> H^ can erase that input and replace it.
>
>>
>>> At that point we have the IDENTICAL set of transitions (with just an
>>> equivalence mapping of state numbers) as H will have, and the EXACT
>>> same input as H
>>
>> it is stipulated by the definition of Olcott machines
>> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> // last element is <Ĥ> (not H)
>
> Nope.
>
> H^.H isn't a "Olcott Machine" it is a sub-machine of H^

You already know that there is no such thing as sub-machines of
Turing machines. Turing machines have a set of states and a tape.
They have no sub-machines.

>
> Your Master UTM can't touch the tape here or it totally breaks the system.
>

The master UTM is merely an ordinary UTM that always appends
the slaves TMD to the slaves tape. That is all that there is
to the master UTM.

> It can only add the description at the beginning, as it doesn't know
> what state in that machine are "sub-machines" and what are just parts of
> the machine running.
>

An ordinary UTM writes the input to the slaves tape.
The master UTM of Olcott machines simply adds one more step to this.

The master UTM is merely an ordinary UTM that always appends
the slaves TMD to the slaves tape. That is all that there is
to the master UTM.

> You don't seem to understand much about Turing machines.
>
> I seem to remember you bailed out after like the first part of the first
> lesson.
>

You can't point out an errors because there are no errors.
You keep saying things at least slightly incorrectly like
sub-machines of Turing machines, there is no such thing.

>>    H ⟨Ĥ⟩ ⟨Ĥ⟩ <H> // last element is <H> (not Ĥ)
>> That the last element of the input to Ĥ.H and H <is> different.
>>
>
> Until the code in H^ between q0 and H^.H changes it.

I have no idea what you are saying yet the only category that
it can be is that Ĥ tries to thwart its own internal termination
analyzer.

>>>>
>>>> No matter how Ĥ ⟨Ĥ⟩ screws itself up this can have no
>>>> effect on H ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>>
>>>> The Olcott machine H ⟨Ĥ⟩ ⟨Ĥ⟩ <H> can see that it does not
>>>> call itself in recursive simulation.
>>>
>>> As will the machine at H^.H, since the description it thinks it is
>>> doesn't match the machine that gets called.
>>
>> A simply string comparison of the finite strings
>> ⟨Ĥ⟩ and <Ĥ> proves that they are the same.
>>
>>>>
>>>> The Olcott machine Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> can see that it calls
>>>> itself in recursive simulation unless it discards this
>>>> ability. In either case it cannot fool H, it either halts
>>>> or fails to halt.
>>>>
>>>
>>> But that isn't what H^.H gets called with.
>>
>> Olcott machines always append the TMD to the end of the tape
>> of this TMD.
> So H^ STARTS with <H^> at the end. The Tape, BY DEFINITION, is writable.
>
> That is sort of one problem with your x86UTM, its "tape" equivalent was
> Read Only since it was executable code space.
>
>>
>> This means that they are an actual input to every TMD that
>> does not ignore them.
>
> Right, and H^ can change it.
>
>>
>>>
>>> The code between H^.q0 and H^.H removes the <H^> and replaces it with
>>> <H>, so the copy of H at H^.H can't tell the difference.
>>>
>>
>> Ĥ cannot possibly do this because it has no access to nor
>> even knows the existence of any external ⟨H⟩.
>
> Of course it know about the ONE H that it is on a mission to make wrong.

On 3/7/24 9:38 PM, olcott wrote:
> On 3/7/2024 9:53 PM, Richard Damon wrote:
>> On 3/7/24 7:29 PM, olcott wrote:
>>> On 3/7/2024 8:34 PM, Richard Damon wrote:
>>>> On 3/7/24 6:02 PM, olcott wrote:
>>>>> On 3/7/2024 7:35 PM, immibis wrote:
>>>>>> On 7/03/24 18:05, olcott wrote:
>>>>>>> On 3/7/2024 8:47 AM, immibis wrote:
>>>>>>>> On 7/03/24 03:40, olcott wrote:
>>>>>>>>> On 3/6/2024 8:22 PM, immibis wrote:
>>>>>>>>>> On 7/03/24 01:12, olcott wrote:
>>>>>>>>>>> On 3/6/2024 5:59 PM, immibis wrote:
>>>>>>>>>>>> On 7/03/24 00:55, olcott wrote:
>>>>>>>>>>>>> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn
>>>>>>>>>>>>> Correctly reports that Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ must abort its simulation.
>>>>>>>>>>>>>
>>>>>>>>>>>>> H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>>>>>>>>>>>> Correctly reports that H ⟨Ĥ⟩ ⟨Ĥ⟩ need not abort its
>>>>>>>>>>>>> simulation.
>>>>>>>>>>>>
>>>>>>>>>>>> What are the exact steps which the exact same program with
>>>>>>>>>>>> the exact same input uses to get two different results?
>>>>>>>>>>>> I saw x86utm. In x86utm there is a mistake because Ĥ.H is
>>>>>>>>>>>> not defined to do exactly the same steps as H, which means
>>>>>>>>>>>> you failed to do the Linz procedure.
>>>>>>>>>>>
>>>>>>>>>>> Both H(D,D) and H1(D,D) answer the exact same question:
>>>>>>>>>>> Can I continue to simulate my input without ever aborting it?
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Both H(D,D) and H1(D,D) are computer programs (or Turing
>>>>>>>>>> machines). They execute instructions (or transitions) in
>>>>>>>>>> sequence, determined by their programming and their input.
>>>>>>>>>
>>>>>>>>> Yet because they both know their own machine address
>>>>>>>>> they can both correctly determine whether or not they
>>>>>>>>> themselves are called in recursive simulation.
>>>>>>>>
>>>>>>>> They cannot do anything except for exactly what they are
>>>>>>>> programmed to do.
>>>>>>>
>>>>>>> H1(D,D) and H(D,D) are programmed to do this.
>>>>>>> Because H1(D,D) simulates D(D) that calls H(D,D) that
>>>>>>> aborts its simulation of D(D). H1 can see that its
>>>>>>> own simulated D(D) returns from its call to H(D,D).
>>>>>>>
>>>>>>>>>
>>>>>>>>> An Olcott machine can perform an equivalent operation.
>>>>>>>>>
>>>>>>>>> Because Olcott machines are essentially nothing more than
>>>>>>>>> conventional UTM's combined with Conventional Turing machine
>>>>>>>>> descriptions their essence is already fully understood.
>>>>>>>>>
>>>>>>>>> The input to Olcott machines can simply be the conventional
>>>>>>>>> space delimited Turing Machine input followed by four spaces.
>>>>>>>>>
>>>>>>>>> This is followed by the machine description of the machine
>>>>>>>>> that the UTM is simulating followed by four more spaces.
>>>>>>>>
>>>>>>>> To make the Linz proof work properly with Olcott machines, Ĥ
>>>>>>>> should search for 4 spaces, delete its own machine description,
>>>>>>>> and then insert the description of the original H. Then the Linz
>>>>>>>> proof works for Olcott machines.
>>>>>>>
>>>>>>> That someone can intentionally break an otherwise correct
>>>>>>> halt decider
>>>>>>
>>>>>> It always gives exactly the same answer as the working one, so how
>>>>>> is it possibly broken?
>>>>>>
>>>>>
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy ∞ // Ĥ applied to ⟨Ĥ⟩ halts
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn   // Ĥ applied to ⟨Ĥ⟩ does not halt
>>>>>
>>>>> When this is executed in an Olcott machine then
>>>>> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> is a different computation than H ⟨Ĥ⟩ ⟨Ĥ⟩ <H>
>>>>
>>>> WHY?
>>>>
>>>> The Master UTM will not change the usage at H^.H, because that is
>>>> just an internal state of the Machine H^
>>>>
>>>
>>> The ONLY thing that the master UTM does differently is append
>>> the TMD to the TMD's own tape.
>>
>> Right, so it gives H and H^ that input.
>>
>> H^ can erase that input and replace it.
>>
>>>
>>>> At that point we have the IDENTICAL set of transitions (with just an
>>>> equivalence mapping of state numbers) as H will have, and the EXACT
>>>> same input as H
>>>
>>> it is stipulated by the definition of Olcott machines
>>> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> // last element is <Ĥ> (not H)
>>
>> Nope.
>>
>> H^.H isn't a "Olcott Machine" it is a sub-machine of H^
>
> You already know that there is no such thing as sub-machines of
> Turing machines. Turing machines have a set of states and a tape.
> They have no sub-machines.

A "Sub-Machine" of a Turing Machine is where you put a copy of another
Turing Machine into the state space of the overall/parent machine,

When the machine H^ reaches the state H^.H, then it encounters the EXACT
sequence of states (after the eqivalence mapping generated when
inserting them H's q0 -> H^.Hqo and so on)

It is called a sub-machine because it acts largely as if that Turing
Machihe "called" the equivalent Turing Machine as a subroutine, only the
machine code was expanded "inline".

>
>>
>> Your Master UTM can't touch the tape here or it totally breaks the
>> system.
>>
>
> The master UTM is merely an ordinary UTM that always appends
> the slaves TMD to the slaves tape. That is all that there is
> to the master UTM.

Right, so it can't change the tape when H^ enters state H^.H and then
runs the exact sequence of steps if the machine H with the exact same

>
>> It can only add the description at the beginning, as it doesn't know
>> what state in that machine are "sub-machines" and what are just parts
>> of the machine running.
>>
>
> An ordinary UTM writes the input to the slaves tape.
> The master UTM of Olcott machines simply adds one more step to this.

Right.

>
> The master UTM is merely an ordinary UTM that always appends
> the slaves TMD to the slaves tape. That is all that there is
> to the master UTM.

Right. so it can't interfere with H^ "lying" to the copy of H that it
has at H^.H to make it think it is the top level machine running.

>
>> You don't seem to understand much about Turing machines.
>>
>> I seem to remember you bailed out after like the first part of the
>> first lesson.
>>
>
> You can't point out an errors because there are no errors.
> You keep saying things at least slightly incorrectly like
> sub-machines of Turing machines, there is no such thing.

Sure there is.

You are just too dumb to understand.

In fact, if you actually try to do work with Turing Machines, the
concept of sub-machines is important to manage the complexity.

Yes, the actual encoding of the Turing Machine doesn't indicate that a
submachine exist at a location, except maybe the state names (which get
lost when you "compile" them into numbers) but often at the design level
they show up in the names.

Why do you think the state is called H^.Hq0, that is the q0 state of the
H sub-machine of the Turing Machine H^.

On 3/8/2024 12:09 AM, Richard Damon wrote:
> On 3/7/24 9:38 PM, olcott wrote:
>> On 3/7/2024 9:53 PM, Richard Damon wrote:
>>> On 3/7/24 7:29 PM, olcott wrote:
>>>> On 3/7/2024 8:34 PM, Richard Damon wrote:
>>>>> On 3/7/24 6:02 PM, olcott wrote:
>>>>>> On 3/7/2024 7:35 PM, immibis wrote:
>>>>>>> On 7/03/24 18:05, olcott wrote:
>>>>>>>> On 3/7/2024 8:47 AM, immibis wrote:
>>>>>>>>> On 7/03/24 03:40, olcott wrote:
>>>>>>>>>> On 3/6/2024 8:22 PM, immibis wrote:
>>>>>>>>>>> On 7/03/24 01:12, olcott wrote:
>>>>>>>>>>>> On 3/6/2024 5:59 PM, immibis wrote:
>>>>>>>>>>>>> On 7/03/24 00:55, olcott wrote:
>>>>>>>>>>>>>> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn
>>>>>>>>>>>>>> Correctly reports that Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ must abort its simulation.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>>>>>>>>>>>>> Correctly reports that H ⟨Ĥ⟩ ⟨Ĥ⟩ need not abort its
>>>>>>>>>>>>>> simulation.
>>>>>>>>>>>>>
>>>>>>>>>>>>> What are the exact steps which the exact same program with
>>>>>>>>>>>>> the exact same input uses to get two different results?
>>>>>>>>>>>>> I saw x86utm. In x86utm there is a mistake because Ĥ.H is
>>>>>>>>>>>>> not defined to do exactly the same steps as H, which means
>>>>>>>>>>>>> you failed to do the Linz procedure.
>>>>>>>>>>>>
>>>>>>>>>>>> Both H(D,D) and H1(D,D) answer the exact same question:
>>>>>>>>>>>> Can I continue to simulate my input without ever aborting it?
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Both H(D,D) and H1(D,D) are computer programs (or Turing
>>>>>>>>>>> machines). They execute instructions (or transitions) in
>>>>>>>>>>> sequence, determined by their programming and their input.
>>>>>>>>>>
>>>>>>>>>> Yet because they both know their own machine address
>>>>>>>>>> they can both correctly determine whether or not they
>>>>>>>>>> themselves are called in recursive simulation.
>>>>>>>>>
>>>>>>>>> They cannot do anything except for exactly what they are
>>>>>>>>> programmed to do.
>>>>>>>>
>>>>>>>> H1(D,D) and H(D,D) are programmed to do this.
>>>>>>>> Because H1(D,D) simulates D(D) that calls H(D,D) that
>>>>>>>> aborts its simulation of D(D). H1 can see that its
>>>>>>>> own simulated D(D) returns from its call to H(D,D).
>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> An Olcott machine can perform an equivalent operation.
>>>>>>>>>>
>>>>>>>>>> Because Olcott machines are essentially nothing more than
>>>>>>>>>> conventional UTM's combined with Conventional Turing machine
>>>>>>>>>> descriptions their essence is already fully understood.
>>>>>>>>>>
>>>>>>>>>> The input to Olcott machines can simply be the conventional
>>>>>>>>>> space delimited Turing Machine input followed by four spaces.
>>>>>>>>>>
>>>>>>>>>> This is followed by the machine description of the machine
>>>>>>>>>> that the UTM is simulating followed by four more spaces.
>>>>>>>>>
>>>>>>>>> To make the Linz proof work properly with Olcott machines, Ĥ
>>>>>>>>> should search for 4 spaces, delete its own machine description,
>>>>>>>>> and then insert the description of the original H. Then the
>>>>>>>>> Linz proof works for Olcott machines.
>>>>>>>>
>>>>>>>> That someone can intentionally break an otherwise correct
>>>>>>>> halt decider
>>>>>>>
>>>>>>> It always gives exactly the same answer as the working one, so
>>>>>>> how is it possibly broken?
>>>>>>>
>>>>>>
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy ∞ // Ĥ applied to ⟨Ĥ⟩ halts
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn   // Ĥ applied to ⟨Ĥ⟩ does not
>>>>>> halt
>>>>>>
>>>>>> When this is executed in an Olcott machine then
>>>>>> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> is a different computation than H ⟨Ĥ⟩ ⟨Ĥ⟩ <H>
>>>>>
>>>>> WHY?
>>>>>
>>>>> The Master UTM will not change the usage at H^.H, because that is
>>>>> just an internal state of the Machine H^
>>>>>
>>>>
>>>> The ONLY thing that the master UTM does differently is append
>>>> the TMD to the TMD's own tape.
>>>
>>> Right, so it gives H and H^ that input.
>>>
>>> H^ can erase that input and replace it.
>>>
>>>>
>>>>> At that point we have the IDENTICAL set of transitions (with just
>>>>> an equivalence mapping of state numbers) as H will have, and the
>>>>> EXACT same input as H
>>>>
>>>> it is stipulated by the definition of Olcott machines
>>>> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> // last element is <Ĥ> (not H)
>>>
>>> Nope.
>>>
>>> H^.H isn't a "Olcott Machine" it is a sub-machine of H^
>>
>> You already know that there is no such thing as sub-machines of
>> Turing machines. Turing machines have a set of states and a tape.
>> They have no sub-machines.
>
> A "Sub-Machine" of a Turing Machine is where you put a copy of another
> Turing Machine into the state space of the overall/parent machine,
>
> When the machine H^ reaches the state H^.H, then it encounters the EXACT
> sequence of states (after the eqivalence mapping generated when
> inserting them H's q0 -> H^.Hqo and so on)
>
> It is called a sub-machine because it acts largely as if that Turing
> Machihe "called" the equivalent Turing Machine as a subroutine, only the
> machine code was expanded "inline".

There is no way that any conventional Turing machine can tell
that the states of another Turing machine are embedded withing it.

>>
>>>
>>> Your Master UTM can't touch the tape here or it totally breaks the
>>> system.
>>>
>>
>> The master UTM is merely an ordinary UTM that always appends
>> the slaves TMD to the slaves tape. That is all that there is
>> to the master UTM.
>
> Right, so it can't change the tape when H^ enters state H^.H and then
> runs the exact sequence of steps if the machine H with the exact same

Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> immediately detects that is about to simulate a
copy of itself with a copy of its own input thus immediately
detects recursive simulation just like H(D,D).

H ⟨Ĥ⟩ ⟨Ĥ⟩ <H> immediately detects that is NOT about to simulate a
copy of itself with a copy of its own input thus immediately
rejects recursive simulation just like H1(D,D).

>>
>>> It can only add the description at the beginning, as it doesn't know
>>> what state in that machine are "sub-machines" and what are just parts
>>> of the machine running.
>>>
>>
>> An ordinary UTM writes the input to the slaves tape.
>> The master UTM of Olcott machines simply adds one more step to this.
>
> Right.
>
>>
>> The master UTM is merely an ordinary UTM that always appends
>> the slaves TMD to the slaves tape. That is all that there is
>> to the master UTM.
>
> Right. so it can't interfere with H^ "lying" to the copy of H that it
> has at H^.H to make it think it is the top level machine running.
>
>>
>>> You don't seem to understand much about Turing machines.
>>>
>>> I seem to remember you bailed out after like the first part of the
>>> first lesson.
>>>
>>
>> You can't point out an errors because there are no errors.
>> You keep saying things at least slightly incorrectly like
>> sub-machines of Turing machines, there is no such thing.
>
> Sure there is.
>
> You are just too dumb to understand.
>
> In fact, if you actually try to do work with Turing Machines, the
> concept of sub-machines is important to manage the complexity.
>
> Yes, the actual encoding of the Turing Machine doesn't indicate that a
> submachine exist at a location, except maybe the state names (which get
> lost when you "compile" them into numbers) but often at the design level
> they show up in the names.
>

On 3/7/24 10:30 PM, olcott wrote:
> On 3/8/2024 12:09 AM, Richard Damon wrote:
>> On 3/7/24 9:38 PM, olcott wrote:
>>> On 3/7/2024 9:53 PM, Richard Damon wrote:
>>>> On 3/7/24 7:29 PM, olcott wrote:
>>>>> On 3/7/2024 8:34 PM, Richard Damon wrote:
>>>>>> On 3/7/24 6:02 PM, olcott wrote:
>>>>>>> On 3/7/2024 7:35 PM, immibis wrote:
>>>>>>>> On 7/03/24 18:05, olcott wrote:
>>>>>>>>> On 3/7/2024 8:47 AM, immibis wrote:
>>>>>>>>>> On 7/03/24 03:40, olcott wrote:
>>>>>>>>>>> On 3/6/2024 8:22 PM, immibis wrote:
>>>>>>>>>>>> On 7/03/24 01:12, olcott wrote:
>>>>>>>>>>>>> On 3/6/2024 5:59 PM, immibis wrote:
>>>>>>>>>>>>>> On 7/03/24 00:55, olcott wrote:
>>>>>>>>>>>>>>> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn
>>>>>>>>>>>>>>> Correctly reports that Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ must abort its
>>>>>>>>>>>>>>> simulation.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>>>>>>>>>>>>>> Correctly reports that H ⟨Ĥ⟩ ⟨Ĥ⟩ need not abort its
>>>>>>>>>>>>>>> simulation.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> What are the exact steps which the exact same program with
>>>>>>>>>>>>>> the exact same input uses to get two different results?
>>>>>>>>>>>>>> I saw x86utm. In x86utm there is a mistake because Ĥ.H is
>>>>>>>>>>>>>> not defined to do exactly the same steps as H, which means
>>>>>>>>>>>>>> you failed to do the Linz procedure.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Both H(D,D) and H1(D,D) answer the exact same question:
>>>>>>>>>>>>> Can I continue to simulate my input without ever aborting it?
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Both H(D,D) and H1(D,D) are computer programs (or Turing
>>>>>>>>>>>> machines). They execute instructions (or transitions) in
>>>>>>>>>>>> sequence, determined by their programming and their input.
>>>>>>>>>>>
>>>>>>>>>>> Yet because they both know their own machine address
>>>>>>>>>>> they can both correctly determine whether or not they
>>>>>>>>>>> themselves are called in recursive simulation.
>>>>>>>>>>
>>>>>>>>>> They cannot do anything except for exactly what they are
>>>>>>>>>> programmed to do.
>>>>>>>>>
>>>>>>>>> H1(D,D) and H(D,D) are programmed to do this.
>>>>>>>>> Because H1(D,D) simulates D(D) that calls H(D,D) that
>>>>>>>>> aborts its simulation of D(D). H1 can see that its
>>>>>>>>> own simulated D(D) returns from its call to H(D,D).
>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> An Olcott machine can perform an equivalent operation.
>>>>>>>>>>>
>>>>>>>>>>> Because Olcott machines are essentially nothing more than
>>>>>>>>>>> conventional UTM's combined with Conventional Turing machine
>>>>>>>>>>> descriptions their essence is already fully understood.
>>>>>>>>>>>
>>>>>>>>>>> The input to Olcott machines can simply be the conventional
>>>>>>>>>>> space delimited Turing Machine input followed by four spaces.
>>>>>>>>>>>
>>>>>>>>>>> This is followed by the machine description of the machine
>>>>>>>>>>> that the UTM is simulating followed by four more spaces.
>>>>>>>>>>
>>>>>>>>>> To make the Linz proof work properly with Olcott machines, Ĥ
>>>>>>>>>> should search for 4 spaces, delete its own machine
>>>>>>>>>> description, and then insert the description of the original
>>>>>>>>>> H. Then the Linz proof works for Olcott machines.
>>>>>>>>>
>>>>>>>>> That someone can intentionally break an otherwise correct
>>>>>>>>> halt decider
>>>>>>>>
>>>>>>>> It always gives exactly the same answer as the working one, so
>>>>>>>> how is it possibly broken?
>>>>>>>>
>>>>>>>
>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy ∞ // Ĥ applied to ⟨Ĥ⟩ halts
>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn   // Ĥ applied to ⟨Ĥ⟩ does not
>>>>>>> halt
>>>>>>>
>>>>>>> When this is executed in an Olcott machine then
>>>>>>> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> is a different computation than H ⟨Ĥ⟩ ⟨Ĥ⟩ <H>
>>>>>>
>>>>>> WHY?
>>>>>>
>>>>>> The Master UTM will not change the usage at H^.H, because that is
>>>>>> just an internal state of the Machine H^
>>>>>>
>>>>>
>>>>> The ONLY thing that the master UTM does differently is append
>>>>> the TMD to the TMD's own tape.
>>>>
>>>> Right, so it gives H and H^ that input.
>>>>
>>>> H^ can erase that input and replace it.
>>>>
>>>>>
>>>>>> At that point we have the IDENTICAL set of transitions (with just
>>>>>> an equivalence mapping of state numbers) as H will have, and the
>>>>>> EXACT same input as H
>>>>>
>>>>> it is stipulated by the definition of Olcott machines
>>>>> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> // last element is <Ĥ> (not H)
>>>>
>>>> Nope.
>>>>
>>>> H^.H isn't a "Olcott Machine" it is a sub-machine of H^
>>>
>>> You already know that there is no such thing as sub-machines of
>>> Turing machines. Turing machines have a set of states and a tape.
>>> They have no sub-machines.
>>
>> A "Sub-Machine" of a Turing Machine is where you put a copy of another
>> Turing Machine into the state space of the overall/parent machine,
>>
>> When the machine H^ reaches the state H^.H, then it encounters the
>> EXACT sequence of states (after the eqivalence mapping generated when
>> inserting them H's q0 -> H^.Hqo and so on)
>>
>> It is called a sub-machine because it acts largely as if that Turing
>> Machihe "called" the equivalent Turing Machine as a subroutine, only
>> the machine code was expanded "inline".
>
> There is no way that any conventional Turing machine can tell
> that the states of another Turing machine are embedded withing it.

It doesn't need to "KNOW", but it HAS THEM there.

It was DESIGNED that way, so the programmer knows what he did.

I think your brain popped a gasket somewhere and is frantically trying
to make sense of the world that is crashind down around you.

>
>>>
>>>>
>>>> Your Master UTM can't touch the tape here or it totally breaks the
>>>> system.
>>>>
>>>
>>> The master UTM is merely an ordinary UTM that always appends
>>> the slaves TMD to the slaves tape. That is all that there is
>>> to the master UTM.
>>
>> Right, so it can't change the tape when H^ enters state H^.H and then
>> runs the exact sequence of steps if the machine H with the exact same
>
> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> immediately detects that is about to simulate a
> copy of itself with a copy of its own input thus immediately
> detects recursive simulation just like H(D,D).

On 3/8/2024 12:48 AM, Richard Damon wrote:
> On 3/7/24 10:30 PM, olcott wrote:
>> On 3/8/2024 12:09 AM, Richard Damon wrote:
>>> On 3/7/24 9:38 PM, olcott wrote:
>>>> On 3/7/2024 9:53 PM, Richard Damon wrote:
>>>>> On 3/7/24 7:29 PM, olcott wrote:
>>>>>> On 3/7/2024 8:34 PM, Richard Damon wrote:
>>>>>>> On 3/7/24 6:02 PM, olcott wrote:
>>>>>>>> On 3/7/2024 7:35 PM, immibis wrote:
>>>>>>>>> On 7/03/24 18:05, olcott wrote:
>>>>>>>>>> On 3/7/2024 8:47 AM, immibis wrote:
>>>>>>>>>>> On 7/03/24 03:40, olcott wrote:
>>>>>>>>>>>> On 3/6/2024 8:22 PM, immibis wrote:
>>>>>>>>>>>>> On 7/03/24 01:12, olcott wrote:
>>>>>>>>>>>>>> On 3/6/2024 5:59 PM, immibis wrote:
>>>>>>>>>>>>>>> On 7/03/24 00:55, olcott wrote:
>>>>>>>>>>>>>>>> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn
>>>>>>>>>>>>>>>> Correctly reports that Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ must abort its
>>>>>>>>>>>>>>>> simulation.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>>>>>>>>>>>>>>> Correctly reports that H ⟨Ĥ⟩ ⟨Ĥ⟩ need not abort its
>>>>>>>>>>>>>>>> simulation.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> What are the exact steps which the exact same program
>>>>>>>>>>>>>>> with the exact same input uses to get two different results?
>>>>>>>>>>>>>>> I saw x86utm. In x86utm there is a mistake because Ĥ.H is
>>>>>>>>>>>>>>> not defined to do exactly the same steps as H, which
>>>>>>>>>>>>>>> means you failed to do the Linz procedure.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Both H(D,D) and H1(D,D) answer the exact same question:
>>>>>>>>>>>>>> Can I continue to simulate my input without ever aborting it?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Both H(D,D) and H1(D,D) are computer programs (or Turing
>>>>>>>>>>>>> machines). They execute instructions (or transitions) in
>>>>>>>>>>>>> sequence, determined by their programming and their input.
>>>>>>>>>>>>
>>>>>>>>>>>> Yet because they both know their own machine address
>>>>>>>>>>>> they can both correctly determine whether or not they
>>>>>>>>>>>> themselves are called in recursive simulation.
>>>>>>>>>>>
>>>>>>>>>>> They cannot do anything except for exactly what they are
>>>>>>>>>>> programmed to do.
>>>>>>>>>>
>>>>>>>>>> H1(D,D) and H(D,D) are programmed to do this.
>>>>>>>>>> Because H1(D,D) simulates D(D) that calls H(D,D) that
>>>>>>>>>> aborts its simulation of D(D). H1 can see that its
>>>>>>>>>> own simulated D(D) returns from its call to H(D,D).
>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> An Olcott machine can perform an equivalent operation.
>>>>>>>>>>>>
>>>>>>>>>>>> Because Olcott machines are essentially nothing more than
>>>>>>>>>>>> conventional UTM's combined with Conventional Turing machine
>>>>>>>>>>>> descriptions their essence is already fully understood.
>>>>>>>>>>>>
>>>>>>>>>>>> The input to Olcott machines can simply be the conventional
>>>>>>>>>>>> space delimited Turing Machine input followed by four spaces.
>>>>>>>>>>>>
>>>>>>>>>>>> This is followed by the machine description of the machine
>>>>>>>>>>>> that the UTM is simulating followed by four more spaces.
>>>>>>>>>>>
>>>>>>>>>>> To make the Linz proof work properly with Olcott machines, Ĥ
>>>>>>>>>>> should search for 4 spaces, delete its own machine
>>>>>>>>>>> description, and then insert the description of the original
>>>>>>>>>>> H. Then the Linz proof works for Olcott machines.
>>>>>>>>>>
>>>>>>>>>> That someone can intentionally break an otherwise correct
>>>>>>>>>> halt decider
>>>>>>>>>
>>>>>>>>> It always gives exactly the same answer as the working one, so
>>>>>>>>> how is it possibly broken?
>>>>>>>>>
>>>>>>>>
>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy ∞ // Ĥ applied to ⟨Ĥ⟩ halts
>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn   // Ĥ applied to ⟨Ĥ⟩ does
>>>>>>>> not halt
>>>>>>>>
>>>>>>>> When this is executed in an Olcott machine then
>>>>>>>> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> is a different computation than H ⟨Ĥ⟩ ⟨Ĥ⟩ <H>
>>>>>>>
>>>>>>> WHY?
>>>>>>>
>>>>>>> The Master UTM will not change the usage at H^.H, because that is
>>>>>>> just an internal state of the Machine H^
>>>>>>>
>>>>>>
>>>>>> The ONLY thing that the master UTM does differently is append
>>>>>> the TMD to the TMD's own tape.
>>>>>
>>>>> Right, so it gives H and H^ that input.
>>>>>
>>>>> H^ can erase that input and replace it.
>>>>>
>>>>>>
>>>>>>> At that point we have the IDENTICAL set of transitions (with just
>>>>>>> an equivalence mapping of state numbers) as H will have, and the
>>>>>>> EXACT same input as H
>>>>>>
>>>>>> it is stipulated by the definition of Olcott machines
>>>>>> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> // last element is <Ĥ> (not H)
>>>>>
>>>>> Nope.
>>>>>
>>>>> H^.H isn't a "Olcott Machine" it is a sub-machine of H^
>>>>
>>>> You already know that there is no such thing as sub-machines of
>>>> Turing machines. Turing machines have a set of states and a tape.
>>>> They have no sub-machines.
>>>
>>> A "Sub-Machine" of a Turing Machine is where you put a copy of
>>> another Turing Machine into the state space of the overall/parent
>>> machine,
>>>
>>> When the machine H^ reaches the state H^.H, then it encounters the
>>> EXACT sequence of states (after the eqivalence mapping generated when
>>> inserting them H's q0 -> H^.Hqo and so on)
>>>
>>> It is called a sub-machine because it acts largely as if that Turing
>>> Machihe "called" the equivalent Turing Machine as a subroutine, only
>>> the machine code was expanded "inline".
>>
>> There is no way that any conventional Turing machine can tell
>> that the states of another Turing machine are embedded withing it.
>
> It doesn't need to "KNOW", but it HAS THEM there.
>
> It was DESIGNED that way, so the programmer knows what he did.
>

immibis thought that Ĥ could copy external <H> on top of internal <Ĥ>
Your words seemed to agree with this.

> I think your brain popped a gasket somewhere and is frantically trying
> to make sense of the world that is crashind down around you.
>
>>
>>>>
>>>>>
>>>>> Your Master UTM can't touch the tape here or it totally breaks the
>>>>> system.
>>>>>
>>>>
>>>> The master UTM is merely an ordinary UTM that always appends
>>>> the slaves TMD to the slaves tape. That is all that there is
>>>> to the master UTM.
>>>
>>> Right, so it can't change the tape when H^ enters state H^.H and then
>>> runs the exact sequence of steps if the machine H with the exact same
>>
>> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> immediately detects that is about to simulate a
>> copy of itself with a copy of its own input thus immediately
>> detects recursive simulation just like H(D,D).
>
> But that isn't what happens.
>
> You seem stuck in your lie.
>
> H^ gets to H^.Hq0 (H^) (H^) <H> not <H^> because that is what H^ needs
> to do to meet its mission.
>
> Your are just stuck with your Strawman, maybe it is more of a tar-baby
> to you.
>
>>
>> H ⟨Ĥ⟩ ⟨Ĥ⟩ <H> immediately detects that is NOT about to simulate a
>> copy of itself with a copy of its own input thus immediately
>> rejects recursive simulation just like H1(D,D).
>
> ?? H (H^) (H^) <H> isn't going to even TRY to see what H^ (H^) <H^>
> would do?
>
> I guess you admit if just FAILS as a any decider.
>
>>
>>>>
>>>>> It can only add the description at the beginning, as it doesn't
>>>>> know what state in that machine are "sub-machines" and what are
>>>>> just parts of the machine running.
>>>>>
>>>>
>>>> An ordinary UTM writes the input to the slaves tape.
>>>> The master UTM of Olcott machines simply adds one more step to this.
>>>
>>> Right.
>>>
>>>>
>>>> The master UTM is merely an ordinary UTM that always appends
>>>> the slaves TMD to the slaves tape. That is all that there is
>>>> to the master UTM.
>>>
>>> Right. so it can't interfere with H^ "lying" to the copy of H that it
>>> has at H^.H to make it think it is the top level machine running.
>>>
>>>>
>>>>> You don't seem to understand much about Turing machines.
>>>>>
>>>>> I seem to remember you bailed out after like the first part of the
>>>>> first lesson.
>>>>>
>>>>
>>>> You can't point out an errors because there are no errors.
>>>> You keep saying things at least slightly incorrectly like
>>>> sub-machines of Turing machines, there is no such thing.
>>>
>>> Sure there is.
>>>
>>> You are just too dumb to understand.
>>>
>>> In fact, if you actually try to do work with Turing Machines, the
>>> concept of sub-machines is important to manage the complexity.
>>>
>>> Yes, the actual encoding of the Turing Machine doesn't indicate that
>>> a submachine exist at a location, except maybe the state names (which
>>> get lost when you "compile" them into numbers) but often at the
>>> design level they show up in the names.
>>>
>>
>> The machine itself has no idea of this thus cannot use it in
>> its computation in any way. It cannot copy the states of an
>> external H because it does not even know that an external H exists.
>
> Machines do what they are programmed to do.
>
> Thus, if programmed to do that, they will.
>
> You are just stuck in your "thinking machine" model aren't you, which
> just shows how ignorant you are of how computers actually work.
>
> That is why you are just a pathetic ignorant pathological lying idiot.
>
>>
>>> Why do you think the state is called H^.Hq0, that is the q0 state of
>>> the H sub-machine of the Turing Machine H^.
>>
>> That is only for human consumption machines only have natural numbers.
>
> Nope. Turing Machines have "states" that can be represented how ever we
> want.
>
> When we represent them, we might use a numeric encoding for convience,
> but that is only an ENCODING of a number, not a number itself.
>
> Turing Machine can't handle actual numbers, just encodings of numbers.
>
> Don't you remeber you lessons on how to write Turing Machines and how to
> encode inputs?
>
>>
>>>>
>>>>>>    H ⟨Ĥ⟩ ⟨Ĥ⟩ <H> // last element is <H> (not Ĥ)
>>>>>> That the last element of the input to Ĥ.H and H <is> different.
>>>>>>
>>>>>
>>>>> Until the code in H^ between q0 and H^.H changes it.
>>>>
>>>> I have no idea what you are saying yet the only category that
>>>> it can be is that Ĥ tries to thwart its own internal termination
>>>> analyzer.
>>>
>>> Right, it sets up its copy of H so that it doesn't know it is part of
>>> a larger computation so it answer just like the actual top level H.
>>>
>>> And of course you have no idea, because you have no idea how Turing
>>> machines actually work.
>>>
>>>>
>>>>>>>>
>>>>>>>> No matter how Ĥ ⟨Ĥ⟩ screws itself up this can have no
>>>>>>>> effect on H ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>>>>>>
>>>>>>>> The Olcott machine H ⟨Ĥ⟩ ⟨Ĥ⟩ <H> can see that it does not
>>>>>>>> call itself in recursive simulation.
>>>>>>>
>>>>>>> As will the machine at H^.H, since the description it thinks it
>>>>>>> is doesn't match the machine that gets called.
>>>>>>
>>>>>> A simply string comparison of the finite strings
>>>>>> ⟨Ĥ⟩ and <Ĥ> proves that they are the same.
>>>>>>
>>>>>>>>
>>>>>>>> The Olcott machine Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> can see that it calls
>>>>>>>> itself in recursive simulation unless it discards this
>>>>>>>> ability. In either case it cannot fool H, it either halts
>>>>>>>> or fails to halt.
>>>>>>>>
>>>>>>>
>>>>>>> But that isn't what H^.H gets called with.
>>>>>>
>>>>>> Olcott machines always append the TMD to the end of the tape
>>>>>> of this TMD.
>>>>> So H^ STARTS with <H^> at the end. The Tape, BY DEFINITION, is
>>>>> writable.
>>>>>
>>>>> That is sort of one problem with your x86UTM, its "tape" equivalent
>>>>> was Read Only since it was executable code space.
>>>>>
>>>>>>
>>>>>> This means that they are an actual input to every TMD that
>>>>>> does not ignore them.
>>>>>
>>>>> Right, and H^ can change it.
>>>>>
>>>>>>
>>>>>>>
>>>>>>> The code between H^.q0 and H^.H removes the <H^> and replaces it
>>>>>>> with <H>, so the copy of H at H^.H can't tell the difference.
>>>>>>>
>>>>>>
>>>>>> Ĥ cannot possibly do this because it has no access to nor
>>>>>> even knows the existence of any external ⟨H⟩.
>>>>>
>>>>> Of course it know about the ONE H that it is on a mission to make
>>>>> wrong.
>>>>
>>>> Most of the halting problem proofs fail to understand
>>>> that an actual Turing machine cannot actually call
>>>> another external Turing machine. This means that it
>>>> cannot actually confound an external Turing machine.
>>>
>>> But it CAN copy the algorithm of one.
>>>
>>
>> One Turing machine cannot copy another one.
>
> The person creating it can.
>
>>
>>> You don't seem to understand how that works.
>>>
>>> It is sort of like an inline function in C, the function that "calls"
>>> the inline function actually has no call instruction, but the code
>>> acts like it did as far as executing all the instructions of the
>>> subroutine at the right part of the code.
>>>
>>> I guess it is because you are thinking of Turing machines in terms of
>>> the goal they are designed to do, and not the actual algorithm they
>>> implement to acheive that goal.
>>>
>>
>> Conventional Turing Machines.
>
> Right,
>
> Which is also the fundamental engine of Olcott-Machines since you didn't
> want to work out anything else.
>
> Turing Machines are just a collection of state transition rules
> (incluing the tape ops) connected to a tape with the data it is to
> process..
>
> The machine itself know NOTHING about its goal, it just follows its
> instructions.
>
>>
>>> Maybe that shows that you do your programming wrong too.
>>>
>>>>
>>>>>
>>>>> So that H, and only that H gets confonded.
>>>>>
>>>>> You sure seem dumb about that.
>>>>>
>>>>>>
>>>>>>> You don't seem to understand what a Turing Machine CAN do.
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

On 3/7/24 11:29 PM, olcott wrote:
> On 3/8/2024 12:48 AM, Richard Damon wrote:
>> On 3/7/24 10:30 PM, olcott wrote:
>>> On 3/8/2024 12:09 AM, Richard Damon wrote:
>>>> On 3/7/24 9:38 PM, olcott wrote:
>>>>> On 3/7/2024 9:53 PM, Richard Damon wrote:
>>>>>> On 3/7/24 7:29 PM, olcott wrote:
>>>>>>> On 3/7/2024 8:34 PM, Richard Damon wrote:
>>>>>>>> On 3/7/24 6:02 PM, olcott wrote:
>>>>>>>>> On 3/7/2024 7:35 PM, immibis wrote:
>>>>>>>>>> On 7/03/24 18:05, olcott wrote:
>>>>>>>>>>> On 3/7/2024 8:47 AM, immibis wrote:
>>>>>>>>>>>> On 7/03/24 03:40, olcott wrote:
>>>>>>>>>>>>> On 3/6/2024 8:22 PM, immibis wrote:
>>>>>>>>>>>>>> On 7/03/24 01:12, olcott wrote:
>>>>>>>>>>>>>>> On 3/6/2024 5:59 PM, immibis wrote:
>>>>>>>>>>>>>>>> On 7/03/24 00:55, olcott wrote:
>>>>>>>>>>>>>>>>> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn
>>>>>>>>>>>>>>>>> Correctly reports that Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ must abort its
>>>>>>>>>>>>>>>>> simulation.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>>>>>>>>>>>>>>>> Correctly reports that H ⟨Ĥ⟩ ⟨Ĥ⟩ need not abort its
>>>>>>>>>>>>>>>>> simulation.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> What are the exact steps which the exact same program
>>>>>>>>>>>>>>>> with the exact same input uses to get two different
>>>>>>>>>>>>>>>> results?
>>>>>>>>>>>>>>>> I saw x86utm. In x86utm there is a mistake because Ĥ.H
>>>>>>>>>>>>>>>> is not defined to do exactly the same steps as H, which
>>>>>>>>>>>>>>>> means you failed to do the Linz procedure.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Both H(D,D) and H1(D,D) answer the exact same question:
>>>>>>>>>>>>>>> Can I continue to simulate my input without ever aborting
>>>>>>>>>>>>>>> it?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Both H(D,D) and H1(D,D) are computer programs (or Turing
>>>>>>>>>>>>>> machines). They execute instructions (or transitions) in
>>>>>>>>>>>>>> sequence, determined by their programming and their input.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Yet because they both know their own machine address
>>>>>>>>>>>>> they can both correctly determine whether or not they
>>>>>>>>>>>>> themselves are called in recursive simulation.
>>>>>>>>>>>>
>>>>>>>>>>>> They cannot do anything except for exactly what they are
>>>>>>>>>>>> programmed to do.
>>>>>>>>>>>
>>>>>>>>>>> H1(D,D) and H(D,D) are programmed to do this.
>>>>>>>>>>> Because H1(D,D) simulates D(D) that calls H(D,D) that
>>>>>>>>>>> aborts its simulation of D(D). H1 can see that its
>>>>>>>>>>> own simulated D(D) returns from its call to H(D,D).
>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> An Olcott machine can perform an equivalent operation.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Because Olcott machines are essentially nothing more than
>>>>>>>>>>>>> conventional UTM's combined with Conventional Turing machine
>>>>>>>>>>>>> descriptions their essence is already fully understood.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The input to Olcott machines can simply be the conventional
>>>>>>>>>>>>> space delimited Turing Machine input followed by four spaces.
>>>>>>>>>>>>>
>>>>>>>>>>>>> This is followed by the machine description of the machine
>>>>>>>>>>>>> that the UTM is simulating followed by four more spaces.
>>>>>>>>>>>>
>>>>>>>>>>>> To make the Linz proof work properly with Olcott machines, Ĥ
>>>>>>>>>>>> should search for 4 spaces, delete its own machine
>>>>>>>>>>>> description, and then insert the description of the original
>>>>>>>>>>>> H. Then the Linz proof works for Olcott machines.
>>>>>>>>>>>
>>>>>>>>>>> That someone can intentionally break an otherwise correct
>>>>>>>>>>> halt decider
>>>>>>>>>>
>>>>>>>>>> It always gives exactly the same answer as the working one, so
>>>>>>>>>> how is it possibly broken?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy ∞ // Ĥ applied to ⟨Ĥ⟩ halts
>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn   // Ĥ applied to ⟨Ĥ⟩ does
>>>>>>>>> not halt
>>>>>>>>>
>>>>>>>>> When this is executed in an Olcott machine then
>>>>>>>>> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> is a different computation than H ⟨Ĥ⟩ ⟨Ĥ⟩ <H>
>>>>>>>>
>>>>>>>> WHY?
>>>>>>>>
>>>>>>>> The Master UTM will not change the usage at H^.H, because that
>>>>>>>> is just an internal state of the Machine H^
>>>>>>>>
>>>>>>>
>>>>>>> The ONLY thing that the master UTM does differently is append
>>>>>>> the TMD to the TMD's own tape.
>>>>>>
>>>>>> Right, so it gives H and H^ that input.
>>>>>>
>>>>>> H^ can erase that input and replace it.
>>>>>>
>>>>>>>
>>>>>>>> At that point we have the IDENTICAL set of transitions (with
>>>>>>>> just an equivalence mapping of state numbers) as H will have,
>>>>>>>> and the EXACT same input as H
>>>>>>>
>>>>>>> it is stipulated by the definition of Olcott machines
>>>>>>> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> // last element is <Ĥ> (not H)
>>>>>>
>>>>>> Nope.
>>>>>>
>>>>>> H^.H isn't a "Olcott Machine" it is a sub-machine of H^
>>>>>
>>>>> You already know that there is no such thing as sub-machines of
>>>>> Turing machines. Turing machines have a set of states and a tape.
>>>>> They have no sub-machines.
>>>>
>>>> A "Sub-Machine" of a Turing Machine is where you put a copy of
>>>> another Turing Machine into the state space of the overall/parent
>>>> machine,
>>>>
>>>> When the machine H^ reaches the state H^.H, then it encounters the
>>>> EXACT sequence of states (after the eqivalence mapping generated
>>>> when inserting them H's q0 -> H^.Hqo and so on)
>>>>
>>>> It is called a sub-machine because it acts largely as if that Turing
>>>> Machihe "called" the equivalent Turing Machine as a subroutine, only
>>>> the machine code was expanded "inline".
>>>
>>> There is no way that any conventional Turing machine can tell
>>> that the states of another Turing machine are embedded withing it.
>>
>> It doesn't need to "KNOW", but it HAS THEM there.
>>
>> It was DESIGNED that way, so the programmer knows what he did.
>>
>
> immibis thought that Ĥ could copy external <H> on top of internal <Ĥ>
> Your words seemed to agree with this.

On 2024-03-07 15:32:07 +0000, olcott said:

> On 3/7/2024 5:17 AM, Mikko wrote:
>> On 2024-03-07 00:12:48 +0000, olcott said:
>>
>>> On 3/6/2024 5:59 PM, immibis wrote:
>>>> On 7/03/24 00:55, olcott wrote:
>>>>> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn
>>>>> Correctly reports that Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ must abort its simulation.
>>>>>
>>>>> H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>>>> Correctly reports that H ⟨Ĥ⟩ ⟨Ĥ⟩ need not abort its simulation.
>>>>
>>>> What are the exact steps which the exact same program with the exact
>>>> same input uses to get two different results?
>>>> I saw x86utm. In x86utm there is a mistake because Ĥ.H is not defined
>>>> to do exactly the same steps as H, which means you failed to do the
>>>> Linz procedure.
>>>
>>> Both H(D,D) and H1(D,D) answer the exact same question:
>>> Can I continue to simulate my input without ever aborting it?
>>
>> It is not the same quessstion unless both machines interprete
>> the word "I" to doenote the same thing.
>>
>
> They are two different machines that interpret that
> I means their own machine address.

As the machine address of one machine is not the same as the other
they interprete "I" differently. Therefore they interpreter the
question differently, i.e., as different qurestions.

--
Mikko

On 3/8/2024 9:07 AM, Mikko wrote:
> On 2024-03-07 15:32:07 +0000, olcott said:
>
>> On 3/7/2024 5:17 AM, Mikko wrote:
>>> On 2024-03-07 00:12:48 +0000, olcott said:
>>>
>>>> On 3/6/2024 5:59 PM, immibis wrote:
>>>>> On 7/03/24 00:55, olcott wrote:
>>>>>> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn
>>>>>> Correctly reports that Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ must abort its simulation.
>>>>>>
>>>>>> H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>>>>> Correctly reports that H ⟨Ĥ⟩ ⟨Ĥ⟩ need not abort its simulation.
>>>>>
>>>>> What are the exact steps which the exact same program with the
>>>>> exact same input uses to get two different results?
>>>>> I saw x86utm. In x86utm there is a mistake because Ĥ.H is not
>>>>> defined to do exactly the same steps as H, which means you failed
>>>>> to do the Linz procedure.
>>>>
>>>> Both H(D,D) and H1(D,D) answer the exact same question:
>>>> Can I continue to simulate my input without ever aborting it?
>>>
>>> It is not the same quessstion unless both machines interprete
>>> the word "I" to doenote the same thing.
>>>
>>
>> They are two different machines that interpret that
>> I means their own machine address.
>
> As the machine address of one machine is not the same as the other
> they interprete "I" differently. Therefore they interpreter the
> question differently, i.e., as different qurestions.
>

My C functions H(D,D) and H1(D,D) can tell if they have been
called in recursive simulation.

Olcott machines provide this same feature to Turing Machines.
The master UTM appends the TMD to the end of the simulated
machine's own tape.

Olcott machines are simply reconfigured Turing machines where
the master UTM appends the TMD to the simulated machines own tape.

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

On 8/03/24 07:30, olcott wrote:
> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> immediately detects that is about to simulate a
> copy of itself with a copy of its own input thus immediately
> detects recursive simulation just like H(D,D).
>
> H ⟨Ĥ⟩ ⟨Ĥ⟩ <H> immediately detects that is NOT about to simulate a
> copy of itself with a copy of its own input thus immediately
> rejects recursive simulation just like H1(D,D).

And what about Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <H> ?

On 3/8/2024 10:09 AM, immibis wrote:
> On 8/03/24 07:30, olcott wrote:
>> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> immediately detects that is about to simulate a
>> copy of itself with a copy of its own input thus immediately
>> detects recursive simulation just like H(D,D).
>>
>> H ⟨Ĥ⟩ ⟨Ĥ⟩ <H> immediately detects that is NOT about to simulate a
>> copy of itself with a copy of its own input thus immediately
>> rejects recursive simulation just like H1(D,D).
>
> And what about Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <H> ?
>

Let's first determine that Olcott machines refute
the uncomputability of the Peter Linz ⟨Ĥ⟩ ⟨Ĥ⟩.

Because my cancer came back in less than 24 months that
means I don't have time for endless divergence.

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

On 8/03/24 03:16, olcott wrote:
> On 3/7/2024 7:37 PM, immibis wrote:
>> On 8/03/24 00:04, olcott wrote:
>>> On 3/7/2024 4:21 PM, Richard Damon wrote:
>>>> On 3/7/24 12:20 PM, olcott wrote:
>>>>> On 3/7/2024 1:59 PM, Richard Damon wrote:
>>>>>> On 3/6/24 11:11 PM, olcott wrote:
>>>>>>> On 3/7/2024 12:37 AM, Richard Damon wrote:
>>>>>>>> On 3/6/24 10:17 PM, olcott wrote:
>>>>>>
>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy ∞ // Ĥ applied to ⟨Ĥ⟩ halts
>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn     // Ĥ applied to ⟨Ĥ⟩ does
>>>>>>>>> not halt
>>>>>>>>>
>>>>>>>>> The design of Olcott Machines makes quite easy for Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>>> to get its abort criteria.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Which doesn't match the Halting Problem requirements,
>>>>>>>
>>>>>>> It does match the Halting Problem requirements, when
>>>>>>> they are implemented indirectly as "abort criteria".
>>>>>>>
>>>>>>
>>>>>> Which is a different criteria, so you are just admitting that you
>>>>>> are using a strawman desception and thus INTENTIONALLY LYING.
>>>>>>
>>>>>> Somehow you think lies are ok if they help you prove your false
>>>>>> statements.
>>>>>
>>>>> The Linz second ⊢* enables H to compute any damn
>>>>> thing as long as this ends up computing halting.
>>>>>
>>>>
>>>> Note quite, it is whatever the algorithm for H generates.
>>>>
>>>> That exact same algorithm exists in H^.H, so that WILL get the same
>>>> answer, and since you logic says it doesn't, that means you are
>>>> lying that H^ was built by the specification, or as to what H will
>>>> actually do.
>>>
>>> *Already addressed in my reply to you here*
>>> We finally know exactly how H1(D,D) derives a different result than
>>> H(D,D)
>>>
>>
>> We know it's because H and H1 are different programs, not copies.
>
> *Even when we remove the infinite loop appended to Ĥ.Hqy*
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy // Ĥ applied to ⟨Ĥ⟩ halts
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn // Ĥ applied to ⟨Ĥ⟩ does not halt
>
> An Olcott machine Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> could trivially determine
> that it is calling itself in recursive simulation.
>
> and Olcott machine H ⟨Ĥ⟩ ⟨Ĥ⟩ <H> could trivially determine
> that it is NOT calling itself in recursive simulation.
>
> This is true even when the embedded portion of H is
> identical to <H>.
>

The copy of
H ⟨Ĥ⟩ ⟨Ĥ⟩ <H>
is not
Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ>

it is actually
Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <H>

this is easily done by deleting <Ĥ> from the tape and inserting <H>

On 8/03/24 17:15, olcott wrote:
> On 3/8/2024 10:09 AM, immibis wrote:
>> On 8/03/24 07:30, olcott wrote:
>>> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> immediately detects that is about to simulate a
>>> copy of itself with a copy of its own input thus immediately
>>> detects recursive simulation just like H(D,D).
>>>
>>> H ⟨Ĥ⟩ ⟨Ĥ⟩ <H> immediately detects that is NOT about to simulate a
>>> copy of itself with a copy of its own input thus immediately
>>> rejects recursive simulation just like H1(D,D).
>>
>> And what about Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <H> ?
>>
>
> Let's first determine that Olcott machines refute
> the uncomputability of the Peter Linz ⟨Ĥ⟩ ⟨Ĥ⟩.

Peter Linz Ĥ ⟨Ĥ⟩ is a Turing machine. The exact same proof does not work
for Olcott machines because they are different. A different proof proves
that Olcott machines cannot compute the halting problem. I have already
told you this proof (but not in great detail).

>
> Because my cancer came back in less than 24 months that
> means I don't have time for endless divergence.
>
Then why do you keep doing it?

On 3/8/2024 10:17 AM, immibis wrote:
> On 8/03/24 03:16, olcott wrote:
>> On 3/7/2024 7:37 PM, immibis wrote:
>>> On 8/03/24 00:04, olcott wrote:
>>>> On 3/7/2024 4:21 PM, Richard Damon wrote:
>>>>> On 3/7/24 12:20 PM, olcott wrote:
>>>>>> On 3/7/2024 1:59 PM, Richard Damon wrote:
>>>>>>> On 3/6/24 11:11 PM, olcott wrote:
>>>>>>>> On 3/7/2024 12:37 AM, Richard Damon wrote:
>>>>>>>>> On 3/6/24 10:17 PM, olcott wrote:
>>>>>>>
>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy ∞ // Ĥ applied to ⟨Ĥ⟩ halts
>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn     // Ĥ applied to ⟨Ĥ⟩
>>>>>>>>>> does not halt
>>>>>>>>>>
>>>>>>>>>> The design of Olcott Machines makes quite easy for Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>>>> to get its abort criteria.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Which doesn't match the Halting Problem requirements,
>>>>>>>>
>>>>>>>> It does match the Halting Problem requirements, when
>>>>>>>> they are implemented indirectly as "abort criteria".
>>>>>>>>
>>>>>>>
>>>>>>> Which is a different criteria, so you are just admitting that you
>>>>>>> are using a strawman desception and thus INTENTIONALLY LYING.
>>>>>>>
>>>>>>> Somehow you think lies are ok if they help you prove your false
>>>>>>> statements.
>>>>>>
>>>>>> The Linz second ⊢* enables H to compute any damn
>>>>>> thing as long as this ends up computing halting.
>>>>>>
>>>>>
>>>>> Note quite, it is whatever the algorithm for H generates.
>>>>>
>>>>> That exact same algorithm exists in H^.H, so that WILL get the same
>>>>> answer, and since you logic says it doesn't, that means you are
>>>>> lying that H^ was built by the specification, or as to what H will
>>>>> actually do.
>>>>
>>>> *Already addressed in my reply to you here*
>>>> We finally know exactly how H1(D,D) derives a different result than
>>>> H(D,D)
>>>>
>>>
>>> We know it's because H and H1 are different programs, not copies.
>>
>> *Even when we remove the infinite loop appended to Ĥ.Hqy*
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy // Ĥ applied to ⟨Ĥ⟩ halts
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn // Ĥ applied to ⟨Ĥ⟩ does not halt
>>
>> An Olcott machine Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> could trivially determine
>> that it is calling itself in recursive simulation.
>>
>> and Olcott machine H ⟨Ĥ⟩ ⟨Ĥ⟩ <H> could trivially determine
>> that it is NOT calling itself in recursive simulation.
>>
>> This is true even when the embedded portion of H is
>> identical to <H>.
>>
>
> The copy of
>   H ⟨Ĥ⟩ ⟨Ĥ⟩ <H>
> is not
>   Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ>
>
> it is actually
>   Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <H>
>
> this is easily done by deleting <Ĥ> from the tape and inserting <H>
>

Because my cancer came back too quickly (in less than 24 months)
I can't afford the time to diverge from Linz until I have closure
on Linz. I am on year 4.2 of a 50% five year mortality rate.

Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> ⊢* Ĥ.Hqn
therefore
H ⟨Ĥ⟩ ⟨Ĥ⟩ <H> ⊢* H.qy

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

On 3/8/2024 10:18 AM, immibis wrote:
> On 8/03/24 17:15, olcott wrote:
>> On 3/8/2024 10:09 AM, immibis wrote:
>>> On 8/03/24 07:30, olcott wrote:
>>>> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> immediately detects that is about to simulate a
>>>> copy of itself with a copy of its own input thus immediately
>>>> detects recursive simulation just like H(D,D).
>>>>
>>>> H ⟨Ĥ⟩ ⟨Ĥ⟩ <H> immediately detects that is NOT about to simulate a
>>>> copy of itself with a copy of its own input thus immediately
>>>> rejects recursive simulation just like H1(D,D).
>>>
>>> And what about Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <H> ?
>>>
>>
>> Let's first determine that Olcott machines refute
>> the uncomputability of the Peter Linz ⟨Ĥ⟩ ⟨Ĥ⟩.
>
> Peter Linz Ĥ ⟨Ĥ⟩ is a Turing machine. The exact same proof does not work
> for Olcott machines because they are different. A different proof proves
> that Olcott machines cannot compute the halting problem. I have already
> told you this proof (but not in great detail).

I am working on the computability of the halting problem
(the exact same TMD / input pairs) by a slightly augmented
notion of Turing machines as elaborated below:

Olcott machines are entirely comprised of a UTM + TMD and one
extra step that any UTM could perform, append the TMD to the end
of its own tape.

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy ∞ // Ĥ applied to ⟨Ĥ⟩ halts
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn // Ĥ applied to ⟨Ĥ⟩ does not halt

Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> ⊢* Ĥ.Hqn
therefore
H ⟨Ĥ⟩ ⟨Ĥ⟩ <H> ⊢* H.qy

Olcott machines take Turing Machine Descriptions.
Thus an Olcott machine does compute halting for
the Linz H ⟨Ĥ⟩ ⟨Ĥ⟩.

>>
>> Because my cancer came back in less than 24 months that
>> means I don't have time for endless divergence.
>>
> Then why do you keep doing it?

You are the one diverging here.

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

On 8/03/24 17:23, olcott wrote:
> On 3/8/2024 10:17 AM, immibis wrote:
>> On 8/03/24 03:16, olcott wrote:
>>> On 3/7/2024 7:37 PM, immibis wrote:
>>>> On 8/03/24 00:04, olcott wrote:
>>>>> On 3/7/2024 4:21 PM, Richard Damon wrote:
>>>>>> On 3/7/24 12:20 PM, olcott wrote:
>>>>>>> On 3/7/2024 1:59 PM, Richard Damon wrote:
>>>>>>>> On 3/6/24 11:11 PM, olcott wrote:
>>>>>>>>> On 3/7/2024 12:37 AM, Richard Damon wrote:
>>>>>>>>>> On 3/6/24 10:17 PM, olcott wrote:
>>>>>>>>
>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy ∞ // Ĥ applied to ⟨Ĥ⟩ halts
>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn     // Ĥ applied to ⟨Ĥ⟩
>>>>>>>>>>> does not halt
>>>>>>>>>>>
>>>>>>>>>>> The design of Olcott Machines makes quite easy for Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>>>>> to get its abort criteria.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Which doesn't match the Halting Problem requirements,
>>>>>>>>>
>>>>>>>>> It does match the Halting Problem requirements, when
>>>>>>>>> they are implemented indirectly as "abort criteria".
>>>>>>>>>
>>>>>>>>
>>>>>>>> Which is a different criteria, so you are just admitting that
>>>>>>>> you are using a strawman desception and thus INTENTIONALLY LYING.
>>>>>>>>
>>>>>>>> Somehow you think lies are ok if they help you prove your false
>>>>>>>> statements.
>>>>>>>
>>>>>>> The Linz second ⊢* enables H to compute any damn
>>>>>>> thing as long as this ends up computing halting.
>>>>>>>
>>>>>>
>>>>>> Note quite, it is whatever the algorithm for H generates.
>>>>>>
>>>>>> That exact same algorithm exists in H^.H, so that WILL get the
>>>>>> same answer, and since you logic says it doesn't, that means you
>>>>>> are lying that H^ was built by the specification, or as to what H
>>>>>> will actually do.
>>>>>
>>>>> *Already addressed in my reply to you here*
>>>>> We finally know exactly how H1(D,D) derives a different result than
>>>>> H(D,D)
>>>>>
>>>>
>>>> We know it's because H and H1 are different programs, not copies.
>>>
>>> *Even when we remove the infinite loop appended to Ĥ.Hqy*
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy // Ĥ applied to ⟨Ĥ⟩ halts
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn // Ĥ applied to ⟨Ĥ⟩ does not halt
>>>
>>> An Olcott machine Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> could trivially determine
>>> that it is calling itself in recursive simulation.
>>>
>>> and Olcott machine H ⟨Ĥ⟩ ⟨Ĥ⟩ <H> could trivially determine
>>> that it is NOT calling itself in recursive simulation.
>>>
>>> This is true even when the embedded portion of H is
>>> identical to <H>.
>>>
>>
>> The copy of
>>    H ⟨Ĥ⟩ ⟨Ĥ⟩ <H>
>> is not
>>    Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ>
>>
>> it is actually
>>    Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <H>
>>
>> this is easily done by deleting <Ĥ> from the tape and inserting <H>
>>
>
> Because my cancer came back too quickly (in less than 24 months)
> I can't afford the time to diverge from Linz until I have closure
> on Linz. I am on year 4.2 of a 50% five year mortality rate.

Here is the closure on Linz: It does not apply to Olcott machines
because it is only a proof about Turing machines. For Olcott machines
you need a different proof.