On 5/22/22 10:57 AM, olcott wrote:
> On 5/22/2022 6:06 AM, Richard Damon wrote:
>> On 5/22/22 1:02 AM, olcott wrote:
>>> On 5/21/2022 11:05 PM, Richard Damon wrote:
>>>> On 5/21/22 11:59 PM, olcott wrote:
>>>>> On 5/21/2022 10:54 PM, Richard Damon wrote:
>>>>>> On 5/21/22 11:36 PM, olcott wrote:
>>>>>>> On 5/21/2022 10:27 PM, Richard Damon wrote:
>>>>>>>> On 5/21/22 10:48 PM, olcott wrote:
>>>>>>>>> On 5/21/2022 9:37 PM, Richard Damon wrote:
>>>>>>>>>> On 5/21/22 10:28 PM, olcott wrote:
>>>>>>>>>>> On 5/21/2022 9:20 PM, Richard Damon wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> On 5/21/22 9:23 PM, olcott wrote:
>>>>>>>>>>>>> On 5/21/2022 8:05 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 5/21/22 3:38 PM, olcott wrote:
>>>>>>>>>>>>>>> On 5/20/2022 5:25 PM, Ben wrote:
>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> You have known that the input to H(P,P) is simulated
>>>>>>>>>>>>>>>>> correctly proving
>>>>>>>>>>>>>>>>> that H(P,P)==0 is correct for the whole six months
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> If H is intended to be a halt decider (even if only for
>>>>>>>>>>>>>>>> the one case you
>>>>>>>>>>>>>>>> claim to care about) then H(P,P) == 0 is wrong, because
>>>>>>>>>>>>>>>> P(P) halts.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> When we correctly reverse-engineer what the execution
>>>>>>>>>>>>>>> trace of the input to H(P,P) would be for one emulation
>>>>>>>>>>>>>>> and one nested emulation we can see that the correctly
>>>>>>>>>>>>>>> emulated input to H(P,P) would never reach its final
>>>>>>>>>>>>>>> state at machine address [0000136c].
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> A nonsense trace, as it is mixing the execution path of
>>>>>>>>>>>>>> two independent execution units.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> In other words you acknowledge that you are technically
>>>>>>>>>>>>> incompetent to provide the execution trace of one
>>>>>>>>>>>>> simulation and one nested simulation of the input to H(P,P).
>>>>>>>>>>>>
>>>>>>>>>>>> No, I am saying that you are asking for the equivalent of a
>>>>>>>>>>>> of a square circle.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> So an execution trace of the input to H(P,P) is easy to show
>>>>>>>>>>> when H simulates its input, yet another execution trace of
>>>>>>>>>>> the input to H(P,P) that was invoked by P is "like a square
>>>>>>>>>>> circle" can't possibly exist?
>>>>>>>>>>
>>>>>>>>>> The problem is that your second trace is NOT a piece of the
>>>>>>>>>> first.
>>>>>>>>>>
>>>>>>>>>> The fact you don't understand that says you just don't know
>>>>>>>>>> how computers or programs actually work.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> When a UTM simulates a TM description that calls a UTM that
>>>>>>>>> simulates a
>>>>>>>>> TM description all of this is simply data on the first UTM's
>>>>>>>>> tape and the only actual executable is the first UTM.
>>>>>>>>
>>>>>>>>
>>>>>>>> Yes, and a trace made by that outer UTM will show the states
>>>>>>>> that the second UTM is going through, but NOT the states that
>>>>>>>> second UTM simulates in its own processing.
>>>>>>>>
>>>>>>>> That second UTM might produce its OWN trace of the states that
>>>>>>>> it has simulated, but that is a SEPERATE trace, and NOT part of
>>>>>>>> the trace from the OUTER UTM.
>>>>>>>>
>>>>>>>
>>>>>>> And this trace is written to the outer UTM's tape as a part of
>>>>>>> its own data.
>>>>>>
>>>>>> Yes, the DATA is there, ENCODED on the tape, but it isn't part of
>>>>>> the trace generated by that UTM.
>>>>>
>>>>> The only actual executable is the outer UTM everything else is a
>>>>> part of the same nested process.
>>>>
>>>> So the only actual valid trace is what that outer simulator actual
>>>> simulated.
>>>>
>>>
>>> There is a valid trace of every line of code that is emulated.
>>> Operating system code has its trace tuned off. This only leaves the
>>> user code such as P() and main(). Then we see the 14 lines execution
>>> trace of the two level simulation of the input to H(P,P)
>>
>> No, because the second level emulation is NOT emulated by the top
>> level emulator, its emulator is.
>>
>> Unless you are lying about what H does, you are just lying that the
>> second level code is emulated by the same emulation process that the
>> first is. (That may well be true, but it means you logic is still
>> built on a lie).
>>
>
> If you are too stupid to understand that H(P,P) derives the same
> execution trace of its input every time it is called you are far too
> stupid to evaluate my work.

Ok, then why does the H(P,P) that P calls get stuck in an infinite
recursion wneh the top level doesn't?

Or is it that it doesn't, but H looks at the trace wrong and THINK that
it will, so it aborts it?

Note also, the question isn't does the copy of H called by P see the
same execution trace as the copy of H making the decision, but why does
the copy making the decision see the trace generated by the copy it is
simulating instead of seeing it simulating that simulator.

The ONLY answer is you are LYING about what H does. My guess is that H
isn't actually an independent computation but all the copies interact
and H is actually incapable is actually simulating a copy of itself.

This means that it is NOT the computation equivalent of an actual Turing
Machine.

One hint about this is that the input isn't in a distinct
"address space" from the code of H. (which actually introduces a
recursion that isn't in the original problem, which is part of your
problem).

>
>>
>>>
>>>> Since it is simulating a call to H, that means it needs to simulate
>>>> the code IN H, not the code that this H is simulating.
>>>>
>>>> DEFINITIONS. (Which you seem to have problems with).
>>>>
>>>>>
>>>>>>
>>>>>> Try it.
>>>>>>
>>>>>> Write a UTM that takes as input the representation of a machine
>>>>>> and its tape, and generates at the end a representation of the
>>>>>> final state f the machine, the represntation of the final tape of
>>>>>> that computation and a trace of the execution it performed, and do
>>>>>> the experement.
>>>>>>
>>>>>> The data from the second level UTM will be in the representation
>>>>>> of the output tape (the output of the second UTM), NOT the section
>>>>>> of the tape with the trace of the execution.
>>>>>>
>>>>>> This shows that this second level trace isn't part of the first
>>>>>> level trace, as you want to claim.
>>>>>>
>>>>>> You just don't understand how it works, and get the level os
>>>>>> execution/simulation confused.
>>>>>>
>>>>>>>
>>>>>>>> Finish your TM simulator, and design (or look up) a UTM and try it.
>>>>>>>>
>>>>>>>> Try to find the execution trace generated by the second UTM
>>>>>>>> actually in the execution trace of the first UTM, it isn't
>>>>>>>> there, because the first UTM never actually did that. All you
>>>>>>>> will see is the steps the second UTM went through to simulate
>>>>>>>> its input.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Everyone here (including you) know that is a ridiculously
>>>>>>>>>>> stupid thing to say. What is you motive for saying these
>>>>>>>>>>> ridiculously stupid things ?
>>>>>>>>>>> Are you tying to announce to the world that you are a total
>>>>>>>>>>> numbskull?
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Yes, ON YOUR PART. It is stupid to suggest that it is correct
>>>>>>>>>> to mix the execution trace of different execution contexts as
>>>>>>>>>> if they were a single context.
>>>>>>>>>>
>>>>>>>>>> When you understand that, you might be able to see your error.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>