On 11/3/2021 4:49 AM, Malcolm McLean wrote:
> On Wednesday, 3 November 2021 at 04:09:54 UTC, 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,
>> 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... :)
>>
> Ah, insightful as always.
> That would explain a lot.
>

It is very obvious to anyone here that knows the x86 language
sufficiently well that when H is a pure simulator that the following
first seven lines remains stuck in infinite recursion.

My current estimate based on only having agreement from Richard
is that everyone here beside myself and Richard is perfectly clueless
about the x86 language thus will never be able to understand what I am
saying.

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)

--
Copyright 2021 Pete Olcott

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