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

To be clear, I'm saying you /could/ do all this and make nested simulations work correctly - not
that your current implementation gets any of this right!

Stepping back a bit... if you're thinking you may not have time to make such changes because you
could die before achieving it, I'd have to say you should spend your remaining time on things in
your life that you actively enjoy! Making coding changes to x86utm will have NO EFFECT WHATSOEVER
on whether your claims about HP are accepted or not. (They will not be, regardless, so don't feel
you will be "enhancing your legacy" or anything like that! That might be depressing, bit it's how
things are.)

Mike.