On 3/1/24 9:27 PM, olcott wrote:
> On 3/1/2024 8:15 PM, Richard Damon wrote:
>> On 3/1/24 7:07 PM, olcott wrote:

>>> H cannot see that there is a reason to abort its own simulation
>>> and Ĥ.H can see that there is a reason to abort its own simulation.
>>
>> What instruction in H gets a difference between the two cases?
>>
>> Same Machine code, same input, every step will be the same.
>>
>
> H sees that D is calling its own machine address.
> H1 does not see that D is calling its own machine address.

And thus you ADMIT that H and H1 are not the same computations.

In fact, they are likely not computations at all.

And thus you admit that you have been lying.

>
> HH(DD,DD) sees that its simulation of DD results in
> a repeated state exactly like infinite recursion.
>
>>>
>>> Because Mike verified that a UTM can pass a portion of its own tape
>>> to its simulated machine this means that the inner instances of Ĥ.H
>>> can pass their execution trace data back up to the outermost Ĥ.H.
>>
>> No, it can NOT. It can use part of the tape for its own purposes, but
>> the simulated machine can have no access to that, as it doesn't exist
>> when the machine is run not under simulation.
>
> On 3/1/2024 12:41 PM, Mike Terry wrote:
> > On 01/03/2024 17:55, olcott wrote:
> >> ... The original H was renamed to HH.
> >> Because a UTM actually can share a portion of its own
> >> tape with the machine it is simulating HH may actually
> >> be the preferred version.
> >
> > Obviously a simulator has access to the internal state
> > (tape contents  etc.) of the simulated machine.  No
> > problem there.
> >
> > What isn't allowed is the simulated machine altering its
> > own behaviour by accessing data outside of its own state.
> > (I.e. accessing data from its parent simulators state.)

Note, He is saying the SIMULATOR can see the information.

The SIMUALATED machine gets no information "passed" to it

Thus, you are caught in another LIE.

>
>> You are just being STUPID again, proving you don't understand even the
>> basics of what you are talking about and obvious errors just go above
>> your head.
>>
>>>
>>> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ specifies nested simulation that is matched by the
>>> infinite recursion behavior pattern.
>>>
>>> H ⟨Ĥ⟩ ⟨Ĥ⟩ does not specify the nested simulation.
>>>
>>>
>>
>> Nope, both specify EXACTLY the same thing,
>> the behavior of H^ applied to (H^).
>>
>> You are just proving your utter stupidity again, showing yourself to
>> be just a pathological liar since you have nothing to compare with to
>> understand what is true.
>>
>> You have been told this, and ignored it, showing it isn't an "Inocent
>> Mistake" but a deliberate action.
>
> When all you have for rebuttal is insults and dogma
> I know that I proved my point.
>
> I proved that you are factually incorrect about what
> Mike said. I expect that you will probably acknowledge
> this.
>

No, you have proved your stupidity.

No, you have proved that you are just a pathological liar reading what
ever twisted meaning you want into other peoples words.

You have KILLED your reputation for ALL ETERNITY.

On 3/1/2024 8:53 PM, Richard Damon wrote:
> On 3/1/24 9:27 PM, olcott wrote:
>> On 3/1/2024 8:15 PM, Richard Damon wrote:
>>> On 3/1/24 7:07 PM, olcott wrote:
>
>>>> H cannot see that there is a reason to abort its own simulation
>>>> and Ĥ.H can see that there is a reason to abort its own simulation.
>>>
>>> What instruction in H gets a difference between the two cases?
>>>
>>> Same Machine code, same input, every step will be the same.
>>>
>>
>> H sees that D is calling its own machine address.
>> H1 does not see that D is calling its own machine address.
>
> And thus you ADMIT that H and H1 are not the same computations.

H and H1 only differ in the exact same way that Ĥ.H and Linz H differ.

>
> In fact, they are likely not computations at all.

None-the-less
H and H1 only differ in the exact same way that Ĥ.H and Linz H differ.

Thus when H sees an execution trace that differs from the one that H1
sees so does Ĥ.H see a different execution trace than Linz 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/1/2024 8:53 PM, Richard Damon wrote:
> On 3/1/24 9:27 PM, olcott wrote:
>> On 3/1/2024 8:15 PM, Richard Damon wrote:
>>> On 3/1/24 7:07 PM, olcott wrote:
>
>> On 3/1/2024 12:41 PM, Mike Terry wrote:
>>  > On 01/03/2024 17:55, olcott wrote:
>>  >> ... The original H was renamed to HH.
>>  >> Because a UTM actually can share a portion of its own
>>  >> tape with the machine it is simulating HH may actually
>>  >> be the preferred version.
>>  >
>>  > Obviously a simulator has access to the internal state
>>  > (tape contents  etc.) of the simulated machine.  No
>>  > problem there.
>>  >
>>  > What isn't allowed is the simulated machine altering its
>>  > own behaviour by accessing data outside of its own state.
>>  > (I.e. accessing data from its parent simulators state.)
>
> Note, He is saying the SIMULATOR can see the information.
>
> The SIMUALATED machine gets no information "passed" to it

The outermost HH needs to see the full execution trace.
The outermost HH needs to see the full execution trace.
The outermost HH needs to see the full execution trace.
The outermost HH needs to see the full execution trace.

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

On 2024-03-01 17:24:28 +0000, olcott said:

> On 3/1/2024 5:36 AM, Mikko wrote:
>> On 2024-02-29 20:08:01 +0000, olcott said:
>>
>>> On 2/29/2024 1:28 PM, Mikko wrote:
>>>> On 2024-02-29 10:31:13 +0000, immibis said:
>>>>
>>>>> On 28/02/24 23:18, olcott wrote:
>>>>>> // Ĥ.q0 ⟨Ĥ⟩ copies its input then transitions to Ĥ.Hq0
>>>>>> // Ĥ.Hq0 is the first state of The Linz hypothetical halt decider
>>>>>> // H transitions to Ĥ.Hqy for halts and Ĥ.Hqn for does not halt
>>>>>> // ∞ means an infinite loop has been appended to the Ĥ.Hqy state
>>>>>> //
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy  ∞ // Ĥ applied to ⟨Ĥ⟩ halts
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn      // Ĥ applied to ⟨Ĥ⟩ does not halt
>>>>>>
>>>>>> When Ĥ is applied to ⟨Ĥ⟩ it contradicts whatever value that Ĥ.H
>>>>>> returns making Ĥ self-contradictory.
>>>>>
>>>>> Turing machine/input pairs are never self-contradictory. Ĥ is only
>>>>> contradictory with its intended specification, which is not itself.
>>>>
>>>> There is no intended specification of Ĥ.
>>>>
>>>
>>> Assuming that Peter Linz has a mind then he intended this specification
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy ∞ // Ĥ applied to ⟨Ĥ⟩ halts
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn   // Ĥ applied to ⟨Ĥ⟩ does not halt
>>
>> Maybe he can but he doesn't.
>>
>
> His paper proves that he does. (page 3)
> https://www.liarparadox.org/Linz_Proof.pdf

No, his paper does not say anything about any specification or Ĥ.
If you want to prove otherwise you must present your own proof,

--
Mikko

On 3/1/24 9:27 PM, olcott wrote:
> On 3/1/2024 8:15 PM, Richard Damon wrote:
>> On 3/1/24 7:07 PM, olcott wrote:
>>> On 3/1/2024 5:39 PM, Richard Damon wrote:
>>>> On 3/1/24 5:45 PM, olcott wrote:
>>>>> On 3/1/2024 3:00 PM, Richard Damon wrote:
>>>>>> On 3/1/24 3:41 PM, olcott wrote:
>>>>>>> On 3/1/2024 11:44 AM, Richard Damon wrote:
>>>>>>>> On 3/1/24 12:24 PM, olcott wrote:
>>>>>>>>> On 3/1/2024 5:36 AM, Mikko wrote:
>>>>>>>>>> On 2024-02-29 20:08:01 +0000, olcott said:
>>>>>>>>>>
>>>>>>>>>>> On 2/29/2024 1:28 PM, Mikko wrote:
>>>>>>>>>>>> On 2024-02-29 10:31:13 +0000, immibis said:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 28/02/24 23:18, olcott wrote:
>>>>>>>>>>>>>> // Ĥ.q0 ⟨Ĥ⟩ copies its input then transitions to Ĥ.Hq0
>>>>>>>>>>>>>> // Ĥ.Hq0 is the first state of The Linz hypothetical halt
>>>>>>>>>>>>>> decider
>>>>>>>>>>>>>> // H transitions to Ĥ.Hqy for halts and Ĥ.Hqn for does not
>>>>>>>>>>>>>> halt
>>>>>>>>>>>>>> // ∞ means an infinite loop has been appended to the Ĥ.Hqy
>>>>>>>>>>>>>> state
>>>>>>>>>>>>>> //
>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy  ∞ // Ĥ applied to ⟨Ĥ⟩
>>>>>>>>>>>>>> halts
>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn      // Ĥ applied to
>>>>>>>>>>>>>> ⟨Ĥ⟩ does not halt
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩ it contradicts whatever value
>>>>>>>>>>>>>> that Ĥ.H
>>>>>>>>>>>>>> returns making Ĥ self-contradictory.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Turing machine/input pairs are never self-contradictory. Ĥ
>>>>>>>>>>>>> is only contradictory with its intended specification,
>>>>>>>>>>>>> which is not itself.
>>>>>>>>>>>>
>>>>>>>>>>>> There is no intended specification of Ĥ.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Assuming that Peter Linz has a mind then he intended this
>>>>>>>>>>> specification
>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy ∞ // Ĥ applied to ⟨Ĥ⟩ halts
>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn   // Ĥ applied to ⟨Ĥ⟩ does
>>>>>>>>>>> not halt
>>>>>>>>>>
>>>>>>>>>> Maybe he can but he doesn't.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> His paper proves that he does. (page 3)
>>>>>>>>> https://www.liarparadox.org/Linz_Proof.pdf
>>>>>>>>>
>>>>>>>>> *Here is my notation of the Linz H that Ben verified on
>>>>>>>>> comp.theory*
>>>>>>>>> H.q0 ⟨H⟩ ⟨H⟩ ⊢* H.qy // H applied to ⟨H⟩ halts
>>>>>>>>> H.q0 ⟨H⟩ ⟨H⟩ ⊢* H.qn // H applied to ⟨H⟩ does not halt
>>>>>>>>
>>>>>>>> Note, the comments you have are the conditions that carry over
>>>>>>>> from H, not the specifications on H^.
>>>>>>>>
>>>>>>>> The "Specification" on H^ is that it:
>>>>>>>> 1) Duplicates its input on the tape
>>>>>>>> 2) Uses its copy of H to determine what H will decide about this
>>>>>>>> input
>>>>>>>
>>>>>>> Wrong.
>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy ∞ // Ĥ applied to ⟨Ĥ⟩ halts
>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn   // Ĥ applied to ⟨Ĥ⟩ does not
>>>>>>> halt
>>>>>>>
>>>>>>> Ĥ applied to ⟨Ĥ⟩ uses Ĥ.H to determine what Ĥ.H will do
>>>>>>> on its input it has no access to and cannot in any way
>>>>>>> effect or examine the return values of the external H.
>>>>>>>
>>>>>>
>>>>>> Except for the FACT that all H's return the same value when given
>>>>>> the same input.
>>>>>>
>>>>>
>>>>> Not when one of them can wait and see what the other one said.
>>>>> The self contradictory input is a toggle just like the Liar Paradox.
>>>>> Thus the outer H will report the opposite of what the inner one
>>>>> reported.
>>>>
>>>> How does it wait longer than the version that H^ uses?
>>>
>>> H cannot see that there is a reason to abort its own simulation
>>> and Ĥ.H can see that there is a reason to abort its own simulation.
>>
>> What instruction in H gets a difference between the two cases?
>>
>> Same Machine code, same input, every step will be the same.
>>
>
> H sees that D is calling its own machine address.
> H1 does not see that D is calling its own machine address.
>
> HH(DD,DD) sees that its simulation of DD results in
> a repeated state exactly like infinite recursion.
>
>>>
>>> Because Mike verified that a UTM can pass a portion of its own tape
>>> to its simulated machine this means that the inner instances of Ĥ.H
>>> can pass their execution trace data back up to the outermost Ĥ.H.
>>
>> No, it can NOT. It can use part of the tape for its own purposes, but
>> the simulated machine can have no access to that, as it doesn't exist
>> when the machine is run not under simulation.
>
> On 3/1/2024 12:41 PM, Mike Terry wrote:
> > On 01/03/2024 17:55, olcott wrote:
> >> ... The original H was renamed to HH.
> >> Because a UTM actually can share a portion of its own
> >> tape with the machine it is simulating HH may actually
> >> be the preferred version.
> >
> > Obviously a simulator has access to the internal state
> > (tape contents  etc.) of the simulated machine.  No
> > problem there.
> >
> > What isn't allowed is the simulated machine altering its
> > own behaviour by accessing data outside of its own state.
> > (I.e. accessing data from its parent simulators state.)
>
>> You are just being STUPID again, proving you don't understand even the
>> basics of what you are talking about and obvious errors just go above
>> your head.
>>
>>>
>>> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ specifies nested simulation that is matched by the
>>> infinite recursion behavior pattern.
>>>
>>> H ⟨Ĥ⟩ ⟨Ĥ⟩ does not specify the nested simulation.
>>>
>>>
>>
>> Nope, both specify EXACTLY the same thing,
>> the behavior of H^ applied to (H^).
>>
>> You are just proving your utter stupidity again, showing yourself to
>> be just a pathological liar since you have nothing to compare with to
>> understand what is true.
>>
>> You have been told this, and ignored it, showing it isn't an "Inocent
>> Mistake" but a deliberate action.
>
> When all you have for rebuttal is insults and dogma
> I know that I proved my point.
>
> I proved that you are factually incorrect about what
> Mike said. I expect that you will probably acknowledge
> this.
>

On 3/1/24 10:59 PM, olcott wrote:
> On 3/1/2024 8:53 PM, Richard Damon wrote:
>> On 3/1/24 9:27 PM, olcott wrote:
>>> On 3/1/2024 8:15 PM, Richard Damon wrote:
>>>> On 3/1/24 7:07 PM, olcott wrote:
>>
>>>>> H cannot see that there is a reason to abort its own simulation
>>>>> and Ĥ.H can see that there is a reason to abort its own simulation.
>>>>
>>>> What instruction in H gets a difference between the two cases?
>>>>
>>>> Same Machine code, same input, every step will be the same.
>>>>
>>>
>>> H sees that D is calling its own machine address.
>>> H1 does not see that D is calling its own machine address.
>>
>> And thus you ADMIT that H and H1 are not the same computations.
>
> H and H1 only differ in the exact same way that Ĥ.H and Linz H differ.

But they are NOT ALLOWED to differ, as in Linz H^, the copy of H has
ZERO changes between its q0 state and qy or qn, its only change is what
happens AFTER H gets to qy, so can't affect what conditions it gets to qy

You are just proving that you have made yourself into an ignorant
pahological liar

>
>>
>> In fact, they are likely not computations at all.
>
> None-the-less
> H and H1 only differ in the exact same way that Ĥ.H and Linz H differ.

Nope, see above. Your problem is you just don't understand (and refuse
or are mentally unable to learn) what a Turing Machine actually is.

Your mental model of the world of programming is that if you think of
some result, you can write a program to do it.
You are just wrong.

>
> Thus when H sees an execution trace that differs from the one that H1
> sees so does Ĥ.H see a different execution trace than Linz H.
>

But it CAN'T if it is doing a CORRECT SIMULATION, since both see the
execution trace of the exact same program H^ (H^)

Your problem is you don't understand that H's answer (as is H1's) for
the input is fixed by its design algorithm.

On 3/1/24 11:01 PM, olcott wrote:
> On 3/1/2024 8:53 PM, Richard Damon wrote:
>> On 3/1/24 9:27 PM, olcott wrote:
>>> On 3/1/2024 8:15 PM, Richard Damon wrote:
>>>> On 3/1/24 7:07 PM, olcott wrote:
>>
>>> On 3/1/2024 12:41 PM, Mike Terry wrote:
>>>  > On 01/03/2024 17:55, olcott wrote:
>>>  >> ... The original H was renamed to HH.
>>>  >> Because a UTM actually can share a portion of its own
>>>  >> tape with the machine it is simulating HH may actually
>>>  >> be the preferred version.
>>>  >
>>>  > Obviously a simulator has access to the internal state
>>>  > (tape contents  etc.) of the simulated machine.  No
>>>  > problem there.
>>>  >
>>>  > What isn't allowed is the simulated machine altering its
>>>  > own behaviour by accessing data outside of its own state.
>>>  > (I.e. accessing data from its parent simulators state.)
>>
>> Note, He is saying the SIMULATOR can see the information.
>>
>> The SIMUALATED machine gets no information "passed" to it
>
> The outermost HH needs to see the full execution trace.
> The outermost HH needs to see the full execution trace.
> The outermost HH needs to see the full execution trace.
> The outermost HH needs to see the full execution trace.
>

And what is stopping it for seeing

that?

The outermost HH is the SIMULATOR and it sees everything about the
simulation.

The first simulated HH is a SIMULATOR and it sees everything about that
exact same simulation it is doing, it just doesn't know it is itself
being simulated.

You are just proving your stupidity and rote processing of information.

You just don't understand the words you are using so if they don't match
the exact form you remember them being used in, you have no idea what is
happening, and have extrapolated what you think they should mean into
areas you just don't understand.

On 3/2/2024 3:48 AM, Mikko wrote:
> On 2024-03-01 17:24:28 +0000, olcott said:
>
>> On 3/1/2024 5:36 AM, Mikko wrote:
>>> On 2024-02-29 20:08:01 +0000, olcott said:
>>>
>>>> On 2/29/2024 1:28 PM, Mikko wrote:
>>>>> On 2024-02-29 10:31:13 +0000, immibis said:
>>>>>
>>>>>> On 28/02/24 23:18, olcott wrote:
>>>>>>> // Ĥ.q0 ⟨Ĥ⟩ copies its input then transitions to Ĥ.Hq0
>>>>>>> // Ĥ.Hq0 is the first state of The Linz hypothetical halt decider
>>>>>>> // H transitions to Ĥ.Hqy for halts and Ĥ.Hqn for does not halt
>>>>>>> // ∞ means an infinite loop has been appended to the Ĥ.Hqy state
>>>>>>> //
>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy  ∞ // Ĥ applied to ⟨Ĥ⟩ halts
>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn      // Ĥ applied to ⟨Ĥ⟩ does
>>>>>>> not halt
>>>>>>>
>>>>>>> When Ĥ is applied to ⟨Ĥ⟩ it contradicts whatever value that Ĥ.H
>>>>>>> returns making Ĥ self-contradictory.
>>>>>>
>>>>>> Turing machine/input pairs are never self-contradictory. Ĥ is only
>>>>>> contradictory with its intended specification, which is not itself.
>>>>>
>>>>> There is no intended specification of Ĥ.
>>>>>
>>>>
>>>> Assuming that Peter Linz has a mind then he intended this specification
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy ∞ // Ĥ applied to ⟨Ĥ⟩ halts
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn   // Ĥ applied to ⟨Ĥ⟩ does not halt
>>>
>>> Maybe he can but he doesn't.
>>>
>>
>> His paper proves that he does. (page 3)
>> https://www.liarparadox.org/Linz_Proof.pdf
>
> No, his paper does not say anything about any specification or Ĥ.
> If you want to prove otherwise you must present your own proof,
>
Are you a Troll?

--
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/2/2024 7:52 AM, Richard Damon wrote:
> On 3/1/24 11:01 PM, olcott wrote:
>> On 3/1/2024 8:53 PM, Richard Damon wrote:
>>> On 3/1/24 9:27 PM, olcott wrote:
>>>> On 3/1/2024 8:15 PM, Richard Damon wrote:
>>>>> On 3/1/24 7:07 PM, olcott wrote:
>>>
>>>> On 3/1/2024 12:41 PM, Mike Terry wrote:
>>>>  > On 01/03/2024 17:55, olcott wrote:
>>>>  >> ... The original H was renamed to HH.
>>>>  >> Because a UTM actually can share a portion of its own
>>>>  >> tape with the machine it is simulating HH may actually
>>>>  >> be the preferred version.
>>>>  >
>>>>  > Obviously a simulator has access to the internal state
>>>>  > (tape contents  etc.) of the simulated machine.  No
>>>>  > problem there.
>>>>  >
>>>>  > What isn't allowed is the simulated machine altering its
>>>>  > own behaviour by accessing data outside of its own state.
>>>>  > (I.e. accessing data from its parent simulators state.)
>>>
>>> Note, He is saying the SIMULATOR can see the information.
>>>
>>> The SIMUALATED machine gets no information "passed" to it
>>
>> The outermost HH needs to see the full execution trace.
>> The outermost HH needs to see the full execution trace.
>> The outermost HH needs to see the full execution trace.
>> The outermost HH needs to see the full execution trace.
>>
>
> And what is stopping it for seeing
>
>  that?
>
> The outermost HH is the SIMULATOR and it sees everything about the
> simulation.
>

Then it can see that the execution trace of DD(DD) that is derives is
identical to the execution trace of DD(DD) that its inner HH derives
thus giving HH the correct criteria to abort its simulation to
prevent its own non-termination.

> The first simulated HH is a SIMULATOR and it sees everything about that
> exact same simulation it is doing, it just doesn't know it is itself
> being simulated.
>

It need not know that. Because the outer HH sees that the inner HH
derives an identical execution trace to the one it derived it sees
a complete copy of both traces.

The inner HH only sees a complete copy of one trace. Thus the upward
flow of execution trace data is all that is needed for HH to correctly
determine that it must abort the simulation of its input.

> You are just proving your stupidity and rote processing of information.
>
> You just don't understand the words you are using so if they don't match
> the exact form you remember them being used in, you have no idea what is
> happening, and have extrapolated what you think they should mean into
> areas you just don't understand.

I would say that the issue is that you are so sure that I must be
wrong that you are not bothering to pay enough attention to what
I have said.

Professor Hehner mostly experienced a much worse case of that.
People would glance at a few of his words and reject his whole
paper out-of-hand without any review.

History of my Problems with the Halting Problem
2013 August 14, 2014 July 6, 2022 April 15
https://www.cs.toronto.edu/~hehner/PHPhistory.pdf

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

On 02/03/2024 00:07, olcott wrote:
> On 3/1/2024 5:39 PM, Richard Damon wrote:
>> On 3/1/24 5:45 PM, olcott wrote:
>>> On 3/1/2024 3:00 PM, Richard Damon wrote:
>>>> On 3/1/24 3:41 PM, olcott wrote:
>>>>> On 3/1/2024 11:44 AM, Richard Damon wrote:
>>>>>> On 3/1/24 12:24 PM, olcott wrote:
>>>>>>> On 3/1/2024 5:36 AM, Mikko wrote:
>>>>>>>> On 2024-02-29 20:08:01 +0000, olcott said:
>>>>>>>>
>>>>>>>>> On 2/29/2024 1:28 PM, Mikko wrote:
>>>>>>>>>> On 2024-02-29 10:31:13 +0000, immibis said:
>>>>>>>>>>
>>>>>>>>>>> On 28/02/24 23:18, olcott wrote:
>>>>>>>>>>>> // Ĥ.q0 ⟨Ĥ⟩ copies its input then transitions to Ĥ.Hq0
>>>>>>>>>>>> // Ĥ.Hq0 is the first state of The Linz hypothetical halt decider
>>>>>>>>>>>> // H transitions to Ĥ.Hqy for halts and Ĥ.Hqn for does not halt
>>>>>>>>>>>> // ∞ means an infinite loop has been appended to the Ĥ.Hqy state
>>>>>>>>>>>> //
>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy  ∞ // Ĥ applied to ⟨Ĥ⟩ halts
>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn      // Ĥ applied to ⟨Ĥ⟩ does not halt
>>>>>>>>>>>>
>>>>>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩ it contradicts whatever value that Ĥ.H
>>>>>>>>>>>> returns making Ĥ self-contradictory.
>>>>>>>>>>>
>>>>>>>>>>> Turing machine/input pairs are never self-contradictory. Ĥ is only contradictory with its
>>>>>>>>>>> intended specification, which is not itself.
>>>>>>>>>>
>>>>>>>>>> There is no intended specification of Ĥ.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Assuming that Peter Linz has a mind then he intended this specification
>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy ∞ // Ĥ applied to ⟨Ĥ⟩ halts
>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn   // Ĥ applied to ⟨Ĥ⟩ does not halt
>>>>>>>>
>>>>>>>> Maybe he can but he doesn't.
>>>>>>>>
>>>>>>>
>>>>>>> His paper proves that he does. (page 3)
>>>>>>> https://www.liarparadox.org/Linz_Proof.pdf
>>>>>>>
>>>>>>> *Here is my notation of the Linz H that Ben verified on comp.theory*
>>>>>>> H.q0 ⟨H⟩ ⟨H⟩ ⊢* H.qy // H applied to ⟨H⟩ halts
>>>>>>> H.q0 ⟨H⟩ ⟨H⟩ ⊢* H.qn // H applied to ⟨H⟩ does not halt
>>>>>>
>>>>>> Note, the comments you have are the conditions that carry over from H, not the specifications
>>>>>> on H^.
>>>>>>
>>>>>> The "Specification" on H^ is that it:
>>>>>> 1) Duplicates its input on the tape
>>>>>> 2) Uses its copy of H to determine what H will decide about this input
>>>>>
>>>>> Wrong.
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy ∞ // Ĥ applied to ⟨Ĥ⟩ halts
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn   // Ĥ applied to ⟨Ĥ⟩ does not halt
>>>>>
>>>>> Ĥ applied to ⟨Ĥ⟩ uses Ĥ.H to determine what Ĥ.H will do
>>>>> on its input it has no access to and cannot in any way
>>>>> effect or examine the return values of the external H.
>>>>>
>>>>
>>>> Except for the FACT that all H's return the same value when given the same input.
>>>>
>>>
>>> Not when one of them can wait and see what the other one said.
>>> The self contradictory input is a toggle just like the Liar Paradox.
>>> Thus the outer H will report the opposite of what the inner one
>>> reported.
>>
>> How does it wait longer than the version that H^ uses?
>
> H cannot see that there is a reason to abort its own simulation
> and Ĥ.H can see that there is a reason to abort its own simulation.
>
> Because Mike verified that a UTM can pass a portion of its own tape
> to its simulated machine this means that the inner instances of Ĥ.H
> can pass their execution trace data back up to the outermost Ĥ.H.

You're doing it again. I reckon /every single instance/ without exception where you claim to speak
for someone else, you get confused and misrepresent their views and what they're saying. And you
know that "Appeal to authority" is a kind of fallacy because you quote it against others on
occasion. Just speak your own thoughts and arguments.

Anyhow...

I did not verify that "a UTM can pass a portion of its own tape...". First off, UTMs replicate the
FULL computation represented by their input, without changing/enhancing/adding functionality etc..
They can't "pass a portion of their own tape" to their input computation.

Talking more loosely about "simuation" generally, I said it would be /possible/ to imagine some kind
of "active-simulator" [my term] that deliberately modifies the behaviour of its simulated input in
order to achieve some goal e.g. enhancing the capabilities of a raw TM. [Calling this a type of
"simulator" is probably a misuse of the term, but I don't have a better term right now.] I said
explicitly that such an enhancement was *NOT* OK FOR YOUR STATED GOALS FOR X86UTM! X86utm
simulation must faithfully replicate the calculation steps of its input, otherwise you won't be able
to conclude anything about problems with the Linz proof.

Obviously passing a portion of its own tape to its simulated machine constitutes actively modifying
the behaviour of the "simulated" computation, which would be a show stopper. That's the opposite of
what you said I "confirmed"!

What I did say was that a simulator naturally has access to the state and memory of the virtual
machine it is simulating. That is not "sharing a portion of its tape", and the simulated
computation is not actively "sending" data to its simulator" because it cannot even be aware that a
simulator exists. The simulator simply grabs what it wants from the simulation as it steps along
the computation steps.

What if the simulation itself simulates another computation? The outer simulator needs to observe
this happening, which means it has to fully understand /how/ the inner simulation is being
performed: where and how /inner/ simulation state and memory is encoded on the virtual memory of
the /outer/ simulation. Then the outer simulator can grab what it needs from the inner simulation
as before. IOW the "inner simulation" is just "more data manipulation" performed as part of the
computation simulated by the outer simulation.

For TMs, as a general problem, this would be incredibly difficult to achieve, because even the
starting assumption that the outer simulator can /recognise/ inner simulation is occuring is
questionable! But in your x86utm specifically, there are factors which would make this fairly
straightforward:

1) The simulation mechanism used for inner simulations is exactly the same as that used by
the outer simulation, i.e. the outer simulator /does/ understand the specific simulation
mechanism to watch out for.
2) stepping a simulation with x86utm is a primitive operaton (DebugStep call), so
it is easily recognised when inner simulations are occuring.
3) Also the inputs to DebugStep indicate where all the required state/memory for the
inner simulation is located
4) Memory is shared between all levels of simulation.

So... if you want to do nested simulation correctly, you need to switch your thinking from "the
inner simulations must actively /pass/ bits of data to the outer simulation" to "the outer
simulation needs to "dig out" any data it needs from inner simulations as it goes along. Obviously
each simulation level will need to maintain its own execution_trace without knowledge of (or ability
to access) execution traces of outer simulations.

(Note that an outer simulator can locate things like where in memory any inner simulation's
execution_traces are being stored, and can grab stuff out of those trace like it can grab other data
from its directly simulated computation...)

On 3/2/2024 11:28 AM, Mike Terry wrote:
> On 02/03/2024 00:07, olcott wrote:
>> On 3/1/2024 5:39 PM, Richard Damon wrote:
>>> On 3/1/24 5:45 PM, olcott wrote:
>>>> On 3/1/2024 3:00 PM, Richard Damon wrote:
>>>>> On 3/1/24 3:41 PM, olcott wrote:
>>>>>> On 3/1/2024 11:44 AM, Richard Damon wrote:
>>>>>>> On 3/1/24 12:24 PM, olcott wrote:
>>>>>>>> On 3/1/2024 5:36 AM, Mikko wrote:
>>>>>>>>> On 2024-02-29 20:08:01 +0000, olcott said:
>>>>>>>>>
>>>>>>>>>> On 2/29/2024 1:28 PM, Mikko wrote:
>>>>>>>>>>> On 2024-02-29 10:31:13 +0000, immibis said:
>>>>>>>>>>>
>>>>>>>>>>>> On 28/02/24 23:18, olcott wrote:
>>>>>>>>>>>>> // Ĥ.q0 ⟨Ĥ⟩ copies its input then transitions to Ĥ.Hq0
>>>>>>>>>>>>> // Ĥ.Hq0 is the first state of The Linz hypothetical halt
>>>>>>>>>>>>> decider
>>>>>>>>>>>>> // H transitions to Ĥ.Hqy for halts and Ĥ.Hqn for does not
>>>>>>>>>>>>> halt
>>>>>>>>>>>>> // ∞ means an infinite loop has been appended to the Ĥ.Hqy
>>>>>>>>>>>>> state
>>>>>>>>>>>>> //
>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy  ∞ // Ĥ applied to ⟨Ĥ⟩
>>>>>>>>>>>>> halts
>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn      // Ĥ applied to ⟨Ĥ⟩
>>>>>>>>>>>>> does not halt
>>>>>>>>>>>>>
>>>>>>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩ it contradicts whatever value that
>>>>>>>>>>>>> Ĥ.H
>>>>>>>>>>>>> returns making Ĥ self-contradictory.
>>>>>>>>>>>>
>>>>>>>>>>>> Turing machine/input pairs are never self-contradictory. Ĥ
>>>>>>>>>>>> is only contradictory with its intended specification, which
>>>>>>>>>>>> is not itself.
>>>>>>>>>>>
>>>>>>>>>>> There is no intended specification of Ĥ.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Assuming that Peter Linz has a mind then he intended this
>>>>>>>>>> specification
>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy ∞ // Ĥ applied to ⟨Ĥ⟩ halts
>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn   // Ĥ applied to ⟨Ĥ⟩ does
>>>>>>>>>> not halt
>>>>>>>>>
>>>>>>>>> Maybe he can but he doesn't.
>>>>>>>>>
>>>>>>>>
>>>>>>>> His paper proves that he does. (page 3)
>>>>>>>> https://www.liarparadox.org/Linz_Proof.pdf
>>>>>>>>
>>>>>>>> *Here is my notation of the Linz H that Ben verified on
>>>>>>>> comp.theory*
>>>>>>>> H.q0 ⟨H⟩ ⟨H⟩ ⊢* H.qy // H applied to ⟨H⟩ halts
>>>>>>>> H.q0 ⟨H⟩ ⟨H⟩ ⊢* H.qn // H applied to ⟨H⟩ does not halt
>>>>>>>
>>>>>>> Note, the comments you have are the conditions that carry over
>>>>>>> from H, not the specifications on H^.
>>>>>>>
>>>>>>> The "Specification" on H^ is that it:
>>>>>>> 1) Duplicates its input on the tape
>>>>>>> 2) Uses its copy of H to determine what H will decide about this
>>>>>>> input
>>>>>>
>>>>>> Wrong.
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy ∞ // Ĥ applied to ⟨Ĥ⟩ halts
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn   // Ĥ applied to ⟨Ĥ⟩ does not
>>>>>> halt
>>>>>>
>>>>>> Ĥ applied to ⟨Ĥ⟩ uses Ĥ.H to determine what Ĥ.H will do
>>>>>> on its input it has no access to and cannot in any way
>>>>>> effect or examine the return values of the external H.
>>>>>>
>>>>>
>>>>> Except for the FACT that all H's return the same value when given
>>>>> the same input.
>>>>>
>>>>
>>>> Not when one of them can wait and see what the other one said.
>>>> The self contradictory input is a toggle just like the Liar Paradox.
>>>> Thus the outer H will report the opposite of what the inner one
>>>> reported.
>>>
>>> How does it wait longer than the version that H^ uses?
>>
>> H cannot see that there is a reason to abort its own simulation
>> and Ĥ.H can see that there is a reason to abort its own simulation.
>>
>> Because Mike verified that a UTM can pass a portion of its own tape
>> to its simulated machine this means that the inner instances of Ĥ.H
>> can pass their execution trace data back up to the outermost Ĥ.H.
>
> You're doing it again.  I reckon /every single instance/ without
> exception where you claim to speak for someone else, you get confused
> and misrepresent their views and what they're saying.  And you know that
> "Appeal to authority" is a kind of fallacy because you quote it against
> others on occasion.  Just speak your own thoughts and arguments.
>

*Again, I really appreciate your feedback*
You have proven to me that your understanding of these
things is very deep.

This verifies that a UTM can see the internal state
of its simulated machine and that this idea is not
a crackpot idea:

On 3/1/2024 12:41 PM, Mike Terry wrote:
> On 01/03/2024 17:55, olcott wrote:
>> ... The original H was renamed to HH.
>> Because a UTM actually can share a portion of its own
>> tape with the machine it is simulating HH may actually
>> be the preferred version.
>
> Obviously a simulator has access to the internal state
> (tape contents etc.) of the simulated machine. No
> problem there.
>
> What isn't allowed is the simulated machine altering its
> own behaviour by accessing data outside of its own state.
> (I.e. accessing data from its parent simulators state.)

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

This entails that Ĥ.H has access to the execution trace
derived by its simulated Ĥ.Hq0.

> Anyhow...
>
> I did not verify that "a UTM can pass a portion of its own tape...".
> First off, UTMs replicate the FULL computation represented by their
> input, without changing/enhancing/adding functionality etc.. They can't
> "pass a portion of their own tape" to their input computation.
>

Try and explain how it can possibly be otherwise when a UTM only
has access to its own tape and its own internal state and the UTM
would not pass its whole tape to any simulated machine.

> Talking more loosely about "simuation" generally, I said it would be
> /possible/ to imagine some kind of  "active-simulator" [my term] that
> deliberately modifies the behaviour of its simulated input in order to
> achieve some goal e.g. enhancing the capabilities of a raw TM.  [Calling
> this a type of "simulator" is probably a misuse of the term, but I don't
> have a better term right now.]

A UTM that simulates its input and examines its own execution trace of
this input adds no functionality to this UTM that causes its simulation
to be incorrect.

When a UTM with the above functionality can also detect
non-halting behavior patterns by this input this too adds
no functionality to this UTM that causes its simulation
to be incorrect.

When a UTM with the above functionality aborts the
simulation of its input that would otherwise cause
itself to never terminate this too adds no functionality
to this UTM that causes its simulation to be incorrect
up to the point where the simulation is aborted.

On 3/2/24 12:23 PM, olcott wrote:
> On 3/2/2024 7:52 AM, Richard Damon wrote:
>> On 3/1/24 11:01 PM, olcott wrote:
>>> On 3/1/2024 8:53 PM, Richard Damon wrote:
>>>> On 3/1/24 9:27 PM, olcott wrote:
>>>>> On 3/1/2024 8:15 PM, Richard Damon wrote:
>>>>>> On 3/1/24 7:07 PM, olcott wrote:
>>>>
>>>>> On 3/1/2024 12:41 PM, Mike Terry wrote:
>>>>>  > On 01/03/2024 17:55, olcott wrote:
>>>>>  >> ... The original H was renamed to HH.
>>>>>  >> Because a UTM actually can share a portion of its own
>>>>>  >> tape with the machine it is simulating HH may actually
>>>>>  >> be the preferred version.
>>>>>  >
>>>>>  > Obviously a simulator has access to the internal state
>>>>>  > (tape contents  etc.) of the simulated machine.  No
>>>>>  > problem there.
>>>>>  >
>>>>>  > What isn't allowed is the simulated machine altering its
>>>>>  > own behaviour by accessing data outside of its own state.
>>>>>  > (I.e. accessing data from its parent simulators state.)
>>>>
>>>> Note, He is saying the SIMULATOR can see the information.
>>>>
>>>> The SIMUALATED machine gets no information "passed" to it
>>>
>>> The outermost HH needs to see the full execution trace.
>>> The outermost HH needs to see the full execution trace.
>>> The outermost HH needs to see the full execution trace.
>>> The outermost HH needs to see the full execution trace.
>>>
>>
>> And what is stopping it for seeing
>>
>>   that?
>>
>> The outermost HH is the SIMULATOR and it sees everything about the
>> simulation.
>>
>
> Then it can see that the execution trace of DD(DD) that is derives is
> identical to the execution trace of DD(DD) that its inner HH derives
> thus giving HH the correct criteria to abort its simulation to
> prevent its own non-termination.
And the one that is one step in sees exactly the same thing, so it waits
for the answer of the one inside it, which sees exactly the same thing
and waits, and nobody every answers.

THEY ALL DO THE SAME THING. BY DEFINITION.

>
>> The first simulated HH is a SIMULATOR and it sees everything about
>> that exact same simulation it is doing, it just doesn't know it is
>> itself being simulated.
>>
>
> It need not know that. Because the outer HH sees that the inner HH
> derives an identical execution trace to the one it derived it sees
> a complete copy of both traces.

And the one inside sees exactly tha same things, and so on, so everybody
waits to see what the machine it simulates does and nobody every answers.

>
> The inner HH only sees a complete copy of one trace. Thus the upward
> flow of execution trace data is all that is needed for HH to correctly
> determine that it must abort the simulation of its input.

No, it sees the trace of the simulation of the machine it is simulating,
just like the outer one it.

>
>> You are just proving your stupidity and rote processing of information.
>>
>> You just don't understand the words you are using so if they don't
>> match the exact form you remember them being used in, you have no idea
>> what is happening, and have extrapolated what you think they should
>> mean into areas you just don't understand.
>
> I would say that the issue is that you are so sure that I must be
> wrong that you are not bothering to pay enough attention to what
> I have said.

No, you so ignore the actual facts and definitions that you fantasies
are just plain obvious.

You are just proving your utter ignorance of the basics of Computation
theory that you are unable to tell that something is just totally wrong.

Since you have decided not to bother learning this, you have just made
yourself into the ignorant pathologically lying idiot you have become.

>
> Professor Hehner mostly experienced a much worse case of that.
> People would glance at a few of his words and reject his whole
> paper out-of-hand without any review.

But he makes the same mistake, so his ideas SHOULD be just rejected

>
> History of my Problems with the Halting Problem
> 2013 August 14, 2014 July 6, 2022 April 15
> https://www.cs.toronto.edu/~hehner/PHPhistory.pdf
>

Which, to anyone who actually understands Computation Theory, shows that
he is just not qualified to talk about it. He doesn't understand the
basic definition of the theory, as he as proven by his statements.

On 2/03/24 01:07, olcott wrote:
> On 3/1/2024 5:39 PM, Richard Damon wrote:
>>
>> How does it wait longer than the version that H^ uses?
>
> H cannot see that there is a reason to abort its own simulation
> and Ĥ.H can see that there is a reason to abort its own simulation.

Ĥ.H is defined to behave identically to H. If they don't behave
identically then you made a mistake when defining Ĥ.H.

On 2/03/24 02:26, olcott wrote:
> On 3/1/2024 7:12 PM, André G. Isaak wrote:
>> On 2024-03-01 17:07, olcott wrote:
>>
>>> Because Mike verified that a UTM can pass a portion of its own tape
>>> to its simulated machine this means that the inner instances of Ĥ.H
>>> can pass their execution trace data back up to the outermost Ĥ.H.
>>
>> You need to read your responses more carefully. This is precisely what
>> Mike states you CANNOT do.
>>
>> André
>>
>
> *I am very surprised that you got this wrong*
> I am however very happy that you are reviewing my work.
>
> On 3/1/2024 12:41 PM, Mike Terry wrote:
> > On 01/03/2024 17:55, olcott wrote:
> >> ... The original H was renamed to HH.
> >> Because a UTM actually can share a portion of its own
> >> tape with the machine it is simulating HH may actually
> >> be the preferred version.
> >
> > Obviously a simulator has access to the internal state
> > (tape contents  etc.) of the simulated machine.  No
> > problem there.
> >
> > What isn't allowed is the simulated machine altering its
> > own behaviour by accessing data outside of its own state.
> > (I.e. accessing data from its parent simulators state.)
>

What is the point of passing some tape data if it doesn't alter the
state of the simulated machine?

On 2/03/24 03:27, olcott wrote:
> On 3/1/2024 8:15 PM, Richard Damon wrote:
>>
>> What instruction in H gets a difference between the two cases?
>>
>> Same Machine code, same input, every step will be the same.
>>
>
> H sees that D is calling its own machine address.
> H1 does not see that D is calling its own machine address.

So the instruction that differs is the instruction that returns its own
machine address? In Turing machines this instruction does not exist.

On 3/5/2024 8:37 PM, immibis wrote:
> On 2/03/24 02:26, olcott wrote:
>> On 3/1/2024 7:12 PM, André G. Isaak wrote:
>>> On 2024-03-01 17:07, olcott wrote:
>>>
>>>> Because Mike verified that a UTM can pass a portion of its own tape
>>>> to its simulated machine this means that the inner instances of Ĥ.H
>>>> can pass their execution trace data back up to the outermost Ĥ.H.
>>>
>>> You need to read your responses more carefully. This is precisely
>>> what Mike states you CANNOT do.
>>>
>>> André
>>>
>>
>> *I am very surprised that you got this wrong*
>> I am however very happy that you are reviewing my work.
>>
>> On 3/1/2024 12:41 PM, Mike Terry wrote:
>>  > On 01/03/2024 17:55, olcott wrote:
>>  >> ... The original H was renamed to HH.
>>  >> Because a UTM actually can share a portion of its own
>>  >> tape with the machine it is simulating HH may actually
>>  >> be the preferred version.
>>  >
>>  > Obviously a simulator has access to the internal state
>>  > (tape contents  etc.) of the simulated machine.  No
>>  > problem there.
>>  >
>>  > What isn't allowed is the simulated machine altering its
>>  > own behaviour by accessing data outside of its own state.
>>  > (I.e. accessing data from its parent simulators state.)
>>
>
> What is the point of passing some tape data if it doesn't alter the
> state of the simulated machine?

Mike said (and I agreed) that HH is not allowed
to alter the state of the simulated machine.

I think that I have the detailed design of Mike's
suggestion correctly summarized in two sentences.
I had to reverse-engineer this from key element
of his idea.

--
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/5/2024 8:37 PM, immibis wrote:
> On 2/03/24 03:27, olcott wrote:
>> On 3/1/2024 8:15 PM, Richard Damon wrote:
>>>
>>> What instruction in H gets a difference between the two cases?
>>>
>>> Same Machine code, same input, every step will be the same.
>>>
>>
>> H sees that D is calling its own machine address.
>> H1 does not see that D is calling its own machine address.
>
> So the instruction that differs is the instruction that returns its own
> machine address? In Turing machines this instruction does not exist.

HH never needed to know its own machine address.
When I implement Mike's suggestion then HH would
become a computable function.

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

On 6/03/24 04:45, olcott wrote:
> On 3/5/2024 8:37 PM, immibis wrote:
>> On 2/03/24 02:26, olcott wrote:
>>> On 3/1/2024 7:12 PM, André G. Isaak wrote:
>>>> On 2024-03-01 17:07, olcott wrote:
>>>>
>>>>> Because Mike verified that a UTM can pass a portion of its own tape
>>>>> to its simulated machine this means that the inner instances of Ĥ.H
>>>>> can pass their execution trace data back up to the outermost Ĥ.H.
>>>>
>>>> You need to read your responses more carefully. This is precisely
>>>> what Mike states you CANNOT do.
>>>>
>>>> André
>>>>
>>>
>>> *I am very surprised that you got this wrong*
>>> I am however very happy that you are reviewing my work.
>>>
>>> On 3/1/2024 12:41 PM, Mike Terry wrote:
>>>  > On 01/03/2024 17:55, olcott wrote:
>>>  >> ... The original H was renamed to HH.
>>>  >> Because a UTM actually can share a portion of its own
>>>  >> tape with the machine it is simulating HH may actually
>>>  >> be the preferred version.
>>>  >
>>>  > Obviously a simulator has access to the internal state
>>>  > (tape contents  etc.) of the simulated machine.  No
>>>  > problem there.
>>>  >
>>>  > What isn't allowed is the simulated machine altering its
>>>  > own behaviour by accessing data outside of its own state.
>>>  > (I.e. accessing data from its parent simulators state.)
>>>
>>
>> What is the point of passing some tape data if it doesn't alter the
>> state of the simulated machine?
>
> Mike said (and I agreed) that HH is not allowed
> to alter the state of the simulated machine.

When the simulator allows the simulated machine's behaviour to depend on
the previous execution trace in a way that the actual execution of the
machine does not, this is altering the state of the simulated machine.

Actually, H is allowed to do anything it wants, including incorrect
simulations. But if H does an incorrect simulation, then any proof based
on the fact that H does a correct simulation is unsound.

>
> I think that I have the detailed design of Mike's
> suggestion correctly summarized in two sentences.
> I had to reverse-engineer this from key element
> of his idea.
>

On 6/03/24 03:22, immibis wrote:
> On 2/03/24 01:07, olcott wrote:
>> On 3/1/2024 5:39 PM, Richard Damon wrote:
>>>
>>> How does it wait longer than the version that H^ uses?
>>
>> H cannot see that there is a reason to abort its own simulation
>> and Ĥ.H can see that there is a reason to abort its own simulation.
>
> Ĥ.H is defined to behave identically to H. If they don't behave
> identically then you made a mistake when defining Ĥ.H.

I feel it is important to emphasize this point: When Linz (or anyone
else) specifies a copy of H, they specify a machine that has exactly
identical behaviour to H in all cases with absolutely no exceptions. If
you are using a weird system where merely copying a machine may change
its behaviour, then it is YOUR responsibility to fix the copy so that it
has exactly identical behaviour to H in all cases with absolutely no
exceptions. In Turing machines, copying never changes behaviour.

On 2/03/24 16:11, olcott wrote:
> On 3/2/2024 3:48 AM, Mikko wrote:
>> On 2024-03-01 17:24:28 +0000, olcott said:
>>
>>> On 3/1/2024 5:36 AM, Mikko wrote:
>>>> On 2024-02-29 20:08:01 +0000, olcott said:
>>>>
>>>>> On 2/29/2024 1:28 PM, Mikko wrote:
>>>>>> On 2024-02-29 10:31:13 +0000, immibis said:
>>>>>>
>>>>>>> On 28/02/24 23:18, olcott wrote:
>>>>>>>> // Ĥ.q0 ⟨Ĥ⟩ copies its input then transitions to Ĥ.Hq0
>>>>>>>> // Ĥ.Hq0 is the first state of The Linz hypothetical halt decider
>>>>>>>> // H transitions to Ĥ.Hqy for halts and Ĥ.Hqn for does not halt
>>>>>>>> // ∞ means an infinite loop has been appended to the Ĥ.Hqy state
>>>>>>>> //
>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy  ∞ // Ĥ applied to ⟨Ĥ⟩ halts
>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn      // Ĥ applied to ⟨Ĥ⟩ does
>>>>>>>> not halt
>>>>>>>>
>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩ it contradicts whatever value that Ĥ.H
>>>>>>>> returns making Ĥ self-contradictory.
>>>>>>>
>>>>>>> Turing machine/input pairs are never self-contradictory. Ĥ is
>>>>>>> only contradictory with its intended specification, which is not
>>>>>>> itself.
>>>>>>
>>>>>> There is no intended specification of Ĥ.
>>>>>>
>>>>>
>>>>> Assuming that Peter Linz has a mind then he intended this
>>>>> specification
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy ∞ // Ĥ applied to ⟨Ĥ⟩ halts
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn   // Ĥ applied to ⟨Ĥ⟩ does not halt
>>>>
>>>> Maybe he can but he doesn't.
>>>>
>>>
>>> His paper proves that he does. (page 3)
>>> https://www.liarparadox.org/Linz_Proof.pdf
>>
>> No, his paper does not say anything about any specification or Ĥ.
>> If you want to prove otherwise you must present your own proof,
>>
> Are you a Troll?

Are you? Ĥ does not have a specification. Ĥ only has a method of
construction. H is *specified* to be a halting decider. Ĥ is
*constructed* by modifying H.