On 8/15/21 9:36 AM, olcott wrote:
> On 8/15/2021 4:39 AM, Malcolm McLean wrote:
>> On Sunday, 15 August 2021 at 05:39:10 UTC+1, olcott wrote:
>>> On 8/14/2021 5:56 PM, Ben Bacarisse wrote:
>>>> Jeff Barnett <j...@notatt.com> writes:
>>>>
>>>>> On 8/14/2021 2:43 PM, Ben Bacarisse wrote:
>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>
>>>>>>> The P(P) of main() only halts because...
>>>>>> As you say, P(P) halts.
>>>>>>
>>>>>>> *Halting computation* is any computation that eventually reaches its
>>>>>>> own final state. This criteria divides computations that halt from
>>>>>>> those that merely stop running because their simulation was aborted.
>>>>>> No. There is no "special kind of halting". The computation M(I)
>>>>>> either
>>>>>> halts or it does not. H(M, I) should be false if, and only if, M(I)
>>>>>> does not halt.
>>>>>>
>>>>>>> void P(u32 x)
>>>>>>> {
>>>>>>> if (H(x, x))
>>>>>>> HERE: goto HERE;
>>>>>>> }
>>>>>> P(P) halts, yet H(P, P) is false. That's the wrong answer.
>>>>>> Why are you still hiding H? Is it because you have still not figured
>>>>>> out how to nest a call to the simulator you are using? Fortunately
>>>>>> "we"
>>>>>> (i.e. everyone but you) can see that H is wrong without even
>>>>>> seeing the
>>>>>> code. Who is included in the "we" of the subject line? Have you found
>>>>>> someone else who thinks that false is the correct return from a
>>>>>> partial
>>>>>> halt decider called with arguments that represent a halting
>>>>>> computation?
>>>>>
>>>>> I have questions about the PO simulator I hope someone can answer. It
>>>>> perhaps concerns memory mapping: First - is every instance of a use at
>>>>> different levels in its own address space? Second - if not, is there
>>>>> any way to know when an address is reported, which simulator instance
>>>>> is being reported on? When the dumb bunny (PO expression) notes that
>>>>> the same address is reached a second time without a conditional branch
>>>>> being executed, is there any assurance that the addresses are noted
>>>>> from the same instance of the simulation? And finally, how can one
>>>>> determine if it's the same address twice without doing some sort of
>>>>> compare and branch? Thanks in advance for any sort of enlightenment.
>>>>
>>>> You won't get a straight answer from PO, but I don't think there is any
>>>> nested simulation happening at all. PO "knows" it's that same a
>>>> recursion, so he just has recursive calls traced from "outside". I may
>>> No this is not possible. There is no possible way to use ordinary
>>> recursion to implement nested x86 emulation without memory corruption of
>>> the stack. I explained all of the technical details of context
>>> switching: Here is a link that does a better job:
>>>
>>> https://en.wikipedia.org/wiki/Context_switch
>>>
>>> Each virtual machine has its own registers, stack and RAM. Once the
>>> virtual machine environment is set up, allocating the stack and RAM and
>>> other house keeping functions a context switch only requires saving and
>>> restoring all the machine registers.
>>>
>> We can write a ZX81 emulator on a modern machine. A ZX81 has 4K ROM
>> and 1K RAM. So our first line can be a "virualmem = malloc(1024 * 5).
>> We then
>> set up everything else in that memory space.
>> However the ZX81 emulator cannot emulate another ZX81, since it has only
>> 1K RAM to play with, and the virtual machine needs 5K.
>> You'll get this problem whenever you try to allow nested emulation on a
>> random-access  memory model machine.
>>
>> Turing machines don't have this problem. Write a UTM, and a "Hello world"
>> program, and
>> UTM<Hello> with output "Hello world" on the tape.
>> UTM<UTM><Hello> will also output "Hello world" on the tape. You can
>> stack up
>> as many UTMs as you like without any reprogramming. It might get very
>> slow,
>> but it will eventually finish.
>>
>> What you can do is treat memory allocation as a special function. Then
>> you
>> can nest simulations.
>>
>
> Yes I do that.
> It does not require knowing any of those details to see how totally
> blatantly obvious it is that:
>
> While H remains in pure simulation mode simulating the input to H(P,P)
> this simulated input never stops running thus conclusively proving that
> when H decides this input never halts it is correct.
>

Except that since H doesn't stay as a Pure Simulator, the transformation
of tracing the simulator doing the simulation to the tracing of the
machine it is simulating is not valid.

If you wish to claim otherwise, please provide a proof that your
transform is actually valid.

That Tranceform only applies to a machine that is ALWAYS a pure
simulation, not one that simulates until some condition.

Thus your analysis that P is infinitely executing is unsound and gives
the wrong answer.

The fact that an aborted simulation doesn't reach the halting point of
the machine it is simulating actually proves nothing.

It IS a fact, that when P is run as the actual machine, or its
represention run by an ACTUAL pure simulator, it does reach a halting state.

So, we can show that H was wrong, as its input when PROPERLY simulated
will halt, H just errors in stopping it too soon due to using UNSOUND logic.

H just stops about 2/3s of the way to the final ending of P. Of course,
P is built on the H that is programed to do it that way. If you change
the H that P is built on, you need to totally restart your analysis.

You analysis that P is non-halting is ONLY sound if H is a ACTUAL pure
simulator, and your problem there is that if that is H, then H never
answers the question H(<P>,<P>) so it doesn't really matter that P(<P>)
is non-halting, H was 'wrong' anyway since it didn't answer.

> _P()
> [00000c36](01)  55          push ebp
> [00000c37](02)  8bec        mov ebp,esp
> [00000c39](03)  8b4508      mov eax,[ebp+08] // 2nd Param
> [00000c3c](01)  50          push eax
> [00000c3d](03)  8b4d08      mov ecx,[ebp+08] // 1st Param
> [00000c40](01)  51          push ecx
> [00000c41](05)  e820fdffff  call 00000966    // call H
> [00000c46](03)  83c408      add esp,+08
> [00000c49](02)  85c0        test eax,eax
> [00000c4b](02)  7402        jz 00000c4f
> [00000c4d](02)  ebfe        jmp 00000c4d
> [00000c4f](01)  5d          pop ebp
> [00000c50](01)  c3          ret
> Size in bytes:(0027) [00000c50]
>
>  machine   stack     stack     machine    assembly
>  address   address   data      code       language
>  ========  ========  ========  =========  =============
> [00000c63][0010171e][00000c68] e8fefcffff  call 00000966 // call H(P,P)
>
> Begin Local Halt Decider Simulation at Machine Address:c36
> [00000c36][002117ca][002117ce] 55          push ebp
> [00000c37][002117ca][002117ce] 8bec        mov ebp,esp
> [00000c39][002117ca][002117ce] 8b4508      mov eax,[ebp+08]
> [00000c3c][002117c6][00000c36] 50          push eax       // push P
> [00000c3d][002117c6][00000c36] 8b4d08      mov ecx,[ebp+08]
> [00000c40][002117c2][00000c36] 51          push ecx       // push P
> [00000c41][002117be][00000c46] e820fdffff  call 00000966  // call H(P,P)
>
> [00000c36][0025c1f2][0025c1f6] 55          push ebp
> [00000c37][0025c1f2][0025c1f6] 8bec        mov ebp,esp
> [00000c39][0025c1f2][0025c1f6] 8b4508      mov eax,[ebp+08]
> [00000c3c][0025c1ee][00000c36] 50          push eax       // push P
> [00000c3d][0025c1ee][00000c36] 8b4d08      mov ecx,[ebp+08]
> [00000c40][0025c1ea][00000c36] 51          push ecx       // push P
> [00000c41][0025c1e6][00000c46] e820fdffff  call 00000966  // call H(P,P)
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>
>
>