On 11/3/21 11:34 AM, olcott wrote:
> 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.
>

And if H actually is a proper pure simulator of P, then H({P,P) can
NEVER return the non-halting answer. If H does, that PROVES, BY
DEFINITION, that it is NOT a proper pure and accurate simulator.

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