On 6/29/2022 11:36 AM, Paul N wrote:
> On Tuesday, June 28, 2022 at 10:08:36 PM UTC+1, olcott wrote:
>
> In maths, sometimes it is possible to prove that there is no number satisfying certain conditions, by showing that it must satisfy conditions which are contradictory. For instance, if we can show that a number X must be greater than 4, and also show that it must be less than 2, this is normally regarded as a proof that no such X exists. You would accept this, would you? You wouldn't start arguing that therefore there must be numbers more than 4 but less then 2 whose existence has been overlooked until now?
>
> It similar here. The requirements of a halt detector are such that we can prove that no such function exists. You seem to think that it ought to be possible, and so you start trying to bend what the requirements require. For instance, you accept that:
Thanks for coming back these guys here don't seem to understand software
engineering at all.
THIS IS NECESSARILY TRUE THUS IMPOSSIBLY FALSE
Every simulating halt decider that correctly simulates its input until
it correctly determines that this simulated input would never reach its
final state correctly determines the halt status of this input.
>
>> (1) A halt decider must compute the mapping from its inputs to an accept
>> or reject state on the basis of the actual behavior that is actually
>> specified by these inputs.
>
> But you also say that H(P, P) is zero, and that P(P) terminates. So H gets it wrong in this case.
>
> So how to resolve this? One way you do this is by trying to change what H is required to do. You have said:
THIS IS NECESSARILY TRUE THUS IMPOSSIBLY FALSE
A halt decider must compute the mapping from its inputs to an accept or
reject state on the basis of the actual behavior that is actually
specified by these inputs.
P(P) is provably not the actual behavior of the actual input to H(P,P).
Instead of simply dismissing this proof because you don't understand it
simply assume that it is true and see where this leads.
>
>>> The complete and correct x86 emulation of the input to H(P,P) by H never reaches the "ret" instruction of P.
>
> It is not clear what this means, but since you have also said that P(P) terminates, and that the "correct emulation" doesn't, this is not actually a correct emulation by the usual definitions of "correct" and "emulation". If it's not an accurate emulation, why does it matter what it does?
>
> You also go on to say:
>
>> (2) P(P) is provably not the actual behavior of the actual input to H(P,P).
>
> In other words, you admit that H gets the prediction of P(P) wrong. You're just trying to blame something or someone else for it, instead of admitting that you don't have (and can't have) an accurate H.
>
Whenever anyone is verifying that there are white cats in their living
room it is flat out incorrect to verify these white cats by looking for
black dogs in their kitchen.
White cats in living room = The actual behavior of the correct and
complete x86 emulation of the input to H(P,P) by H.
Black dogs in kitchen = The behavior of P(P).

> Going back to maths again, there is a proof that even if you make an infinitely long list of real numbers, there will be some real number that does not appear anywhere on that list. You simply choose a number whose first digit after the decimal point is different from the corresponding digit of the first number, whose second digit after the point is different from that of the second number, etc, with a check you aren't dealing with 0s and 9s (0.9999... = 1.0000...). There once was someone who thought this proof was invalid. He thought you could work out the missing number and then just sort of slot it into the list somewhere, refuting the proof that it was left out. He didn't seem to realise that you can perform the same trick to the new list to find a new number which is left out. You seem to be doing much the same thing - define an H which will run forever in some circumstances, and then tweak it to not run forever, while failing to realise that you have changed its behaviour.
>
>> If (1) and (2) are true then I am necessarily correct.
>
> No, if (2) is true you are necessarily incorrect.

--
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 6/29/2022 10:36 AM, Paul N wrote:
> On Tuesday, June 28, 2022 at 10:08:36 PM UTC+1, olcott wrote:
>
> In maths, sometimes it is possible to prove that there is no number satisfying certain conditions, by showing that it must satisfy conditions which are contradictory. For instance, if we can show that a number X must be greater than 4, and also show that it must be less than 2, this is normally regarded as a proof that no such X exists. You would accept this, would you? You wouldn't start arguing that therefore there must be numbers more than 4 but less then 2 whose existence has been overlooked until now?
>
> It similar here. The requirements of a halt detector are such that we can prove that no such function exists. You seem to think that it ought to be possible, and so you start trying to bend what the requirements require. For instance, you accept that:
>
>> (1) A halt decider must compute the mapping from its inputs to an accept
>> or reject state on the basis of the actual behavior that is actually
>> specified by these inputs.
>
> But you also say that H(P, P) is zero, and that P(P) terminates. So H gets it wrong in this case.
>
> So how to resolve this? One way you do this is by trying to change what H is required to do. You have said:
>
>>> The complete and correct x86 emulation of the input to H(P,P) by H never reaches the "ret" instruction of P.
>
> It is not clear what this means, but since you have also said that P(P) terminates, and that the "correct emulation" doesn't, this is not actually a correct emulation by the usual definitions of "correct" and "emulation". If it's not an accurate emulation, why does it matter what it does?
>
> You also go on to say:
>
>> (2) P(P) is provably not the actual behavior of the actual input to H(P,P).
>
> In other words, you admit that H gets the prediction of P(P) wrong. You're just trying to blame something or someone else for it, instead of admitting that you don't have (and can't have) an accurate H.
>
> Going back to maths again, there is a proof that even if you make an infinitely long list of real numbers, there will be some real number that does not appear anywhere on that list. You simply choose a number whose first digit after the decimal point is different from the corresponding digit of the first number, whose second digit after the point is different from that of the second number, etc, with a check you aren't dealing with 0s and 9s (0.9999... = 1.0000...). There once was someone who thought this proof was invalid. He thought you could work out the missing number and then just sort of slot it into the list somewhere, refuting the proof that it was left out. He didn't seem to realise that you can perform the same trick to the new list to find a new number which is left out. You seem to be doing much the same thing - define an H which will run forever in some circumstances, and then tweak it to not run forever, while failing to realise that you have changed its behaviour.
>
>> If (1) and (2) are true then I am necessarily correct.
>
> No, if (2) is true you are necessarily incorrect.
This above is a very good summary that should inform us all of the
actual state of affairs with PO's efforts. Unfortunately the "all" in
the prior dose not include him. The problem is two-fold: a learning
disability and personality disorders. As to the first - he is not
competent to read or even reread and absorb material because of an
attention deficit disorder. This is a likely reason that he was not able
to hold a job and lived with his mother until recently.
As to the second issue - He see to have an underlying low opinion of
self and has learned to bluff. In fact he sometimes thinks he was put on
earth to do something big. For decades he has gone around in circles
"looking for a new insight in a big problem". If he could concentrate
better (first problem) he would have spent those decades doing real
research and development and maybe even published a minor article. That
would be a real accomplishment but he's not built for it.
He, instead, has turned into a successful troll and that bolsters his
ego: "Look at all of those supposedly sharp people I can lead around in
circles by their noses!" He would like to make sharp and accurate
rebuttals but he usually can't so he flames instead and relishes the
long threads that develop with him in charge.
He takes glee in thread length and contents are not particularly
important. There are others that participate here that have decided to
play sheriff - "I wont let him get away with anything!" I think there
might even be a side race to see who can respond to PO most accurately
and the most times. This group (Damon, Fibble, Bush, and a few others)
is as misguided as PO though much more knowledgeable: they will not
change or enlighten him. In fact, since no progress is made, they resort
to the same type of repetition that appears in PO's offerings.
In other words, the contents in this newsgroup and its threads are
frozen in time. I will give the only sane advise that I know if you are
to continue here: Return to a warm spot once in a while.
--
Jeff Barnett

Dennis Bush <dbush.mobile@gmail.com> writes:

<cut>

Was all of the 38 nested levels of quotation, 378 lines in all, really
needed to make your point?

Such posts become virtually unreadable in some newsreaders. I like to
keep up with the state of the lunacy (not yours, of course) but it's not
worth the time when it's like wading through molasses!

--
Ben.

On 6/29/2022 2:29 PM, Jeff Barnett wrote:
> On 6/29/2022 10:36 AM, Paul N wrote:
>> On Tuesday, June 28, 2022 at 10:08:36 PM UTC+1, olcott wrote:
>>
>> In maths, sometimes it is possible to prove that there is no number
>> satisfying certain conditions, by showing that it must satisfy
>> conditions which are contradictory. For instance, if we can show that
>> a number X must be greater than 4, and also show that it must be less
>> than 2, this is normally regarded as a proof that no such X exists.
>> You would accept this, would you? You wouldn't start arguing that
>> therefore there must be numbers more than 4 but less then 2 whose
>> existence has been overlooked until now?
>>
>> It similar here. The requirements of a halt detector are such that we
>> can prove that no such function exists. You seem to think that it
>> ought to be possible, and so you start trying to bend what the
>> requirements require. For instance, you accept that:
>>
>>> (1) A halt decider must compute the mapping from its inputs to an accept
>>> or reject state on the basis of the actual behavior that is actually
>>> specified by these inputs.
>>
>> But you also say that H(P, P) is zero, and that P(P) terminates. So H
>> gets it wrong in this case.
>>
>> So how to resolve this? One way you do this is by trying to change
>> what H is required to do. You have said:
>>
>>>> The complete and correct x86 emulation of the input to H(P,P) by H
>>>> never reaches the "ret" instruction of P.
>>
>> It is not clear what this means, but since you have also said that
>> P(P) terminates, and that the "correct emulation" doesn't, this is not
>> actually a correct emulation by the usual definitions of "correct" and
>> "emulation". If it's not an accurate emulation, why does it matter
>> what it does?
>>
>> You also go on to say:
>>
>>> (2) P(P) is provably not the actual behavior of the actual input to
>>> H(P,P).
>>
>> In other words, you admit that H gets the prediction of P(P) wrong.
>> You're just trying to blame something or someone else for it, instead
>> of admitting that you don't have (and can't have) an accurate H.
>>
>> Going back to maths again, there is a proof that even if you make an
>> infinitely long list of real numbers, there will be some real number
>> that does not appear anywhere on that list. You simply choose a number
>> whose first digit after the decimal point is different from the
>> corresponding digit of the first number, whose second digit after the
>> point is different from that of the second number, etc, with a check
>> you aren't dealing with 0s and 9s (0.9999... = 1.0000...). There once
>> was someone who thought this proof was invalid. He thought you could
>> work out the missing number and then just sort of slot it into the
>> list somewhere, refuting the proof that it was left out. He didn't
>> seem to realise that you can perform the same trick to the new list to
>> find a new number which is left out. You seem to be doing much the
>> same thing - define an H which will run forever in some circumstances,
>> and then tweak it to not run forever, while failing to realise that
>> you have changed its behaviour.
>>
>>> If (1) and (2) are true then I am necessarily correct.
>>
>> No, if (2) is true you are necessarily incorrect.
>
> This above is a very good summary that should inform us all of the
> actual state of affairs with PO's efforts. Unfortunately the "all" in
> the prior dose not include him. The problem is two-fold: a learning
> disability and personality disorders. As to the first - he is not
> competent to read or even reread and absorb material because of an
> attention deficit disorder. This is a likely reason that he was not able
> to hold a job and lived with his mother until recently.
>
> As to the second issue - He see to have an underlying low opinion of
> self and has learned to bluff. In fact he sometimes thinks he was put on
> earth to do something big. For decades he has gone around in circles
> "looking for a new insight in a big problem". If he could concentrate
> better (first problem) he would have spent those decades doing real
> research and development and maybe even published a minor article. That
> would be a real accomplishment but he's not built for it.
>
> He, instead, has turned into a successful troll and that bolsters his
> ego: "Look at all of those supposedly sharp people I can lead around in
> circles by their noses!" He would like to make sharp and accurate
> rebuttals but he usually can't so he flames instead and relishes the
> long threads that develop with him in charge.
>
> He takes glee in thread length and contents are not particularly
> important. There are others that participate here that have decided to
> play sheriff - "I wont let him get away with anything!" I think there
> might even be a side race to see who can respond to PO most accurately
> and the most times. This group (Damon, Fibble, Bush, and a few others)
> is as misguided as PO though much more knowledgeable: they will not
> change or enlighten him. In fact, since no progress is made, they resort
> to the same type of repetition that appears in PO's offerings.
>
> In other words, the contents in this newsgroup and its threads are
> frozen in time. I will give the only sane advise that I know if you are
> to continue here: Return to a warm spot once in a while.

In other words you resort to ad hominem because you are insufficiently
technically competent to to correctly evaluate the following according
to the semantics of the x86 language:

void P(u32 x)
{ if (H(x, x))
HERE: goto HERE;
return;
}

int main()
{ P(P);
}

_P()
[000011f0](01) 55 push ebp
[000011f1](02) 8bec mov ebp,esp
[000011f3](03) 8b4508 mov eax,[ebp+08]
[000011f6](01) 50 push eax
[000011f7](03) 8b4d08 mov ecx,[ebp+08]
[000011fa](01) 51 push ecx
[000011fb](05) e820feffff call 00001020
[00001200](03) 83c408 add esp,+08
[00001203](02) 85c0 test eax,eax
[00001205](02) 7402 jz 00001209
[00001207](02) ebfe jmp 00001207
[00001209](01) 5d pop ebp
[0000120a](01) c3 ret
Size in bytes:(0027) [0000120a]

_main()
[00001210](01) 55 push ebp
[00001211](02) 8bec mov ebp,esp
[00001213](05) 68f0110000 push 000011f0
[00001218](05) e8d3ffffff call 000011f0
[0000121d](03) 83c404 add esp,+04
[00001220](02) 33c0 xor eax,eax
[00001222](01) 5d pop ebp
[00001223](01) c3 ret
Size in bytes:(0020) [00001223]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[00001210][00101fba][00000000] 55 push ebp
[00001211][00101fba][00000000] 8bec mov ebp,esp
[00001213][00101fb6][000011f0] 68f0110000 push 000011f0 // push P
[00001218][00101fb2][0000121d] e8d3ffffff call 000011f0 // call P
[000011f0][00101fae][00101fba] 55 push ebp // enter executed P
[000011f1][00101fae][00101fba] 8bec mov ebp,esp
[000011f3][00101fae][00101fba] 8b4508 mov eax,[ebp+08]
[000011f6][00101faa][000011f0] 50 push eax // push P
[000011f7][00101faa][000011f0] 8b4d08 mov ecx,[ebp+08]
[000011fa][00101fa6][000011f0] 51 push ecx // push P
[000011fb][00101fa2][00001200] e820feffff call 00001020 // call H

Begin Simulation Execution Trace Stored at:21206e
Address_of_H:1020
[000011f0][0021205a][0021205e] 55 push ebp // enter emulated P
[000011f1][0021205a][0021205e] 8bec mov ebp,esp
[000011f3][0021205a][0021205e] 8b4508 mov eax,[ebp+08]
[000011f6][00212056][000011f0] 50 push eax // push P
[000011f7][00212056][000011f0] 8b4d08 mov ecx,[ebp+08]
[000011fa][00212052][000011f0] 51 push ecx // push P
[000011fb][0021204e][00001200] e820feffff call 00001020 // call emulated H
Infinitely Recursive Simulation Detected Simulation Stopped

H knows its own machine address and on this basis it can easily
examine its stored execution_trace of P (see above) to determine:
(a) P is calling H with the same arguments that H was called with.
(b) No instructions in P could possibly escape this otherwise infinitely
recursive emulation.
(c) H aborts its emulation of P before its call to H is emulated.

[00001200][00101fae][00101fba] 83c408 add esp,+08 // return to
executed P
[00001203][00101fae][00101fba] 85c0 test eax,eax
[00001205][00101fae][00101fba] 7402 jz 00001209
[00001209][00101fb2][0000121d] 5d pop ebp
[0000120a][00101fb6][000011f0] c3 ret // return from
executed P
[0000121d][00101fba][00000000] 83c404 add esp,+04
[00001220][00101fba][00000000] 33c0 xor eax,eax
[00001222][00101fbe][00100000] 5d pop ebp
[00001223][00101fc2][00000000] c3 ret // ret from main
Number of Instructions Executed(878) / 67 = 13 pages

Paul N <gw7rib@aol.com> writes:

> On Tuesday, June 28, 2022 at 10:08:36 PM UTC+1, olcott wrote:
>
> In maths, sometimes it is possible to prove that there is no number
> satisfying certain conditions, by showing that it must satisfy
> conditions which are contradictory. For instance, if we can show that
> a number X must be greater than 4, and also show that it must be less
> than 2, this is normally regarded as a proof that no such X
> exists. You would accept this, would you? You wouldn't start arguing
> that therefore there must be numbers more than 4 but less then 2 whose
> existence has been overlooked until now?
>
> It similar here. The requirements of a halt detector are such that we
> can prove that no such function exists. You seem to think that it
> ought to be possible, and so you start trying to bend what the
> requirements require. For instance, you accept that:
>
>> (1) A halt decider must compute the mapping from its inputs to an accept
>> or reject state on the basis of the actual behavior that is actually
>> specified by these inputs.
>
> But you also say that H(P, P) is zero, and that P(P) terminates. So H
> gets it wrong in this case.

You keep missing the magic words! The behaviour "actually specified by
these inputs" is not the actual behaviour of P(P). Even since it's been
clear that H(P,P) == 0 and that P(P) he's been searching for some form
of words that make H look less obviously wrong.

> You also go on to say:
>
>> (2) P(P) is provably not the actual behavior of the actual input to H(P,P).
>
> In other words, you admit that H gets the prediction of P(P) wrong.

Yes -- for the rest of the world -- but the word game is to find a way
to keep the discussion going; some mantra that is vague enough about
what H is really doing that it will enable a few thousand more posts.

This is the main reason he abandoned talking about TMs (not really
understanding them was secondary). You just can't get away with this
using TMs without making it clear that you are no longer talking about
the halting theorem proof. He did try for a while. He would write
configuration sequences without any attached conditions, and when that
got too embarrassing, he simply had to re-write the conditions. There
was a few months of "they are same but different" but it just didn't
wash and was not sustainable.

--
Ben.

On 6/29/2022 9:02 AM, Dennis Bush wrote:
> On Wednesday, June 29, 2022 at 9:44:39 AM UTC-4, olcott wrote:
>> On 6/28/2022 8:44 PM, Dennis Bush wrote:
>>> On Tuesday, June 28, 2022 at 8:08:10 PM UTC-4, olcott wrote:
>>>> On 6/28/2022 4:13 PM, Dennis Bush wrote:
>>>>> On Tuesday, June 28, 2022 at 5:01:29 PM UTC-4, olcott wrote:
>>>>>> On 6/28/2022 3:34 PM, Dennis Bush wrote:
>>>>>>> On Tuesday, June 28, 2022 at 4:30:29 PM UTC-4, olcott wrote:
>>>>>>>> On 6/28/2022 3:27 PM, Dennis Bush wrote:
>>>>>>>>> On Tuesday, June 28, 2022 at 4:22:23 PM UTC-4, olcott wrote:
>>>>>>>>>> On 6/28/2022 3:02 PM, Dennis Bush wrote:
>>>>>>>>>>> On Tuesday, June 28, 2022 at 3:44:30 PM UTC-4, olcott wrote:
>>>>>>>>>>>> On 6/28/2022 10:03 AM, Dennis Bush wrote:
>>>>>>>>>>>>> On Tuesday, June 28, 2022 at 10:47:01 AM UTC-4, olcott wrote:
>>>>>>>>>>>>>> On 6/28/2022 9:22 AM, Dennis Bush wrote:
>>>>>>>>>>>>>>> On Tuesday, June 28, 2022 at 10:14:33 AM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>> On 6/27/2022 5:03 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 5:58:55 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>> On 6/27/2022 4:46 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 5:38:02 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 6/27/2022 4:14 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 5:11:30 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>> On 6/27/2022 4:02 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 4:52:17 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 6/27/2022 2:45 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 2:13:44 PM UTC-4, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 2:11:45 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/27/2022 1:03 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 1:20:39 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/27/2022 12:03 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 9:28:22 AM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/27/2022 7:58 AM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 8:50:05 AM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/27/2022 7:40 AM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 8:34:22 AM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/27/2022 7:26 AM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 8:14:31 AM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/27/2022 6:57 AM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 7:11:21 AM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> *This is the outline of the complete refutation*
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> *of the only rebuttal that anyone has left*
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (a) The complete and correct x86 emulation of the input to H(P,P) by H
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> never reaches the "ret" instruction of P.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It is known that H aborts its simulation and returns 0. That means that H *by definition* does not perform a complete and correct emulation. And since H (if it was constructed correctly) is a pure function of its inputs, it will ALWAYS return the same return for a given input.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> To state that H aborts *and* does a complete and correct simulation is simply nonsense.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> What *does* perform a complete and correct emulation of the input to H(P,P) is UTM(P,P) which halts, therefore H(P,P)==0 is wrong.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (b) The direct execution of P(P) does reach its "ret" instruction.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The above two are proven to be verified facts entirely on the basis of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the semantics of the x86 language.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> A nonsense statement can't be a "fact", verified or otherwise.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> A halt decider must compute the mapping from its inputs to an accept or
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reject state on the basis of the actual behavior that is actually
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> specified by these inputs.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Which for H(P,P) is BY DEFINITION is the behavior of P(P). The halting problem says that H MUST implement the following mapping (i.e. the halting function):
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H(x,y)==1 if and only if x(y) halts, and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H(x,y)==0 if and only if x(y) does not halt.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H does not perform this mapping.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> P(P) is provably not the actual behavior of the actual input.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It is BY DEFINITION. So if H comes up with something different that means it did something wrong, specifically it aborted a halting computation too soon.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> void P(u32 x)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> if (H(x, x))
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> P(P);
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> _P()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f0](01) 55 push ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f1](02) 8bec mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f3](03) 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f6](01) 50 push eax
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f7](03) 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011fa](01) 51 push ecx
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011fb](05) e820feffff call 00001020
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001200](03) 83c408 add esp,+08
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001203](02) 85c0 test eax,eax
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001205](02) 7402 jz 00001209
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001207](02) ebfe jmp 00001207
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001209](01) 5d pop ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [0000120a](01) c3 ret
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Size in bytes:(0027) [0000120a]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> _main()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001210](01) 55 push ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001211](02) 8bec mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001213](05) 68f0110000 push 000011f0
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001218](05) e8d3ffffff call 000011f0
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [0000121d](03) 83c404 add esp,+04
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001220](02) 33c0 xor eax,eax
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001222](01) 5d pop ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001223](01) c3 ret
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Size in bytes:(0020) [00001223]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> machine stack stack machine assembly
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> address address data code language
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ======== ======== ======== ========= =============
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001210][00101fba][00000000] 55 push ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001211][00101fba][00000000] 8bec mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001213][00101fb6][000011f0] 68f0110000 push 000011f0 // push P
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001218][00101fb2][0000121d] e8d3ffffff call 000011f0 // call P
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f0][00101fae][00101fba] 55 push ebp // enter executed P
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f1][00101fae][00101fba] 8bec mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f3][00101fae][00101fba] 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f6][00101faa][000011f0] 50 push eax // push P
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f7][00101faa][000011f0] 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011fa][00101fa6][000011f0] 51 push ecx // push P
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011fb][00101fa2][00001200] e820feffff call 00001020 // call H
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Begin Simulation Execution Trace Stored at:21206e
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Address_of_H:1020
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f0][0021205a][0021205e] 55 push ebp // enter emulated P
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f1][0021205a][0021205e] 8bec mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f3][0021205a][0021205e] 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f6][00212056][000011f0] 50 push eax // push P
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f7][00212056][000011f0] 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011fa][00212052][000011f0] 51 push ecx // push P
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011fb][0021204e][00001200] e820feffff call 00001020 // call emulated H
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Infinitely Recursive Simulation Detected Simulation Stopped
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H knows its own machine address and on this basis it can easily
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> examine its stored execution_trace of P (see above) to determine:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (a) P is calling H with the same arguments that H was called with.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (b) No instructions in P could possibly escape this otherwise infinitely
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> recursive emulation.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> FALSE. P contains these instructions:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> if (Decide_Halting(&execution_trace, &decoded, code_end, &master_state,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> &slave_state, &slave_stack, Address_of_H, P, I))
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> goto END_OF_CODE;
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> return 0; // Does not halt
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> END_OF_CODE:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> return 1; // Input has normally terminated
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> That *can* and *do* prevent infinite recursive emulation in a *correct* and *complete* emulation
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (c) H aborts its emulation of P before its call to H is emulated.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> And in doing so it fails to see that the call to H, since H is a computation, will aborts *its* simulation of P and return 0 to the outer P being emulated, which would cause it to halt, making H(P,P)==0 wrong.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001200][00101fae][00101fba] 83c408 add esp,+08 // return to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> executed P
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001203][00101fae][00101fba] 85c0 test eax,eax
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001205][00101fae][00101fba] 7402 jz 00001209
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001209][00101fb2][0000121d] 5d pop ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [0000120a][00101fb6][000011f0] c3 ret // return from
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> executed P
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [0000121d][00101fba][00000000] 83c404 add esp,+04
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001220][00101fba][00000000] 33c0 xor eax,eax
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001222][00101fbe][00100000] 5d pop ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001223][00101fc2][00000000] c3 ret // ret from main
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Number of Instructions Executed(878) / 67 = 13 pages
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I've stated in detail why you're wrong. Now you need to explain in detail why I'm wrong.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Failure to do so, which includes simply restating your original point, will be taken as admission that what I've stated is correct.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H correctly predicts that its complete and correct x86 emulation of its
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> input never reaches the the "ret" instruction of P.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Repeating your original point.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> This is the actual behavior of the input to H(P,P).
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> P(P) is not the actual behavior of the input to H(P,P).
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Again, repeating your original point.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Never reaching the "ret" instruction means that P does not halt.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> A halt decider must compute the mapping from its inputs to an accept or
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reject state on the basis of the actual behavior that is actually
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> specified by these inputs.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Therefore H(P,P)==0 is correct.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> And again, repeating your original point.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> So no explanation as to why I'm wrong, just a repetition of your original points.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> That means you accept that what I've said is true, and that H(P,P)==0 is wrong.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You rebuttal is based on rejecting the verified fact that a simulating
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> halt decider correctly predicts that its correctly simulated input will
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> never reach the final state "ret" instruction of this input.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> FALSE. The correctly simulated input to H(P,P) is UTM(P,P) which halts, therefore H(P,P)==0 is wrong.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> First of all I am not talking about UTM's.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I am talking about x86 emulation.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Try to encode what you mean, here is my guess:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> void P(u32 x)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> if (emulate_x86(x, x))
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> P is a computation and therefore it can't be changed, nor can anything that it calls. I mean UTM(P,P). The simplest way to implement this is:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> void UTM(u32 x, u32 y)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> x(y)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H cannot by definition perform a correct and complete emulation if it aborts, so the input must be passed to something that does, i.e. a UTM, for the source of truth.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> A simulating halt decider correctly simulates its input until it
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> correctly determines that this simulated input would never reach its
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> final state.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> But H isn't such a decider, because the simulated input does reach a final state when correctly simulated, i.e. by UTM(P,P), therefore H(P,P)==0 is wrong.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Every simulating decider that correctly simulates its input until it
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> correctly determines that this simulated input would never reach its
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> final state correctly determines the halt status of this input.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> And H isn't such a decider, because it does not correctly determine that the input to H(P,P) would never halt as demonstrated by UTM(P,P) halting.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> The specification for H:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> H(x,y)==0 if and only if x(y) does not halt, and
>>>>>>>>>>>>>>>>>>>>>>>>>>>> H(x,y)==1 if and only if x(y) halts.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> H does not meet the specification.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> The spec is provably incorrect in this case:
>>>>>>>>>>>>>>>>>>>>>>>>>> A spec can't be incorrect. It just is. If it can't be satisfied, then that validates the halting problem proofs that say it can't be satisfied.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> No response to this I see. So you agree that your H does not meet the above spec that the halting problem requires?
>>>>>>>>>>>>>>>>>>>>>>>> You are just playing word games so I will use a different word:
>>>>>>>>>>>>>>>>>>>>>>>> "criterion measure".
>>>>>>>>>>>>>>>>>>>>>>>> A halt decider must compute the mapping from its inputs to an accept or
>>>>>>>>>>>>>>>>>>>>>>>> reject state on the basis of the actual behavior that is actually
>>>>>>>>>>>>>>>>>>>>>>>> specified by these inputs.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> As per this specification:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> H(x,y)==0 if and only if x(y) does not halt, and
>>>>>>>>>>>>>>>>>>>>>>> H(x,y)==1 if and only if x(y) halts
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Which means the actual behavior of the actual input to H(P,P) is defined to be the behavior of P(P).
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Remember, the halting problem is ultimately about algorithms, not some simulator's simulation of it.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> This also means that if the result of H(P,P) doesn't match the behavior of P(P) then H is wrong by definition.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> P(P) is provably not the actual behavior of the actual input,
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> If you mean that H(P,P) can't simulate its input to a final state, then any simulator that aborts its input for any reason is necessarily correct, which is clearly nonsense.
>>>>>>>>>>>>>>>>>>>>>> The formal mathematical semantics of the x86 language conclusively
>>>>>>>>>>>>>>>>>>>>>> proves that P(P) is not the actual behavior of the actual input to H(P,P).
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> UTM(P,P) halting proves otherwise, demonstrating that H aborted its simulation too soon.
>>>>>>>>>>>>>>>>>>>> BUSTED!
>>>>>>>>>>>>>>>>>>>> I GOT YOU NOW!
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> How many recursive emulations does H need to wait before its emulated P
>>>>>>>>>>>>>>>>>>>> to reaches its final instruction?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Since H has a fixed algorithm (which we'll refer to as Ha, and the P that calls it we'll refer to as Pa to make that point clear) to to stop after N recursive emulations, it would need to simulate for N+1 emulations. But its fixed algorithm prevents it from simulating any more than N emulations.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> "H aborted its simulation too soon."
>>>>>>>>>>>>>>>>>> Liar liar pants on fire.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> PO-speak for "I know you proved me wrong and I don't know what else to say"
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> It is PO-speak for I just proved that you are lying:
>>>>>>>>>>>>>>>> On 6/27/2022 4:14 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>> demonstrating that H aborted its simulation too soon.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> How many recursive emulations must H(P,P) emulate its input until its
>>>>>>>>>>>>>>>> emulated input reaches the "ret" instruction of the emulated P?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The fixed algorithm of H, which we'll refer to as Ha and the P that calls it we'll refer to as Pa, simulates for N recursive emulations. Therefore the input must be simulated for N+1 recursive emulations. The fixed algorthm Ha is unable to simulate for this many cycles and therefore gets the wrong answer.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *Because I boxed you into a corner* you are finally implicitly admitting
>>>>>>>>>>>>>> that there is no integer value N number of cycles of recursive emulation
>>>>>>>>>>>>>> that H(P,P) can emulate its input such that the emulated P reaches its
>>>>>>>>>>>>>> final state "ret" instruction.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I already told you: N+1 cycles for Pa which is built on Ha.
>>>>>>>>>>>>>
>>>>>>>>>>>> I am asking for the exact integer value of N in (numeric digits) and you
>>>>>>>>>>>> consistently refuse to provide it because you know that it does not exist.
>>>>>>>>>>>
>>>>>>>>>>> I don't know the exact value because you haven't shown the full code of Ha. So assuming that Ha simulates for N iterations, then it takes N+1 iterations to reach a final state. And the fixed algorithm of Ha is unable to simulate for N+1 iterations, but UTM is.
>>>>>>>>>> So you are saying that when the emulated input to H(P,P) is emulated by
>>>>>>>>>> H that this emulated input reaches its final state just after its
>>>>>>>>>> emulation has been aborted?
>>>>>>>>>
>>>>>>>>> I'm saying that the emulated input to Ha(Pa,Pa) is aborted one iteration too soon.
>>>>>>>> Which necessitates that there is a finite integer number of recursive
>>>>>>>> emulations that is not too soon. What are the numeric digits of this
>>>>>>>> integer?
>>>>>>>
>>>>>>> Since you haven't told me how many iterations Ha simulates for, I'm going to assume that it simulates for 1 iteration. That means Pa(Pa) must be simulated for 2 iterations. But since Ha only simulates for 1 iteration, Ha(Pa,Pa)==0 is wrong because it aborted too soon.
>>>>>> You are still saying the an aborted emulation keeps running after it has
>>>>>> been aborted. I am not asking when some P reaches its "ret" instruction.
>>>>>
>>>>> I'm saying that the machine that the input represents continues to run past the point where Ha aborts its simulation to a final state, proving that Ha(Pa,Pa)==0 is wrong.
>>>>>
>>>>>>
>>>>>> I am asking when does the emulated input to H(P,P) that H emulates
>>>>>> reaches its "ret" instruction.
>>>>>> void P(u32 x)
>>>>>> {
>>>>>> if (H(x, x))
>>>>>> HERE: goto HERE;
>>>>>> return;
>>>>>> }
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>> Output("Input_Halts = ", Emulate_x86((u32)P, (u32)P));
>>>>>> }
>>>>>
>>>>> If you're asking if Ha(Pa,Pa) is able to simulate it's input to a final state, it can't. So you're saying that alone makes it correct?
>>>>>
>>>>
>>>> THIS MAKES Ha(Pa,Pa)==0 CORRECT:
>>>> I am saying that Ha(Pa,Pa) correctly determines/predicts that its
>>>> complete and correct x86 emulation of its input would never reach the
>>>> "ret" instruction of Pa.
>>>
>>> But Ha doesn't do a correct and complete simulation. It aborts. So to say what the correct and complete simulation of the input by Ha would do makes no sense.
>> Every simulating halt decider correctly simulates its input until it
>> correctly determines that this simulated input would never reach its
>> final state.
>> I don't know why you keep making the ridiculous assertion that a
>> simulating halt decider cannot possibly predict/determine that its
>> complete and correct x86 emulation of its input would never reach the
>> "ret" instruction of this input.
>
> But Ha doesn't *do* a complete and correct emulation of its input as per its fixed algorithm, so to say what the complete and correct emulation of the input to Ha(Pa,Pa) by Ha is, is simply nonsense.

On Wednesday, June 29, 2022 at 4:53:00 PM UTC-4, olcott wrote:
> On 6/29/2022 9:02 AM, Dennis Bush wrote:
> > On Wednesday, June 29, 2022 at 9:44:39 AM UTC-4, olcott wrote:
> >> On 6/28/2022 8:44 PM, Dennis Bush wrote:
> >>> On Tuesday, June 28, 2022 at 8:08:10 PM UTC-4, olcott wrote:
> >>>> On 6/28/2022 4:13 PM, Dennis Bush wrote:
> >>>>> On Tuesday, June 28, 2022 at 5:01:29 PM UTC-4, olcott wrote:
> >>>>>> On 6/28/2022 3:34 PM, Dennis Bush wrote:
> >>>>>>> On Tuesday, June 28, 2022 at 4:30:29 PM UTC-4, olcott wrote:
> >>>>>>>> On 6/28/2022 3:27 PM, Dennis Bush wrote:
> >>>>>>>>> On Tuesday, June 28, 2022 at 4:22:23 PM UTC-4, olcott wrote:
> >>>>>>>>>> On 6/28/2022 3:02 PM, Dennis Bush wrote:
> >>>>>>>>>>> On Tuesday, June 28, 2022 at 3:44:30 PM UTC-4, olcott wrote:
> >>>>>>>>>>>> On 6/28/2022 10:03 AM, Dennis Bush wrote:
> >>>>>>>>>>>>> On Tuesday, June 28, 2022 at 10:47:01 AM UTC-4, olcott wrote:
> >>>>>>>>>>>>>> On 6/28/2022 9:22 AM, Dennis Bush wrote:
> >>>>>>>>>>>>>>> On Tuesday, June 28, 2022 at 10:14:33 AM UTC-4, olcott wrote:
> >>>>>>>>>>>>>>>> On 6/27/2022 5:03 PM, Dennis Bush wrote:
> >>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 5:58:55 PM UTC-4, olcott wrote:
> >>>>>>>>>>>>>>>>>> On 6/27/2022 4:46 PM, Dennis Bush wrote:
> >>>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 5:38:02 PM UTC-4, olcott wrote:
> >>>>>>>>>>>>>>>>>>>> On 6/27/2022 4:14 PM, Dennis Bush wrote:
> >>>>>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 5:11:30 PM UTC-4, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>> On 6/27/2022 4:02 PM, Dennis Bush wrote:
> >>>>>>>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 4:52:17 PM UTC-4, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>>>> On 6/27/2022 2:45 PM, Dennis Bush wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 2:13:44 PM UTC-4, Dennis Bush wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 2:11:45 PM UTC-4, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/27/2022 1:03 PM, Dennis Bush wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 1:20:39 PM UTC-4, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/27/2022 12:03 PM, Dennis Bush wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 9:28:22 AM UTC-4, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/27/2022 7:58 AM, Dennis Bush wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 8:50:05 AM UTC-4, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/27/2022 7:40 AM, Dennis Bush wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 8:34:22 AM UTC-4, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/27/2022 7:26 AM, Dennis Bush wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 8:14:31 AM UTC-4, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/27/2022 6:57 AM, Dennis Bush wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 7:11:21 AM UTC-4, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> *This is the outline of the complete refutation*
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> *of the only rebuttal that anyone has left*
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (a) The complete and correct x86 emulation of the input to H(P,P) by H
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> never reaches the "ret" instruction of P.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It is known that H aborts its simulation and returns 0. That means that H *by definition* does not perform a complete and correct emulation. And since H (if it was constructed correctly) is a pure function of its inputs, it will ALWAYS return the same return for a given input.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> To state that H aborts *and* does a complete and correct simulation is simply nonsense.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> What *does* perform a complete and correct emulation of the input to H(P,P) is UTM(P,P) which halts, therefore H(P,P)==0 is wrong.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (b) The direct execution of P(P) does reach its "ret" instruction.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The above two are proven to be verified facts entirely on the basis of
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the semantics of the x86 language..
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> A nonsense statement can't be a "fact", verified or otherwise.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> A halt decider must compute the mapping from its inputs to an accept or
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reject state on the basis of the actual behavior that is actually
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> specified by these inputs.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Which for H(P,P) is BY DEFINITION is the behavior of P(P). The halting problem says that H MUST implement the following mapping (i.e. the halting function):
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H(x,y)==1 if and only if x(y) halts, and
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H(x,y)==0 if and only if x(y) does not halt.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H does not perform this mapping.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> P(P) is provably not the actual behavior of the actual input.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It is BY DEFINITION. So if H comes up with something different that means it did something wrong, specifically it aborted a halting computation too soon.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> void P(u32 x)
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> if (H(x, x))
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> return;
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int main()
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> P(P);
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> _P()
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f0](01) 55 push ebp
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f1](02) 8bec mov ebp,esp
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f3](03) 8b4508 mov eax,[ebp+08]
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f6](01) 50 push eax
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f7](03) 8b4d08 mov ecx,[ebp+08]
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011fa](01) 51 push ecx
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011fb](05) e820feffff call 00001020
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001200](03) 83c408 add esp,+08
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001203](02) 85c0 test eax,eax
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001205](02) 7402 jz 00001209
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001207](02) ebfe jmp 00001207
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001209](01) 5d pop ebp
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [0000120a](01) c3 ret
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Size in bytes:(0027) [0000120a]
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> _main()
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001210](01) 55 push ebp
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001211](02) 8bec mov ebp,esp
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001213](05) 68f0110000 push 000011f0
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001218](05) e8d3ffffff call 000011f0
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [0000121d](03) 83c404 add esp,+04
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001220](02) 33c0 xor eax,eax
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001222](01) 5d pop ebp
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001223](01) c3 ret
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Size in bytes:(0020) [00001223]
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> machine stack stack machine assembly
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> address address data code language
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ======== ======== ======== ========= =============
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001210][00101fba][00000000] 55 push ebp
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001211][00101fba][00000000] 8bec mov ebp,esp
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001213][00101fb6][000011f0] 68f0110000 push 000011f0 // push P
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001218][00101fb2][0000121d] e8d3ffffff call 000011f0 // call P
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f0][00101fae][00101fba] 55 push ebp // enter executed P
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f1][00101fae][00101fba] 8bec mov ebp,esp
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f3][00101fae][00101fba] 8b4508 mov eax,[ebp+08]
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f6][00101faa][000011f0] 50 push eax // push P
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f7][00101faa][000011f0] 8b4d08 mov ecx,[ebp+08]
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011fa][00101fa6][000011f0] 51 push ecx // push P
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011fb][00101fa2][00001200] e820feffff call 00001020 // call H
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Begin Simulation Execution Trace Stored at:21206e
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Address_of_H:1020
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f0][0021205a][0021205e] 55 push ebp // enter emulated P
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f1][0021205a][0021205e] 8bec mov ebp,esp
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f3][0021205a][0021205e] 8b4508 mov eax,[ebp+08]
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f6][00212056][000011f0] 50 push eax // push P
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f7][00212056][000011f0] 8b4d08 mov ecx,[ebp+08]
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011fa][00212052][000011f0] 51 push ecx // push P
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011fb][0021204e][00001200] e820feffff call 00001020 // call emulated H
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Infinitely Recursive Simulation Detected Simulation Stopped
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H knows its own machine address and on this basis it can easily
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> examine its stored execution_trace of P (see above) to determine:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (a) P is calling H with the same arguments that H was called with.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (b) No instructions in P could possibly escape this otherwise infinitely
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> recursive emulation.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> FALSE. P contains these instructions:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> if (Decide_Halting(&execution_trace, &decoded, code_end, &master_state,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> &slave_state, &slave_stack, Address_of_H, P, I))
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> goto END_OF_CODE;
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> return 0; // Does not halt
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> END_OF_CODE:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> return 1; // Input has normally terminated
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> That *can* and *do* prevent infinite recursive emulation in a *correct* and *complete* emulation
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (c) H aborts its emulation of P before its call to H is emulated.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> And in doing so it fails to see that the call to H, since H is a computation, will aborts *its* simulation of P and return 0 to the outer P being emulated, which would cause it to halt, making H(P,P)==0 wrong.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001200][00101fae][00101fba] 83c408 add esp,+08 // return to
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> executed P
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001203][00101fae][00101fba] 85c0 test eax,eax
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001205][00101fae][00101fba] 7402 jz 00001209
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001209][00101fb2][0000121d] 5d pop ebp
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [0000120a][00101fb6][000011f0] c3 ret // return from
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> executed P
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [0000121d][00101fba][00000000] 83c404 add esp,+04
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001220][00101fba][00000000] 33c0 xor eax,eax
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001222][00101fbe][00100000] 5d pop ebp
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001223][00101fc2][00000000] c3 ret // ret from main
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Number of Instructions Executed(878) / 67 = 13 pages
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I've stated in detail why you're wrong. Now you need to explain in detail why I'm wrong.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Failure to do so, which includes simply restating your original point, will be taken as admission that what I've stated is correct.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H correctly predicts that its complete and correct x86 emulation of its
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> input never reaches the the "ret" instruction of P.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Repeating your original point.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> This is the actual behavior of the input to H(P,P).
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> P(P) is not the actual behavior of the input to H(P,P).
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Again, repeating your original point..
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Never reaching the "ret" instruction means that P does not halt.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> A halt decider must compute the mapping from its inputs to an accept or
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reject state on the basis of the actual behavior that is actually
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> specified by these inputs.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Therefore H(P,P)==0 is correct.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> And again, repeating your original point.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> So no explanation as to why I'm wrong, just a repetition of your original points.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> That means you accept that what I've said is true, and that H(P,P)==0 is wrong.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You rebuttal is based on rejecting the verified fact that a simulating
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> halt decider correctly predicts that its correctly simulated input will
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> never reach the final state "ret" instruction of this input.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> FALSE. The correctly simulated input to H(P,P) is UTM(P,P) which halts, therefore H(P,P)==0 is wrong.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> First of all I am not talking about UTM's.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I am talking about x86 emulation.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Try to encode what you mean, here is my guess:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> void P(u32 x)
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> if (emulate_x86(x, x))
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> return;
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int main()
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> P is a computation and therefore it can't be changed, nor can anything that it calls. I mean UTM(P,P). The simplest way to implement this is:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> void UTM(u32 x, u32 y)
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> x(y)
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H cannot by definition perform a correct and complete emulation if it aborts, so the input must be passed to something that does, i.e. a UTM, for the source of truth.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> A simulating halt decider correctly simulates its input until it
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> correctly determines that this simulated input would never reach its
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> final state.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> But H isn't such a decider, because the simulated input does reach a final state when correctly simulated, i.e. by UTM(P,P), therefore H(P,P)==0 is wrong.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Every simulating decider that correctly simulates its input until it
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> correctly determines that this simulated input would never reach its
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> final state correctly determines the halt status of this input.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> And H isn't such a decider, because it does not correctly determine that the input to H(P,P) would never halt as demonstrated by UTM(P,P) halting.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> The specification for H:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> H(x,y)==0 if and only if x(y) does not halt, and
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> H(x,y)==1 if and only if x(y) halts.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> H does not meet the specification.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> The spec is provably incorrect in this case:
> >>>>>>>>>>>>>>>>>>>>>>>>>> A spec can't be incorrect. It just is. If it can't be satisfied, then that validates the halting problem proofs that say it can't be satisfied.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> No response to this I see. So you agree that your H does not meet the above spec that the halting problem requires?
> >>>>>>>>>>>>>>>>>>>>>>>> You are just playing word games so I will use a different word:
> >>>>>>>>>>>>>>>>>>>>>>>> "criterion measure".
> >>>>>>>>>>>>>>>>>>>>>>>> A halt decider must compute the mapping from its inputs to an accept or
> >>>>>>>>>>>>>>>>>>>>>>>> reject state on the basis of the actual behavior that is actually
> >>>>>>>>>>>>>>>>>>>>>>>> specified by these inputs.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> As per this specification:
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> H(x,y)==0 if and only if x(y) does not halt, and
> >>>>>>>>>>>>>>>>>>>>>>> H(x,y)==1 if and only if x(y) halts
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Which means the actual behavior of the actual input to H(P,P) is defined to be the behavior of P(P).
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Remember, the halting problem is ultimately about algorithms, not some simulator's simulation of it.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> This also means that if the result of H(P,P) doesn't match the behavior of P(P) then H is wrong by definition.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> P(P) is provably not the actual behavior of the actual input,
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> If you mean that H(P,P) can't simulate its input to a final state, then any simulator that aborts its input for any reason is necessarily correct, which is clearly nonsense.
> >>>>>>>>>>>>>>>>>>>>>> The formal mathematical semantics of the x86 language conclusively
> >>>>>>>>>>>>>>>>>>>>>> proves that P(P) is not the actual behavior of the actual input to H(P,P).
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> UTM(P,P) halting proves otherwise, demonstrating that H aborted its simulation too soon.
> >>>>>>>>>>>>>>>>>>>> BUSTED!
> >>>>>>>>>>>>>>>>>>>> I GOT YOU NOW!
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> How many recursive emulations does H need to wait before its emulated P
> >>>>>>>>>>>>>>>>>>>> to reaches its final instruction?
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Since H has a fixed algorithm (which we'll refer to as Ha, and the P that calls it we'll refer to as Pa to make that point clear) to to stop after N recursive emulations, it would need to simulate for N+1 emulations. But its fixed algorithm prevents it from simulating any more than N emulations.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> "H aborted its simulation too soon."
> >>>>>>>>>>>>>>>>>> Liar liar pants on fire.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> PO-speak for "I know you proved me wrong and I don't know what else to say"
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> It is PO-speak for I just proved that you are lying:
> >>>>>>>>>>>>>>>> On 6/27/2022 4:14 PM, Dennis Bush wrote:
> >>>>>>>>>>>>>>>>> demonstrating that H aborted its simulation too soon.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> How many recursive emulations must H(P,P) emulate its input until its
> >>>>>>>>>>>>>>>> emulated input reaches the "ret" instruction of the emulated P?
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> The fixed algorithm of H, which we'll refer to as Ha and the P that calls it we'll refer to as Pa, simulates for N recursive emulations. Therefore the input must be simulated for N+1 recursive emulations. The fixed algorthm Ha is unable to simulate for this many cycles and therefore gets the wrong answer.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>> *Because I boxed you into a corner* you are finally implicitly admitting
> >>>>>>>>>>>>>> that there is no integer value N number of cycles of recursive emulation
> >>>>>>>>>>>>>> that H(P,P) can emulate its input such that the emulated P reaches its
> >>>>>>>>>>>>>> final state "ret" instruction.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I already told you: N+1 cycles for Pa which is built on Ha.
> >>>>>>>>>>>>>
> >>>>>>>>>>>> I am asking for the exact integer value of N in (numeric digits) and you
> >>>>>>>>>>>> consistently refuse to provide it because you know that it does not exist.
> >>>>>>>>>>>
> >>>>>>>>>>> I don't know the exact value because you haven't shown the full code of Ha. So assuming that Ha simulates for N iterations, then it takes N+1 iterations to reach a final state. And the fixed algorithm of Ha is unable to simulate for N+1 iterations, but UTM is.
> >>>>>>>>>> So you are saying that when the emulated input to H(P,P) is emulated by
> >>>>>>>>>> H that this emulated input reaches its final state just after its
> >>>>>>>>>> emulation has been aborted?
> >>>>>>>>>
> >>>>>>>>> I'm saying that the emulated input to Ha(Pa,Pa) is aborted one iteration too soon.
> >>>>>>>> Which necessitates that there is a finite integer number of recursive
> >>>>>>>> emulations that is not too soon. What are the numeric digits of this
> >>>>>>>> integer?
> >>>>>>>
> >>>>>>> Since you haven't told me how many iterations Ha simulates for, I'm going to assume that it simulates for 1 iteration. That means Pa(Pa) must be simulated for 2 iterations. But since Ha only simulates for 1 iteration, Ha(Pa,Pa)==0 is wrong because it aborted too soon.
> >>>>>> You are still saying the an aborted emulation keeps running after it has
> >>>>>> been aborted. I am not asking when some P reaches its "ret" instruction.
> >>>>>
> >>>>> I'm saying that the machine that the input represents continues to run past the point where Ha aborts its simulation to a final state, proving that Ha(Pa,Pa)==0 is wrong.
> >>>>>
> >>>>>>
> >>>>>> I am asking when does the emulated input to H(P,P) that H emulates
> >>>>>> reaches its "ret" instruction.
> >>>>>> void P(u32 x)
> >>>>>> {
> >>>>>> if (H(x, x))
> >>>>>> HERE: goto HERE;
> >>>>>> return;
> >>>>>> }
> >>>>>>
> >>>>>> int main()
> >>>>>> {
> >>>>>> Output("Input_Halts = ", Emulate_x86((u32)P, (u32)P));
> >>>>>> }
> >>>>>
> >>>>> If you're asking if Ha(Pa,Pa) is able to simulate it's input to a final state, it can't. So you're saying that alone makes it correct?
> >>>>>
> >>>>
> >>>> THIS MAKES Ha(Pa,Pa)==0 CORRECT:
> >>>> I am saying that Ha(Pa,Pa) correctly determines/predicts that its
> >>>> complete and correct x86 emulation of its input would never reach the
> >>>> "ret" instruction of Pa.
> >>>
> >>> But Ha doesn't do a correct and complete simulation. It aborts. So to say what the correct and complete simulation of the input by Ha would do makes no sense.
> >> Every simulating halt decider correctly simulates its input until it
> >> correctly determines that this simulated input would never reach its
> >> final state.
> >> I don't know why you keep making the ridiculous assertion that a
> >> simulating halt decider cannot possibly predict/determine that its
> >> complete and correct x86 emulation of its input would never reach the
> >> "ret" instruction of this input.
> >
> > But Ha doesn't *do* a complete and correct emulation of its input as per its fixed algorithm, so to say what the complete and correct emulation of the input to Ha(Pa,Pa) by Ha is, is simply nonsense.
> To continue to insist that a simulating halt decider cannot correctly
> predict (in a finite number of steps) that its complete and correct x86
> emulation of its input

On 6/29/2022 3:43 PM, Ben Bacarisse wrote:
> Paul N <gw7rib@aol.com> writes:
>
>> On Tuesday, June 28, 2022 at 10:08:36 PM UTC+1, olcott wrote:
>>
>> In maths, sometimes it is possible to prove that there is no number
>> satisfying certain conditions, by showing that it must satisfy
>> conditions which are contradictory. For instance, if we can show that
>> a number X must be greater than 4, and also show that it must be less
>> than 2, this is normally regarded as a proof that no such X
>> exists. You would accept this, would you? You wouldn't start arguing
>> that therefore there must be numbers more than 4 but less then 2 whose
>> existence has been overlooked until now?
>>
>> It similar here. The requirements of a halt detector are such that we
>> can prove that no such function exists. You seem to think that it
>> ought to be possible, and so you start trying to bend what the
>> requirements require. For instance, you accept that:
>>
>>> (1) A halt decider must compute the mapping from its inputs to an accept
>>> or reject state on the basis of the actual behavior that is actually
>>> specified by these inputs.
>>
>> But you also say that H(P, P) is zero, and that P(P) terminates. So H
>> gets it wrong in this case.
>
> You keep missing the magic words! The behaviour "actually specified by
> these inputs" is not the actual behaviour of P(P). Even since it's been
> clear that H(P,P) == 0 and that P(P) he's been searching for some form
> of words that make H look less obviously wrong.
>
>> You also go on to say:
>>
>>> (2) P(P) is provably not the actual behavior of the actual input to H(P,P).
>>
>> In other words, you admit that H gets the prediction of P(P) wrong.
>
> Yes -- for the rest of the world -- but the word game is to find a way
> to keep the discussion going; some mantra that is vague enough about
> what H is really doing that it will enable a few thousand more posts.
>
> This is the main reason he abandoned talking about TMs (not really
> understanding them was secondary). You just can't get away with this
> using TMs without making it clear that you are no longer talking about
> the halting theorem proof. He did try for a while. He would write
> configuration sequences without any attached conditions, and when that
> got too embarrassing, he simply had to re-write the conditions. There
> was a few months of "they are same but different" but it just didn't
> wash and was not sustainable.
>

When you say that I am wrong on the basis of your lack of comprehension
of the semantics of the x86 language that proves that I am right

MAKES YOU A LIAR.
MAKES YOU A LIAR.
MAKES YOU A LIAR.

(a) The complete and correct x86 emulation of the input to H(P,P) by H
never reaches the "ret" instruction of P.

(b) The direct execution of P(P) does reach its "ret" instruction.

The above two are proven to be verified facts entirely on the basis of
the semantics of the x86 language.

A halt decider must compute the mapping from its inputs to an accept or
reject state on the basis of the actual behavior that is actually
specified by these inputs.

P(P) is provably not the actual behavior of the actual input to H(P,P).

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On Wednesday, June 29, 2022 at 4:58:29 PM UTC-4, olcott wrote:
> On 6/29/2022 3:43 PM, Ben Bacarisse wrote:
> > Paul N <gw7...@aol.com> writes:
> >
> >> On Tuesday, June 28, 2022 at 10:08:36 PM UTC+1, olcott wrote:
> >>
> >> In maths, sometimes it is possible to prove that there is no number
> >> satisfying certain conditions, by showing that it must satisfy
> >> conditions which are contradictory. For instance, if we can show that
> >> a number X must be greater than 4, and also show that it must be less
> >> than 2, this is normally regarded as a proof that no such X
> >> exists. You would accept this, would you? You wouldn't start arguing
> >> that therefore there must be numbers more than 4 but less then 2 whose
> >> existence has been overlooked until now?
> >>
> >> It similar here. The requirements of a halt detector are such that we
> >> can prove that no such function exists. You seem to think that it
> >> ought to be possible, and so you start trying to bend what the
> >> requirements require. For instance, you accept that:
> >>
> >>> (1) A halt decider must compute the mapping from its inputs to an accept
> >>> or reject state on the basis of the actual behavior that is actually
> >>> specified by these inputs.
> >>
> >> But you also say that H(P, P) is zero, and that P(P) terminates. So H
> >> gets it wrong in this case.
> >
> > You keep missing the magic words! The behaviour "actually specified by
> > these inputs" is not the actual behaviour of P(P). Even since it's been
> > clear that H(P,P) == 0 and that P(P) he's been searching for some form
> > of words that make H look less obviously wrong.
> >
> >> You also go on to say:
> >>
> >>> (2) P(P) is provably not the actual behavior of the actual input to H(P,P).
> >>
> >> In other words, you admit that H gets the prediction of P(P) wrong.
> >
> > Yes -- for the rest of the world -- but the word game is to find a way
> > to keep the discussion going; some mantra that is vague enough about
> > what H is really doing that it will enable a few thousand more posts.
> >
> > This is the main reason he abandoned talking about TMs (not really
> > understanding them was secondary). You just can't get away with this
> > using TMs without making it clear that you are no longer talking about
> > the halting theorem proof. He did try for a while. He would write
> > configuration sequences without any attached conditions, and when that
> > got too embarrassing, he simply had to re-write the conditions. There
> > was a few months of "they are same but different" but it just didn't
> > wash and was not sustainable.
> >
> When you say that I am wrong on the basis of your lack of comprehension
> of the semantics of the x86 language that proves that I am right
>
> MAKES YOU A LIAR.
> MAKES YOU A LIAR.
> MAKES YOU A LIAR.
>
>
> (a) The complete and correct x86 emulation of the input to H(P,P) by H

Does not exist because Ha doesn't do a complete and correct x86 emulation of its input.

> never reaches the "ret" instruction of P.
> (b) The direct execution of P(P) does reach its "ret" instruction.
>
> The above two are proven to be verified facts entirely on the basis of
> the semantics of the x86 language.
> A halt decider must compute the mapping from its inputs to an accept or
> reject state on the basis of the actual behavior that is actually
> specified by these inputs.
> P(P) is provably not the actual behavior of the actual input to H(P,P).
> --
> Copyright 2022 Pete Olcott
>
> "Talent hits a target no one else can hit;
> Genius hits a target no one else can see."
> Arthur Schopenhauer

On 6/29/2022 2:32 PM, olcott wrote:
> On 6/29/2022 2:29 PM, Jeff Barnett wrote:
>> On 6/29/2022 10:36 AM, Paul N wrote:
>>> On Tuesday, June 28, 2022 at 10:08:36 PM UTC+1, olcott wrote:
>>>
>>> In maths, sometimes it is possible to prove that there is no number
>>> satisfying certain conditions, by showing that it must satisfy
>>> conditions which are contradictory. For instance, if we can show that
>>> a number X must be greater than 4, and also show that it must be less
>>> than 2, this is normally regarded as a proof that no such X exists.
>>> You would accept this, would you? You wouldn't start arguing that
>>> therefore there must be numbers more than 4 but less then 2 whose
>>> existence has been overlooked until now?
>>>
>>> It similar here. The requirements of a halt detector are such that we
>>> can prove that no such function exists. You seem to think that it
>>> ought to be possible, and so you start trying to bend what the
>>> requirements require. For instance, you accept that:
>>>
>>>> (1) A halt decider must compute the mapping from its inputs to an
>>>> accept
>>>> or reject state on the basis of the actual behavior that is actually
>>>> specified by these inputs.
>>>
>>> But you also say that H(P, P) is zero, and that P(P) terminates. So H
>>> gets it wrong in this case.
>>>
>>> So how to resolve this? One way you do this is by trying to change
>>> what H is required to do. You have said:
>>>
>>>>> The complete and correct x86 emulation of the input to H(P,P) by H
>>>>> never reaches the "ret" instruction of P.
>>>
>>> It is not clear what this means, but since you have also said that
>>> P(P) terminates, and that the "correct emulation" doesn't, this is
>>> not actually a correct emulation by the usual definitions of
>>> "correct" and "emulation". If it's not an accurate emulation, why
>>> does it matter what it does?
>>>
>>> You also go on to say:
>>>
>>>> (2) P(P) is provably not the actual behavior of the actual input to
>>>> H(P,P).
>>>
>>> In other words, you admit that H gets the prediction of P(P) wrong.
>>> You're just trying to blame something or someone else for it, instead
>>> of admitting that you don't have (and can't have) an accurate H.
>>>
>>> Going back to maths again, there is a proof that even if you make an
>>> infinitely long list of real numbers, there will be some real number
>>> that does not appear anywhere on that list. You simply choose a
>>> number whose first digit after the decimal point is different from
>>> the corresponding digit of the first number, whose second digit after
>>> the point is different from that of the second number, etc, with a
>>> check you aren't dealing with 0s and 9s (0.9999... = 1.0000...).
>>> There once was someone who thought this proof was invalid. He thought
>>> you could work out the missing number and then just sort of slot it
>>> into the list somewhere, refuting the proof that it was left out. He
>>> didn't seem to realise that you can perform the same trick to the new
>>> list to find a new number which is left out. You seem to be doing
>>> much the same thing - define an H which will run forever in some
>>> circumstances, and then tweak it to not run forever, while failing to
>>> realise that you have changed its behaviour.
>>>
>>>> If (1) and (2) are true then I am necessarily correct.
>>>
>>> No, if (2) is true you are necessarily incorrect.
>>
>> This above is a very good summary that should inform us all of the
>> actual state of affairs with PO's efforts. Unfortunately the "all" in
>> the prior dose not include him. The problem is two-fold: a learning
>> disability and personality disorders. As to the first - he is not
>> competent to read or even reread and absorb material because of an
>> attention deficit disorder. This is a likely reason that he was not
>> able to hold a job and lived with his mother until recently.
>>
>> As to the second issue - He see to have an underlying low opinion of
>> self and has learned to bluff. In fact he sometimes thinks he was put
>> on earth to do something big. For decades he has gone around in
>> circles "looking for a new insight in a big problem". If he could
>> concentrate better (first problem) he would have spent those decades
>> doing real research and development and maybe even published a minor
>> article. That would be a real accomplishment but he's not built for it.
>>
>> He, instead, has turned into a successful troll and that bolsters his
>> ego: "Look at all of those supposedly sharp people I can lead around
>> in circles by their noses!" He would like to make sharp and accurate
>> rebuttals but he usually can't so he flames instead and relishes the
>> long threads that develop with him in charge.
>>
>> He takes glee in thread length and contents are not particularly
>> important. There are others that participate here that have decided to
>> play sheriff - "I wont let him get away with anything!" I think there
>> might even be a side race to see who can respond to PO most accurately
>> and the most times. This group (Damon, Fibble, Bush, and a few others)
>> is as misguided as PO though much more knowledgeable: they will not
>> change or enlighten him. In fact, since no progress is made, they
>> resort to the same type of repetition that appears in PO's offerings.
>>
>> In other words, the contents in this newsgroup and its threads are
>> frozen in time. I will give the only sane advise that I know if you
>> are to continue here: Return to a warm spot once in a while.
>
> In other words you resort to ad hominem because you are insufficiently
> technically competent to to correctly evaluate the following according
> to the semantics of the x86 language:

In other word I think you are nuts and maladjusted. Was I that unclear?

<snipped parrot poop>
--
Jeff Barnett

On Wednesday, June 29, 2022 at 6:00:25 AM UTC-7, olcott wrote:
> On 6/29/2022 2:07 AM, dklei...@gmail.com wrote:
>>
> > I hope you will share your attempts to define "the x86 language" and "its
> > precise semantics" with us. I don't think you will be able to do it.
>
> This is already documented in many different places:
> https://c9x.me/x86/
>
Your link is nothing more than a list of op-codes. No language
there. No definition of statements. No statement syntax. No
semantics at all. I am fairly sure Intel has published more
detailed descriptions - like what the arguments of these
op-codes are.

On 6/29/2022 6:26 PM, dklei...@gmail.com wrote:
> On Wednesday, June 29, 2022 at 6:00:25 AM UTC-7, olcott wrote:
>> On 6/29/2022 2:07 AM, dklei...@gmail.com wrote:
>>>
>>> I hope you will share your attempts to define "the x86 language" and "its
>>> precise semantics" with us. I don't think you will be able to do it.
>>
>> This is already documented in many different places:
>> https://c9x.me/x86/
>>
> Your link is nothing more than a list of op-codes. No language
> there. No definition of statements.

Ah so you are unaware that with HTLM one must click on the links?
https://c9x.me/x86/html/file_module_x86_id_146.html

> No statement syntax. No
> semantics at all. I am fairly sure Intel has published more
> detailed descriptions - like what the arguments of these
> op-codes are.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 6/29/2022 5:57 PM, Jeff Barnett wrote:
> On 6/29/2022 2:32 PM, olcott wrote:
>> On 6/29/2022 2:29 PM, Jeff Barnett wrote:
>>> On 6/29/2022 10:36 AM, Paul N wrote:
>>>> On Tuesday, June 28, 2022 at 10:08:36 PM UTC+1, olcott wrote:
>>>>
>>>> In maths, sometimes it is possible to prove that there is no number
>>>> satisfying certain conditions, by showing that it must satisfy
>>>> conditions which are contradictory. For instance, if we can show
>>>> that a number X must be greater than 4, and also show that it must
>>>> be less than 2, this is normally regarded as a proof that no such X
>>>> exists. You would accept this, would you? You wouldn't start arguing
>>>> that therefore there must be numbers more than 4 but less then 2
>>>> whose existence has been overlooked until now?
>>>>
>>>> It similar here. The requirements of a halt detector are such that
>>>> we can prove that no such function exists. You seem to think that it
>>>> ought to be possible, and so you start trying to bend what the
>>>> requirements require. For instance, you accept that:
>>>>
>>>>> (1) A halt decider must compute the mapping from its inputs to an
>>>>> accept
>>>>> or reject state on the basis of the actual behavior that is actually
>>>>> specified by these inputs.
>>>>
>>>> But you also say that H(P, P) is zero, and that P(P) terminates. So
>>>> H gets it wrong in this case.
>>>>
>>>> So how to resolve this? One way you do this is by trying to change
>>>> what H is required to do. You have said:
>>>>
>>>>>> The complete and correct x86 emulation of the input to H(P,P) by H
>>>>>> never reaches the "ret" instruction of P.
>>>>
>>>> It is not clear what this means, but since you have also said that
>>>> P(P) terminates, and that the "correct emulation" doesn't, this is
>>>> not actually a correct emulation by the usual definitions of
>>>> "correct" and "emulation". If it's not an accurate emulation, why
>>>> does it matter what it does?
>>>>
>>>> You also go on to say:
>>>>
>>>>> (2) P(P) is provably not the actual behavior of the actual input to
>>>>> H(P,P).
>>>>
>>>> In other words, you admit that H gets the prediction of P(P) wrong.
>>>> You're just trying to blame something or someone else for it,
>>>> instead of admitting that you don't have (and can't have) an
>>>> accurate H.
>>>>
>>>> Going back to maths again, there is a proof that even if you make an
>>>> infinitely long list of real numbers, there will be some real number
>>>> that does not appear anywhere on that list. You simply choose a
>>>> number whose first digit after the decimal point is different from
>>>> the corresponding digit of the first number, whose second digit
>>>> after the point is different from that of the second number, etc,
>>>> with a check you aren't dealing with 0s and 9s (0.9999... =
>>>> 1.0000...). There once was someone who thought this proof was
>>>> invalid. He thought you could work out the missing number and then
>>>> just sort of slot it into the list somewhere, refuting the proof
>>>> that it was left out. He didn't seem to realise that you can perform
>>>> the same trick to the new list to find a new number which is left
>>>> out. You seem to be doing much the same thing - define an H which
>>>> will run forever in some circumstances, and then tweak it to not run
>>>> forever, while failing to realise that you have changed its behaviour.
>>>>
>>>>> If (1) and (2) are true then I am necessarily correct.
>>>>
>>>> No, if (2) is true you are necessarily incorrect.
>>>
>>> This above is a very good summary that should inform us all of the
>>> actual state of affairs with PO's efforts. Unfortunately the "all" in
>>> the prior dose not include him. The problem is two-fold: a learning
>>> disability and personality disorders. As to the first - he is not
>>> competent to read or even reread and absorb material because of an
>>> attention deficit disorder. This is a likely reason that he was not
>>> able to hold a job and lived with his mother until recently.
>>>
>>> As to the second issue - He see to have an underlying low opinion of
>>> self and has learned to bluff. In fact he sometimes thinks he was put
>>> on earth to do something big. For decades he has gone around in
>>> circles "looking for a new insight in a big problem". If he could
>>> concentrate better (first problem) he would have spent those decades
>>> doing real research and development and maybe even published a minor
>>> article. That would be a real accomplishment but he's not built for it.
>>>
>>> He, instead, has turned into a successful troll and that bolsters his
>>> ego: "Look at all of those supposedly sharp people I can lead around
>>> in circles by their noses!" He would like to make sharp and accurate
>>> rebuttals but he usually can't so he flames instead and relishes the
>>> long threads that develop with him in charge.
>>>
>>> He takes glee in thread length and contents are not particularly
>>> important. There are others that participate here that have decided
>>> to play sheriff - "I wont let him get away with anything!" I think
>>> there might even be a side race to see who can respond to PO most
>>> accurately and the most times. This group (Damon, Fibble, Bush, and a
>>> few others) is as misguided as PO though much more knowledgeable:
>>> they will not change or enlighten him. In fact, since no progress is
>>> made, they resort to the same type of repetition that appears in PO's
>>> offerings.
>>>
>>> In other words, the contents in this newsgroup and its threads are
>>> frozen in time. I will give the only sane advise that I know if you
>>> are to continue here: Return to a warm spot once in a while.
>>
>> In other words you resort to ad hominem because you are insufficiently
>> technically competent to to correctly evaluate the following according
>> to the semantics of the x86 language:
>
> In other word I think you are nuts and maladjusted. Was I that unclear?
>
> <snipped parrot poop>

You are clearly a Jackass.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 6/29/22 9:44 AM, olcott wrote:
>
> Every simulating halt decider correctly simulates its input until it
> correctly determines that this simulated input would never reach its
> final state.

Then H must not abort its simulation of P(P), and thus not return an
answer, as if at ANY point it does stop its emulation and return 0, then
that makes P(P) a Halting Computation, and thus H was WRING to say the
correct answer to H(P,P) is 0.

You H doesn't do this, since you claim it returns 0.

Until you can show how you emulated the infinite nesting of emulations
in finite time, you are just a liar.

On 6/29/22 4:52 PM, olcott wrote:
> On 6/29/2022 9:02 AM, Dennis Bush wrote:
>>
>> But Ha doesn't *do* a complete and correct emulation of its input as
>> per its fixed algorithm, so to say what the complete and correct
>> emulation of the input to Ha(Pa,Pa) by Ha is, is simply nonsense.
>
> To continue to insist that a simulating halt decider cannot correctly
> predict (in a finite number of steps) that its complete and correct x86
> emulation of its input would never reach the "ret" instruction of this
> input when you were repeatedly corrected by the example below,
>
> MAKES YOU A LIAR:
> MAKES YOU A LIAR:
> MAKES YOU A LIAR:

No, this example make YOU the liar.

He didn't say it can't predict any cases, he said it doesn't actually do
the complete emulation your definition requires.

Thus, even for this case, though H got the right answer for the
traditional definition of Halting, it didn't meet YOUR requirement to
match its own complete emulation, since it didn't do one.

>
> void Infinite_Loop()
> {
>   HERE: goto HERE;
> }
>
> int main()
> {
>   Output("Input_Halts = ", H0((u32)Infinite_Loop));
> }
>
> _Infinite_Loop()
> [00001102](01)  55         push ebp
> [00001103](02)  8bec       mov ebp,esp
> [00001105](02)  ebfe       jmp 00001105
> [00001107](01)  5d         pop ebp
> [00001108](01)  c3         ret
> Size in bytes:(0007) [00001108]
>
> _main()
> [00001192](01)  55         push ebp
> [00001193](02)  8bec       mov ebp,esp
> [00001195](05)  6802110000 push 00001102
> [0000119a](05)  e8d3fbffff call 00000d72
> [0000119f](03)  83c404     add esp,+04
> [000011a2](01)  50         push eax
> [000011a3](05)  68a3040000 push 000004a3
> [000011a8](05)  e845f3ffff call 000004f2
> [000011ad](03)  83c408     add esp,+08
> [000011b0](02)  33c0       xor eax,eax
> [000011b2](01)  5d         pop ebp
> [000011b3](01)  c3         ret
> Size in bytes:(0034) [000011b3]
>
>  machine   stack     stack     machine    assembly
>  address   address   data      code       language
>  ========  ========  ========  =========  =============
> [00001192][00101ef8][00000000] 55         push ebp
> [00001193][00101ef8][00000000] 8bec       mov ebp,esp
> [00001195][00101ef4][00001102] 6802110000 push 00001102
> [0000119a][00101ef0][0000119f] e8d3fbffff call 00000d72
>
> H0: Begin Simulation   Execution Trace Stored at:211fac
> Address_of_H0:d72
> [00001102][00211f9c][00211fa0] 55         push ebp
> [00001103][00211f9c][00211fa0] 8bec       mov ebp,esp
> [00001105][00211f9c][00211fa0] ebfe       jmp 00001105
> [00001105][00211f9c][00211fa0] ebfe       jmp 00001105
> H0: Infinite Loop Detected Simulation Stopped
>
> [0000119f][00101ef8][00000000] 83c404     add esp,+04
> [000011a2][00101ef4][00000000] 50         push eax
> [000011a3][00101ef0][000004a3] 68a3040000 push 000004a3
> [000011a8][00101ef0][000004a3] e845f3ffff call 000004f2
> Input_Halts = 0
> [000011ad][00101ef8][00000000] 83c408     add esp,+08
> [000011b0][00101ef8][00000000] 33c0       xor eax,eax
> [000011b2][00101efc][00100000] 5d         pop ebp
> [000011b3][00101f00][00000004] c3         ret
> Number of Instructions Executed(554) == 8 Pages
>
>

On 6/29/22 9:58 AM, olcott wrote:
> On 6/28/2022 8:48 PM, Dennis Bush wrote:
>>
>> Not according to the specification put forth by the halting problem:
>>
>> H(x,y)==1 if and only if x(y) halts, and
>> H(x,y)==0 if and only if x(y) does not halt
>>
>> Remember, the question is: does an algorithm exist that can determine
>> whether *any* arbitrary algorithm will halt when given a particular
>> input.  That's what the above specification is saying, and Ha is
>> unable to answer that question correctly for Pa(Pa).
>
> A halt decider must compute the mapping from its inputs to an accept or
> reject state on the basis of the actual behavior that is actually
> specified by these inputs.
>
> The specification provided in computer science textbooks contradicts the
> above necessarily true statement thus proving that this specification is
> incorrect. *Alternatively you must find an error in the above statement*
>
> Even people that are not very bright understand that a pair of
> statements that contradict each other cannot both be true.
>

No, sicne the ACTUAL BEHAVIOR of the input to H(P,P) is the behavior of
P(P), given the definition of what a Halt Decider is and the design
specs of the "impossible program" P were.

The fact that the job is impossible, doesn't mean the spec is wrong.

What is the error in MY statement? If YOU don't answer YOU are shown to
be the LIAR.

Yes, two contraditory statements can't both be true, but that means the
error is most likely in your claim that H(P,P) doesn't represent P(P),
since that is just YOUR unfounded claim based on bad logic, as opposed
to the actual requirements of the theory.

YOU have the contradiction of H doing both a complete and correct
emulation of its input and ALSO stopping that emulation to return the
value 0.

YOu can't STOP and GO at the same time.

On 6/29/22 9:00 AM, olcott wrote:
> On 6/29/2022 2:07 AM, dklei...@gmail.com wrote:
>> On Tuesday, June 28, 2022 at 10:03:13 PM UTC-7, olcott wrote:
>>
>>> Here is the new title:
>>> *Halting problem proofs refuted on the basis of software engineering*
>>>
>>> We construe the x86 language as a formal language that corresponds
>>> to its precise semantics.
>>
>>   I think your new title should be: The proofs of the Halting Problem
>> for Turing
>> Machines refuted.
>>
>
> The reason that I refute the halting problem proofs using the x86 model
> of computation is that I can show 100% of every single detail. By
> showing 100% of every single detail false assumptions are refuted by
> verified facts.
>
> All of the other proofs leave out 99.999% of the detail because the TM
> description language is simply far too cumbersome.

If you actually read the proofs, you will note that they don't have to
actually trace out the exection of the Turing Machine, just know that

>
> IT IS THIS SIMPLE PRINCIPLE THAT REFUTES THE HALTING PROBLEM PROOFS:
> Every simulating halt decider correctly simulates its input until it
> correctly determines that this simulated input would never reach its
> final state.

Except you haven't proved the EXISTANCE of such an algorithm.

In fact, your Halt Decider needs a Halt Decider to help it decide when
to Halt.

You want a real infinite recursion, you definition does it.

>
> That same principle applies to the Linz proof:
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy
> If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would reach its own final
> state of ⟨Ĥ.qy⟩ or ⟨Ĥ.qn⟩.

Note, H^.qy is NOT a final state of H^, so your proof is derailed already.

H^.q0 [H^} needs to go to H^.qy if H [H^} [H^} -> qy which implies that
H^.q0 [H^] halted at H^.qn

>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
> If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would never reach its own
> final state of ⟨Ĥ.qy⟩ or ⟨Ĥ.qn⟩.

AGAIN, H^.qy is NOT a final state (H.qy is, but H^ makes it non-final
and never halting).

H^.q0 [H^] needs to go to H^.qn if H [H^] [H^] -> Qn which means that
H^.q0 [H^] did NOT go to H^.qn

Thus if H is correct then

H^ [H^] -> H^.qy (and then loops) if and only if H^ [H^} -> H^.qn, and
H^ [H^] -> H^.qn (and halts) if and only if H^ [H^} NEVER gets to H^.qh

so we hit the contradiction that H^ goes to qn if and only if it never
goes to qn, and never goes to qn only if it actaull goes to qn.

Expalin how that works.

>
>> You say "the proofs". There is at least one other proof than the one
>> you have
>> chosen to drill in on.
>>
>
> All the proofs follow this same template:

That is not ALL the proofs of the Halting Theorem, that is all the
proofs of one type mentioned there.

There ARE others, not of that type, but why let facts get in the way of
your lying.

This is again you committing the fallacy of proof by example.

>      For any program H that might determine if programs halt, a
> "pathological"
>      program P, called with some input, can pass its own 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
>
>> I hope you will share your attempts to define "the x86 language" and "its
>> precise  semantics" with us. I don't think you will be able to do it.
>
> This is already documented in many different places:
> https://c9x.me/x86/
>
> If I was writing a paper on the biology of cows I would not need to tell
> people what a cow is.
>

On 6/29/2022 9:41 AM, Dennis Bush wrote:
> On Wednesday, June 29, 2022 at 10:15:59 AM UTC-4, olcott wrote:
>> On 6/29/2022 8:18 AM, Dennis Bush wrote:
>>> On Wednesday, June 29, 2022 at 9:00:25 AM UTC-4, olcott wrote:
>>>> On 6/29/2022 2:07 AM, dklei...@gmail.com wrote:
>>>>> On Tuesday, June 28, 2022 at 10:03:13 PM UTC-7, olcott wrote:
>>>>>
>>>>>> Here is the new title:
>>>>>> *Halting problem proofs refuted on the basis of software engineering*
>>>>>>
>>>>>> We construe the x86 language as a formal language that corresponds
>>>>>> to its precise semantics.
>>>>>
>>>>> I think your new title should be: The proofs of the Halting Problem for Turing
>>>>> Machines refuted.
>>>>>
>>>> The reason that I refute the halting problem proofs using the x86 model
>>>> of computation is that I can show 100% of every single detail. By
>>>> showing 100% of every single detail false assumptions are refuted by
>>>> verified facts.
>>>>
>>>> All of the other proofs leave out 99.999% of the detail because the TM
>>>> description language is simply far too cumbersome.
>>>>
>>>> IT IS THIS SIMPLE PRINCIPLE THAT REFUTES THE HALTING PROBLEM PROOFS:
>>>> Every simulating halt decider correctly simulates its input until it
>>>> correctly determines that this simulated input would never reach its
>>>> final state.
>>>
>>> In the case of Ha(Pa,Pa) it does not do this. The correctly simulated input to Ha(Pa,Pa), i.e. UTM(Pa,Pa), halts, therefore Ha(Pa,Pa)==0 is wrong.
>> Gullible fools may not be bright enough to spot your strawman deception,
>> I am not a gullible fool.
>> straw man
>> An intentionally misrepresented proposition that is set up because it is
>> easier to defeat than an opponent's real argument.
>> https://www.lexico.com/en/definition/straw_man
>> Ha(Pa,Pa) continues to emulate its input until it determines/predicts
>> that its emulation of this input would never reach the "ret" instruction
>> (final state) of this input.
>
> So because Ha(Pa,Pa) is unable to simulate its input to a final state, Ha(Pa,Pa)==0 is correct?

No that it incorrect. Ha(Pa,Pa) would never reach its "ret" instruction
in any finite number of emulated steps.

>
> Then by that logic, since Ha3(N,5) is unable to simulate its input to a final state, *according to you* Ha3(N,5)==0 is correct. Agreed? If not, then you agree that your above criteria for correctness is invalid.
>
>>
>> When you switch what I just said to a UTM then you are being
>> intentionally deceptive.
>
> Not at all. Since Ha can't do a correct and complete simulation, the input must be given to a UTM to see what the actual correct and complete simulation would be.
>
>>
>> Ha(Pa,Pa) is physically implemented in my code as H(P,P).
>> UTM(Pa,Pa) is physically implemented in my code as H1(P,P).
>>
>> H1 is actually exactly the same as H yet does not have a pathological
>> relationship to P thus merely simulates its input.
>
> It *correctly* simulates its input all the way to a final state, proving that Ha(Pa,Pa)==0 is wrong.
>
>>
>> I claim that H(P,P) correctly determines that its correct and complete
>> x86 emulation of its input never reaches the "ret" instruction of this
>> input.
>
> But since Ha(Pa,Pa) aborts, it doesn't do a correct and complete emulation of its input, so this claim is nonsense.
>
>>
>> Your rebuttal is that because H1(P,P) [a completely different
>> computation] correctly determines that its correct and complete x86
>> emulation of its input reaches the "ret" instruction of this input, I am
>> wrong.
>
> UTM(Pa,Pa) is the *definition* of the correct and complete simulation of the input. and Ha(Pa,Pa) have the same input
>
>>
>> This is the same as I claim that there is a white cat in my kitchen and
>> your rebuttal is that I am wrong there is no black dog in my living room.
>
>
> Yes, because if I ask you if there's a black dog in your living room, telling me that you have a white cat in your kitchen is answering the wrong question.

Every simulating halt decider correctly simulates its input until it
correctly determines that this simulated input would never reach its
final state.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 6/29/2022 9:02 AM, Dennis Bush wrote:
> On Wednesday, June 29, 2022 at 9:44:39 AM UTC-4, olcott wrote:
>> On 6/28/2022 8:44 PM, Dennis Bush wrote:
>>> On Tuesday, June 28, 2022 at 8:08:10 PM UTC-4, olcott wrote:
>>>> On 6/28/2022 4:13 PM, Dennis Bush wrote:
>>>>> On Tuesday, June 28, 2022 at 5:01:29 PM UTC-4, olcott wrote:
>>>>>> On 6/28/2022 3:34 PM, Dennis Bush wrote:
>>>>>>> On Tuesday, June 28, 2022 at 4:30:29 PM UTC-4, olcott wrote:
>>>>>>>> On 6/28/2022 3:27 PM, Dennis Bush wrote:
>>>>>>>>> On Tuesday, June 28, 2022 at 4:22:23 PM UTC-4, olcott wrote:
>>>>>>>>>> On 6/28/2022 3:02 PM, Dennis Bush wrote:
>>>>>>>>>>> On Tuesday, June 28, 2022 at 3:44:30 PM UTC-4, olcott wrote:
>>>>>>>>>>>> On 6/28/2022 10:03 AM, Dennis Bush wrote:
>>>>>>>>>>>>> On Tuesday, June 28, 2022 at 10:47:01 AM UTC-4, olcott wrote:
>>>>>>>>>>>>>> On 6/28/2022 9:22 AM, Dennis Bush wrote:
>>>>>>>>>>>>>>> On Tuesday, June 28, 2022 at 10:14:33 AM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>> On 6/27/2022 5:03 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 5:58:55 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>> On 6/27/2022 4:46 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 5:38:02 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 6/27/2022 4:14 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 5:11:30 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>> On 6/27/2022 4:02 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 4:52:17 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 6/27/2022 2:45 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 2:13:44 PM UTC-4, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 2:11:45 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/27/2022 1:03 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 1:20:39 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/27/2022 12:03 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 9:28:22 AM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/27/2022 7:58 AM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 8:50:05 AM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/27/2022 7:40 AM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 8:34:22 AM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/27/2022 7:26 AM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 8:14:31 AM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/27/2022 6:57 AM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 7:11:21 AM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> *This is the outline of the complete refutation*
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> *of the only rebuttal that anyone has left*
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (a) The complete and correct x86 emulation of the input to H(P,P) by H
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> never reaches the "ret" instruction of P.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It is known that H aborts its simulation and returns 0. That means that H *by definition* does not perform a complete and correct emulation. And since H (if it was constructed correctly) is a pure function of its inputs, it will ALWAYS return the same return for a given input.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> To state that H aborts *and* does a complete and correct simulation is simply nonsense.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> What *does* perform a complete and correct emulation of the input to H(P,P) is UTM(P,P) which halts, therefore H(P,P)==0 is wrong.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (b) The direct execution of P(P) does reach its "ret" instruction.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The above two are proven to be verified facts entirely on the basis of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the semantics of the x86 language.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> A nonsense statement can't be a "fact", verified or otherwise.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> A halt decider must compute the mapping from its inputs to an accept or
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reject state on the basis of the actual behavior that is actually
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> specified by these inputs.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Which for H(P,P) is BY DEFINITION is the behavior of P(P). The halting problem says that H MUST implement the following mapping (i.e. the halting function):
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H(x,y)==1 if and only if x(y) halts, and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H(x,y)==0 if and only if x(y) does not halt.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H does not perform this mapping.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> P(P) is provably not the actual behavior of the actual input.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It is BY DEFINITION. So if H comes up with something different that means it did something wrong, specifically it aborted a halting computation too soon.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> void P(u32 x)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> if (H(x, x))
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> P(P);
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> _P()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f0](01) 55 push ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f1](02) 8bec mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f3](03) 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f6](01) 50 push eax
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f7](03) 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011fa](01) 51 push ecx
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011fb](05) e820feffff call 00001020
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001200](03) 83c408 add esp,+08
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001203](02) 85c0 test eax,eax
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001205](02) 7402 jz 00001209
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001207](02) ebfe jmp 00001207
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001209](01) 5d pop ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [0000120a](01) c3 ret
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Size in bytes:(0027) [0000120a]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> _main()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001210](01) 55 push ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001211](02) 8bec mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001213](05) 68f0110000 push 000011f0
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001218](05) e8d3ffffff call 000011f0
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [0000121d](03) 83c404 add esp,+04
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001220](02) 33c0 xor eax,eax
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001222](01) 5d pop ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001223](01) c3 ret
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Size in bytes:(0020) [00001223]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> machine stack stack machine assembly
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> address address data code language
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ======== ======== ======== ========= =============
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001210][00101fba][00000000] 55 push ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001211][00101fba][00000000] 8bec mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001213][00101fb6][000011f0] 68f0110000 push 000011f0 // push P
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001218][00101fb2][0000121d] e8d3ffffff call 000011f0 // call P
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f0][00101fae][00101fba] 55 push ebp // enter executed P
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f1][00101fae][00101fba] 8bec mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f3][00101fae][00101fba] 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f6][00101faa][000011f0] 50 push eax // push P
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f7][00101faa][000011f0] 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011fa][00101fa6][000011f0] 51 push ecx // push P
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011fb][00101fa2][00001200] e820feffff call 00001020 // call H
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Begin Simulation Execution Trace Stored at:21206e
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Address_of_H:1020
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f0][0021205a][0021205e] 55 push ebp // enter emulated P
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f1][0021205a][0021205e] 8bec mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f3][0021205a][0021205e] 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f6][00212056][000011f0] 50 push eax // push P
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f7][00212056][000011f0] 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011fa][00212052][000011f0] 51 push ecx // push P
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011fb][0021204e][00001200] e820feffff call 00001020 // call emulated H
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Infinitely Recursive Simulation Detected Simulation Stopped
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H knows its own machine address and on this basis it can easily
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> examine its stored execution_trace of P (see above) to determine:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (a) P is calling H with the same arguments that H was called with.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (b) No instructions in P could possibly escape this otherwise infinitely
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> recursive emulation.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> FALSE. P contains these instructions:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> if (Decide_Halting(&execution_trace, &decoded, code_end, &master_state,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> &slave_state, &slave_stack, Address_of_H, P, I))
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> goto END_OF_CODE;
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> return 0; // Does not halt
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> END_OF_CODE:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> return 1; // Input has normally terminated
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> That *can* and *do* prevent infinite recursive emulation in a *correct* and *complete* emulation
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (c) H aborts its emulation of P before its call to H is emulated.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> And in doing so it fails to see that the call to H, since H is a computation, will aborts *its* simulation of P and return 0 to the outer P being emulated, which would cause it to halt, making H(P,P)==0 wrong.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001200][00101fae][00101fba] 83c408 add esp,+08 // return to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> executed P
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001203][00101fae][00101fba] 85c0 test eax,eax
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001205][00101fae][00101fba] 7402 jz 00001209
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001209][00101fb2][0000121d] 5d pop ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [0000120a][00101fb6][000011f0] c3 ret // return from
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> executed P
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [0000121d][00101fba][00000000] 83c404 add esp,+04
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001220][00101fba][00000000] 33c0 xor eax,eax
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001222][00101fbe][00100000] 5d pop ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001223][00101fc2][00000000] c3 ret // ret from main
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Number of Instructions Executed(878) / 67 = 13 pages
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I've stated in detail why you're wrong. Now you need to explain in detail why I'm wrong.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Failure to do so, which includes simply restating your original point, will be taken as admission that what I've stated is correct.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H correctly predicts that its complete and correct x86 emulation of its
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> input never reaches the the "ret" instruction of P.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Repeating your original point.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> This is the actual behavior of the input to H(P,P).
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> P(P) is not the actual behavior of the input to H(P,P).
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Again, repeating your original point.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Never reaching the "ret" instruction means that P does not halt.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> A halt decider must compute the mapping from its inputs to an accept or
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reject state on the basis of the actual behavior that is actually
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> specified by these inputs.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Therefore H(P,P)==0 is correct.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> And again, repeating your original point.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> So no explanation as to why I'm wrong, just a repetition of your original points.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> That means you accept that what I've said is true, and that H(P,P)==0 is wrong.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You rebuttal is based on rejecting the verified fact that a simulating
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> halt decider correctly predicts that its correctly simulated input will
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> never reach the final state "ret" instruction of this input.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> FALSE. The correctly simulated input to H(P,P) is UTM(P,P) which halts, therefore H(P,P)==0 is wrong.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> First of all I am not talking about UTM's.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I am talking about x86 emulation.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Try to encode what you mean, here is my guess:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> void P(u32 x)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> if (emulate_x86(x, x))
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> P is a computation and therefore it can't be changed, nor can anything that it calls. I mean UTM(P,P). The simplest way to implement this is:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> void UTM(u32 x, u32 y)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> x(y)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H cannot by definition perform a correct and complete emulation if it aborts, so the input must be passed to something that does, i.e. a UTM, for the source of truth.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> A simulating halt decider correctly simulates its input until it
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> correctly determines that this simulated input would never reach its
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> final state.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> But H isn't such a decider, because the simulated input does reach a final state when correctly simulated, i.e. by UTM(P,P), therefore H(P,P)==0 is wrong.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Every simulating decider that correctly simulates its input until it
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> correctly determines that this simulated input would never reach its
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> final state correctly determines the halt status of this input.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> And H isn't such a decider, because it does not correctly determine that the input to H(P,P) would never halt as demonstrated by UTM(P,P) halting.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> The specification for H:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> H(x,y)==0 if and only if x(y) does not halt, and
>>>>>>>>>>>>>>>>>>>>>>>>>>>> H(x,y)==1 if and only if x(y) halts.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> H does not meet the specification.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> The spec is provably incorrect in this case:
>>>>>>>>>>>>>>>>>>>>>>>>>> A spec can't be incorrect. It just is. If it can't be satisfied, then that validates the halting problem proofs that say it can't be satisfied.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> No response to this I see. So you agree that your H does not meet the above spec that the halting problem requires?
>>>>>>>>>>>>>>>>>>>>>>>> You are just playing word games so I will use a different word:
>>>>>>>>>>>>>>>>>>>>>>>> "criterion measure".
>>>>>>>>>>>>>>>>>>>>>>>> A halt decider must compute the mapping from its inputs to an accept or
>>>>>>>>>>>>>>>>>>>>>>>> reject state on the basis of the actual behavior that is actually
>>>>>>>>>>>>>>>>>>>>>>>> specified by these inputs.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> As per this specification:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> H(x,y)==0 if and only if x(y) does not halt, and
>>>>>>>>>>>>>>>>>>>>>>> H(x,y)==1 if and only if x(y) halts
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Which means the actual behavior of the actual input to H(P,P) is defined to be the behavior of P(P).
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Remember, the halting problem is ultimately about algorithms, not some simulator's simulation of it.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> This also means that if the result of H(P,P) doesn't match the behavior of P(P) then H is wrong by definition.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> P(P) is provably not the actual behavior of the actual input,
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> If you mean that H(P,P) can't simulate its input to a final state, then any simulator that aborts its input for any reason is necessarily correct, which is clearly nonsense.
>>>>>>>>>>>>>>>>>>>>>> The formal mathematical semantics of the x86 language conclusively
>>>>>>>>>>>>>>>>>>>>>> proves that P(P) is not the actual behavior of the actual input to H(P,P).
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> UTM(P,P) halting proves otherwise, demonstrating that H aborted its simulation too soon.
>>>>>>>>>>>>>>>>>>>> BUSTED!
>>>>>>>>>>>>>>>>>>>> I GOT YOU NOW!
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> How many recursive emulations does H need to wait before its emulated P
>>>>>>>>>>>>>>>>>>>> to reaches its final instruction?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Since H has a fixed algorithm (which we'll refer to as Ha, and the P that calls it we'll refer to as Pa to make that point clear) to to stop after N recursive emulations, it would need to simulate for N+1 emulations. But its fixed algorithm prevents it from simulating any more than N emulations.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> "H aborted its simulation too soon."
>>>>>>>>>>>>>>>>>> Liar liar pants on fire.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> PO-speak for "I know you proved me wrong and I don't know what else to say"
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> It is PO-speak for I just proved that you are lying:
>>>>>>>>>>>>>>>> On 6/27/2022 4:14 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>> demonstrating that H aborted its simulation too soon.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> How many recursive emulations must H(P,P) emulate its input until its
>>>>>>>>>>>>>>>> emulated input reaches the "ret" instruction of the emulated P?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The fixed algorithm of H, which we'll refer to as Ha and the P that calls it we'll refer to as Pa, simulates for N recursive emulations. Therefore the input must be simulated for N+1 recursive emulations. The fixed algorthm Ha is unable to simulate for this many cycles and therefore gets the wrong answer.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *Because I boxed you into a corner* you are finally implicitly admitting
>>>>>>>>>>>>>> that there is no integer value N number of cycles of recursive emulation
>>>>>>>>>>>>>> that H(P,P) can emulate its input such that the emulated P reaches its
>>>>>>>>>>>>>> final state "ret" instruction.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I already told you: N+1 cycles for Pa which is built on Ha.
>>>>>>>>>>>>>
>>>>>>>>>>>> I am asking for the exact integer value of N in (numeric digits) and you
>>>>>>>>>>>> consistently refuse to provide it because you know that it does not exist.
>>>>>>>>>>>
>>>>>>>>>>> I don't know the exact value because you haven't shown the full code of Ha. So assuming that Ha simulates for N iterations, then it takes N+1 iterations to reach a final state. And the fixed algorithm of Ha is unable to simulate for N+1 iterations, but UTM is.
>>>>>>>>>> So you are saying that when the emulated input to H(P,P) is emulated by
>>>>>>>>>> H that this emulated input reaches its final state just after its
>>>>>>>>>> emulation has been aborted?
>>>>>>>>>
>>>>>>>>> I'm saying that the emulated input to Ha(Pa,Pa) is aborted one iteration too soon.
>>>>>>>> Which necessitates that there is a finite integer number of recursive
>>>>>>>> emulations that is not too soon. What are the numeric digits of this
>>>>>>>> integer?
>>>>>>>
>>>>>>> Since you haven't told me how many iterations Ha simulates for, I'm going to assume that it simulates for 1 iteration. That means Pa(Pa) must be simulated for 2 iterations. But since Ha only simulates for 1 iteration, Ha(Pa,Pa)==0 is wrong because it aborted too soon.
>>>>>> You are still saying the an aborted emulation keeps running after it has
>>>>>> been aborted. I am not asking when some P reaches its "ret" instruction.
>>>>>
>>>>> I'm saying that the machine that the input represents continues to run past the point where Ha aborts its simulation to a final state, proving that Ha(Pa,Pa)==0 is wrong.
>>>>>
>>>>>>
>>>>>> I am asking when does the emulated input to H(P,P) that H emulates
>>>>>> reaches its "ret" instruction.
>>>>>> void P(u32 x)
>>>>>> {
>>>>>> if (H(x, x))
>>>>>> HERE: goto HERE;
>>>>>> return;
>>>>>> }
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>> Output("Input_Halts = ", Emulate_x86((u32)P, (u32)P));
>>>>>> }
>>>>>
>>>>> If you're asking if Ha(Pa,Pa) is able to simulate it's input to a final state, it can't. So you're saying that alone makes it correct?
>>>>>
>>>>
>>>> THIS MAKES Ha(Pa,Pa)==0 CORRECT:
>>>> I am saying that Ha(Pa,Pa) correctly determines/predicts that its
>>>> complete and correct x86 emulation of its input would never reach the
>>>> "ret" instruction of Pa.
>>>
>>> But Ha doesn't do a correct and complete simulation. It aborts. So to say what the correct and complete simulation of the input by Ha would do makes no sense.
>> Every simulating halt decider correctly simulates its input until it
>> correctly determines that this simulated input would never reach its
>> final state.
>> I don't know why you keep making the ridiculous assertion that a
>> simulating halt decider cannot possibly predict/determine that its
>> complete and correct x86 emulation of its input would never reach the
>> "ret" instruction of this input.
>
> But Ha doesn't *do* a complete and correct emulation of its input as per its fixed algorithm, so to say what the complete and correct emulation of the input to Ha(Pa,Pa) by Ha is, is simply nonsense.