On Thursday, June 30, 2022 at 12:59:38 AM UTC-4, olcott wrote:
> On 6/29/2022 11:51 PM, Dennis Bush wrote:
> > On Thursday, June 30, 2022 at 12:42:59 AM 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:
> >
> >>>> 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
> >
> > Which does not exist because Ha aborts and therefore does not do a complete and correct x86 emulation.
> We are taking that what you are saying means that you believe it is
> impossible for H to correctly determine that Infinite_Loop() never halts.

No, you're saying that the correctness criteria for Ha(Pa,Pa) is a complete and correct emulation of the input *by Ha*. And because Ha has a fixed algorithm that aborts, Ha does not do a complete and correct emulation of the input.

And because Ha does not do a complete and correct emulation of the input, what I'm saying is that your correctness criteria simply doesn't exist.

On 6/30/2022 7:12 AM, Dennis Bush wrote:
> On Thursday, June 30, 2022 at 12:59:38 AM UTC-4, olcott wrote:
>> On 6/29/2022 11:51 PM, Dennis Bush wrote:
>>> On Thursday, June 30, 2022 at 12:42:59 AM 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:
>>>
>>>>>> 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
>>>
>>> Which does not exist because Ha aborts and therefore does not do a complete and correct x86 emulation.
>> We are taking that what you are saying means that you believe it is
>> impossible for H to correctly determine that Infinite_Loop() never halts.
>
> No, you're saying that the correctness criteria for Ha(Pa,Pa) is a complete and correct emulation of the input *by Ha*. And because Ha has a fixed algorithm that aborts, Ha does not do a complete and correct emulation of the input.
>
> And because Ha does not do a complete and correct emulation of the input, what I'm saying is that your correctness criteria simply doesn't exist.
>

That is a Jackass (deceptive head games) thing to say when you already
know that H merely needs to correctly predict what the complete and
correct x86 emulation of its input would do and it need not actually to
a complete emulation to do this. EXAMPLE BELOW

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

--
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 Thursday, June 30, 2022 at 11:36:43 AM UTC-4, olcott wrote:
> On 6/30/2022 7:12 AM, Dennis Bush wrote:
> > On Thursday, June 30, 2022 at 12:59:38 AM UTC-4, olcott wrote:
> >> On 6/29/2022 11:51 PM, Dennis Bush wrote:
> >>> On Thursday, June 30, 2022 at 12:42:59 AM 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:
> >>>
> >>>>>> 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
> >>>
> >>> Which does not exist because Ha aborts and therefore does not do a complete and correct x86 emulation.
> >> We are taking that what you are saying means that you believe it is
> >> impossible for H to correctly determine that Infinite_Loop() never halts.
> >
> > No, you're saying that the correctness criteria for Ha(Pa,Pa) is a complete and correct emulation of the input *by Ha*. And because Ha has a fixed algorithm that aborts, Ha does not do a complete and correct emulation of the input.
> >
> > And because Ha does not do a complete and correct emulation of the input, what I'm saying is that your correctness criteria simply doesn't exist.
> >
> That is a Jackass (deceptive head games) thing to say when you already
> know that H merely needs to correctly predict what the complete and
> correct x86 emulation of its input would do and it need not actually to
> a complete emulation to do this. EXAMPLE BELOW

*The* complete and correct emulation of the input to Ha(Pa,Pa) is performed by UTM(Pa,Pa) which halts, proving that Ha(Pa,Pa)==0 is wrong.

On 6/30/2022 10:40 AM, Dennis Bush wrote:
> On Thursday, June 30, 2022 at 11:36:43 AM UTC-4, olcott wrote:
>> On 6/30/2022 7:12 AM, Dennis Bush wrote:
>>> On Thursday, June 30, 2022 at 12:59:38 AM UTC-4, olcott wrote:
>>>> On 6/29/2022 11:51 PM, Dennis Bush wrote:
>>>>> On Thursday, June 30, 2022 at 12:42:59 AM 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:
>>>>>
>>>>>>>> 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
>>>>>
>>>>> Which does not exist because Ha aborts and therefore does not do a complete and correct x86 emulation.
>>>> We are taking that what you are saying means that you believe it is
>>>> impossible for H to correctly determine that Infinite_Loop() never halts.
>>>
>>> No, you're saying that the correctness criteria for Ha(Pa,Pa) is a complete and correct emulation of the input *by Ha*. And because Ha has a fixed algorithm that aborts, Ha does not do a complete and correct emulation of the input.
>>>
>>> And because Ha does not do a complete and correct emulation of the input, what I'm saying is that your correctness criteria simply doesn't exist.
>>>
>> That is a Jackass (deceptive head games) thing to say when you already
>> know that H merely needs to correctly predict what the complete and
>> correct x86 emulation of its input would do and it need not actually to
>> a complete emulation to do this. EXAMPLE BELOW
>
> *The* complete and correct emulation of the input to Ha(Pa,Pa) is performed by UTM(Pa,Pa) which halts, proving that Ha(Pa,Pa)==0 is wrong.

The part that you keep erasing proves that you are a liar.
You keep erasing it because you know that it proves you are a liar.

Changing the subject to a completely different computation UTM(Pa,Pa)
than the actual computation Ha(Pa,Pa) is the strawman deception.

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

THIS IS NECESSARILY TRUE THUS IMPOSSIBLY FALSE
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 Thursday, June 30, 2022 at 12:15:58 PM UTC-4, olcott wrote:
> On 6/30/2022 10:40 AM, Dennis Bush wrote:
> > On Thursday, June 30, 2022 at 11:36:43 AM UTC-4, olcott wrote:
> >> On 6/30/2022 7:12 AM, Dennis Bush wrote:
> >>> On Thursday, June 30, 2022 at 12:59:38 AM UTC-4, olcott wrote:
> >>>> On 6/29/2022 11:51 PM, Dennis Bush wrote:
> >>>>> On Thursday, June 30, 2022 at 12:42:59 AM 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:
> >>>>>
> >>>>>>>> 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
> >>>>>
> >>>>> Which does not exist because Ha aborts and therefore does not do a complete and correct x86 emulation.
> >>>> We are taking that what you are saying means that you believe it is
> >>>> impossible for H to correctly determine that Infinite_Loop() never halts.
> >>>
> >>> No, you're saying that the correctness criteria for Ha(Pa,Pa) is a complete and correct emulation of the input *by Ha*. And because Ha has a fixed algorithm that aborts, Ha does not do a complete and correct emulation of the input.
> >>>
> >>> And because Ha does not do a complete and correct emulation of the input, what I'm saying is that your correctness criteria simply doesn't exist..
> >>>
> >> That is a Jackass (deceptive head games) thing to say when you already
> >> know that H merely needs to correctly predict what the complete and
> >> correct x86 emulation of its input would do and it need not actually to
> >> a complete emulation to do this. EXAMPLE BELOW
> >
> > *The* complete and correct emulation of the input to Ha(Pa,Pa) is performed by UTM(Pa,Pa) which halts, proving that Ha(Pa,Pa)==0 is wrong.
> The part that you keep erasing proves that you are a liar.
> You keep erasing it because you know that it proves you are a liar.

Infinite_Loop was previously shown to be irrelevant.

>
> Changing the subject to a completely different computation UTM(Pa,Pa)
> than the actual computation Ha(Pa,Pa) is the strawman deception.
> 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

I'm not changing the subject. I'm just going by what you're saying.

> THIS IS NECESSARILY TRUE THUS IMPOSSIBLY FALSE
> Every simulating halt decider correctly simulates its input until it
> correctly determines that this simulated input would never reach its
> final state.

You keep changing this part. Sometimes you say "the" simulated input, sometimes "its" simulated input, sometimes "this" simulated input.

*The* complete and correct simulation of the input to Ha(Pa,Pa) is by definition performed by UTM(Pa,Pa). This simulation halts, which proves that Ha(Pa,Pa)==0 is wrong.

*It's* complete and correct simulation of the input to Ha(Pa,Pa) (i.e. one performed by Ha) does not exist because the fixed algorithm of Ha does not perform a complete and correct simulation. So there's no baseline to dictate what the right answer is.

When you say *this* simulated input would never reach its final state, you're saying that Ha(Pa,Pa) reports whether or not it is able to simulate its input to completion. This criteria means that any simulating halt decider that aborts its input and returns 0 is necessarily correct. And it's this logic that says that Ha3(N,5)==0 is correct, and also says that Ha0(x,y)==0 is correct for *all* x and y where Ha0 simulates for 0 steps. That conclusion is obviously incorrect, which means this criteria is invalid.

So no matter which way you read it, Ha(Pa,Pa)==0 is wrong. As Richard likes to say, choose which way you are wrong.

On Thu, 30 Jun 2022 09:34:49 -0700 (PDT)
Dennis Bush <dbush.mobile@gmail.com> wrote:

> On Thursday, June 30, 2022 at 12:15:58 PM UTC-4, olcott wrote:
> > On 6/30/2022 10:40 AM, Dennis Bush wrote:
> > > On Thursday, June 30, 2022 at 11:36:43 AM UTC-4, olcott wrote:
> > >> On 6/30/2022 7:12 AM, Dennis Bush wrote:
> > >>> On Thursday, June 30, 2022 at 12:59:38 AM UTC-4, olcott wrote:
> > >>>
> > >>>> On 6/29/2022 11:51 PM, Dennis Bush wrote:
> > >>>>> On Thursday, June 30, 2022 at 12:42:59 AM 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:
> > >>>>>
> > >>>>>>>> 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
> > >>>>>
> > >>>>> Which does not exist because Ha aborts and therefore does not
> > >>>>> do a complete and correct x86 emulation.
> > >>>> We are taking that what you are saying means that you believe
> > >>>> it is impossible for H to correctly determine that
> > >>>> Infinite_Loop() never halts.
> > >>>
> > >>> No, you're saying that the correctness criteria for Ha(Pa,Pa)
> > >>> is a complete and correct emulation of the input *by Ha*. And
> > >>> because Ha has a fixed algorithm that aborts, Ha does not do a
> > >>> complete and correct emulation of the input.
> > >>>
> > >>> And because Ha does not do a complete and correct emulation of
> > >>> the input, what I'm saying is that your correctness criteria
> > >>> simply doesn't exist.
> > >> That is a Jackass (deceptive head games) thing to say when you
> > >> already know that H merely needs to correctly predict what the
> > >> complete and correct x86 emulation of its input would do and it
> > >> need not actually to a complete emulation to do this. EXAMPLE
> > >> BELOW
> > >
> > > *The* complete and correct emulation of the input to Ha(Pa,Pa) is
> > > performed by UTM(Pa,Pa) which halts, proving that Ha(Pa,Pa)==0 is
> > > wrong.
> > The part that you keep erasing proves that you are a liar.
> > You keep erasing it because you know that it proves you are a liar.
> >
>
> Infinite_Loop was previously shown to be irrelevant.
>
> >
> > Changing the subject to a completely different computation
> > UTM(Pa,Pa) than the actual computation Ha(Pa,Pa) is the strawman
> > deception. 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
>
> I'm not changing the subject. I'm just going by what you're saying.
>
> > THIS IS NECESSARILY TRUE THUS IMPOSSIBLY FALSE
> > Every simulating halt decider correctly simulates its input until
> > it correctly determines that this simulated input would never reach
> > its final state.
>
> You keep changing this part. Sometimes you say "the" simulated
> input, sometimes "its" simulated input, sometimes "this" simulated
> input.
>
> *The* complete and correct simulation of the input to Ha(Pa,Pa) is by
> definition performed by UTM(Pa,Pa). This simulation halts, which
> proves that Ha(Pa,Pa)==0 is wrong.
>
> *It's* complete and correct simulation of the input to Ha(Pa,Pa)
> (i.e. one performed by Ha) does not exist because the fixed algorithm
> of Ha does not perform a complete and correct simulation. So there's
> no baseline to dictate what the right answer is.
>
> When you say *this* simulated input would never reach its final
> state, you're saying that Ha(Pa,Pa) reports whether or not it is able
> to simulate its input to completion. This criteria means that any
> simulating halt decider that aborts its input and returns 0 is
> necessarily correct. And it's this logic that says that Ha3(N,5)==0
> is correct, and also says that Ha0(x,y)==0 is correct for *all* x and
> y where Ha0 simulates for 0 steps. That conclusion is obviously
> incorrect, which means this criteria is invalid.
>
> So no matter which way you read it, Ha(Pa,Pa)==0 is wrong. As
> Richard likes to say, choose which way you are wrong.
Olcott already lost the argument with Richard when he blocked him:
blocking someone is admitting defeat.

/Flibble

On 6/30/2022 11:34 AM, Dennis Bush wrote:
> On Thursday, June 30, 2022 at 12:15:58 PM UTC-4, olcott wrote:
>> On 6/30/2022 10:40 AM, Dennis Bush wrote:
>>> On Thursday, June 30, 2022 at 11:36:43 AM UTC-4, olcott wrote:
>>>> On 6/30/2022 7:12 AM, Dennis Bush wrote:
>>>>> On Thursday, June 30, 2022 at 12:59:38 AM UTC-4, olcott wrote:
>>>>>> On 6/29/2022 11:51 PM, Dennis Bush wrote:
>>>>>>> On Thursday, June 30, 2022 at 12:42:59 AM 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:
>>>>>>>
>>>>>>>>>> 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
>>>>>>>
>>>>>>> Which does not exist because Ha aborts and therefore does not do a complete and correct x86 emulation.
>>>>>> We are taking that what you are saying means that you believe it is
>>>>>> impossible for H to correctly determine that Infinite_Loop() never halts.
>>>>>
>>>>> No, you're saying that the correctness criteria for Ha(Pa,Pa) is a complete and correct emulation of the input *by Ha*. And because Ha has a fixed algorithm that aborts, Ha does not do a complete and correct emulation of the input.
>>>>>
>>>>> And because Ha does not do a complete and correct emulation of the input, what I'm saying is that your correctness criteria simply doesn't exist.
>>>>>
>>>> That is a Jackass (deceptive head games) thing to say when you already
>>>> know that H merely needs to correctly predict what the complete and
>>>> correct x86 emulation of its input would do and it need not actually to
>>>> a complete emulation to do this. EXAMPLE BELOW
>>>
>>> *The* complete and correct emulation of the input to Ha(Pa,Pa) is performed by UTM(Pa,Pa) which halts, proving that Ha(Pa,Pa)==0 is wrong.
>> The part that you keep erasing proves that you are a liar.
>> You keep erasing it because you know that it proves you are a liar.
>
> Infinite_Loop was previously shown to be irrelevant.
>
>>
>> Changing the subject to a completely different computation UTM(Pa,Pa)
>> than the actual computation Ha(Pa,Pa) is the strawman deception.
>> 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
>
> I'm not changing the subject. I'm just going by what you're saying.
>
>> THIS IS NECESSARILY TRUE THUS IMPOSSIBLY FALSE
>> Every simulating halt decider correctly simulates its input until it
>> correctly determines that this simulated input would never reach its
>> final state.
>
> You keep changing this part. Sometimes you say "the" simulated input, sometimes "its" simulated input, sometimes "this" simulated input.
>
> *The* complete and correct simulation of the input to Ha(Pa,Pa) is by definition performed by UTM(Pa,Pa).

That is a lie and you know it.

The actual behavior of the actual input to H(P,P) is conclusively proven
to diverge from the actual behavior of the actual input to H1(P,P) on
the basis of the semantics of the x86 language.

H1(P,P) *is* UTM(P,P) in this case because H1 never aborts its x86
emulation of its input.

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

int main()
{ Output("Input_Halts = ", H1((u32)P, (u32)P));
}

_P()
[0000163a](01) 55 push ebp
[0000163b](02) 8bec mov ebp,esp
[0000163d](03) 8b4508 mov eax,[ebp+08]
[00001640](01) 50 push eax
[00001641](03) 8b4d08 mov ecx,[ebp+08]
[00001644](01) 51 push ecx
[00001645](05) e8f0fdffff call 0000143a // call H
[0000164a](03) 83c408 add esp,+08
[0000164d](02) 85c0 test eax,eax
[0000164f](02) 7402 jz 00001653
[00001651](02) ebfe jmp 00001651
[00001653](01) 5d pop ebp
[00001654](01) c3 ret
Size in bytes:(0027) [00001654]

_main()
[0000165a](01) 55 push ebp
[0000165b](02) 8bec mov ebp,esp
[0000165d](05) 683a160000 push 0000163a // push P
[00001662](05) 683a160000 push 0000163a // push P
[00001667](05) e8cef9ffff call 0000103a // call H1
[0000166c](03) 83c408 add esp,+08
[0000166f](01) 50 push eax // push return value
[00001670](05) 689b040000 push 0000049b // "Input_Halts = "
[00001675](05) e870eeffff call 000004ea // call Output
[0000167a](03) 83c408 add esp,+08
[0000167d](02) 33c0 xor eax,eax
[0000167f](01) 5d pop ebp
[00001680](01) c3 ret
Size in bytes:(0039) [00001680]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[0000165a][001026a9][00000000] 55 push ebp
[0000165b][001026a9][00000000] 8bec mov ebp,esp
[0000165d][001026a5][0000163a] 683a160000 push 0000163a // push P
[00001662][001026a1][0000163a] 683a160000 push 0000163a // push P
[00001667][0010269d][0000166c] e8cef9ffff call 0000103a // call H1

H1: Begin Simulation Execution Trace Stored at:21275d
Address_of_H1:103a
[0000163a][00212749][0021274d] 55 push ebp
[0000163b][00212749][0021274d] 8bec mov ebp,esp
[0000163d][00212749][0021274d] 8b4508 mov eax,[ebp+08]
[00001640][00212745][0000163a] 50 push eax // push P
[00001641][00212745][0000163a] 8b4d08 mov ecx,[ebp+08]
[00001644][00212741][0000163a] 51 push ecx // push P
[00001645][0021273d][0000164a] e8f0fdffff call 0000143a // call H

H: Begin Simulation Execution Trace Stored at:2285c5
Address_of_H:143a
[0000163a][002285b1][002285b5] 55 push ebp
[0000163b][002285b1][002285b5] 8bec mov ebp,esp
[0000163d][002285b1][002285b5] 8b4508 mov eax,[ebp+08]
[00001640][002285ad][0000163a] 50 push eax // push P
[00001641][002285ad][0000163a] 8b4d08 mov ecx,[ebp+08]
[00001644][002285a9][0000163a] 51 push ecx // push P
[00001645][002285a5][0000164a] e8f0fdffff call 0000143a // call H
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.

[0000164a][00212749][0021274d] 83c408 add esp,+08
[0000164d][00212749][0021274d] 85c0 test eax,eax
[0000164f][00212749][0021274d] 7402 jz 00001653
[00001653][0021274d][0000111e] 5d pop ebp
[00001654][00212751][0000163a] c3 ret
H1: End Simulation Input Terminated Normally

[0000166c][001026a9][00000000] 83c408 add esp,+08
[0000166f][001026a5][00000001] 50 push eax // return value
[00001670][001026a1][0000049b] 689b040000 push 0000049b // "Input_Halts = "
[00001675][001026a1][0000049b] e870eeffff call 000004ea // call Output
Input_Halts = 1
[0000167a][001026a9][00000000] 83c408 add esp,+08
[0000167d][001026a9][00000000] 33c0 xor eax,eax
[0000167f][001026ad][00100000] 5d pop ebp
[00001680][001026b1][00000004] c3 ret
Number of Instructions Executed(409590) == 6113 Pages

--
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/30/2022 11:36 AM, Mr Flibble wrote:
> On Thu, 30 Jun 2022 09:34:49 -0700 (PDT)
> Dennis Bush <dbush.mobile@gmail.com> wrote:
>
>> On Thursday, June 30, 2022 at 12:15:58 PM UTC-4, olcott wrote:
>>> On 6/30/2022 10:40 AM, Dennis Bush wrote:
>>>> On Thursday, June 30, 2022 at 11:36:43 AM UTC-4, olcott wrote:
>>>>> On 6/30/2022 7:12 AM, Dennis Bush wrote:
>>>>>> On Thursday, June 30, 2022 at 12:59:38 AM UTC-4, olcott wrote:
>>>>>>
>>>>>>> On 6/29/2022 11:51 PM, Dennis Bush wrote:
>>>>>>>> On Thursday, June 30, 2022 at 12:42:59 AM 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:
>>>>>>>>
>>>>>>>>>>> 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
>>>>>>>>
>>>>>>>> Which does not exist because Ha aborts and therefore does not
>>>>>>>> do a complete and correct x86 emulation.
>>>>>>> We are taking that what you are saying means that you believe
>>>>>>> it is impossible for H to correctly determine that
>>>>>>> Infinite_Loop() never halts.
>>>>>>
>>>>>> No, you're saying that the correctness criteria for Ha(Pa,Pa)
>>>>>> is a complete and correct emulation of the input *by Ha*. And
>>>>>> because Ha has a fixed algorithm that aborts, Ha does not do a
>>>>>> complete and correct emulation of the input.
>>>>>>
>>>>>> And because Ha does not do a complete and correct emulation of
>>>>>> the input, what I'm saying is that your correctness criteria
>>>>>> simply doesn't exist.
>>>>> That is a Jackass (deceptive head games) thing to say when you
>>>>> already know that H merely needs to correctly predict what the
>>>>> complete and correct x86 emulation of its input would do and it
>>>>> need not actually to a complete emulation to do this. EXAMPLE
>>>>> BELOW
>>>>
>>>> *The* complete and correct emulation of the input to Ha(Pa,Pa) is
>>>> performed by UTM(Pa,Pa) which halts, proving that Ha(Pa,Pa)==0 is
>>>> wrong.
>>> The part that you keep erasing proves that you are a liar.
>>> You keep erasing it because you know that it proves you are a liar.
>>>
>>
>> Infinite_Loop was previously shown to be irrelevant.
>>
>>>
>>> Changing the subject to a completely different computation
>>> UTM(Pa,Pa) than the actual computation Ha(Pa,Pa) is the strawman
>>> deception. 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
>>
>> I'm not changing the subject. I'm just going by what you're saying.
>>
>>> THIS IS NECESSARILY TRUE THUS IMPOSSIBLY FALSE
>>> Every simulating halt decider correctly simulates its input until
>>> it correctly determines that this simulated input would never reach
>>> its final state.
>>
>> You keep changing this part. Sometimes you say "the" simulated
>> input, sometimes "its" simulated input, sometimes "this" simulated
>> input.
>>
>> *The* complete and correct simulation of the input to Ha(Pa,Pa) is by
>> definition performed by UTM(Pa,Pa). This simulation halts, which
>> proves that Ha(Pa,Pa)==0 is wrong.
>>
>> *It's* complete and correct simulation of the input to Ha(Pa,Pa)
>> (i.e. one performed by Ha) does not exist because the fixed algorithm
>> of Ha does not perform a complete and correct simulation. So there's
>> no baseline to dictate what the right answer is.
>>
>> When you say *this* simulated input would never reach its final
>> state, you're saying that Ha(Pa,Pa) reports whether or not it is able
>> to simulate its input to completion. This criteria means that any
>> simulating halt decider that aborts its input and returns 0 is
>> necessarily correct. And it's this logic that says that Ha3(N,5)==0
>> is correct, and also says that Ha0(x,y)==0 is correct for *all* x and
>> y where Ha0 simulates for 0 steps. That conclusion is obviously
>> incorrect, which means this criteria is invalid.
>>
>> So no matter which way you read it, Ha(Pa,Pa)==0 is wrong. As
>> Richard likes to say, choose which way you are wrong.
>
> Olcott already lost the argument with Richard when he blocked him:
> blocking someone is admitting defeat.
>
> /Flibble
>

Richard is a clueless wonder that cannot possibly ever learn.
Flibble seems to be the same.

My proof has been boiled down to two verified facts:

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.

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

(b) 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 Thursday, June 30, 2022 at 12:43:17 PM UTC-4, olcott wrote:
> On 6/30/2022 11:34 AM, Dennis Bush wrote:
> > On Thursday, June 30, 2022 at 12:15:58 PM UTC-4, olcott wrote:
> >> On 6/30/2022 10:40 AM, Dennis Bush wrote:
> >>> On Thursday, June 30, 2022 at 11:36:43 AM UTC-4, olcott wrote:
> >>>> On 6/30/2022 7:12 AM, Dennis Bush wrote:
> >>>>> On Thursday, June 30, 2022 at 12:59:38 AM UTC-4, olcott wrote:
> >>>>>> On 6/29/2022 11:51 PM, Dennis Bush wrote:
> >>>>>>> On Thursday, June 30, 2022 at 12:42:59 AM 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:
> >>>>>>>
> >>>>>>>>>> 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
> >>>>>>>
> >>>>>>> Which does not exist because Ha aborts and therefore does not do a complete and correct x86 emulation.
> >>>>>> We are taking that what you are saying means that you believe it is
> >>>>>> impossible for H to correctly determine that Infinite_Loop() never halts.
> >>>>>
> >>>>> No, you're saying that the correctness criteria for Ha(Pa,Pa) is a complete and correct emulation of the input *by Ha*. And because Ha has a fixed algorithm that aborts, Ha does not do a complete and correct emulation of the input.
> >>>>>
> >>>>> And because Ha does not do a complete and correct emulation of the input, what I'm saying is that your correctness criteria simply doesn't exist.
> >>>>>
> >>>> That is a Jackass (deceptive head games) thing to say when you already
> >>>> know that H merely needs to correctly predict what the complete and
> >>>> correct x86 emulation of its input would do and it need not actually to
> >>>> a complete emulation to do this. EXAMPLE BELOW
> >>>
> >>> *The* complete and correct emulation of the input to Ha(Pa,Pa) is performed by UTM(Pa,Pa) which halts, proving that Ha(Pa,Pa)==0 is wrong.
> >> The part that you keep erasing proves that you are a liar.
> >> You keep erasing it because you know that it proves you are a liar.
> >
> > Infinite_Loop was previously shown to be irrelevant.
> >
> >>
> >> Changing the subject to a completely different computation UTM(Pa,Pa)
> >> than the actual computation Ha(Pa,Pa) is the strawman deception.
> >> 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
> >
> > I'm not changing the subject. I'm just going by what you're saying.
> >
> >> THIS IS NECESSARILY TRUE THUS IMPOSSIBLY FALSE
> >> Every simulating halt decider correctly simulates its input until it
> >> correctly determines that this simulated input would never reach its
> >> final state.
> >
> > You keep changing this part. Sometimes you say "the" simulated input, sometimes "its" simulated input, sometimes "this" simulated input.
> >
> > *The* complete and correct simulation of the input to Ha(Pa,Pa) is by definition performed by UTM(Pa,Pa).
> That is a lie and you know it.
>
> The actual behavior of the actual input to H(P,P) is conclusively proven
> to diverge from the actual behavior of the actual input to H1(P,P) on
> the basis of the semantics of the x86 language.

Then what is the first x86 instruction where the behavior of Ha(Pa,Pa) and UTM(Pa,Pa) differ?

Failure to identify such an instruction will be taken as an admission that there is no difference between the two and Ha(Pa,Pa)==0 is wrong because it aborts too soon as demonstrated by UTM(Pa,Pa) halting.

> H1(P,P) *is* UTM(P,P) in this case because H1 never aborts its x86
> emulation of its input.
> void P(u32 x)
> {
> if (H(x, x))
> HERE: goto HERE;
> return;
> }
> int main()
> {
> Output("Input_Halts = ", H1((u32)P, (u32)P));
> }
>
> _P()
> [0000163a](01) 55 push ebp
> [0000163b](02) 8bec mov ebp,esp
> [0000163d](03) 8b4508 mov eax,[ebp+08]
> [00001640](01) 50 push eax
> [00001641](03) 8b4d08 mov ecx,[ebp+08]
> [00001644](01) 51 push ecx
> [00001645](05) e8f0fdffff call 0000143a // call H
> [0000164a](03) 83c408 add esp,+08
> [0000164d](02) 85c0 test eax,eax
> [0000164f](02) 7402 jz 00001653
> [00001651](02) ebfe jmp 00001651
> [00001653](01) 5d pop ebp
> [00001654](01) c3 ret
> Size in bytes:(0027) [00001654]
>
> _main()
> [0000165a](01) 55 push ebp
> [0000165b](02) 8bec mov ebp,esp
> [0000165d](05) 683a160000 push 0000163a // push P
> [00001662](05) 683a160000 push 0000163a // push P
> [00001667](05) e8cef9ffff call 0000103a // call H1
> [0000166c](03) 83c408 add esp,+08
> [0000166f](01) 50 push eax // push return value
> [00001670](05) 689b040000 push 0000049b // "Input_Halts = "
> [00001675](05) e870eeffff call 000004ea // call Output
> [0000167a](03) 83c408 add esp,+08
> [0000167d](02) 33c0 xor eax,eax
> [0000167f](01) 5d pop ebp
> [00001680](01) c3 ret
> Size in bytes:(0039) [00001680]
> machine stack stack machine assembly
> address address data code language
> ======== ======== ======== ========= =============
> [0000165a][001026a9][00000000] 55 push ebp
> [0000165b][001026a9][00000000] 8bec mov ebp,esp
> [0000165d][001026a5][0000163a] 683a160000 push 0000163a // push P
> [00001662][001026a1][0000163a] 683a160000 push 0000163a // push P
> [00001667][0010269d][0000166c] e8cef9ffff call 0000103a // call H1
>
> H1: Begin Simulation Execution Trace Stored at:21275d
> Address_of_H1:103a
> [0000163a][00212749][0021274d] 55 push ebp
> [0000163b][00212749][0021274d] 8bec mov ebp,esp
> [0000163d][00212749][0021274d] 8b4508 mov eax,[ebp+08]
> [00001640][00212745][0000163a] 50 push eax // push P
> [00001641][00212745][0000163a] 8b4d08 mov ecx,[ebp+08]
> [00001644][00212741][0000163a] 51 push ecx // push P
> [00001645][0021273d][0000164a] e8f0fdffff call 0000143a // call H
>
> H: Begin Simulation Execution Trace Stored at:2285c5
> Address_of_H:143a
> [0000163a][002285b1][002285b5] 55 push ebp
> [0000163b][002285b1][002285b5] 8bec mov ebp,esp
> [0000163d][002285b1][002285b5] 8b4508 mov eax,[ebp+08]
> [00001640][002285ad][0000163a] 50 push eax // push P
> [00001641][002285ad][0000163a] 8b4d08 mov ecx,[ebp+08]
> [00001644][002285a9][0000163a] 51 push ecx // push P
> [00001645][002285a5][0000164a] e8f0fdffff call 0000143a // call H
> 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.

This condition is not met. Pa contains the following code:

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

On 2022-06-29 13:00:16 +0000, olcott said:

> 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.

That does not refute any halting problem proof. Instead, you should prove:
Some simulating halt decider correctly simulates its input until it
correctly determines that this simulated input would never reach its
final state.

Mikko

On 6/30/2022 1:22 PM, Mikko wrote:
> On 2022-06-29 13:00:16 +0000, olcott said:
>
>> 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.
>
> That does not refute any halting problem proof. Instead, you should prove:
> Some simulating halt decider correctly simulates its input until it
> correctly determines that this simulated input would never reach its
> final state.
>
> Mikko

I do not see any material difference between the two.

--
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:39:03 PM UTC-7, olcott wrote:
> 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

Thank You. I missed the fact that first column was blue.

This is indeed a lot of information. But still not a language. There
is no defined control structure or syntax.

On 6/30/2022 1:39 PM, dklei...@gmail.com wrote:
> On Wednesday, June 29, 2022 at 4:39:03 PM UTC-7, olcott wrote:
>> 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
>
> Thank You. I missed the fact that first column was blue.
>
> This is indeed a lot of information. But still not a language. There
> is no defined control structure or syntax.

This *is* documented somewhere thus I do not need to document this
myself. https://css.csail.mit.edu/6.858/2019/readings/i386.pdf

--
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 2022-06-30 12:56, olcott wrote:
> On 6/30/2022 1:39 PM, dklei...@gmail.com wrote:
>> On Wednesday, June 29, 2022 at 4:39:03 PM UTC-7, olcott wrote:
>>> 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 statem
>>>
>>> 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
>>
>> Thank You. I missed the fact that first column was blue.
>>
>> This is indeed a lot of information. But still not a language. There
>> is no defined control structure or syntax.
>
> This *is* documented somewhere thus I do not need to document this
> myself. https://css.csail.mit.edu/6.858/2019/readings/i386.pdf

That link documents the 80386 processor and its instruction set. An
instruction set and a language are different things.

There are various languages which can be *used* to program x86
processors. These would include Intel x86 assembly language and AT&T x86
assembly language (which are entirely different languages with very
different syntaxes). But there is no such thing as "The x86 language".

André

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

On 6/30/2022 2:49 PM, André G. Isaak wrote:
> On 2022-06-30 12:56, olcott wrote:
>> On 6/30/2022 1:39 PM, dklei...@gmail.com wrote:
>>> On Wednesday, June 29, 2022 at 4:39:03 PM UTC-7, olcott wrote:
>>>> 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 statem
>>>>
>>>> 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
>>>
>>> Thank You. I missed the fact that first column was blue.
>>>
>>> This is indeed a lot of information. But still not a language. There
>>> is no defined control structure or syntax.
>>
>> This *is* documented somewhere thus I do not need to document this
>> myself. https://css.csail.mit.edu/6.858/2019/readings/i386.pdf
>
> That link documents the 80386 processor and its instruction set. An
> instruction set and a language are different things.
>
> There are various languages which can be *used* to program x86
> processors. These would include Intel x86 assembly language and AT&T x86
> assembly language (which are entirely different languages with very
> different syntaxes). But there is no such thing as "The x86 language".
>
> André

Hi André, good to hear from you again, you are one of my competent
reviewers. I wish that Ben was competent in the Intel x86 language.

There is a single unique 80386 processor machine language that forms a
bijection with its corresponding Intel x86 assembly language.
https://en.wikipedia.org/wiki/Bijection

My halt decider operates on the basis of the actual machine code.
The assembly language is output only for human consumption.

x86 assembly language
https://en.wikipedia.org/wiki/X86_assembly_language

--
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/30/2022 11:55 AM, Dennis Bush wrote:
> On Thursday, June 30, 2022 at 12:43:17 PM UTC-4, olcott wrote:
>> On 6/30/2022 11:34 AM, Dennis Bush wrote:
>>> On Thursday, June 30, 2022 at 12:15:58 PM UTC-4, olcott wrote:
>>>> On 6/30/2022 10:40 AM, Dennis Bush wrote:
>>>>> On Thursday, June 30, 2022 at 11:36:43 AM UTC-4, olcott wrote:
>>>>>> On 6/30/2022 7:12 AM, Dennis Bush wrote:
>>>>>>> On Thursday, June 30, 2022 at 12:59:38 AM UTC-4, olcott wrote:
>>>>>>>> On 6/29/2022 11:51 PM, Dennis Bush wrote:
>>>>>>>>> On Thursday, June 30, 2022 at 12:42:59 AM 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:
>>>>>>>>>
>>>>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>> Which does not exist because Ha aborts and therefore does not do a complete and correct x86 emulation.
>>>>>>>> We are taking that what you are saying means that you believe it is
>>>>>>>> impossible for H to correctly determine that Infinite_Loop() never halts.
>>>>>>>
>>>>>>> No, you're saying that the correctness criteria for Ha(Pa,Pa) is a complete and correct emulation of the input *by Ha*. And because Ha has a fixed algorithm that aborts, Ha does not do a complete and correct emulation of the input.
>>>>>>>
>>>>>>> And because Ha does not do a complete and correct emulation of the input, what I'm saying is that your correctness criteria simply doesn't exist.
>>>>>>>
>>>>>> That is a Jackass (deceptive head games) thing to say when you already
>>>>>> know that H merely needs to correctly predict what the complete and
>>>>>> correct x86 emulation of its input would do and it need not actually to
>>>>>> a complete emulation to do this. EXAMPLE BELOW
>>>>>
>>>>> *The* complete and correct emulation of the input to Ha(Pa,Pa) is performed by UTM(Pa,Pa) which halts, proving that Ha(Pa,Pa)==0 is wrong.
>>>> The part that you keep erasing proves that you are a liar.
>>>> You keep erasing it because you know that it proves you are a liar.
>>>
>>> Infinite_Loop was previously shown to be irrelevant.
>>>
>>>>
>>>> Changing the subject to a completely different computation UTM(Pa,Pa)
>>>> than the actual computation Ha(Pa,Pa) is the strawman deception.
>>>> 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
>>>
>>> I'm not changing the subject. I'm just going by what you're saying.
>>>
>>>> THIS IS NECESSARILY TRUE THUS IMPOSSIBLY FALSE
>>>> Every simulating halt decider correctly simulates its input until it
>>>> correctly determines that this simulated input would never reach its
>>>> final state.
>>>
>>> You keep changing this part. Sometimes you say "the" simulated input, sometimes "its" simulated input, sometimes "this" simulated input.
>>>
>>> *The* complete and correct simulation of the input to Ha(Pa,Pa) is by definition performed by UTM(Pa,Pa).
>> That is a lie and you know it.
>>
>> The actual behavior of the actual input to H(P,P) is conclusively proven
>> to diverge from the actual behavior of the actual input to H1(P,P) on
>> the basis of the semantics of the x86 language.
>
> Then what is the first x86 instruction where the behavior of Ha(Pa,Pa) and UTM(Pa,Pa) differ?
>

[0000164a][00212749][0021274d] 83c408 add esp,+08

> Failure to identify such an instruction will be taken as an admission that there is no difference between the two and Ha(Pa,Pa)==0 is wrong because it aborts too soon as demonstrated by UTM(Pa,Pa) halting.
>
>> H1(P,P) *is* UTM(P,P) in this case because H1 never aborts its x86
>> emulation of its input.
>> void P(u32 x)
>> {
>> if (H(x, x))
>> HERE: goto HERE;
>> return;
>> }
>> int main()
>> {
>> Output("Input_Halts = ", H1((u32)P, (u32)P));
>> }
>>
>> _P()
>> [0000163a](01) 55 push ebp
>> [0000163b](02) 8bec mov ebp,esp
>> [0000163d](03) 8b4508 mov eax,[ebp+08]
>> [00001640](01) 50 push eax
>> [00001641](03) 8b4d08 mov ecx,[ebp+08]
>> [00001644](01) 51 push ecx
>> [00001645](05) e8f0fdffff call 0000143a // call H
>> [0000164a](03) 83c408 add esp,+08
>> [0000164d](02) 85c0 test eax,eax
>> [0000164f](02) 7402 jz 00001653
>> [00001651](02) ebfe jmp 00001651
>> [00001653](01) 5d pop ebp
>> [00001654](01) c3 ret
>> Size in bytes:(0027) [00001654]
>>
>> _main()
>> [0000165a](01) 55 push ebp
>> [0000165b](02) 8bec mov ebp,esp
>> [0000165d](05) 683a160000 push 0000163a // push P
>> [00001662](05) 683a160000 push 0000163a // push P
>> [00001667](05) e8cef9ffff call 0000103a // call H1
>> [0000166c](03) 83c408 add esp,+08
>> [0000166f](01) 50 push eax // push return value
>> [00001670](05) 689b040000 push 0000049b // "Input_Halts = "
>> [00001675](05) e870eeffff call 000004ea // call Output
>> [0000167a](03) 83c408 add esp,+08
>> [0000167d](02) 33c0 xor eax,eax
>> [0000167f](01) 5d pop ebp
>> [00001680](01) c3 ret
>> Size in bytes:(0039) [00001680]
>> machine stack stack machine assembly
>> address address data code language
>> ======== ======== ======== ========= =============
>> [0000165a][001026a9][00000000] 55 push ebp
>> [0000165b][001026a9][00000000] 8bec mov ebp,esp
>> [0000165d][001026a5][0000163a] 683a160000 push 0000163a // push P
>> [00001662][001026a1][0000163a] 683a160000 push 0000163a // push P
>> [00001667][0010269d][0000166c] e8cef9ffff call 0000103a // call H1
>>
>> H1: Begin Simulation Execution Trace Stored at:21275d
>> Address_of_H1:103a
>> [0000163a][00212749][0021274d] 55 push ebp
>> [0000163b][00212749][0021274d] 8bec mov ebp,esp
>> [0000163d][00212749][0021274d] 8b4508 mov eax,[ebp+08]
>> [00001640][00212745][0000163a] 50 push eax // push P
>> [00001641][00212745][0000163a] 8b4d08 mov ecx,[ebp+08]
>> [00001644][00212741][0000163a] 51 push ecx // push P
>> [00001645][0021273d][0000164a] e8f0fdffff call 0000143a // call H
>>
>> H: Begin Simulation Execution Trace Stored at:2285c5
>> Address_of_H:143a
>> [0000163a][002285b1][002285b5] 55 push ebp
>> [0000163b][002285b1][002285b5] 8bec mov ebp,esp
>> [0000163d][002285b1][002285b5] 8b4508 mov eax,[ebp+08]
>> [00001640][002285ad][0000163a] 50 push eax // push P
>> [00001641][002285ad][0000163a] 8b4d08 mov ecx,[ebp+08]
>> [00001644][002285a9][0000163a] 51 push ecx // push P
>> [00001645][002285a5][0000164a] e8f0fdffff call 0000143a // call H
>> 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.
>
> This condition is not met. Pa contains the following code:
>
> 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
>
> Which *can* and *does* prevent infinitely nested simulation in a complete and correct simulation. Ha is unable to see this which is why it gets the wrong answer.

On Thursday, June 30, 2022 at 11:56:41 AM UTC-7, olcott wrote:
> On 6/30/2022 1:39 PM, dklei...@gmail.com wrote:
> > On Wednesday, June 29, 2022 at 4:39:03 PM UTC-7, olcott wrote:
> >> 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
> >
> > Thank You. I missed the fact that first column was blue.
> >
> > This is indeed a lot of information. But still not a language. There
> > is no defined control structure or syntax.
> This *is* documented somewhere thus I do not need to document this
> myself. https://css.csail.mit.edu/6.858/2019/readings/i386.pdf

Different x86 processor. I think the 486 was the high point of that
series and would be preferable to the 386.

I think maybe the point is that you need to work in assembly
language rather than the actual op-codes.

But even assembly "language" is only a language by courtesy.
It lacks some features that were added by assemblers back in
the good old days.

On Thursday, June 30, 2022 at 4:22:57 PM UTC-4, olcott wrote:
> On 6/30/2022 11:55 AM, Dennis Bush wrote:
> > On Thursday, June 30, 2022 at 12:43:17 PM UTC-4, olcott wrote:
> >> On 6/30/2022 11:34 AM, Dennis Bush wrote:
> >>> On Thursday, June 30, 2022 at 12:15:58 PM UTC-4, olcott wrote:
> >>>> On 6/30/2022 10:40 AM, Dennis Bush wrote:
> >>>>> On Thursday, June 30, 2022 at 11:36:43 AM UTC-4, olcott wrote:
> >>>>>> On 6/30/2022 7:12 AM, Dennis Bush wrote:
> >>>>>>> On Thursday, June 30, 2022 at 12:59:38 AM UTC-4, olcott wrote:
> >>>>>>>> On 6/29/2022 11:51 PM, Dennis Bush wrote:
> >>>>>>>>> On Thursday, June 30, 2022 at 12:42:59 AM 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:
> >>>>>>>>>
> >>>>>>>>>>>> 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
> >>>>>>>>>
> >>>>>>>>> Which does not exist because Ha aborts and therefore does not do a complete and correct x86 emulation.
> >>>>>>>> We are taking that what you are saying means that you believe it is
> >>>>>>>> impossible for H to correctly determine that Infinite_Loop() never halts.
> >>>>>>>
> >>>>>>> No, you're saying that the correctness criteria for Ha(Pa,Pa) is a complete and correct emulation of the input *by Ha*. And because Ha has a fixed algorithm that aborts, Ha does not do a complete and correct emulation of the input.
> >>>>>>>
> >>>>>>> And because Ha does not do a complete and correct emulation of the input, what I'm saying is that your correctness criteria simply doesn't exist.
> >>>>>>>
> >>>>>> That is a Jackass (deceptive head games) thing to say when you already
> >>>>>> know that H merely needs to correctly predict what the complete and
> >>>>>> correct x86 emulation of its input would do and it need not actually to
> >>>>>> a complete emulation to do this. EXAMPLE BELOW
> >>>>>
> >>>>> *The* complete and correct emulation of the input to Ha(Pa,Pa) is performed by UTM(Pa,Pa) which halts, proving that Ha(Pa,Pa)==0 is wrong.
> >>>> The part that you keep erasing proves that you are a liar.
> >>>> You keep erasing it because you know that it proves you are a liar.
> >>>
> >>> Infinite_Loop was previously shown to be irrelevant.
> >>>
> >>>>
> >>>> Changing the subject to a completely different computation UTM(Pa,Pa)
> >>>> than the actual computation Ha(Pa,Pa) is the strawman deception.
> >>>> 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
> >>>
> >>> I'm not changing the subject. I'm just going by what you're saying.
> >>>
> >>>> THIS IS NECESSARILY TRUE THUS IMPOSSIBLY FALSE
> >>>> Every simulating halt decider correctly simulates its input until it
> >>>> correctly determines that this simulated input would never reach its
> >>>> final state.
> >>>
> >>> You keep changing this part. Sometimes you say "the" simulated input, sometimes "its" simulated input, sometimes "this" simulated input.
> >>>
> >>> *The* complete and correct simulation of the input to Ha(Pa,Pa) is by definition performed by UTM(Pa,Pa).
> >> That is a lie and you know it.
> >>
> >> The actual behavior of the actual input to H(P,P) is conclusively proven
> >> to diverge from the actual behavior of the actual input to H1(P,P) on
> >> the basis of the semantics of the x86 language.
> >
> > Then what is the first x86 instruction where the behavior of Ha(Pa,Pa) and UTM(Pa,Pa) differ?
> >
> [0000164a][00212749][0021274d] 83c408 add esp,+08

FALSE

The simulation performed by Ha is aborted before that instruction can be reached. The simulated instructions performed by Ha and UTM are identical up to the point where Ha aborts. UTM then continues to simulate the same input past the point where Ha aborted, allowing it to reach that statement as well as the final "ret" at the end, demonstrating that Ha aborted too soon.

> > Failure to identify such an instruction will be taken as an admission that there is no difference between the two and Ha(Pa,Pa)==0 is wrong because it aborts too soon as demonstrated by UTM(Pa,Pa) halting.
> >
> >> H1(P,P) *is* UTM(P,P) in this case because H1 never aborts its x86
> >> emulation of its input.
> >> void P(u32 x)
> >> {
> >> if (H(x, x))
> >> HERE: goto HERE;
> >> return;
> >> }
> >> int main()
> >> {
> >> Output("Input_Halts = ", H1((u32)P, (u32)P));
> >> }
> >>
> >> _P()
> >> [0000163a](01) 55 push ebp
> >> [0000163b](02) 8bec mov ebp,esp
> >> [0000163d](03) 8b4508 mov eax,[ebp+08]
> >> [00001640](01) 50 push eax
> >> [00001641](03) 8b4d08 mov ecx,[ebp+08]
> >> [00001644](01) 51 push ecx
> >> [00001645](05) e8f0fdffff call 0000143a // call H
> >> [0000164a](03) 83c408 add esp,+08
> >> [0000164d](02) 85c0 test eax,eax
> >> [0000164f](02) 7402 jz 00001653
> >> [00001651](02) ebfe jmp 00001651
> >> [00001653](01) 5d pop ebp
> >> [00001654](01) c3 ret
> >> Size in bytes:(0027) [00001654]
> >>
> >> _main()
> >> [0000165a](01) 55 push ebp
> >> [0000165b](02) 8bec mov ebp,esp
> >> [0000165d](05) 683a160000 push 0000163a // push P
> >> [00001662](05) 683a160000 push 0000163a // push P
> >> [00001667](05) e8cef9ffff call 0000103a // call H1
> >> [0000166c](03) 83c408 add esp,+08
> >> [0000166f](01) 50 push eax // push return value
> >> [00001670](05) 689b040000 push 0000049b // "Input_Halts = "
> >> [00001675](05) e870eeffff call 000004ea // call Output
> >> [0000167a](03) 83c408 add esp,+08
> >> [0000167d](02) 33c0 xor eax,eax
> >> [0000167f](01) 5d pop ebp
> >> [00001680](01) c3 ret
> >> Size in bytes:(0039) [00001680]
> >> machine stack stack machine assembly
> >> address address data code language
> >> ======== ======== ======== ========= =============
> >> [0000165a][001026a9][00000000] 55 push ebp
> >> [0000165b][001026a9][00000000] 8bec mov ebp,esp
> >> [0000165d][001026a5][0000163a] 683a160000 push 0000163a // push P
> >> [00001662][001026a1][0000163a] 683a160000 push 0000163a // push P
> >> [00001667][0010269d][0000166c] e8cef9ffff call 0000103a // call H1
> >>
> >> H1: Begin Simulation Execution Trace Stored at:21275d
> >> Address_of_H1:103a
> >> [0000163a][00212749][0021274d] 55 push ebp
> >> [0000163b][00212749][0021274d] 8bec mov ebp,esp
> >> [0000163d][00212749][0021274d] 8b4508 mov eax,[ebp+08]
> >> [00001640][00212745][0000163a] 50 push eax // push P
> >> [00001641][00212745][0000163a] 8b4d08 mov ecx,[ebp+08]
> >> [00001644][00212741][0000163a] 51 push ecx // push P
> >> [00001645][0021273d][0000164a] e8f0fdffff call 0000143a // call H
> >>
> >> H: Begin Simulation Execution Trace Stored at:2285c5
> >> Address_of_H:143a
> >> [0000163a][002285b1][002285b5] 55 push ebp
> >> [0000163b][002285b1][002285b5] 8bec mov ebp,esp
> >> [0000163d][002285b1][002285b5] 8b4508 mov eax,[ebp+08]
> >> [00001640][002285ad][0000163a] 50 push eax // push P
> >> [00001641][002285ad][0000163a] 8b4d08 mov ecx,[ebp+08]
> >> [00001644][002285a9][0000163a] 51 push ecx // push P
> >> [00001645][002285a5][0000164a] e8f0fdffff call 0000143a // call H
> >> 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.
> >
> > This condition is not met. Pa contains the following code:
> >
> > 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
> >
> > Which *can* and *does* prevent infinitely nested simulation in a complete and correct simulation. Ha is unable to see this which is why it gets the wrong answer.
> As you continue to deceitfully assert the actual simulated input to
> H(P,P) does stop running because its simulation has been aborted.

On 6/30/2022 3:41 PM, dklei...@gmail.com wrote:
> On Thursday, June 30, 2022 at 11:56:41 AM UTC-7, olcott wrote:
>> On 6/30/2022 1:39 PM, dklei...@gmail.com wrote:
>>> On Wednesday, June 29, 2022 at 4:39:03 PM UTC-7, olcott wrote:
>>>> 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
>>>
>>> Thank You. I missed the fact that first column was blue.
>>>
>>> This is indeed a lot of information. But still not a language. There
>>> is no defined control structure or syntax.
>> This *is* documented somewhere thus I do not need to document this
>> myself. https://css.csail.mit.edu/6.858/2019/readings/i386.pdf
>
> Different x86 processor. I think the 486 was the high point of that
> series and would be preferable to the 386.
>
> I think maybe the point is that you need to work in assembly
> language rather than the actual op-codes.
>
> But even assembly "language" is only a language by courtesy.
> It lacks some features that were added by assemblers back in
> the good old days.

My code only uses the machine language.
I think that the default Visual C 32-bit compiler generates 80386 code.

--
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/30/2022 3:50 PM, Dennis Bush wrote:
> On Thursday, June 30, 2022 at 4:22:57 PM UTC-4, olcott wrote:
>> On 6/30/2022 11:55 AM, Dennis Bush wrote:
>>> On Thursday, June 30, 2022 at 12:43:17 PM UTC-4, olcott wrote:
>>>> On 6/30/2022 11:34 AM, Dennis Bush wrote:
>>>>> On Thursday, June 30, 2022 at 12:15:58 PM UTC-4, olcott wrote:
>>>>>> On 6/30/2022 10:40 AM, Dennis Bush wrote:
>>>>>>> On Thursday, June 30, 2022 at 11:36:43 AM UTC-4, olcott wrote:
>>>>>>>> On 6/30/2022 7:12 AM, Dennis Bush wrote:
>>>>>>>>> On Thursday, June 30, 2022 at 12:59:38 AM UTC-4, olcott wrote:
>>>>>>>>>> On 6/29/2022 11:51 PM, Dennis Bush wrote:
>>>>>>>>>>> On Thursday, June 30, 2022 at 12:42:59 AM 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:
>>>>>>>>>>>
>>>>>>>>>>>>>> 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
>>>>>>>>>>>
>>>>>>>>>>> Which does not exist because Ha aborts and therefore does not do a complete and correct x86 emulation.
>>>>>>>>>> We are taking that what you are saying means that you believe it is
>>>>>>>>>> impossible for H to correctly determine that Infinite_Loop() never halts.
>>>>>>>>>
>>>>>>>>> No, you're saying that the correctness criteria for Ha(Pa,Pa) is a complete and correct emulation of the input *by Ha*. And because Ha has a fixed algorithm that aborts, Ha does not do a complete and correct emulation of the input.
>>>>>>>>>
>>>>>>>>> And because Ha does not do a complete and correct emulation of the input, what I'm saying is that your correctness criteria simply doesn't exist.
>>>>>>>>>
>>>>>>>> That is a Jackass (deceptive head games) thing to say when you already
>>>>>>>> know that H merely needs to correctly predict what the complete and
>>>>>>>> correct x86 emulation of its input would do and it need not actually to
>>>>>>>> a complete emulation to do this. EXAMPLE BELOW
>>>>>>>
>>>>>>> *The* complete and correct emulation of the input to Ha(Pa,Pa) is performed by UTM(Pa,Pa) which halts, proving that Ha(Pa,Pa)==0 is wrong.
>>>>>> The part that you keep erasing proves that you are a liar.
>>>>>> You keep erasing it because you know that it proves you are a liar.
>>>>>
>>>>> Infinite_Loop was previously shown to be irrelevant.
>>>>>
>>>>>>
>>>>>> Changing the subject to a completely different computation UTM(Pa,Pa)
>>>>>> than the actual computation Ha(Pa,Pa) is the strawman deception.
>>>>>> 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
>>>>>
>>>>> I'm not changing the subject. I'm just going by what you're saying.
>>>>>
>>>>>> THIS IS NECESSARILY TRUE THUS IMPOSSIBLY FALSE
>>>>>> Every simulating halt decider correctly simulates its input until it
>>>>>> correctly determines that this simulated input would never reach its
>>>>>> final state.
>>>>>
>>>>> You keep changing this part. Sometimes you say "the" simulated input, sometimes "its" simulated input, sometimes "this" simulated input.
>>>>>
>>>>> *The* complete and correct simulation of the input to Ha(Pa,Pa) is by definition performed by UTM(Pa,Pa).
>>>> That is a lie and you know it.
>>>>
>>>> The actual behavior of the actual input to H(P,P) is conclusively proven
>>>> to diverge from the actual behavior of the actual input to H1(P,P) on
>>>> the basis of the semantics of the x86 language.
>>>
>>> Then what is the first x86 instruction where the behavior of Ha(Pa,Pa) and UTM(Pa,Pa) differ?
>>>
>> [0000164a][00212749][0021274d] 83c408 add esp,+08
>
> FALSE
>
> The simulation performed by Ha is aborted before that instruction can be reached.

Aborted or not the above instruction is the first instruction that
differs. Perhaps it is simply beyond you technical capacity to
understand that any function called in infinite recursion never returns
to its caller.

> The simulated instructions performed by Ha and UTM are identical up to the point where Ha aborts. UTM then continues to simulate the same input past the point where Ha aborted, allowing it to reach that statement as well as the final "ret" at the end, demonstrating that Ha aborted too soon.
>
>
>>> Failure to identify such an instruction will be taken as an admission that there is no difference between the two and Ha(Pa,Pa)==0 is wrong because it aborts too soon as demonstrated by UTM(Pa,Pa) halting.
>>>
>>>> H1(P,P) *is* UTM(P,P) in this case because H1 never aborts its x86
>>>> emulation of its input.
>>>> void P(u32 x)
>>>> {
>>>> if (H(x, x))
>>>> HERE: goto HERE;
>>>> return;
>>>> }
>>>> int main()
>>>> {
>>>> Output("Input_Halts = ", H1((u32)P, (u32)P));
>>>> }
>>>>
>>>> _P()
>>>> [0000163a](01) 55 push ebp
>>>> [0000163b](02) 8bec mov ebp,esp
>>>> [0000163d](03) 8b4508 mov eax,[ebp+08]
>>>> [00001640](01) 50 push eax
>>>> [00001641](03) 8b4d08 mov ecx,[ebp+08]
>>>> [00001644](01) 51 push ecx
>>>> [00001645](05) e8f0fdffff call 0000143a // call H
>>>> [0000164a](03) 83c408 add esp,+08
>>>> [0000164d](02) 85c0 test eax,eax
>>>> [0000164f](02) 7402 jz 00001653
>>>> [00001651](02) ebfe jmp 00001651
>>>> [00001653](01) 5d pop ebp
>>>> [00001654](01) c3 ret
>>>> Size in bytes:(0027) [00001654]
>>>>
>>>> _main()
>>>> [0000165a](01) 55 push ebp
>>>> [0000165b](02) 8bec mov ebp,esp
>>>> [0000165d](05) 683a160000 push 0000163a // push P
>>>> [00001662](05) 683a160000 push 0000163a // push P
>>>> [00001667](05) e8cef9ffff call 0000103a // call H1
>>>> [0000166c](03) 83c408 add esp,+08
>>>> [0000166f](01) 50 push eax // push return value
>>>> [00001670](05) 689b040000 push 0000049b // "Input_Halts = "
>>>> [00001675](05) e870eeffff call 000004ea // call Output
>>>> [0000167a](03) 83c408 add esp,+08
>>>> [0000167d](02) 33c0 xor eax,eax
>>>> [0000167f](01) 5d pop ebp
>>>> [00001680](01) c3 ret
>>>> Size in bytes:(0039) [00001680]
>>>> machine stack stack machine assembly
>>>> address address data code language
>>>> ======== ======== ======== ========= =============
>>>> [0000165a][001026a9][00000000] 55 push ebp
>>>> [0000165b][001026a9][00000000] 8bec mov ebp,esp
>>>> [0000165d][001026a5][0000163a] 683a160000 push 0000163a // push P
>>>> [00001662][001026a1][0000163a] 683a160000 push 0000163a // push P
>>>> [00001667][0010269d][0000166c] e8cef9ffff call 0000103a // call H1
>>>>
>>>> H1: Begin Simulation Execution Trace Stored at:21275d
>>>> Address_of_H1:103a
>>>> [0000163a][00212749][0021274d] 55 push ebp
>>>> [0000163b][00212749][0021274d] 8bec mov ebp,esp
>>>> [0000163d][00212749][0021274d] 8b4508 mov eax,[ebp+08]
>>>> [00001640][00212745][0000163a] 50 push eax // push P
>>>> [00001641][00212745][0000163a] 8b4d08 mov ecx,[ebp+08]
>>>> [00001644][00212741][0000163a] 51 push ecx // push P
>>>> [00001645][0021273d][0000164a] e8f0fdffff call 0000143a // call H
>>>>
>>>> H: Begin Simulation Execution Trace Stored at:2285c5
>>>> Address_of_H:143a
>>>> [0000163a][002285b1][002285b5] 55 push ebp
>>>> [0000163b][002285b1][002285b5] 8bec mov ebp,esp
>>>> [0000163d][002285b1][002285b5] 8b4508 mov eax,[ebp+08]
>>>> [00001640][002285ad][0000163a] 50 push eax // push P
>>>> [00001641][002285ad][0000163a] 8b4d08 mov ecx,[ebp+08]
>>>> [00001644][002285a9][0000163a] 51 push ecx // push P
>>>> [00001645][002285a5][0000164a] e8f0fdffff call 0000143a // call H
>>>> 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.
>>>
>>> This condition is not met. Pa contains the following code:
>>>
>>> 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
>>>
>>> Which *can* and *does* prevent infinitely nested simulation in a complete and correct simulation. Ha is unable to see this which is why it gets the wrong answer.
>> As you continue to deceitfully assert the actual simulated input to
>> H(P,P) does stop running because its simulation has been aborted.
>
> As usual, your poor reading comprehension skills are on full display. Ha is unable to see that the above instructions in Pa *will* escape infinitely recursive emulation and halt normally if fully simulated.
>
>>
>> The reason that this assertion is deceitful is that halting does not
>> mean stops running. Halting means reaches its final "ret" instruction
>> state.
>
> And a correct simulation of the input to Ha(Pa,Pa), i.e. UTM(Pa,Pa), does reach the "ret" instruction.

On Thursday, June 30, 2022 at 5:52:37 PM UTC-4, olcott wrote:
> On 6/30/2022 3:50 PM, Dennis Bush wrote:
> > On Thursday, June 30, 2022 at 4:22:57 PM UTC-4, olcott wrote:
> >> On 6/30/2022 11:55 AM, Dennis Bush wrote:
> >>> On Thursday, June 30, 2022 at 12:43:17 PM UTC-4, olcott wrote:
> >>>> On 6/30/2022 11:34 AM, Dennis Bush wrote:
> >>>>> On Thursday, June 30, 2022 at 12:15:58 PM UTC-4, olcott wrote:
> >>>>>> On 6/30/2022 10:40 AM, Dennis Bush wrote:
> >>>>>>> On Thursday, June 30, 2022 at 11:36:43 AM UTC-4, olcott wrote:
> >>>>>>>> On 6/30/2022 7:12 AM, Dennis Bush wrote:
> >>>>>>>>> On Thursday, June 30, 2022 at 12:59:38 AM UTC-4, olcott wrote:
> >>>>>>>>>> On 6/29/2022 11:51 PM, Dennis Bush wrote:
> >>>>>>>>>>> On Thursday, June 30, 2022 at 12:42:59 AM 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:
> >>>>>>>>>>>
> >>>>>>>>>>>>>> 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
> >>>>>>>>>>>
> >>>>>>>>>>> Which does not exist because Ha aborts and therefore does not do a complete and correct x86 emulation.
> >>>>>>>>>> We are taking that what you are saying means that you believe it is
> >>>>>>>>>> impossible for H to correctly determine that Infinite_Loop() never halts.
> >>>>>>>>>
> >>>>>>>>> No, you're saying that the correctness criteria for Ha(Pa,Pa) is a complete and correct emulation of the input *by Ha*. And because Ha has a fixed algorithm that aborts, Ha does not do a complete and correct emulation of the input.
> >>>>>>>>>
> >>>>>>>>> And because Ha does not do a complete and correct emulation of the input, what I'm saying is that your correctness criteria simply doesn't exist.
> >>>>>>>>>
> >>>>>>>> That is a Jackass (deceptive head games) thing to say when you already
> >>>>>>>> know that H merely needs to correctly predict what the complete and
> >>>>>>>> correct x86 emulation of its input would do and it need not actually to
> >>>>>>>> a complete emulation to do this. EXAMPLE BELOW
> >>>>>>>
> >>>>>>> *The* complete and correct emulation of the input to Ha(Pa,Pa) is performed by UTM(Pa,Pa) which halts, proving that Ha(Pa,Pa)==0 is wrong.
> >>>>>> The part that you keep erasing proves that you are a liar.
> >>>>>> You keep erasing it because you know that it proves you are a liar..
> >>>>>
> >>>>> Infinite_Loop was previously shown to be irrelevant.
> >>>>>
> >>>>>>
> >>>>>> Changing the subject to a completely different computation UTM(Pa,Pa)
> >>>>>> than the actual computation Ha(Pa,Pa) is the strawman deception.
> >>>>>> 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
> >>>>>
> >>>>> I'm not changing the subject. I'm just going by what you're saying.
> >>>>>
> >>>>>> THIS IS NECESSARILY TRUE THUS IMPOSSIBLY FALSE
> >>>>>> Every simulating halt decider correctly simulates its input until it
> >>>>>> correctly determines that this simulated input would never reach its
> >>>>>> final state.
> >>>>>
> >>>>> You keep changing this part. Sometimes you say "the" simulated input, sometimes "its" simulated input, sometimes "this" simulated input.
> >>>>>
> >>>>> *The* complete and correct simulation of the input to Ha(Pa,Pa) is by definition performed by UTM(Pa,Pa).
> >>>> That is a lie and you know it.
> >>>>
> >>>> The actual behavior of the actual input to H(P,P) is conclusively proven
> >>>> to diverge from the actual behavior of the actual input to H1(P,P) on
> >>>> the basis of the semantics of the x86 language.
> >>>
> >>> Then what is the first x86 instruction where the behavior of Ha(Pa,Pa) and UTM(Pa,Pa) differ?
> >>>
> >> [0000164a][00212749][0021274d] 83c408 add esp,+08
> >
> > FALSE
> >
> > The simulation performed by Ha is aborted before that instruction can be reached.
> Aborted or not the above instruction is the first instruction that
> differs.

That instruction doesn't differ between the two simulations because Ha stopped before it got there. Would you argue that Ha3(N,5)==0 and Ha7(N,5)==1 are both correct, and that the point at which the simulated inputs differ is the first instruction after Ha3 aborts? Of course not. That one stopped too soon doesn't mean the two have differing behavior. The same goes for Ha(Pa,Pa) and UTM(Pa,Pa).

> Perhaps it is simply beyond you technical capacity to
> understand that any function called in infinite recursion never returns
> to its caller.

But it wasn't called in infinite recursion. If Ha is a pure function of its inputs, then Ha(Pa,Pa) will ALWAYS return 0 in all contexts. Ha makes an error thinking this will not be the case when it simulates Pa and sees it calling Ha.

> > The simulated instructions performed by Ha and UTM are identical up to the point where Ha aborts. UTM then continues to simulate the same input past the point where Ha aborted, allowing it to reach that statement as well as the final "ret" at the end, demonstrating that Ha aborted too soon.
> >
> >
> >>> Failure to identify such an instruction will be taken as an admission that there is no difference between the two and Ha(Pa,Pa)==0 is wrong because it aborts too soon as demonstrated by UTM(Pa,Pa) halting.
> >>>
> >>>> H1(P,P) *is* UTM(P,P) in this case because H1 never aborts its x86
> >>>> emulation of its input.
> >>>> void P(u32 x)
> >>>> {
> >>>> if (H(x, x))
> >>>> HERE: goto HERE;
> >>>> return;
> >>>> }
> >>>> int main()
> >>>> {
> >>>> Output("Input_Halts = ", H1((u32)P, (u32)P));
> >>>> }
> >>>>
> >>>> _P()
> >>>> [0000163a](01) 55 push ebp
> >>>> [0000163b](02) 8bec mov ebp,esp
> >>>> [0000163d](03) 8b4508 mov eax,[ebp+08]
> >>>> [00001640](01) 50 push eax
> >>>> [00001641](03) 8b4d08 mov ecx,[ebp+08]
> >>>> [00001644](01) 51 push ecx
> >>>> [00001645](05) e8f0fdffff call 0000143a // call H
> >>>> [0000164a](03) 83c408 add esp,+08
> >>>> [0000164d](02) 85c0 test eax,eax
> >>>> [0000164f](02) 7402 jz 00001653
> >>>> [00001651](02) ebfe jmp 00001651
> >>>> [00001653](01) 5d pop ebp
> >>>> [00001654](01) c3 ret
> >>>> Size in bytes:(0027) [00001654]
> >>>>
> >>>> _main()
> >>>> [0000165a](01) 55 push ebp
> >>>> [0000165b](02) 8bec mov ebp,esp
> >>>> [0000165d](05) 683a160000 push 0000163a // push P
> >>>> [00001662](05) 683a160000 push 0000163a // push P
> >>>> [00001667](05) e8cef9ffff call 0000103a // call H1
> >>>> [0000166c](03) 83c408 add esp,+08
> >>>> [0000166f](01) 50 push eax // push return value
> >>>> [00001670](05) 689b040000 push 0000049b // "Input_Halts = "
> >>>> [00001675](05) e870eeffff call 000004ea // call Output
> >>>> [0000167a](03) 83c408 add esp,+08
> >>>> [0000167d](02) 33c0 xor eax,eax
> >>>> [0000167f](01) 5d pop ebp
> >>>> [00001680](01) c3 ret
> >>>> Size in bytes:(0039) [00001680]
> >>>> machine stack stack machine assembly
> >>>> address address data code language
> >>>> ======== ======== ======== ========= =============
> >>>> [0000165a][001026a9][00000000] 55 push ebp
> >>>> [0000165b][001026a9][00000000] 8bec mov ebp,esp
> >>>> [0000165d][001026a5][0000163a] 683a160000 push 0000163a // push P
> >>>> [00001662][001026a1][0000163a] 683a160000 push 0000163a // push P
> >>>> [00001667][0010269d][0000166c] e8cef9ffff call 0000103a // call H1
> >>>>
> >>>> H1: Begin Simulation Execution Trace Stored at:21275d
> >>>> Address_of_H1:103a
> >>>> [0000163a][00212749][0021274d] 55 push ebp
> >>>> [0000163b][00212749][0021274d] 8bec mov ebp,esp
> >>>> [0000163d][00212749][0021274d] 8b4508 mov eax,[ebp+08]
> >>>> [00001640][00212745][0000163a] 50 push eax // push P
> >>>> [00001641][00212745][0000163a] 8b4d08 mov ecx,[ebp+08]
> >>>> [00001644][00212741][0000163a] 51 push ecx // push P
> >>>> [00001645][0021273d][0000164a] e8f0fdffff call 0000143a // call H
> >>>>
> >>>> H: Begin Simulation Execution Trace Stored at:2285c5
> >>>> Address_of_H:143a
> >>>> [0000163a][002285b1][002285b5] 55 push ebp
> >>>> [0000163b][002285b1][002285b5] 8bec mov ebp,esp
> >>>> [0000163d][002285b1][002285b5] 8b4508 mov eax,[ebp+08]
> >>>> [00001640][002285ad][0000163a] 50 push eax // push P
> >>>> [00001641][002285ad][0000163a] 8b4d08 mov ecx,[ebp+08]
> >>>> [00001644][002285a9][0000163a] 51 push ecx // push P
> >>>> [00001645][002285a5][0000164a] e8f0fdffff call 0000143a // call H
> >>>> 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.
> >>>
> >>> This condition is not met. Pa contains the following code:
> >>>
> >>> 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
> >>>
> >>> Which *can* and *does* prevent infinitely nested simulation in a complete and correct simulation. Ha is unable to see this which is why it gets the wrong answer.
> >> As you continue to deceitfully assert the actual simulated input to
> >> H(P,P) does stop running because its simulation has been aborted.
> >
> > As usual, your poor reading comprehension skills are on full display. Ha is unable to see that the above instructions in Pa *will* escape infinitely recursive emulation and halt normally if fully simulated.
> >
> >>
> >> The reason that this assertion is deceitful is that halting does not
> >> mean stops running. Halting means reaches its final "ret" instruction
> >> state.
> >
> > And a correct simulation of the input to Ha(Pa,Pa), i.e. UTM(Pa,Pa), does reach the "ret" instruction.
> That I proved that Ha(Pa,Pa) and UTM(Pa,Pa) are different computations
> makes you either ignorant or a liar.

On 6/30/2022 5:09 PM, Dennis Bush wrote:
> On Thursday, June 30, 2022 at 5:52:37 PM UTC-4, olcott wrote:
>> On 6/30/2022 3:50 PM, Dennis Bush wrote:
>>> On Thursday, June 30, 2022 at 4:22:57 PM UTC-4, olcott wrote:
>>>> On 6/30/2022 11:55 AM, Dennis Bush wrote:
>>>>> On Thursday, June 30, 2022 at 12:43:17 PM UTC-4, olcott wrote:
>>>>>> On 6/30/2022 11:34 AM, Dennis Bush wrote:
>>>>>>> On Thursday, June 30, 2022 at 12:15:58 PM UTC-4, olcott wrote:
>>>>>>>> On 6/30/2022 10:40 AM, Dennis Bush wrote:
>>>>>>>>> On Thursday, June 30, 2022 at 11:36:43 AM UTC-4, olcott wrote:
>>>>>>>>>> On 6/30/2022 7:12 AM, Dennis Bush wrote:
>>>>>>>>>>> On Thursday, June 30, 2022 at 12:59:38 AM UTC-4, olcott wrote:
>>>>>>>>>>>> On 6/29/2022 11:51 PM, Dennis Bush wrote:
>>>>>>>>>>>>> On Thursday, June 30, 2022 at 12:42:59 AM 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:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>
>>>>>>>>>>>>> Which does not exist because Ha aborts and therefore does not do a complete and correct x86 emulation.
>>>>>>>>>>>> We are taking that what you are saying means that you believe it is
>>>>>>>>>>>> impossible for H to correctly determine that Infinite_Loop() never halts.
>>>>>>>>>>>
>>>>>>>>>>> No, you're saying that the correctness criteria for Ha(Pa,Pa) is a complete and correct emulation of the input *by Ha*. And because Ha has a fixed algorithm that aborts, Ha does not do a complete and correct emulation of the input.
>>>>>>>>>>>
>>>>>>>>>>> And because Ha does not do a complete and correct emulation of the input, what I'm saying is that your correctness criteria simply doesn't exist.
>>>>>>>>>>>
>>>>>>>>>> That is a Jackass (deceptive head games) thing to say when you already
>>>>>>>>>> know that H merely needs to correctly predict what the complete and
>>>>>>>>>> correct x86 emulation of its input would do and it need not actually to
>>>>>>>>>> a complete emulation to do this. EXAMPLE BELOW
>>>>>>>>>
>>>>>>>>> *The* complete and correct emulation of the input to Ha(Pa,Pa) is performed by UTM(Pa,Pa) which halts, proving that Ha(Pa,Pa)==0 is wrong.
>>>>>>>> The part that you keep erasing proves that you are a liar.
>>>>>>>> You keep erasing it because you know that it proves you are a liar.
>>>>>>>
>>>>>>> Infinite_Loop was previously shown to be irrelevant.
>>>>>>>
>>>>>>>>
>>>>>>>> Changing the subject to a completely different computation UTM(Pa,Pa)
>>>>>>>> than the actual computation Ha(Pa,Pa) is the strawman deception.
>>>>>>>> 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
>>>>>>>
>>>>>>> I'm not changing the subject. I'm just going by what you're saying.
>>>>>>>
>>>>>>>> THIS IS NECESSARILY TRUE THUS IMPOSSIBLY FALSE
>>>>>>>> Every simulating halt decider correctly simulates its input until it
>>>>>>>> correctly determines that this simulated input would never reach its
>>>>>>>> final state.
>>>>>>>
>>>>>>> You keep changing this part. Sometimes you say "the" simulated input, sometimes "its" simulated input, sometimes "this" simulated input.
>>>>>>>
>>>>>>> *The* complete and correct simulation of the input to Ha(Pa,Pa) is by definition performed by UTM(Pa,Pa).
>>>>>> That is a lie and you know it.
>>>>>>
>>>>>> The actual behavior of the actual input to H(P,P) is conclusively proven
>>>>>> to diverge from the actual behavior of the actual input to H1(P,P) on
>>>>>> the basis of the semantics of the x86 language.
>>>>>
>>>>> Then what is the first x86 instruction where the behavior of Ha(Pa,Pa) and UTM(Pa,Pa) differ?
>>>>>
>>>> [0000164a][00212749][0021274d] 83c408 add esp,+08
>>>
>>> FALSE
>>>
>>> The simulation performed by Ha is aborted before that instruction can be reached.
>> Aborted or not the above instruction is the first instruction that
>> differs.
>
> That instruction doesn't differ between the two simulations because Ha stopped before it got there.
Perhaps you are simply not bright enough to understand that aborted or
not the emulated input never reaches its "ret" instruction.

--
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 Thursday, June 30, 2022 at 6:23:56 PM UTC-4, olcott wrote:
> On 6/30/2022 5:09 PM, Dennis Bush wrote:
> > On Thursday, June 30, 2022 at 5:52:37 PM UTC-4, olcott wrote:
> >> On 6/30/2022 3:50 PM, Dennis Bush wrote:
> >>> On Thursday, June 30, 2022 at 4:22:57 PM UTC-4, olcott wrote:
> >>>> On 6/30/2022 11:55 AM, Dennis Bush wrote:
> >>>>> On Thursday, June 30, 2022 at 12:43:17 PM UTC-4, olcott wrote:
> >>>>>> On 6/30/2022 11:34 AM, Dennis Bush wrote:
> >>>>>>> On Thursday, June 30, 2022 at 12:15:58 PM UTC-4, olcott wrote:
> >>>>>>>> On 6/30/2022 10:40 AM, Dennis Bush wrote:
> >>>>>>>>> On Thursday, June 30, 2022 at 11:36:43 AM UTC-4, olcott wrote:
> >>>>>>>>>> On 6/30/2022 7:12 AM, Dennis Bush wrote:
> >>>>>>>>>>> On Thursday, June 30, 2022 at 12:59:38 AM UTC-4, olcott wrote:
> >>>>>>>>>>>> On 6/29/2022 11:51 PM, Dennis Bush wrote:
> >>>>>>>>>>>>> On Thursday, June 30, 2022 at 12:42:59 AM 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:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> 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
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Which does not exist because Ha aborts and therefore does not do a complete and correct x86 emulation.
> >>>>>>>>>>>> We are taking that what you are saying means that you believe it is
> >>>>>>>>>>>> impossible for H to correctly determine that Infinite_Loop() never halts.
> >>>>>>>>>>>
> >>>>>>>>>>> No, you're saying that the correctness criteria for Ha(Pa,Pa) is a complete and correct emulation of the input *by Ha*. And because Ha has a fixed algorithm that aborts, Ha does not do a complete and correct emulation of the input.
> >>>>>>>>>>>
> >>>>>>>>>>> And because Ha does not do a complete and correct emulation of the input, what I'm saying is that your correctness criteria simply doesn't exist.
> >>>>>>>>>>>
> >>>>>>>>>> That is a Jackass (deceptive head games) thing to say when you already
> >>>>>>>>>> know that H merely needs to correctly predict what the complete and
> >>>>>>>>>> correct x86 emulation of its input would do and it need not actually to
> >>>>>>>>>> a complete emulation to do this. EXAMPLE BELOW
> >>>>>>>>>
> >>>>>>>>> *The* complete and correct emulation of the input to Ha(Pa,Pa) is performed by UTM(Pa,Pa) which halts, proving that Ha(Pa,Pa)==0 is wrong.
> >>>>>>>> The part that you keep erasing proves that you are a liar.
> >>>>>>>> You keep erasing it because you know that it proves you are a liar.
> >>>>>>>
> >>>>>>> Infinite_Loop was previously shown to be irrelevant.
> >>>>>>>
> >>>>>>>>
> >>>>>>>> Changing the subject to a completely different computation UTM(Pa,Pa)
> >>>>>>>> than the actual computation Ha(Pa,Pa) is the strawman deception.
> >>>>>>>> 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
> >>>>>>>
> >>>>>>> I'm not changing the subject. I'm just going by what you're saying.
> >>>>>>>
> >>>>>>>> THIS IS NECESSARILY TRUE THUS IMPOSSIBLY FALSE
> >>>>>>>> Every simulating halt decider correctly simulates its input until it
> >>>>>>>> correctly determines that this simulated input would never reach its
> >>>>>>>> final state.
> >>>>>>>
> >>>>>>> You keep changing this part. Sometimes you say "the" simulated input, sometimes "its" simulated input, sometimes "this" simulated input.
> >>>>>>>
> >>>>>>> *The* complete and correct simulation of the input to Ha(Pa,Pa) is by definition performed by UTM(Pa,Pa).
> >>>>>> That is a lie and you know it.
> >>>>>>
> >>>>>> The actual behavior of the actual input to H(P,P) is conclusively proven
> >>>>>> to diverge from the actual behavior of the actual input to H1(P,P) on
> >>>>>> the basis of the semantics of the x86 language.
> >>>>>
> >>>>> Then what is the first x86 instruction where the behavior of Ha(Pa,Pa) and UTM(Pa,Pa) differ?
> >>>>>
> >>>> [0000164a][00212749][0021274d] 83c408 add esp,+08
> >>>
> >>> FALSE
> >>>
> >>> The simulation performed by Ha is aborted before that instruction can be reached.
> >> Aborted or not the above instruction is the first instruction that
> >> differs.
> >
> > That instruction doesn't differ between the two simulations because Ha stopped before it got there.
> Perhaps you are simply not bright enough to understand that aborted or
> not the emulated input never reaches its "ret" instruction.