On 11/3/2021 9:54 AM, Mike Terry wrote:
> On 03/11/2021 04:09, Mike Terry wrote:
>> On 03/11/2021 03:30, André G. Isaak wrote:
>>> On 2021-11-02 21:14, olcott wrote:
>>>> On 11/2/2021 9:26 PM, André G. Isaak wrote:
>>>>> On 2021-11-02 19:32, olcott wrote:
>>>>>> On 11/2/2021 8:07 PM, André G. Isaak wrote:
>>>>>>> On 2021-11-02 18:49, olcott wrote:
>>>>>>>> On 11/2/2021 6:31 PM, André G. Isaak wrote:
>>>>>>>>> On 2021-11-02 16:51, olcott wrote:
>>>>>>>>>> On 11/2/2021 4:49 PM, André G. Isaak wrote:
>>>>>>>>>>> On 2021-11-02 15:41, olcott wrote:
>>>>>>>>>>>> On 11/2/2021 4:05 PM, André G. Isaak wrote:
>>>>>>>>>>>>> On 2021-11-02 14:43, olcott wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> If everyone "defines" that the halt decider is wrong when
>>>>>>>>>>>>>> it correctly reports what the actual behavior of its
>>>>>>>>>>>>>> actual input would be then everyone (besides me) is wrong.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The definition tells you what a halt decider *is*. It
>>>>>>>>>>>>> doesn't define it as 'wrong'. It defines what question it
>>>>>>>>>>>>> is supposed to answer.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The input to a halt decider is a string. Strings don't
>>>>>>>>>>>>> *have* halting behaviour so your position above is entirely
>>>>>>>>>>>>> incoherent.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> In computability theory, the halting problem is the problem
>>>>>>>>>>>> of determining, from a description of an arbitrary computer
>>>>>>>>>>>> program and an input, whether the program will finish
>>>>>>>>>>>> running, or continue to run forever.
>>>>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>>>>>
>>>>>>>>>>> The definition of 'halting problem' is what it is.
>>>>>>>>>>>
>>>>>>>>>>> Note that the above definition doesn't make any mentions of
>>>>>>>>>>> 'simulations' just as the more formal definition used by
>>>>>>>>>>> Linz's does not.
>>>>>>>>>>>
>>>>>>>>>>>> A halt decider only need answer whether or not the correct
>>>>>>>>>>>> simulation of its input would ever reach a final state of
>>>>>>>>>>>> this input by a simulating halt decider.
>>>>>>>>>>>
>>>>>>>>>>> A 'correct simulation', presumably, would be one that acts
>>>>>>>>>>> identically to the actual TM being simulated. That means that
>>>>>>>>>>> if the actual TM halts the simulation also must halt. Which
>>>>>>>>>>> means that your simulation is not a 'correct simulation'.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> There are no freaking presumptions about it. As long as the
>>>>>>>>>> simulation of P(P) matches its x86 source code then the
>>>>>>>>>> simulation is correct.
>>>>>>>>>
>>>>>>>>> I have no idea what it means for a simulation of P(P) to "match
>>>>>>>>> its x86 source code".
>>>>>>>>>
>>>>>>>>
>>>>>>>> When the simulator executes the instructions at
>>>>>>>> 0xc36, 0xc37, 0xc39, 0xc3c, 0xc3d, 0xc40, 0xc41
>>>>>>>> of the x86 source code of P, then the simulator
>>>>>>>> correctly simulated P(P).
>>>>>>>
>>>>>>> No. A simulator only 'correctly simulates' a machine when it
>>>>>>> accurately duplicates *all* of the behaviour of that machine.
>>>>>>> Part of the behaviour of P(P) is that it halts.
>>>>>>>
>>>>>>
>>>>>> That is a stupid thing to say. The x86 emulator correctly emulates
>>>>>> the x86 instructions of P iff it emulates the actual x86
>>>>>> intructions of P saying anything else is both pure bullshit and
>>>>>> quite nutty.
>>>>>
>>>>> That's a nonsensical claim. If it correctly emulates all the
>>>>> instructions then it should have identical behaviour. That includes
>>>>> whether it halts or not.
>>>>
>>>> Maybe you don't understand the x86 language well enough to ever
>>>> understand what I am saying.
>>>>
>>>> While H continues to simulate P these first seven instructions of P
>>>> continue to repeat. Do you understand that?
>>>
>>> Which is irrelevant to the halting problem which asks whether P(P)
>>> halts? Does it? Yes. Ergo the only correct for H(P, P) to give is
>>> 'true'. *Nothing* apart from the actual behaviour of P(P) is relevant
>>> to determining what the correct answer to this question is, so
>>> there's not even any point in providing all your meaningless traces.
>>>
>>> The correct answer to H(P, P) is determined by the actual behaviour
>>> of P(P). We know the actual behaviour of P(P). So there's absolutely
>>> no reason to consider anything else.
>>>
>>> And you conveniently ignored all the questions which I asked.
>>>
>>> What does the input to H(P, P) represent if not P(P)?
>>>
>>> How can the inputs to H1(P, P) and H(P, P) represent different things
>>> given that they are the *same* input?
>>
>> My suspicion (difficult to confirm) is still that in both those cases,
>> PO is looking at the same computation.  It's simply that H and H1, in
>> examining the identical execution traces, behave differently because
>> they take their own machine code address and use that in interpreting
>> the instruction trace.
>>
>> So e.g. H uses its address to exclude certain parts of the trace it
>> examines, and consequently INCORRECTLY decides it is seeing infinite
>> recursion.  H1 excludes a different address range, so it doesn't see
>> infinite recursion and so the simulation continues FURTHER than H
>> continues it, and in fact with H1 the simulation proceeds right up to
>> the point where it reaches its halt state, so H1 give the correct
>> answer.  [I'd guess H1 works because it is seeing the conditional
>> branch instructions that H deliberately ignores, and so his unsound
>> recursion test does not match.]
>>
>> I bet if we looked at the actual traces that H and H1 are producing,
>
> Correction - what I meant to say here is "actual traces that H and H1
> are EXAMINING".
>
> Obviously the traces of H(P,P) and H1(P,P) [including the traces of the
> outer emulations of H, H1 themselves] will be different, because H and
> H1 addresses will be different if nothing else.
>
> That's a trivial point, but seems to be a constant point of
> miscomunication between PO and others.  I reckon that when PO says
> "computations H(P,P) and H1(P,P)" he is intending to say "the traces of
> the SIMULATIONS of P(P) within H and H1", or similar.  [And if I'm right
> above, those are NOT different, other than that H1 simulates FURTHER
> than H, and so gets to observe the simulation halting.  Nothing to do
> with the presence of mysterious PSR!.]
>
> Mike.
>

_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]

Begin Local Halt Decider Simulation at Machine Address:c36

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[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

I am not going to explain the difference between H1 and H at this point
because you would be overwhelmed. You first must understand that while H
is a pure simulator the above seven lines of P continue to repeat.

>
>> they would be exactly the same UP TO THE POINT WHERE H MAKES ITS
>> MISTAKE AND SAYS "INFINITE RECURSION DETECTED".  I.e. H just makes the
>> wrong decision and terminates the simulation too early, like everyone
>> has been saying for over a year...  :)
>>
>> Mike.
>

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein