On 5/27/22 11:54 AM, olcott wrote:
> On 5/27/2022 4:36 AM, Malcolm McLean wrote:
>> On Thursday, 26 May 2022 at 12:21:07 UTC+1, Ben wrote:
>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>
>>>> On Thursday, 26 May 2022 at 02:15:36 UTC+1, Ben wrote:
>>>>>
>>>>> I admit it's all guesswork though. I seriously lost interest when
>>>>> all I
>>>>> thought it worth doing was pointing out that if H(X,Y) does not report
>>>>> on the "halting" of X(Y) then it's not doing what everyone else is
>>>>> talking about.
>>>>>
>>>> To me, that's what retains the interest.
>>>> If someone claims that H_Hat(H_Hat) halts, and they have an H such
>>>> that H(Hat, H_Hat) reports "Halting", then they would say that,
>>>> wouldn't they?
>>>>
>>>> If it turns out that H isn't a Turing machine but a C/x86 program, and
>>>> that they are refusing to provide the source, then really the whole
>>>> thing must be dismissed.
>>>>
>>>> However if they say that H_Hat(H_Hat) halts, and H(H_Hat,H_Hat)
>>>> reports non-halting, and they can prove that H is correct.
>>> There's no reason at all to think that H is /not/ correct. But since H
>>> is not reporting on the halting of a call to H_Hat(H_Hat), I don't see
>>> what's interesting about it being correct. Do you really think it's
>>> "deciding" some interesting property of the "input"?
>>>
>> I can't follow all the arguments, and they seem to shift over time.
>> But basically PO is trying to argue that H_Hat is an invalid input,
>> on the analogue that a sentence like "this sentence is false" isn't
>> a valid sentence.
>
> No that is not what I am saying. I am saying that H(H_Hat, H_Hat) or the
> current way of saying that input to H(P,P) specifies behavior to H that
> would never reach its under its correct x86 emulation by H.

But the question isn't does *H* reach the final state of the input in
its processing, it is does the computation the input represents reach
its final state.

You are just admitting to trying to answer the WRONG question.

>
> _P()
> [00001352](01)  55              push ebp
> [00001353](02)  8bec            mov ebp,esp
> [00001355](03)  8b4508          mov eax,[ebp+08]
> [00001358](01)  50              push eax      // push P
> [00001359](03)  8b4d08          mov ecx,[ebp+08]
> [0000135c](01)  51              push ecx      // push P
> [0000135d](05)  e840feffff      call 000011a2 // call H
> [00001362](03)  83c408          add esp,+08
> [00001365](02)  85c0            test eax,eax
> [00001367](02)  7402            jz 0000136b
> [00001369](02)  ebfe            jmp 00001369
> [0000136b](01)  5d              pop ebp
> [0000136c](01)  c3              ret
> Size in bytes:(0027) [0000136c]
>
> When the above is correctly emulated by H the first seven instructions
> are emulated then P calls H(P,P) which causes H to emulate the first
> seven instructions again. This infinite emulation never stops unless
> aborted. Whether or not it is aborted the emulated P never reaches its
> "ret" instruction thus never halts. The H(P,P)==0 is proved to be correct.
>

But H can't correctly emulate all of the input, and give an answer. That
is your problem

Again, what is your definition of "Correct emulation" here, it seems
different that that which is normally taken

>> He then makes the observation that a simulating halt decider will
>> be thrown into infinitely nested simulations by H_Hat. So its own
>> behaviour is what is problematical, not the "invert the answer"
>> step.
>
> It is that P calls H(P,P) that causes the nested emulation.
> It is not that H(P,P) emulates its input that causes this.
> P specifies infinite emulation to H.

Except P doesn't specify infinite emulation to H if H knowns that H can
abort its emulation.

>
>> I can't quite follow his next step of reasoning, which seems to be
>> that because H aborts itself (the simulated copy of itself which it
>> is running, which in PO's system is the identical same physical
>> machine code), the abort doesn't count as part of the behavior of
>
> H(P,P) does not abort itself it aborts its input which also aborts
> everything that this input invoked.
>

Right, which means that a P that calls this H gets the answer and
returns, showing it is Haling.

This also shows up in a CORRECT emulaton of the input, which H doesn't do.

>> the input. So "Non-halting" is correct even though H_Hat halts.
>
> This input does not halt (meaning that it has reached its "ret"
> instruction) it was aborted because it will never reach its "ret"
> instruction.
>
> _Infinite_Loop()
> [000012c2](01)  55              push ebp
> [000012c3](02)  8bec            mov ebp,esp
> [000012c5](02)  ebfe            jmp 000012c5
> [000012c7](01)  5d              pop ebp
> [000012c8](01)  c3              ret
> Size in bytes:(0007) [000012c8]

Right, THIS input never halts

>
> The exact same process applies to the above _Infinite_Loop()

But P does Halt if correctly emulated, as your traces for H1 show.

>
>> PO will probably come in here as a mischaracterisation of his
>> position.
>>
>> A simulator is a perfectly reasonable program to write, and there are
>> many practical simulators. Adding a bit of simple loop detection to
>> a simulator is also a reasonable thing to do, and might be of practical
>> value. However it's not of much theoretical value, because however
>> complicated you make the loop detection, there will always be some
>> examples of unterminating loops it fails to catch.
>>
>
>      For any program H that might determine if programs halt, a
> "pathological"
>      program P, called with some input, can pass its own (x86) source
> and its input to
>      H and then specifically do the opposite of what H predicts P will
> do. No H
>      can exist that handles this case.
> https://en.wikipedia.org/wiki/Halting_problem
>
>
> void P(u32 x)
> {
>   if (H(x, x))
>     HERE: goto HERE;
>   return;
> }
>
> When I correctly determine the halt status of that input I have refuted
> all of the HP proofs.

Except you didn't. You say P(P) is non-halting when it halts.

You apparently just can't read a requirements document.

H needs to determine if the program its input represent will Halt, not
if its own simulation of that input will halt, because it doesn't
actualy need to do a simulation of the input.

>
>> I'm sceptical that PO's H detects nested simulation rather than
>> recursion,
>> partly because he himself said it was infinite recursion before I pointed
>> out that it was  not, and partly because nested simulation is more
>> challenging to detect, and he hasn't been forthcoming on how it is
>> achieved. But since has hasn't yet made H available, there's no way of
>> knowing.
>>
>
> The nested simulation pattern derives behavior precisely matching
> infinite recursion. If H(P,P) simulates its input (as in nested
> simulation) or directly executes its input (as in infinite recursion)
> the exact same behavior is derived to outside observers:
>
> If the execution trace of function H() called by function P() shows:
> (1) Function H() is called twice in sequence from the same machine
> address of P().
> (2) With the same parameters to H().
> (3) With no conditional branch or indexed jump instructions in P().
> (4) With no function call returns from H() to P().
> then the function call from P() to H() is infinitely recursive.

Nope, not proven.

(3) needs to include ALL the code in the computation P between the
loops, which includes the code in H. There is no exclusion for the
"system code" of H, because the copy of H that P calls is user code.

You just are proving you don't understand how programs work.

Can you provide a reference that states it YOUR way, allowing the
ignoring of the code in H?

I don't think so.

>
>> As for the "H_Hat is a form of invalid speech" argument, I don't really
>> understand the philosophy of maths, but I don't see it myself.
>>
>
> To sum it all up I show how H can treat its pathological input as an
> ordinary input and simply decide that this input never halts.
>

And be WRONG.

P(P) Halts if H(P,P) returns 0, so that answer is WRONG by definition.

You are just proving how stupid you are.