On 11/5/21 9:27 AM, olcott wrote:
> On 11/5/2021 5:49 AM, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>
>>> On Thursday, 4 November 2021 at 21:14:31 UTC, Ben Bacarisse wrote:
>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>
>>>>> On Thursday, 4 November 2021 at 17:41:31 UTC, André G. Isaak wrote:
>>>>>>
>>>>>>> (1) The above 14 simulated lines are a correct pure simulation of
>>>>>>> the
>>>>>>> input to H(P,P) for every possible encoding of simulating halt
>>>>>>> decider H.
>>>>>>
>>>>>> What exactly does 'every possible encoding of simulating halt
>>>>>> decider H'
>>>>>> even mean?
>>>>>>
>>>>> You need to understand the PO is working with x86 code, not Turing
>>>>> machines.
>>>> Not always. He's also posted a lot of incorrect things about TMs.
>>>>> So P does not contain an embedded near copy of H, as in Linz's scheme,
>>>>> but a call to H. Now at first sight, that doesn't matter. But it
>>>>> allows for a mental separation between "the input" (the simple little
>>>>> driver which calls H and inverts behaviour when it gets the result)
>>>>> and H itself (the halt decider).
>>>> How does this mental separation help PO ignore the fact that H gets the
>>>> answer wrong? How do you excuse his simply ignoring the plain fact that
>>>> H(P,P) == false is the wrong answer? I ask /you/, specifically, because
>>>> you seem to be kindly disposed towards PO, and I can't work it out at
>>>> all. He can't not know that an H that gives the wrong answer is utterly
>>>> trivial. He must know, that we know, that this can't be the miraculous
>>>> impossible TM he claimed to have tree years ago. I just can't find any
>>>> flattering spin to put on it.
>>>>
>>> So in PO's mind, "P" is a small section of machine code at a contiguous
>>> address that contains a call to "H", and inverts the result. "P" doesn't
>>> include "H", because that's not "input".
>>> Now because "P" calls "H" and inverts the result, it's asking what PO
>>> calls
>>> the "liar's paradox" of "H". H(P,P) is therefore not a legitimate
>>> computation.
>>
>> I don't think he is still banging that drum.  If he is, how can he claim
>> that H(P,P) == false is the correct return?
>>
>
> As soon as we verify that the correct pure simulation of the input to
> H(P,0) never reaches the last address of P at c50 we know that the input
> to H(P,P) never halts thus the correctly halt status of H(P,P)==0;

Except that we KNOW that the CORRECT PURE SIMULATION of this input DOES
reach the lats address of the program, becauswe know that P(P) Halts
(and you agree to that) and the DEFINITION of a correct pure simulation
is that the simulation EXACTLY matches the behavior of the program whose
representation it is simulating.

You seem to be under the incorrect assumption that H is a pure
simulator, when it fails to meet that basic definitional requirement.

Well, ONE H does meet the requirements, the H that doesn't ever abort it
simulation, but that H doesn't answer the question H(P,P) is it is wrong
for a different reason. Since every H gets its own H^/P. the fact that
the P for that H happens to be non-halting doesn't imply the same for
the others.

You don't seem to understand these basics.

And until you learn what the se terms mean and correct your arguments to
use them correctly, EVERYTHING you try to write will be rejected for
starting with incorrect definitons.

>
>
>>> Now Mike Terry suggested that we have H1, which is identical code to
>>> H, but compiled at a different address. Because "H" reports
>>> non-halting for "P", based on filtering out code in calls to its own
>>> address, H1 reports halting for "P", because it doesn't filter out the
>>> calls to "H", and sees that H returns non-halting to "P", which P
>>> inverts, and halts.
>>>
>>> The difficulty with Mike Terry's suggestion is that PO insists that
>>> "H" gets the right answer, not "H1", despite the fact that P(P) halts.
>>
>> I think Mike was only addressing the identical code question.  I had the
>> same thought, but then I've never believed that PO had nested
>> simulations either.  He's using, I think, only the top-level trace and
>> that allows identical code to take different execution paths.
>>
>>> So I speculate that PO is thinking "we can replace the call to "H" by
>>> any
>>> equivalent simulating halt decider, without changing anything". If we
>>> replace "H" by a pure simulator that doesn't have an abort step, then
>>> indeed the recursive calls never end and "P" never halts. Remember "P"
>>> is just the small section of contiguous machine code, not the call.
>>>
>>> Now the final stage is to say that, though "H" is not a pure simulator
>>> but has an abort step, it must be aborting "P" correctly, because
>>> otherwise
>>> "P" would run forever. Therefore "H" is correct.
>>
>> He's been saying that for a very ling time.  The wrong answer is
>> "correct" because of what a slightly different computation would do.
>> It's been explicit since the "line 15 commented out" days.  I thought he
>> had abandoned that plan, but being obscure is a key strategy for keeping
>> the game going, so I can't really know.
>>
>> But that's not what I was getting at.  I am trying to grasp how he can
>> ignore the definition of the problem.  He must surely know that what he
>> is claiming now is trivial, whereas he made a significant (though false)
>> claim three years ago.  What's going on in his head that allows him to
>> think he's talking about the halting problem and that he has found an
>> "impossible H" when an H that returns false for a halting computation is
>> so utterly trivial.
>>
>
> // Simplified Linz Ĥ (Linz:1990:319)
> // Strachey(1965) CPL translated to C
> void P(u32 x)
> {
>   if (H(x, x))
>     HERE: goto HERE;
> }
>
> _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)
>
> The above proves:
> (a) That it is the correct pure simulation of the first 14 steps of the
> input to H(P,P)  **

Nope, been pointed out many times before

Your CPU is broken (or at least your simulation of it)

Call 966 needs to go to 966 not C36.

>
> (b) That the correct pure simulation of H(P,P) never halts.

Also incorrect.

Your batting 0/2, and two wrongs don't make a right.
>
> ** Because it only claims to show the simulation of P it can screen out
> the 350 pages of the simulation of H.

Except that the copy of H inside P IS PART of the PROGRAM P.

YOu ar just talking POOP.

>
> Since we are not asserting that H correctly decides the halt status of
> its input and we are only verifying that H performs a correct pure
> simulation of the first 14 steps of its input H(P,P) we don't need to
> see any of the behavior of H.
>

Nope, FAIL.

>
>
>
> Copyright 2021 Pete Olcott
>
> "Great spirits have always encountered violent opposition from mediocre
> minds." Einstein