On 11/6/21 1:52 PM, olcott wrote:
> On 11/6/2021 12:36 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 11/5/2021 7:01 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 11/5/2021 6:08 AM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>> On 11/4/2021 8:16 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>> On 11/4/2021 12:21 PM, Ben Bacarisse wrote:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>>>>>>>> 2021-11-03 Halt Deciding Criteria
>>>>>>>>>>> It is impossible for any halt decider to be incorrect when
>>>>>>>>>>> the correct
>>>>>>>>>>> pure simulation of its input never halts and it reports not
>>>>>>>>>>> halting.
>>>>>>>>>>
>>>>>>>>>> Unfortunately H(P,P) does not meet the criterion for being
>>>>>>>>>> correct about
>>>>>>>>>> the computation represented by it's arguments.  H(P,P) == 0
>>>>>>>>>> when P(P)
>>>>>>>>>> halts is wrong:
>>>>>>>>>
>>>>>>>>> Since you can't comprehend the x86 assembly language you are
>>>>>>>>> out of
>>>>>>>>> your depth in this.
>>>>>>>>
>>>>>>>> You are funny!  The definition of the halting problem is what it
>>>>>>>> is.
>>>>>>>
>>>>>>> And you are incapable of examining this at the totally concrete
>>>>>>> level
>>>>>>> of the x86 language.
>>>>>>
>>>>>> What the correct answer is for a halting computation is in the
>>>>>> problem
>>>>>> definition.  Since you've told us that H gets the key case wrong,
>>>>>> what
>>>>>> is the point of all your posts?
>>>>>
>>>>> _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]
>>>>>
>>>>> If the provably correct pure simulation of the input to H(P,P) by
>>>>> every possible simulating halt decider H never halts then the correct
>>>>> halt status of the input to H(P,P)==0
>>>> If P(P) halts (and it does),
>>>
>>> and the correct pure simulation of the input to H(P,P) never halts
>>> then we know that P(P) and H(P,P) are not computationally equivalent
>>> to each other and can thus have opposite values.
>>
>> Goodness you are confused.  H(P,P) and P(P) are never the same
>> computation no matter what H does.  But since any correct simulation of
>> P applied to P halts (it must do since P(P) halts) your remark has
>> nothing to do with the case in hand.
>>
>>> The big difference between this proof and the prior proof form the
>>> last six months is that now we know that the pure simulation of the
>>> input to H(P,P) never halts
>>
>> A correct simulation of P applied to P halts because P(P) halts.  That's
>> why H(P,P) == 0 is wrong.  I can't see what it is that's preventing you
>> from seeing this huge elephant in the room.
>>
>>> A correct pure simulation is not verified on the basis of any mere
>>> assumptions.
>>
>> Indeed.  I have to rely on what you've told me and the definition of a
>> simulation.  You've told me that P(P) (the computation represented by
>> the arguments to H) halts (in fact you also showed a trace of it
>> halting).  We know, therefore, from the definition of what a "correct"
>> simulation is, that a simulation of the computation represented by the
>> arguments to H will also halt.
>>
>>> As long as the first seven x86 instructions of the source code of P
>>> are executed in order and the seventh instruction causes this cycle to
>>> repeat then we know that H(P,P) performed a correct pure simulation of
>>> its input for the entire 14 steps of this simulation.
>>
>> If your code for P(P) does not halt, or your simulation of P(P) does not
>> halt then the code is wrong, but I can't help with that because its
>> "secret" (i.e. you dare not show it).
>>
>>>> H(P,P) == 0 is wrong.  Is your plan to just
>>>> keep ignoring what the halting problem is?  Do you get enough joy from
>>>> pasting the same text in every reply to make t worth while?
>>>> Looking back at your old posts from Dec 2018 you seemed genuinely
>>>> thrilled to have something that everyone said as impossible.  You
>>>> surely
>>>> can't be thrilled about touting an H that everyone knows is trivial to
>>>> write.  But if it does bring you joy, I'll play along...
>>
>> No answer?  Does this bring you joy?
>>
>
>
> The brand new exception to the rule that the pure simulation of a
> machine description on its input and the direct execution of this
> machine on its input ARE COMPUTATIONALLY EQUIVALENT is the case where
> the decider and its machine description input have a pathological
> relationship to each other.
>

Where is that exception stated? You don't get to make new rules.

Are you are just talking about POOP agian?

> When the correct pure simulation of the input to H(P,P) never reaches a
> final state of P it is necessarily true that H(P,P)==0 even if no H in
> the universe can correctly determine that its input specifies infinitely
> nested simulation.
>

IF H(P,P) doesn't return 0, then 0 might be the right answer, but H is
still wrong as it is H that needs to give the answer to be right.

olcott <NoOne@NoWhere.com> writes:

> On 11/5/2021 6:49 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> 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;
>> But P(P) halts, so H(P,P) == 0 is the wrong result.
>
> When the correct pure simulation of the actual input to the halt
> decider never halts then the halt decider is necessarily correct when
> it reports that its input never halts.

P(P) halts. H(P,P) == 0 is not the correct return for arguments that
represent a halting computation.

> Disagreeing with a logical tautology is a break from reality.

Why do you think I am disagreeing with a tautology? I am not. You are
just typing words (or more likely pasting words) that don't address the
elephant in the room. H(P,P) == 0 is not the correct return for
arguments that represent a halting computation, and P(P) is a halting
computation. But then you are now so obviously wrong, what else can you
do?

> If both P(P) halts and the input to H(P,P) never halts are established
> facts (and they are) then it must be the case that P(P) and H(P,P) are
> not computationally equivalent to each other.

The input to H(P,P), by which sloppy wording I presume you mean the
arguments to H in that call, represent a computation -- P(P). That
computation halts (according to you). If a simulation of that
computation does not halt, then the simulator has a bug in it
somewhere. Correct simulations of halting computations halt.

But that's just your attempt at distraction. The halting problem is
about what the computation represented by the arguments passed to the
decider actually does. What any correct, buggy, partial, total or magic
simulation of that computation does is not part of the problem. P(P)
halts, so H(P,P) == 0 is wrong.

Don't you wish for the heady days when you could just boast that

"Everyone has claimed that H on input pair (Ĥ, Ĥ) meeting the Linz specs
does not exist. I now have a fully encoded pair of Turing Machines H / Ĥ
proving them wrong."[1]?

Back then you refused to say which way H decided (Ĥ, Ĥ), and you
couldn't say what Ĥ(Ĥ) did because you never had it. But over time, you
let things slip out, and now we know you have an H that does not meet
Linz's spec.

[1] Message-ID: <JbydneYGrrpProjBnZ2dnUU7-X3NnZ2d@giganews.com>

--
Ben.

On 11/6/2021 2:48 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 11/5/2021 6:49 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> 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;
>>> But P(P) halts, so H(P,P) == 0 is the wrong result.
>>
>> When the correct pure simulation of the actual input to the halt
>> decider never halts then the halt decider is necessarily correct when
>> it reports that its input never halts.
>
> P(P) halts. H(P,P) == 0 is not the correct return for arguments that
> represent a halting computation.
>
>> Disagreeing with a logical tautology is a break from reality.
>
> Why do you think I am disagreeing with a tautology? I am not. You are
> just typing words (or more likely pasting words) that don't address the
> elephant in the room. H(P,P) == 0 is not the correct return for
> arguments that represent a halting computation, and P(P) is a halting
> computation. But then you are now so obviously wrong, what else can you
> do?
>
>> If both P(P) halts and the input to H(P,P) never halts are established
>> facts (and they are) then it must be the case that P(P) and H(P,P) are
>> not computationally equivalent to each other.
>
> The input to H(P,P), by which sloppy wording I presume you mean the
> arguments to H in that call, represent a computation -- P(P). That
> computation halts (according to you). If a simulation of that
> computation does not halt, then the simulator has a bug in it
> somewhere. Correct simulations of halting computations halt.
>

_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]

If you understood the x86 language you would be able to directly see
that it is an established fact that the pure simulation of the input to
H(P,P) is correctly shown by the first 14 steps of the simulation of
this input.

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)

Once you see that the above 14 steps are a correct pure simulation of
the input to H(P,P) it is much easier to see that these first seven
instructions of P continue in increasing nested simulation depth that
never ceases.

Whether or not H(P,P) ever aborts the simulation of its input H(P,P)==0
remains correct because P never reaches its final state in both cases.

--
Copyright 2021 Pete Olcott

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

On 2021-11-06 11:52, olcott wrote:

> The brand new exception to the rule that the pure simulation of a
> machine description on its input and the direct execution of this
> machine on its input ARE COMPUTATIONALLY EQUIVALENT is the case where
> the decider and its machine description input have a pathological
> relationship to each other.

And you justify this incoherent claim how exactly?

If the pure simulation isn't computationally equivalent to the direct
execution, in what possible sense is it a 'pure simulation'?

And if your 'simulating halt decider' is simulating something which is
not computationally equivalent to the computation described by its
input, then in what possible sense is it actually answering a question
about its input?

P(P) halts. A halt decider must therefore claim that it halts. If it
decides that some simulation which is not computationally equivalent to
P(P) doesn't halt then it isn't answering about its input, which means
it isn't a halt decider at all.

André

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

On 11/6/21 4:02 PM, olcott wrote:
> On 11/6/2021 2:48 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 11/5/2021 6:49 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> 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;
>>>> But P(P) halts, so H(P,P) == 0 is the wrong result.
>>>
>>> When the correct pure simulation of the actual input to the halt
>>> decider never halts then the halt decider is necessarily correct when
>>> it reports that its input never halts.
>>
>> P(P) halts.  H(P,P) == 0 is not the correct return for arguments that
>> represent a halting computation.
>>
>>> Disagreeing with a logical tautology is a break from reality.
>>
>> Why do you think I am disagreeing with a tautology?  I am not.  You are
>> just typing words (or more likely pasting words) that don't address the
>> elephant in the room.  H(P,P) == 0 is not the correct return for
>> arguments that represent a halting computation, and P(P) is a halting
>> computation.  But then you are now so obviously wrong, what else can you
>> do?
>>
>>> If both P(P) halts and the input to H(P,P) never halts are established
>>> facts (and they are) then it must be the case that P(P) and H(P,P) are
>>> not computationally equivalent to each other.
>>
>> The input to H(P,P), by which sloppy wording I presume you mean the
>> arguments to H in that call, represent a computation -- P(P).  That
>> computation halts (according to you).  If a simulation of that
>> computation does not halt, then the simulator has a bug in it
>> somewhere.  Correct simulations of halting computations halt.
>>
>
> _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]
>
> If you understood the x86 language you would be able to directly see
> that it is an established fact that the pure simulation of the input to
> H(P,P) is correctly shown by the first 14 steps of the simulation of
> this input.

Again, the trace is in ERROR. The call to 0966 MUST be followed by the
code at 0966.

Your argument that it isn't part of the C function P is irrelevant as H
is being asked to decide on the COMPUTATION, ie FULL PROGRAM that P is
in control of, and THAT does include what is at 0966.

Note, that x86 assembly code doesn't know about the source file
distinctions of what started of a P and what is other stuff that it is
using.

Would you say a function that call say sin(x) doesn't depend on the
details of what sin(x) does.

The fact that you can't figure out what to presume H returns just means
you FAIL, or need to guess and be willing to fail. It doesn't make the
wrong answer right.

FAIL

>
>  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)
>
> Once you see that the above 14 steps are a correct pure simulation of
> the input to H(P,P) it is much easier to see that these first seven
> instructions of P continue in increasing nested simulation depth that
> never ceases.
>
> Whether or not H(P,P) ever aborts the simulation of its input H(P,P)==0
> remains correct because P never reaches its final state in both cases.
>
>

WRONG. YOU FAIL.

You just seem to not understand the basics of what you are talking about.

Since when H(P,P) returns 0 (Non-Halting) that P(P) does halt and thus
also that the ACTUAL CORRECT PURE SIMULATION of that input will also
halt. The fact that H has to abort the simulation before seeing the halt
or it fails to answer does NOT say that P is non-halting.

Yes, the P based on the H that doesn't abort will be non-halting, but
that H never gives that anwwer.

If H does answer 0, then its P will always Halt (or the input when
actually simulated purely will Halt), so that H is also wrong.

You don't get credit for the aborting H getting the P built on the
non-aborting H correctly.

On 11/6/2021 3:46 PM, André G. Isaak wrote:
> On 2021-11-06 11:52, olcott wrote:
>
>> The brand new exception to the rule that the pure simulation of a
>> machine description on its input and the direct execution of this
>> machine on its input ARE COMPUTATIONALLY EQUIVALENT is the case where
>> the decider and its machine description input have a pathological
>> relationship to each other.
>
> And you justify this incoherent claim how exactly?
>

The actual pure simulation of the first 14 steps of the x86 machine
language input to H(P,P) conclusively proves beyond all possible doubt
that H(P,P)==0 is correct even of H never returns.

You won't be able to understand what I am saying until after you
comprehend this fact. Ben is hopelessly lost because he is utterly
clueless about the x86 language, perhaps you too are utterly clueless
about the x86 language.

> If the pure simulation isn't computationally equivalent to the direct
> execution, in what possible sense is it a 'pure simulation'?
>

I have told you this too many times.

When each instruction of the x86 source code is simulated in the exact
same sequence that it is specified in the source code we know that this
aspect of the simulation is perfectly correct.

We also know that when H is a pure simulator of its input that the
seventh line of the correct pure simulation execution trace shown below
would result in another identical sequence.

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)

We don't need to see the 350 pages of the simulation of H to know that
if this H does a pure simulation of its input that the above seven lines
will be repeated in the subsequent nested simulation.

> And if your 'simulating halt decider' is simulating something which is
> not computationally equivalent to the computation described by its
> input, then in what possible sense is it actually answering a question
> about its input?
>
> P(P) halts. A halt decider must therefore claim that it halts. If it
> decides that some simulation which is not computationally equivalent to
> P(P) doesn't halt then it isn't answering about its input, which means
> it isn't a halt decider at all.
>
> André
>
>

--
Copyright 2021 Pete Olcott

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

On 11/6/21 5:55 PM, olcott wrote:
> On 11/6/2021 3:46 PM, André G. Isaak wrote:
>> On 2021-11-06 11:52, olcott wrote:
>>
>>> The brand new exception to the rule that the pure simulation of a
>>> machine description on its input and the direct execution of this
>>> machine on its input ARE COMPUTATIONALLY EQUIVALENT is the case where
>>> the decider and its machine description input have a pathological
>>> relationship to each other.
>>
>> And you justify this incoherent claim how exactly?
>>
>
> The actual pure simulation of the first 14 steps of the x86 machine
> language input to H(P,P) conclusively proves beyond all possible doubt
> that H(P,P)==0 is correct even of H never returns.

No, it isn't an accurate pure simulation of the input, as a call
instruction needs to go to the address called.

If this is what x86 says, you need to get your money back, as it is
defiective.

Bad trace, bad results. An accurate trace MUST exactly copy what the
code says to do.

Call 00966 must then go to address 00966

Note also, once you apply 'equivalencies', you are no longer dealing
with pure simulations, and the transform you are trying to apply doesn't
apply here as it assumes that H NEVER aborts its simulation, but since
you show H does abort the simulation, you have just proved that your
logic is unsound.

>
> You won't be able to understand what I am saying until after you
> comprehend this fact. Ben is hopelessly lost because he is utterly
> clueless about the x86 language, perhaps you too are utterly clueless
> about the x86 language.
>
>> If the pure simulation isn't computationally equivalent to the direct
>> execution, in what possible sense is it a 'pure simulation'?
>>
>
> I have told you this too many times.
>
> When each instruction of the x86 source code is simulated in the exact
> same sequence that it is specified in the source code we know that this
> aspect of the simulation is perfectly correct.

So why doesn't the call instrction go where it is supposed to?

THAT PROVES the simulation is not accurate.

>
> We also know that when H is a pure simulator of its input that the
> seventh line of the correct pure simulation execution trace shown below
> would result in another identical sequence.

NOTE CONDITIONAL.

IF H is a pure simulator, then yes, P(P) will be non-halting, but H(P,P)
never answers so is still not a correct halt decider.

If H is NOT a pure simulator and aborts its simulation, the logic that
assumes that it is one is unsound.

FAILO.

>
>  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)
>
> We don't need to see the 350 pages of the simulation of H to know that
> if this H does a pure simulation of its input that the above seven lines
> will be repeated in the subsequent nested simulation.

No, we just need to see that H(P,P) says non-halting when P(P) is
halting to know it is wrong.

>> And if your 'simulating halt decider' is simulating something which is
>> not computationally equivalent to the computation described by its
>> input, then in what possible sense is it actually answering a question
>> about its input?
>>
>> P(P) halts. A halt decider must therefore claim that it halts. If it
>> decides that some simulation which is not computationally equivalent
>> to P(P) doesn't halt then it isn't answering about its input, which
>> means it isn't a halt decider at all.
>>
>> André
>>
>>
>
>

olcott <NoOne@NoWhere.com> writes:

> On 11/6/2021 12:36 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 11/5/2021 7:01 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 11/5/2021 6:08 AM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>> On 11/4/2021 8:16 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>> On 11/4/2021 12:21 PM, Ben Bacarisse wrote:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>>>>>>>> 2021-11-03 Halt Deciding Criteria
>>>>>>>>>>> It is impossible for any halt decider to be incorrect when the correct
>>>>>>>>>>> pure simulation of its input never halts and it reports not halting.
>>>>>>>>>>
>>>>>>>>>> Unfortunately H(P,P) does not meet the criterion for being correct about
>>>>>>>>>> the computation represented by it's arguments. H(P,P) == 0 when P(P)
>>>>>>>>>> halts is wrong:
>>>>>>>>>
>>>>>>>>> Since you can't comprehend the x86 assembly language you are out of
>>>>>>>>> your depth in this.
>>>>>>>>
>>>>>>>> You are funny! The definition of the halting problem is what it is.
>>>>>>>
>>>>>>> And you are incapable of examining this at the totally concrete level
>>>>>>> of the x86 language.
>>>>>>
>>>>>> What the correct answer is for a halting computation is in the problem
>>>>>> definition. Since you've told us that H gets the key case wrong, what
>>>>>> is the point of all your posts?
>>>>>
>>>>> _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]
>>>>>
>>>>> If the provably correct pure simulation of the input to H(P,P) by
>>>>> every possible simulating halt decider H never halts then the correct
>>>>> halt status of the input to H(P,P)==0
>>>> If P(P) halts (and it does),
>>>
>>> and the correct pure simulation of the input to H(P,P) never halts
>>> then we know that P(P) and H(P,P) are not computationally equivalent
>>> to each other and can thus have opposite values.
>> Goodness you are confused. H(P,P) and P(P) are never the same
>> computation no matter what H does. But since any correct simulation of
>> P applied to P halts (it must do since P(P) halts) your remark has
>> nothing to do with the case in hand.
>>
>>> The big difference between this proof and the prior proof form the
>>> last six months is that now we know that the pure simulation of the
>>> input to H(P,P) never halts
>> A correct simulation of P applied to P halts because P(P) halts. That's
>> why H(P,P) == 0 is wrong. I can't see what it is that's preventing you
>> from seeing this huge elephant in the room.
>>
>>> A correct pure simulation is not verified on the basis of any mere
>>> assumptions.
>> Indeed. I have to rely on what you've told me and the definition of a
>> simulation. You've told me that P(P) (the computation represented by
>> the arguments to H) halts (in fact you also showed a trace of it
>> halting). We know, therefore, from the definition of what a "correct"
>> simulation is, that a simulation of the computation represented by the
>> arguments to H will also halt.
>>
>>> As long as the first seven x86 instructions of the source code of P
>>> are executed in order and the seventh instruction causes this cycle to
>>> repeat then we know that H(P,P) performed a correct pure simulation of
>>> its input for the entire 14 steps of this simulation.
>> If your code for P(P) does not halt, or your simulation of P(P) does not
>> halt then the code is wrong, but I can't help with that because its
>> "secret" (i.e. you dare not show it).
>>
>>>> H(P,P) == 0 is wrong. Is your plan to just
>>>> keep ignoring what the halting problem is? Do you get enough joy from
>>>> pasting the same text in every reply to make t worth while?
>>>> Looking back at your old posts from Dec 2018 you seemed genuinely
>>>> thrilled to have something that everyone said as impossible. You surely
>>>> can't be thrilled about touting an H that everyone knows is trivial to
>>>> write. But if it does bring you joy, I'll play along...
>> No answer? Does this bring you joy?
>
>
> The brand new exception to the rule that the pure simulation of a
> machine description on its input and the direct execution of this
> machine on its input ARE COMPUTATIONALLY EQUIVALENT is the case where
> the decider and its machine description input have a pathological
> relationship to each other.

The halting problem is the same as it always was.

--
Ben.

olcott <NoOne@NoWhere.com> writes:

> On 11/6/2021 2:48 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 11/5/2021 6:49 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> 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;
>>>> But P(P) halts, so H(P,P) == 0 is the wrong result.
>>>
>>> When the correct pure simulation of the actual input to the halt
>>> decider never halts then the halt decider is necessarily correct when
>>> it reports that its input never halts.
>> P(P) halts. H(P,P) == 0 is not the correct return for arguments that
>> represent a halting computation.
>>
>>> Disagreeing with a logical tautology is a break from reality.
>> Why do you think I am disagreeing with a tautology? I am not. You are
>> just typing words (or more likely pasting words) that don't address the
>> elephant in the room. H(P,P) == 0 is not the correct return for
>> arguments that represent a halting computation, and P(P) is a halting
>> computation. But then you are now so obviously wrong, what else can you
>> do?
>>
>>> If both P(P) halts and the input to H(P,P) never halts are established
>>> facts (and they are) then it must be the case that P(P) and H(P,P) are
>>> not computationally equivalent to each other.
>> The input to H(P,P), by which sloppy wording I presume you mean the
>> arguments to H in that call, represent a computation -- P(P). That
>> computation halts (according to you). If a simulation of that
>> computation does not halt, then the simulator has a bug in it
>> somewhere. Correct simulations of halting computations halt.
>>
>
> _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]
>
> If you understood the x86 language you would be able to directly see
> that it is an established fact that the pure simulation of the input
> to H(P,P) is correctly shown by the first 14 steps of the simulation
> of this input.

P(P) halts. H(P,P) == 0 is the wrong result for those arguments.

> 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)
>
> Once you see that the above 14 steps are a correct pure simulation of
> the input to H(P,P) it is much easier to see that these first seven
> instructions of P continue in increasing nested simulation depth that
> never ceases.

P(P) halts, yes? H(P,P) == 0, yes? Still wrong.

> Whether or not H(P,P) ever aborts the simulation of its input
> H(P,P)==0 remains correct because P never reaches its final state in
> both cases.

H(P,P) == 0 will remain the wrong answer no matter much you waffle or
what silly traces you post.

--
Ben.

On 11/6/2021 9:08 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 11/6/2021 2:48 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 11/5/2021 6:49 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> 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;
>>>>> But P(P) halts, so H(P,P) == 0 is the wrong result.
>>>>
>>>> When the correct pure simulation of the actual input to the halt
>>>> decider never halts then the halt decider is necessarily correct when
>>>> it reports that its input never halts.
>>> P(P) halts. H(P,P) == 0 is not the correct return for arguments that
>>> represent a halting computation.
>>>
>>>> Disagreeing with a logical tautology is a break from reality.
>>> Why do you think I am disagreeing with a tautology? I am not. You are
>>> just typing words (or more likely pasting words) that don't address the
>>> elephant in the room. H(P,P) == 0 is not the correct return for
>>> arguments that represent a halting computation, and P(P) is a halting
>>> computation. But then you are now so obviously wrong, what else can you
>>> do?
>>>
>>>> If both P(P) halts and the input to H(P,P) never halts are established
>>>> facts (and they are) then it must be the case that P(P) and H(P,P) are
>>>> not computationally equivalent to each other.
>>> The input to H(P,P), by which sloppy wording I presume you mean the
>>> arguments to H in that call, represent a computation -- P(P). That
>>> computation halts (according to you). If a simulation of that
>>> computation does not halt, then the simulator has a bug in it
>>> somewhere. Correct simulations of halting computations halt.
>>>
>>
>> _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]
>>
>> If you understood the x86 language you would be able to directly see
>> that it is an established fact that the pure simulation of the input
>> to H(P,P) is correctly shown by the first 14 steps of the simulation
>> of this input.
>
> P(P) halts. H(P,P) == 0 is the wrong result for those arguments.
>
>> 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)
>>
>> Once you see that the above 14 steps are a correct pure simulation of
>> the input to H(P,P) it is much easier to see that these first seven
>> instructions of P continue in increasing nested simulation depth that
>> never ceases.
>
> P(P) halts, yes? H(P,P) == 0, yes? Still wrong.
>

If you had the mandatory prerequisite knowledge of the x86 language
(which apparently no one here does) then you would see that there is no
possible simulating halt decider H such that the input to H(P,P) ever
reaches its final state.

>> Whether or not H(P,P) ever aborts the simulation of its input
>> H(P,P)==0 remains correct because P never reaches its final state in
>> both cases.
>
> H(P,P) == 0 will remain the wrong answer no matter much you waffle or
> what silly traces you post.
>

--
Copyright 2021 Pete Olcott

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

On 11/7/21 12:05 AM, olcott wrote:
> On 11/6/2021 9:08 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 11/6/2021 2:48 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 11/5/2021 6:49 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> 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;
>>>>>> But P(P) halts, so H(P,P) == 0 is the wrong result.
>>>>>
>>>>> When the correct pure simulation of the actual input to the halt
>>>>> decider never halts then the halt decider is necessarily correct when
>>>>> it reports that its input never halts.
>>>> P(P) halts.  H(P,P) == 0 is not the correct return for arguments that
>>>> represent a halting computation.
>>>>
>>>>> Disagreeing with a logical tautology is a break from reality.
>>>> Why do you think I am disagreeing with a tautology?  I am not.  You are
>>>> just typing words (or more likely pasting words) that don't address the
>>>> elephant in the room.  H(P,P) == 0 is not the correct return for
>>>> arguments that represent a halting computation, and P(P) is a halting
>>>> computation.  But then you are now so obviously wrong, what else can
>>>> you
>>>> do?
>>>>
>>>>> If both P(P) halts and the input to H(P,P) never halts are established
>>>>> facts (and they are) then it must be the case that P(P) and H(P,P) are
>>>>> not computationally equivalent to each other.
>>>> The input to H(P,P), by which sloppy wording I presume you mean the
>>>> arguments to H in that call, represent a computation -- P(P).  That
>>>> computation halts (according to you).  If a simulation of that
>>>> computation does not halt, then the simulator has a bug in it
>>>> somewhere.  Correct simulations of halting computations halt.
>>>>
>>>
>>> _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]
>>>
>>> If you understood the x86 language you would be able to directly see
>>> that it is an established fact that the pure simulation of the input
>>> to H(P,P) is correctly shown by the first 14 steps of the simulation
>>> of this input.
>>
>> P(P) halts.  H(P,P) == 0 is the wrong result for those arguments.
>>
>>>   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)
>>>
>>> Once you see that the above 14 steps are a correct pure simulation of
>>> the input to H(P,P) it is much easier to see that these first seven
>>> instructions of P continue in increasing nested simulation depth that
>>> never ceases.
>>
>> P(P) halts, yes?  H(P,P) == 0, yes?  Still wrong.
>>
>
> If you had the mandatory prerequisite knowledge of the x86 language
> (which apparently no one here does) then you would see that there is no
> possible simulating halt decider H such that the input to H(P,P) ever
> reaches its final state.
>

It seems that even YOU don't have the required knowledge, since you
don't understand what a call instruction does.

But you do have a point, There is No possible simulating Halt Decider
that can, for P built by Linz from it, simulate the input from the call
H(P,P) to the final halting state.

Your problem is that this doesn't say that P(P) is non-halting or that
saying non-halting is right.

Yes, if H actually is just a pure simulator, and thus never aborted the
input, then the P based on that H is non-halting, but this H doesn't
meet the requirements of a decider as it doesn't give an answer.

If H does at some point abort its simulation, and return the non-halting
answer, then it turns out that all these Ps based on them will be
halting, teh fact that H didn't reach that halting state is that H
aborts its simulation 'too soon', as H isn't a pure simulator in this
case, so not seeing that halting state doesn't mean anyting.

You don't seem to understand this basic fact. Knowledge of x86 doesn't
really matter and is just your smoke screen, because it doesn't matter
how H makes its incorrect decision, from macro level behavior, we can
see it is wrong.

olcott <NoOne@NoWhere.com> writes:

> On 11/6/2021 9:08 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 11/6/2021 2:48 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 11/5/2021 6:49 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> 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;
>>>>>> But P(P) halts, so H(P,P) == 0 is the wrong result.
>>>>>
>>>>> When the correct pure simulation of the actual input to the halt
>>>>> decider never halts then the halt decider is necessarily correct when
>>>>> it reports that its input never halts.
>>>> P(P) halts. H(P,P) == 0 is not the correct return for arguments that
>>>> represent a halting computation.
>>>>
>>>>> Disagreeing with a logical tautology is a break from reality.
>>>> Why do you think I am disagreeing with a tautology? I am not. You are
>>>> just typing words (or more likely pasting words) that don't address the
>>>> elephant in the room. H(P,P) == 0 is not the correct return for
>>>> arguments that represent a halting computation, and P(P) is a halting
>>>> computation. But then you are now so obviously wrong, what else can you
>>>> do?
>>>>
>>>>> If both P(P) halts and the input to H(P,P) never halts are established
>>>>> facts (and they are) then it must be the case that P(P) and H(P,P) are
>>>>> not computationally equivalent to each other.
>>>> The input to H(P,P), by which sloppy wording I presume you mean the
>>>> arguments to H in that call, represent a computation -- P(P). That
>>>> computation halts (according to you). If a simulation of that
>>>> computation does not halt, then the simulator has a bug in it
>>>> somewhere. Correct simulations of halting computations halt.
>>>>
>>>
>>> _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]
>>>
>>> If you understood the x86 language you would be able to directly see
>>> that it is an established fact that the pure simulation of the input
>>> to H(P,P) is correctly shown by the first 14 steps of the simulation
>>> of this input.
>> P(P) halts. H(P,P) == 0 is the wrong result for those arguments.
>>
>>> 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)
>>>
>>> Once you see that the above 14 steps are a correct pure simulation of
>>> the input to H(P,P) it is much easier to see that these first seven
>>> instructions of P continue in increasing nested simulation depth that
>>> never ceases.
>>
>> P(P) halts, yes? H(P,P) == 0, yes? Still wrong.
>
> If you had the mandatory prerequisite knowledge of the x86 language
> (which apparently no one here does) then you would see that there is
> no possible simulating halt decider H such that the input to H(P,P)
> ever reaches its final state.

There are no halt deciders, as you know, so no simulating halt deciders
either. Anything can be said to be true of the members of an empty set.

A while back you claimed to have an H that was not a halt decider
because H(P,P) == 0 despite P(P) halting. At least you have switched to
talking about halt deciders rather than code that is no a halt decider,
but I do with you'd use different names for clarity.

--
Ben.