On 11/2/2021 11:09 PM, 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.
>

The key additional insight that I have had in the last couple of days is
that my proof applies to every possible encoding of simulating halt
decider H.

While H continues to simulate these first seven instructions of P, P
never reaches its final state of 0xc50. When H(P,P) aborts its
simulation of P, P never reaches its final state of 0xc50.

Thus for every possible encoding of H and every possible behavior of H,
H(P,P)==0 is necessarily correct.

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)

Apparently only Richard can understand that while H is a pure simulator
the above code never halts. Apparently no one besides me understands
that when the above code is aborted it never reaches its final state.

> 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...  :)
>
> Mike.

--
Copyright 2021 Pete Olcott

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