On 6/11/22 12:21 PM, olcott wrote:
> On 6/11/2022 10:31 AM, Mr Flibble wrote:
>> On Sat, 11 Jun 2022 10:29:06 -0500
>> olcott <NoOne@NoWhere.com> wrote:
>>
>>> On 6/11/2022 10:19 AM, Mr Flibble wrote:
>>>> On Sat, 11 Jun 2022 10:18:14 -0500
>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>> On 6/11/2022 10:12 AM, Mr Flibble wrote:
>>>>>> On Sat, 11 Jun 2022 10:11:37 -0500
>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>> On 6/11/2022 10:01 AM, Mr Flibble wrote:
>>>>>>>> On Sat, 11 Jun 2022 09:59:10 -0500
>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>> On 6/11/2022 9:55 AM, Mr Flibble wrote:
>>>>>>>>>> On Sat, 11 Jun 2022 09:52:34 -0500
>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>> On 6/11/2022 9:40 AM, Mr Flibble wrote:
>>>>>>>>>>>> On Sat, 11 Jun 2022 09:35:02 -0500
>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>> On 6/11/2022 7:03 AM, Mr Flibble wrote:
>>>>>>>>>>>>>> On Sat, 11 Jun 2022 00:03:37 -0500
>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> "H(P,P) as a pure function of its inputs is easy"
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If H as a "pure function" doesn't return a result to its
>>>>>>>>>>>>>> caller then it isn't a halt decider.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>
>>>>>>>>>>>>> The first H(P,P) that is invoked always returns a value to
>>>>>>>>>>>>> its caller. Subsequent recursive invocations are a part of
>>>>>>>>>>>>> infinitely nested simulation that must be aborted.
>>>>>>>>>>>> Nope. A pure function always returns the same value for the
>>>>>>>>>>>> same inputs:
>>>>>>>>>>>
>>>>>>>>>>> One can assume this when one has never bothered to think
>>>>>>>>>>> infinitely nested simulation all the way through. Parroting
>>>>>>>>>>> things that textbooks say is of no use because textbooks have
>>>>>>>>>>> never addressed this.
>>>>>>>>>>>
>>>>>>>>>>> The idea of a simulating halt decider that correctly detects
>>>>>>>>>>> infinitely nested simulation of the conventional halting
>>>>>>>>>>> problem proof counter-examples is brand new with me so you
>>>>>>>>>>> won't find any textbook that discusses it.
>>>>>>>>>>>
>>>>>>>>>>> The outer-most H(P,P) is a pure function of its inputs.
>>>>>>>>>>
>>>>>>>>>> Then the H that P calls is a different H because as I just
>>>>>>>>>> stated, "a pure function always returns the same value for the
>>>>>>>>>> same inputs".
>>>>>>>>>>
>>>>>>>>>> You can't just redefine accepted computer science concepts
>>>>>>>>>> such as what constitutes a pure function.
>>>>>>>>>
>>>>>>>>> It is the case that the outer H(P,P) is a pure function of its
>>>>>>>>> inputs.
>>>>>>>>
>>>>>>>> So your tactic now is simply to ignore what people say and just
>>>>>>>> repeat yourself? What is the point of doing that? Seems like a
>>>>>>>> waste of time to me.
>>>>>>>>
>>>>>>>> /Flibble
>>>>>>>
>>>>>>> We need actual PhD computer scientists that are experts in the
>>>>>>> theory of computation to evaluate these things. You guys are
>>>>>>> merely spouting off misonceptions.
>>>>>> LOL. Appeal to authority, a logical fallacy, mate.
>>>>>>
>>>>>> /Flibble
>>>>>
>>>>> People that only understand these things from the very shallow
>>>>> perspective of learned-by-rote can't see any of the relevant
>>>>> details.
>>>>>
>>>>> The best that they can do is parrot the words of others never
>>>>> realizing that these words do not apply to this case. No one has
>>>>> ever examined this case before.
>>>> More repetition and refusal to engage in reasoned debate. You've got
>>>> nothing.
>>>>
>>>> /Flibble
>>>
>>> You are spouting off things that are not true and too ignorant to
>>> understand that they are not true.
>> You have not addressed my argument: simply asserting that my argument
>> is false without explaining why just doesn't cut the mustard I'm afraid.
>>
>> You've got no argument. You've got nothing.
>>
>> /Flibble
>>
>
> The execution traces prove that I am correct that you simply "do not
> believe in" these execution traces is no rebuttal at all.
>

You mean the execution traces that aren't actually correct, because
theuy don't show what the x86 cpu is actually doing?

Namely, that the call H needs to show the actual execution of the code
of H, or at the very least, show that either H is doing a conditional
emulation or is doing an undonditional emulation (and thus can never
abort and never answer)

On 6/11/2022 11:36 AM, Richard Damon wrote:
> On 6/11/22 12:21 PM, olcott wrote:
>> On 6/11/2022 10:31 AM, Mr Flibble wrote:
>>> On Sat, 11 Jun 2022 10:29:06 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 6/11/2022 10:19 AM, Mr Flibble wrote:
>>>>> On Sat, 11 Jun 2022 10:18:14 -0500
>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>> On 6/11/2022 10:12 AM, Mr Flibble wrote:
>>>>>>> On Sat, 11 Jun 2022 10:11:37 -0500
>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>> On 6/11/2022 10:01 AM, Mr Flibble wrote:
>>>>>>>>> On Sat, 11 Jun 2022 09:59:10 -0500
>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>> On 6/11/2022 9:55 AM, Mr Flibble wrote:
>>>>>>>>>>> On Sat, 11 Jun 2022 09:52:34 -0500
>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>> On 6/11/2022 9:40 AM, Mr Flibble wrote:
>>>>>>>>>>>>> On Sat, 11 Jun 2022 09:35:02 -0500
>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>> On 6/11/2022 7:03 AM, Mr Flibble wrote:
>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 00:03:37 -0500
>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> "H(P,P) as a pure function of its inputs is easy"
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If H as a "pure function" doesn't return a result to its
>>>>>>>>>>>>>>> caller then it isn't a halt decider.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The first H(P,P) that is invoked always returns a value to
>>>>>>>>>>>>>> its caller. Subsequent recursive invocations are a part of
>>>>>>>>>>>>>> infinitely nested simulation that must be aborted.
>>>>>>>>>>>>> Nope. A pure function always returns the same value for the
>>>>>>>>>>>>> same inputs:
>>>>>>>>>>>>
>>>>>>>>>>>> One can assume this when one has never bothered to think
>>>>>>>>>>>> infinitely nested simulation all the way through. Parroting
>>>>>>>>>>>> things that textbooks say is of no use because textbooks have
>>>>>>>>>>>> never addressed this.
>>>>>>>>>>>>
>>>>>>>>>>>> The idea of a simulating halt decider that correctly detects
>>>>>>>>>>>> infinitely nested simulation of the conventional halting
>>>>>>>>>>>> problem proof counter-examples is brand new with me so you
>>>>>>>>>>>> won't find any textbook that discusses it.
>>>>>>>>>>>>
>>>>>>>>>>>> The outer-most H(P,P) is a pure function of its inputs.
>>>>>>>>>>>
>>>>>>>>>>> Then the H that P calls is a different H because as I just
>>>>>>>>>>> stated, "a pure function always returns the same value for the
>>>>>>>>>>> same inputs".
>>>>>>>>>>>
>>>>>>>>>>> You can't just redefine accepted computer science concepts
>>>>>>>>>>> such as what constitutes a pure function.
>>>>>>>>>>
>>>>>>>>>> It is the case that the outer H(P,P) is a pure function of its
>>>>>>>>>> inputs.
>>>>>>>>>
>>>>>>>>> So your tactic now is simply to ignore what people say and just
>>>>>>>>> repeat yourself? What is the point of doing that? Seems like a
>>>>>>>>> waste of time to me.
>>>>>>>>>
>>>>>>>>> /Flibble
>>>>>>>>
>>>>>>>> We need actual PhD computer scientists that are experts in the
>>>>>>>> theory of computation to evaluate these things. You guys are
>>>>>>>> merely spouting off misonceptions.
>>>>>>> LOL. Appeal to authority, a logical fallacy, mate.
>>>>>>>
>>>>>>> /Flibble
>>>>>>
>>>>>> People that only understand these things from the very shallow
>>>>>> perspective of learned-by-rote can't see any of the relevant
>>>>>> details.
>>>>>>
>>>>>> The best that they can do is parrot the words of others never
>>>>>> realizing that these words do not apply to this case. No one has
>>>>>> ever examined this case before.
>>>>> More repetition and refusal to engage in reasoned debate. You've got
>>>>> nothing.
>>>>>
>>>>> /Flibble
>>>>
>>>> You are spouting off things that are not true and too ignorant to
>>>> understand that they are not true.
>>> You have not addressed my argument: simply asserting that my argument
>>> is false without explaining why just doesn't cut the mustard I'm afraid.
>>>
>>> You've got no argument. You've got nothing.
>>>
>>> /Flibble
>>>
>>
>> The execution traces prove that I am correct that you simply "do not
>> believe in" these execution traces is no rebuttal at all.
>>
>
> You mean the execution traces that aren't actually correct, because
> theuy don't show what the x86 cpu is actually doing?

This is false. Why lie?

--
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/11/22 12:42 PM, olcott wrote:
> On 6/11/2022 11:36 AM, Richard Damon wrote:
>> On 6/11/22 12:21 PM, olcott wrote:
>>> On 6/11/2022 10:31 AM, Mr Flibble wrote:
>>>> On Sat, 11 Jun 2022 10:29:06 -0500
>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>
>>>>> On 6/11/2022 10:19 AM, Mr Flibble wrote:
>>>>>> On Sat, 11 Jun 2022 10:18:14 -0500
>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>> On 6/11/2022 10:12 AM, Mr Flibble wrote:
>>>>>>>> On Sat, 11 Jun 2022 10:11:37 -0500
>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>> On 6/11/2022 10:01 AM, Mr Flibble wrote:
>>>>>>>>>> On Sat, 11 Jun 2022 09:59:10 -0500
>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>> On 6/11/2022 9:55 AM, Mr Flibble wrote:
>>>>>>>>>>>> On Sat, 11 Jun 2022 09:52:34 -0500
>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>> On 6/11/2022 9:40 AM, Mr Flibble wrote:
>>>>>>>>>>>>>> On Sat, 11 Jun 2022 09:35:02 -0500
>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>> On 6/11/2022 7:03 AM, Mr Flibble wrote:
>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 00:03:37 -0500
>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> "H(P,P) as a pure function of its inputs is easy"
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> If H as a "pure function" doesn't return a result to its
>>>>>>>>>>>>>>>> caller then it isn't a halt decider.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The first H(P,P) that is invoked always returns a value to
>>>>>>>>>>>>>>> its caller. Subsequent recursive invocations are a part of
>>>>>>>>>>>>>>> infinitely nested simulation that must be aborted.
>>>>>>>>>>>>>> Nope. A pure function always returns the same value for the
>>>>>>>>>>>>>> same inputs:
>>>>>>>>>>>>>
>>>>>>>>>>>>> One can assume this when one has never bothered to think
>>>>>>>>>>>>> infinitely nested simulation all the way through. Parroting
>>>>>>>>>>>>> things that textbooks say is of no use because textbooks have
>>>>>>>>>>>>> never addressed this.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The idea of a simulating halt decider that correctly detects
>>>>>>>>>>>>> infinitely nested simulation of the conventional halting
>>>>>>>>>>>>> problem proof counter-examples is brand new with me so you
>>>>>>>>>>>>> won't find any textbook that discusses it.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The outer-most H(P,P) is a pure function of its inputs.
>>>>>>>>>>>>
>>>>>>>>>>>> Then the H that P calls is a different H because as I just
>>>>>>>>>>>> stated, "a pure function always returns the same value for the
>>>>>>>>>>>> same inputs".
>>>>>>>>>>>>
>>>>>>>>>>>> You can't just redefine accepted computer science concepts
>>>>>>>>>>>> such as what constitutes a pure function.
>>>>>>>>>>>
>>>>>>>>>>> It is the case that the outer H(P,P) is a pure function of its
>>>>>>>>>>> inputs.
>>>>>>>>>>
>>>>>>>>>> So your tactic now is simply to ignore what people say and just
>>>>>>>>>> repeat yourself? What is the point of doing that? Seems like a
>>>>>>>>>> waste of time to me.
>>>>>>>>>>
>>>>>>>>>> /Flibble
>>>>>>>>>
>>>>>>>>> We need actual PhD computer scientists that are experts in the
>>>>>>>>> theory of computation to evaluate these things. You guys are
>>>>>>>>> merely spouting off misonceptions.
>>>>>>>> LOL. Appeal to authority, a logical fallacy, mate.
>>>>>>>>
>>>>>>>> /Flibble
>>>>>>>
>>>>>>> People that only understand these things from the very shallow
>>>>>>> perspective of learned-by-rote can't see any of the relevant
>>>>>>> details.
>>>>>>>
>>>>>>> The best that they can do is parrot the words of others never
>>>>>>> realizing that these words do not apply to this case. No one has
>>>>>>> ever examined this case before.
>>>>>> More repetition and refusal to engage in reasoned debate. You've got
>>>>>> nothing.
>>>>>>
>>>>>> /Flibble
>>>>>
>>>>> You are spouting off things that are not true and too ignorant to
>>>>> understand that they are not true.
>>>> You have not addressed my argument: simply asserting that my argument
>>>> is false without explaining why just doesn't cut the mustard I'm
>>>> afraid.
>>>>
>>>> You've got no argument. You've got nothing.
>>>>
>>>> /Flibble
>>>>
>>>
>>> The execution traces prove that I am correct that you simply "do not
>>> believe in" these execution traces is no rebuttal at all.
>>>
>>
>> You mean the execution traces that aren't actually correct, because
>> theuy don't show what the x86 cpu is actually doing?
>
> This is false. Why lie?
>
>

I'm not. That is the definition of a correct trace.

Why do YOU lie.

There is NO x86 processor that after execution the instruction Call H
doesn't next execute the first instruction at H, and therefore a correct
trace of that code needs to show that instruction being executed.

That you don't, just means that what you are showing is BY DEFINITION,
not a correct x86 emulation trace of the code.

You just don't seem to know the meaning of the words you use.

How do YOU define a correct x86 emulation trace if it isn't what the x86
processor would do.

Remember, to the x86 processor, "H" isn't special, so it doesn't "skip"
that code.

On 6/11/2022 11:46 AM, Richard Damon wrote:
> On 6/11/22 12:42 PM, olcott wrote:
>> On 6/11/2022 11:36 AM, Richard Damon wrote:
>>> On 6/11/22 12:21 PM, olcott wrote:
>>>> On 6/11/2022 10:31 AM, Mr Flibble wrote:
>>>>> On Sat, 11 Jun 2022 10:29:06 -0500
>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>
>>>>>> On 6/11/2022 10:19 AM, Mr Flibble wrote:
>>>>>>> On Sat, 11 Jun 2022 10:18:14 -0500
>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>> On 6/11/2022 10:12 AM, Mr Flibble wrote:
>>>>>>>>> On Sat, 11 Jun 2022 10:11:37 -0500
>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>> On 6/11/2022 10:01 AM, Mr Flibble wrote:
>>>>>>>>>>> On Sat, 11 Jun 2022 09:59:10 -0500
>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>> On 6/11/2022 9:55 AM, Mr Flibble wrote:
>>>>>>>>>>>>> On Sat, 11 Jun 2022 09:52:34 -0500
>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>> On 6/11/2022 9:40 AM, Mr Flibble wrote:
>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 09:35:02 -0500
>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>> On 6/11/2022 7:03 AM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 00:03:37 -0500
>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> "H(P,P) as a pure function of its inputs is easy"
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> If H as a "pure function" doesn't return a result to its
>>>>>>>>>>>>>>>>> caller then it isn't a halt decider.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The first H(P,P) that is invoked always returns a value to
>>>>>>>>>>>>>>>> its caller. Subsequent recursive invocations are a part of
>>>>>>>>>>>>>>>> infinitely nested simulation that must be aborted.
>>>>>>>>>>>>>>> Nope. A pure function always returns the same value for the
>>>>>>>>>>>>>>> same inputs:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> One can assume this when one has never bothered to think
>>>>>>>>>>>>>> infinitely nested simulation all the way through. Parroting
>>>>>>>>>>>>>> things that textbooks say is of no use because textbooks have
>>>>>>>>>>>>>> never addressed this.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The idea of a simulating halt decider that correctly detects
>>>>>>>>>>>>>> infinitely nested simulation of the conventional halting
>>>>>>>>>>>>>> problem proof counter-examples is brand new with me so you
>>>>>>>>>>>>>> won't find any textbook that discusses it.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The outer-most H(P,P) is a pure function of its inputs.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Then the H that P calls is a different H because as I just
>>>>>>>>>>>>> stated, "a pure function always returns the same value for the
>>>>>>>>>>>>> same inputs".
>>>>>>>>>>>>>
>>>>>>>>>>>>> You can't just redefine accepted computer science concepts
>>>>>>>>>>>>> such as what constitutes a pure function.
>>>>>>>>>>>>
>>>>>>>>>>>> It is the case that the outer H(P,P) is a pure function of its
>>>>>>>>>>>> inputs.
>>>>>>>>>>>
>>>>>>>>>>> So your tactic now is simply to ignore what people say and just
>>>>>>>>>>> repeat yourself? What is the point of doing that? Seems like a
>>>>>>>>>>> waste of time to me.
>>>>>>>>>>>
>>>>>>>>>>> /Flibble
>>>>>>>>>>
>>>>>>>>>> We need actual PhD computer scientists that are experts in the
>>>>>>>>>> theory of computation to evaluate these things. You guys are
>>>>>>>>>> merely spouting off misonceptions.
>>>>>>>>> LOL. Appeal to authority, a logical fallacy, mate.
>>>>>>>>>
>>>>>>>>> /Flibble
>>>>>>>>
>>>>>>>> People that only understand these things from the very shallow
>>>>>>>> perspective of learned-by-rote can't see any of the relevant
>>>>>>>> details.
>>>>>>>>
>>>>>>>> The best that they can do is parrot the words of others never
>>>>>>>> realizing that these words do not apply to this case. No one has
>>>>>>>> ever examined this case before.
>>>>>>> More repetition and refusal to engage in reasoned debate. You've got
>>>>>>> nothing.
>>>>>>>
>>>>>>> /Flibble
>>>>>>
>>>>>> You are spouting off things that are not true and too ignorant to
>>>>>> understand that they are not true.
>>>>> You have not addressed my argument: simply asserting that my argument
>>>>> is false without explaining why just doesn't cut the mustard I'm
>>>>> afraid.
>>>>>
>>>>> You've got no argument. You've got nothing.
>>>>>
>>>>> /Flibble
>>>>>
>>>>
>>>> The execution traces prove that I am correct that you simply "do not
>>>> believe in" these execution traces is no rebuttal at all.
>>>>
>>>
>>> You mean the execution traces that aren't actually correct, because
>>> theuy don't show what the x86 cpu is actually doing?
>>
>> This is false. Why lie?
>>
>>
>
> I'm not. That is the definition of a correct trace.
>
> Why do YOU lie.

This is showing what the x86 processor is doing therefore your claim
that it is not shown is proven to be false. WHY LIE ?

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[00001307][00102190][00000000] 55 push ebp
[00001308][00102190][00000000] 8bec mov ebp,esp
[0000130a][0010218c][000012e7] 68e7120000 push 000012e7 // push P
[0000130f][00102188][00001314] e8d3ffffff call 000012e7 // call P
[000012e7][00102184][00102190] 55 push ebp // enter executed P
[000012e8][00102184][00102190] 8bec mov ebp,esp
[000012ea][00102184][00102190] 8b4508 mov eax,[ebp+08]
[000012ed][00102180][000012e7] 50 push eax // push P
[000012ee][00102180][000012e7] 8b4d08 mov ecx,[ebp+08]
[000012f1][0010217c][000012e7] 51 push ecx // push P
[000012f2][00102178][000012f7] e880feffff call 00001177 // call H

--
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/11/22 12:50 PM, olcott wrote:
> On 6/11/2022 11:46 AM, Richard Damon wrote:
>> On 6/11/22 12:42 PM, olcott wrote:
>>> On 6/11/2022 11:36 AM, Richard Damon wrote:
>>>> On 6/11/22 12:21 PM, olcott wrote:
>>>>> On 6/11/2022 10:31 AM, Mr Flibble wrote:
>>>>>> On Sat, 11 Jun 2022 10:29:06 -0500
>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>
>>>>>>> On 6/11/2022 10:19 AM, Mr Flibble wrote:
>>>>>>>> On Sat, 11 Jun 2022 10:18:14 -0500
>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>> On 6/11/2022 10:12 AM, Mr Flibble wrote:
>>>>>>>>>> On Sat, 11 Jun 2022 10:11:37 -0500
>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>> On 6/11/2022 10:01 AM, Mr Flibble wrote:
>>>>>>>>>>>> On Sat, 11 Jun 2022 09:59:10 -0500
>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>> On 6/11/2022 9:55 AM, Mr Flibble wrote:
>>>>>>>>>>>>>> On Sat, 11 Jun 2022 09:52:34 -0500
>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>> On 6/11/2022 9:40 AM, Mr Flibble wrote:
>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 09:35:02 -0500
>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>> On 6/11/2022 7:03 AM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 00:03:37 -0500
>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> "H(P,P) as a pure function of its inputs is easy"
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> If H as a "pure function" doesn't return a result to its
>>>>>>>>>>>>>>>>>> caller then it isn't a halt decider.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The first H(P,P) that is invoked always returns a value to
>>>>>>>>>>>>>>>>> its caller. Subsequent recursive invocations are a part of
>>>>>>>>>>>>>>>>> infinitely nested simulation that must be aborted.
>>>>>>>>>>>>>>>> Nope. A pure function always returns the same value for the
>>>>>>>>>>>>>>>> same inputs:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> One can assume this when one has never bothered to think
>>>>>>>>>>>>>>> infinitely nested simulation all the way through. Parroting
>>>>>>>>>>>>>>> things that textbooks say is of no use because textbooks
>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>> never addressed this.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The idea of a simulating halt decider that correctly detects
>>>>>>>>>>>>>>> infinitely nested simulation of the conventional halting
>>>>>>>>>>>>>>> problem proof counter-examples is brand new with me so you
>>>>>>>>>>>>>>> won't find any textbook that discusses it.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The outer-most H(P,P) is a pure function of its inputs.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Then the H that P calls is a different H because as I just
>>>>>>>>>>>>>> stated, "a pure function always returns the same value for
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> same inputs".
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You can't just redefine accepted computer science concepts
>>>>>>>>>>>>>> such as what constitutes a pure function.
>>>>>>>>>>>>>
>>>>>>>>>>>>> It is the case that the outer H(P,P) is a pure function of its
>>>>>>>>>>>>> inputs.
>>>>>>>>>>>>
>>>>>>>>>>>> So your tactic now is simply to ignore what people say and just
>>>>>>>>>>>> repeat yourself? What is the point of doing that? Seems like a
>>>>>>>>>>>> waste of time to me.
>>>>>>>>>>>>
>>>>>>>>>>>> /Flibble
>>>>>>>>>>>
>>>>>>>>>>> We need actual PhD computer scientists that are experts in the
>>>>>>>>>>> theory of computation to evaluate these things. You guys are
>>>>>>>>>>> merely spouting off misonceptions.
>>>>>>>>>> LOL. Appeal to authority, a logical fallacy, mate.
>>>>>>>>>>
>>>>>>>>>> /Flibble
>>>>>>>>>
>>>>>>>>> People that only understand these things from the very shallow
>>>>>>>>> perspective of learned-by-rote can't see any of the relevant
>>>>>>>>> details.
>>>>>>>>>
>>>>>>>>> The best that they can do is parrot the words of others never
>>>>>>>>> realizing that these words do not apply to this case. No one has
>>>>>>>>> ever examined this case before.
>>>>>>>> More repetition and refusal to engage in reasoned debate. You've
>>>>>>>> got
>>>>>>>> nothing.
>>>>>>>>
>>>>>>>> /Flibble
>>>>>>>
>>>>>>> You are spouting off things that are not true and too ignorant to
>>>>>>> understand that they are not true.
>>>>>> You have not addressed my argument: simply asserting that my argument
>>>>>> is false without explaining why just doesn't cut the mustard I'm
>>>>>> afraid.
>>>>>>
>>>>>> You've got no argument. You've got nothing.
>>>>>>
>>>>>> /Flibble
>>>>>>
>>>>>
>>>>> The execution traces prove that I am correct that you simply "do
>>>>> not believe in" these execution traces is no rebuttal at all.
>>>>>
>>>>
>>>> You mean the execution traces that aren't actually correct, because
>>>> theuy don't show what the x86 cpu is actually doing?
>>>
>>> This is false. Why lie?
>>>
>>>
>>
>> I'm not. That is the definition of a correct trace.
>>
>> Why do YOU lie.
>
> This is showing what the x86 processor is doing therefore your claim
> that it is not shown is proven to be false. WHY LIE ?
>
>  machine   stack     stack     machine    assembly
>  address   address   data      code       language
>  ========  ========  ========  =========  =============
> [00001307][00102190][00000000] 55         push ebp
> [00001308][00102190][00000000] 8bec       mov ebp,esp
> [0000130a][0010218c][000012e7] 68e7120000 push 000012e7 // push P
> [0000130f][00102188][00001314] e8d3ffffff call 000012e7 // call P
> [000012e7][00102184][00102190] 55         push ebp      // enter executed P
> [000012e8][00102184][00102190] 8bec       mov ebp,esp
> [000012ea][00102184][00102190] 8b4508     mov eax,[ebp+08]
> [000012ed][00102180][000012e7] 50         push eax      // push P
> [000012ee][00102180][000012e7] 8b4d08     mov ecx,[ebp+08]
> [000012f1][0010217c][000012e7] 51         push ecx      // push P
> [000012f2][00102178][000012f7] e880feffff call 00001177 // call H
>
>

On 6/11/2022 12:04 PM, Richard Damon wrote:
> On 6/11/22 12:50 PM, olcott wrote:
>> On 6/11/2022 11:46 AM, Richard Damon wrote:
>>> On 6/11/22 12:42 PM, olcott wrote:
>>>> On 6/11/2022 11:36 AM, Richard Damon wrote:
>>>>> On 6/11/22 12:21 PM, olcott wrote:
>>>>>> On 6/11/2022 10:31 AM, Mr Flibble wrote:
>>>>>>> On Sat, 11 Jun 2022 10:29:06 -0500
>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>
>>>>>>>> On 6/11/2022 10:19 AM, Mr Flibble wrote:
>>>>>>>>> On Sat, 11 Jun 2022 10:18:14 -0500
>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>> On 6/11/2022 10:12 AM, Mr Flibble wrote:
>>>>>>>>>>> On Sat, 11 Jun 2022 10:11:37 -0500
>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>> On 6/11/2022 10:01 AM, Mr Flibble wrote:
>>>>>>>>>>>>> On Sat, 11 Jun 2022 09:59:10 -0500
>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>> On 6/11/2022 9:55 AM, Mr Flibble wrote:
>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 09:52:34 -0500
>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>> On 6/11/2022 9:40 AM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 09:35:02 -0500
>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>> On 6/11/2022 7:03 AM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 00:03:37 -0500
>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> "H(P,P) as a pure function of its inputs is easy"
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> If H as a "pure function" doesn't return a result to its
>>>>>>>>>>>>>>>>>>> caller then it isn't a halt decider.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The first H(P,P) that is invoked always returns a
>>>>>>>>>>>>>>>>>> value to
>>>>>>>>>>>>>>>>>> its caller. Subsequent recursive invocations are a
>>>>>>>>>>>>>>>>>> part of
>>>>>>>>>>>>>>>>>> infinitely nested simulation that must be aborted.
>>>>>>>>>>>>>>>>> Nope. A pure function always returns the same value for
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> same inputs:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> One can assume this when one has never bothered to think
>>>>>>>>>>>>>>>> infinitely nested simulation all the way through. Parroting
>>>>>>>>>>>>>>>> things that textbooks say is of no use because textbooks
>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>> never addressed this.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The idea of a simulating halt decider that correctly
>>>>>>>>>>>>>>>> detects
>>>>>>>>>>>>>>>> infinitely nested simulation of the conventional halting
>>>>>>>>>>>>>>>> problem proof counter-examples is brand new with me so you
>>>>>>>>>>>>>>>> won't find any textbook that discusses it.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The outer-most H(P,P) is a pure function of its inputs.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Then the H that P calls is a different H because as I just
>>>>>>>>>>>>>>> stated, "a pure function always returns the same value
>>>>>>>>>>>>>>> for the
>>>>>>>>>>>>>>> same inputs".
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You can't just redefine accepted computer science concepts
>>>>>>>>>>>>>>> such as what constitutes a pure function.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It is the case that the outer H(P,P) is a pure function of
>>>>>>>>>>>>>> its
>>>>>>>>>>>>>> inputs.
>>>>>>>>>>>>>
>>>>>>>>>>>>> So your tactic now is simply to ignore what people say and
>>>>>>>>>>>>> just
>>>>>>>>>>>>> repeat yourself? What is the point of doing that? Seems like a
>>>>>>>>>>>>> waste of time to me.
>>>>>>>>>>>>>
>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>
>>>>>>>>>>>> We need actual PhD computer scientists that are experts in the
>>>>>>>>>>>> theory of computation to evaluate these things. You guys are
>>>>>>>>>>>> merely spouting off misonceptions.
>>>>>>>>>>> LOL. Appeal to authority, a logical fallacy, mate.
>>>>>>>>>>>
>>>>>>>>>>> /Flibble
>>>>>>>>>>
>>>>>>>>>> People that only understand these things from the very shallow
>>>>>>>>>> perspective of learned-by-rote can't see any of the relevant
>>>>>>>>>> details.
>>>>>>>>>>
>>>>>>>>>> The best that they can do is parrot the words of others never
>>>>>>>>>> realizing that these words do not apply to this case. No one has
>>>>>>>>>> ever examined this case before.
>>>>>>>>> More repetition and refusal to engage in reasoned debate.
>>>>>>>>> You've got
>>>>>>>>> nothing.
>>>>>>>>>
>>>>>>>>> /Flibble
>>>>>>>>
>>>>>>>> You are spouting off things that are not true and too ignorant to
>>>>>>>> understand that they are not true.
>>>>>>> You have not addressed my argument: simply asserting that my
>>>>>>> argument
>>>>>>> is false without explaining why just doesn't cut the mustard I'm
>>>>>>> afraid.
>>>>>>>
>>>>>>> You've got no argument. You've got nothing.
>>>>>>>
>>>>>>> /Flibble
>>>>>>>
>>>>>>
>>>>>> The execution traces prove that I am correct that you simply "do
>>>>>> not believe in" these execution traces is no rebuttal at all.
>>>>>>
>>>>>
>>>>> You mean the execution traces that aren't actually correct, because
>>>>> theuy don't show what the x86 cpu is actually doing?
>>>>
>>>> This is false. Why lie?
>>>>
>>>>
>>>
>>> I'm not. That is the definition of a correct trace.
>>>
>>> Why do YOU lie.
>>
>> This is showing what the x86 processor is doing therefore your claim
>> that it is not shown is proven to be false. WHY LIE ?
>>
>>   machine   stack     stack     machine    assembly
>>   address   address   data      code       language
>>   ========  ========  ========  =========  =============
>> [00001307][00102190][00000000] 55         push ebp
>> [00001308][00102190][00000000] 8bec       mov ebp,esp
>> [0000130a][0010218c][000012e7] 68e7120000 push 000012e7 // push P
>> [0000130f][00102188][00001314] e8d3ffffff call 000012e7 // call P
>> [000012e7][00102184][00102190] 55         push ebp      // enter
>> executed P
>> [000012e8][00102184][00102190] 8bec       mov ebp,esp
>> [000012ea][00102184][00102190] 8b4508     mov eax,[ebp+08]
>> [000012ed][00102180][000012e7] 50         push eax      // push P
>> [000012ee][00102180][000012e7] 8b4d08     mov ecx,[ebp+08]
>> [000012f1][0010217c][000012e7] 51         push ecx      // push P
>> [000012f2][00102178][000012f7] e880feffff call 00001177 // call H
>>
>>
>
>
> Right, so what is the next instruction in the trace, it NEEDS to be the
> execution of the instruciton at 00001177, as that is what the x86
> processor does.

On 6/11/22 1:09 PM, olcott wrote:
> On 6/11/2022 12:04 PM, Richard Damon wrote:
>> On 6/11/22 12:50 PM, olcott wrote:
>>> On 6/11/2022 11:46 AM, Richard Damon wrote:
>>>> On 6/11/22 12:42 PM, olcott wrote:
>>>>> On 6/11/2022 11:36 AM, Richard Damon wrote:
>>>>>> On 6/11/22 12:21 PM, olcott wrote:
>>>>>>> On 6/11/2022 10:31 AM, Mr Flibble wrote:
>>>>>>>> On Sat, 11 Jun 2022 10:29:06 -0500
>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>
>>>>>>>>> On 6/11/2022 10:19 AM, Mr Flibble wrote:
>>>>>>>>>> On Sat, 11 Jun 2022 10:18:14 -0500
>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>> On 6/11/2022 10:12 AM, Mr Flibble wrote:
>>>>>>>>>>>> On Sat, 11 Jun 2022 10:11:37 -0500
>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>> On 6/11/2022 10:01 AM, Mr Flibble wrote:
>>>>>>>>>>>>>> On Sat, 11 Jun 2022 09:59:10 -0500
>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>> On 6/11/2022 9:55 AM, Mr Flibble wrote:
>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 09:52:34 -0500
>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>> On 6/11/2022 9:40 AM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 09:35:02 -0500
>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>> On 6/11/2022 7:03 AM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 00:03:37 -0500
>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> "H(P,P) as a pure function of its inputs is easy"
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> If H as a "pure function" doesn't return a result to
>>>>>>>>>>>>>>>>>>>> its
>>>>>>>>>>>>>>>>>>>> caller then it isn't a halt decider.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The first H(P,P) that is invoked always returns a
>>>>>>>>>>>>>>>>>>> value to
>>>>>>>>>>>>>>>>>>> its caller. Subsequent recursive invocations are a
>>>>>>>>>>>>>>>>>>> part of
>>>>>>>>>>>>>>>>>>> infinitely nested simulation that must be aborted.
>>>>>>>>>>>>>>>>>> Nope. A pure function always returns the same value
>>>>>>>>>>>>>>>>>> for the
>>>>>>>>>>>>>>>>>> same inputs:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> One can assume this when one has never bothered to think
>>>>>>>>>>>>>>>>> infinitely nested simulation all the way through.
>>>>>>>>>>>>>>>>> Parroting
>>>>>>>>>>>>>>>>> things that textbooks say is of no use because
>>>>>>>>>>>>>>>>> textbooks have
>>>>>>>>>>>>>>>>> never addressed this.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The idea of a simulating halt decider that correctly
>>>>>>>>>>>>>>>>> detects
>>>>>>>>>>>>>>>>> infinitely nested simulation of the conventional halting
>>>>>>>>>>>>>>>>> problem proof counter-examples is brand new with me so you
>>>>>>>>>>>>>>>>> won't find any textbook that discusses it.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The outer-most H(P,P) is a pure function of its inputs.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Then the H that P calls is a different H because as I just
>>>>>>>>>>>>>>>> stated, "a pure function always returns the same value
>>>>>>>>>>>>>>>> for the
>>>>>>>>>>>>>>>> same inputs".
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> You can't just redefine accepted computer science concepts
>>>>>>>>>>>>>>>> such as what constitutes a pure function.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It is the case that the outer H(P,P) is a pure function
>>>>>>>>>>>>>>> of its
>>>>>>>>>>>>>>> inputs.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So your tactic now is simply to ignore what people say and
>>>>>>>>>>>>>> just
>>>>>>>>>>>>>> repeat yourself? What is the point of doing that? Seems
>>>>>>>>>>>>>> like a
>>>>>>>>>>>>>> waste of time to me.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>
>>>>>>>>>>>>> We need actual PhD computer scientists that are experts in the
>>>>>>>>>>>>> theory of computation to evaluate these things. You guys are
>>>>>>>>>>>>> merely spouting off misonceptions.
>>>>>>>>>>>> LOL. Appeal to authority, a logical fallacy, mate.
>>>>>>>>>>>>
>>>>>>>>>>>> /Flibble
>>>>>>>>>>>
>>>>>>>>>>> People that only understand these things from the very shallow
>>>>>>>>>>> perspective of learned-by-rote can't see any of the relevant
>>>>>>>>>>> details.
>>>>>>>>>>>
>>>>>>>>>>> The best that they can do is parrot the words of others never
>>>>>>>>>>> realizing that these words do not apply to this case. No one has
>>>>>>>>>>> ever examined this case before.
>>>>>>>>>> More repetition and refusal to engage in reasoned debate.
>>>>>>>>>> You've got
>>>>>>>>>> nothing.
>>>>>>>>>>
>>>>>>>>>> /Flibble
>>>>>>>>>
>>>>>>>>> You are spouting off things that are not true and too ignorant to
>>>>>>>>> understand that they are not true.
>>>>>>>> You have not addressed my argument: simply asserting that my
>>>>>>>> argument
>>>>>>>> is false without explaining why just doesn't cut the mustard I'm
>>>>>>>> afraid.
>>>>>>>>
>>>>>>>> You've got no argument. You've got nothing.
>>>>>>>>
>>>>>>>> /Flibble
>>>>>>>>
>>>>>>>
>>>>>>> The execution traces prove that I am correct that you simply "do
>>>>>>> not believe in" these execution traces is no rebuttal at all.
>>>>>>>
>>>>>>
>>>>>> You mean the execution traces that aren't actually correct,
>>>>>> because theuy don't show what the x86 cpu is actually doing?
>>>>>
>>>>> This is false. Why lie?
>>>>>
>>>>>
>>>>
>>>> I'm not. That is the definition of a correct trace.
>>>>
>>>> Why do YOU lie.
>>>
>>> This is showing what the x86 processor is doing therefore your claim
>>> that it is not shown is proven to be false. WHY LIE ?
>>>
>>>   machine   stack     stack     machine    assembly
>>>   address   address   data      code       language
>>>   ========  ========  ========  =========  =============
>>> [00001307][00102190][00000000] 55         push ebp
>>> [00001308][00102190][00000000] 8bec       mov ebp,esp
>>> [0000130a][0010218c][000012e7] 68e7120000 push 000012e7 // push P
>>> [0000130f][00102188][00001314] e8d3ffffff call 000012e7 // call P
>>> [000012e7][00102184][00102190] 55         push ebp      // enter
>>> executed P
>>> [000012e8][00102184][00102190] 8bec       mov ebp,esp
>>> [000012ea][00102184][00102190] 8b4508     mov eax,[ebp+08]
>>> [000012ed][00102180][000012e7] 50         push eax      // push P
>>> [000012ee][00102180][000012e7] 8b4d08     mov ecx,[ebp+08]
>>> [000012f1][0010217c][000012e7] 51         push ecx      // push P
>>> [000012f2][00102178][000012f7] e880feffff call 00001177 // call H
>>>
>>>
>>
>>
>> Right, so what is the next instruction in the trace, it NEEDS to be
>> the execution of the instruciton at 00001177, as that is what the x86
>> processor does.
>
> >>>>> theuy don't show what the x86 cpu is actually doing?
>
> Liar
>

On 6/11/2022 1:26 PM, Richard Damon wrote:
> On 6/11/22 1:09 PM, olcott wrote:
>> On 6/11/2022 12:04 PM, Richard Damon wrote:
>>> On 6/11/22 12:50 PM, olcott wrote:
>>>> On 6/11/2022 11:46 AM, Richard Damon wrote:
>>>>> On 6/11/22 12:42 PM, olcott wrote:
>>>>>> On 6/11/2022 11:36 AM, Richard Damon wrote:
>>>>>>> On 6/11/22 12:21 PM, olcott wrote:
>>>>>>>> On 6/11/2022 10:31 AM, Mr Flibble wrote:
>>>>>>>>> On Sat, 11 Jun 2022 10:29:06 -0500
>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>
>>>>>>>>>> On 6/11/2022 10:19 AM, Mr Flibble wrote:
>>>>>>>>>>> On Sat, 11 Jun 2022 10:18:14 -0500
>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>> On 6/11/2022 10:12 AM, Mr Flibble wrote:
>>>>>>>>>>>>> On Sat, 11 Jun 2022 10:11:37 -0500
>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>> On 6/11/2022 10:01 AM, Mr Flibble wrote:
>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 09:59:10 -0500
>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>> On 6/11/2022 9:55 AM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 09:52:34 -0500
>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>> On 6/11/2022 9:40 AM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 09:35:02 -0500
>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>> On 6/11/2022 7:03 AM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 00:03:37 -0500
>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> "H(P,P) as a pure function of its inputs is easy"
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> If H as a "pure function" doesn't return a result
>>>>>>>>>>>>>>>>>>>>> to its
>>>>>>>>>>>>>>>>>>>>> caller then it isn't a halt decider.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> The first H(P,P) that is invoked always returns a
>>>>>>>>>>>>>>>>>>>> value to
>>>>>>>>>>>>>>>>>>>> its caller. Subsequent recursive invocations are a
>>>>>>>>>>>>>>>>>>>> part of
>>>>>>>>>>>>>>>>>>>> infinitely nested simulation that must be aborted.
>>>>>>>>>>>>>>>>>>> Nope. A pure function always returns the same value
>>>>>>>>>>>>>>>>>>> for the
>>>>>>>>>>>>>>>>>>> same inputs:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> One can assume this when one has never bothered to think
>>>>>>>>>>>>>>>>>> infinitely nested simulation all the way through.
>>>>>>>>>>>>>>>>>> Parroting
>>>>>>>>>>>>>>>>>> things that textbooks say is of no use because
>>>>>>>>>>>>>>>>>> textbooks have
>>>>>>>>>>>>>>>>>> never addressed this.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The idea of a simulating halt decider that correctly
>>>>>>>>>>>>>>>>>> detects
>>>>>>>>>>>>>>>>>> infinitely nested simulation of the conventional halting
>>>>>>>>>>>>>>>>>> problem proof counter-examples is brand new with me so
>>>>>>>>>>>>>>>>>> you
>>>>>>>>>>>>>>>>>> won't find any textbook that discusses it.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The outer-most H(P,P) is a pure function of its inputs.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Then the H that P calls is a different H because as I just
>>>>>>>>>>>>>>>>> stated, "a pure function always returns the same value
>>>>>>>>>>>>>>>>> for the
>>>>>>>>>>>>>>>>> same inputs".
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> You can't just redefine accepted computer science concepts
>>>>>>>>>>>>>>>>> such as what constitutes a pure function.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> It is the case that the outer H(P,P) is a pure function
>>>>>>>>>>>>>>>> of its
>>>>>>>>>>>>>>>> inputs.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So your tactic now is simply to ignore what people say
>>>>>>>>>>>>>>> and just
>>>>>>>>>>>>>>> repeat yourself? What is the point of doing that? Seems
>>>>>>>>>>>>>>> like a
>>>>>>>>>>>>>>> waste of time to me.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> We need actual PhD computer scientists that are experts in
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> theory of computation to evaluate these things. You guys are
>>>>>>>>>>>>>> merely spouting off misonceptions.
>>>>>>>>>>>>> LOL. Appeal to authority, a logical fallacy, mate.
>>>>>>>>>>>>>
>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>
>>>>>>>>>>>> People that only understand these things from the very shallow
>>>>>>>>>>>> perspective of learned-by-rote can't see any of the relevant
>>>>>>>>>>>> details.
>>>>>>>>>>>>
>>>>>>>>>>>> The best that they can do is parrot the words of others never
>>>>>>>>>>>> realizing that these words do not apply to this case. No one
>>>>>>>>>>>> has
>>>>>>>>>>>> ever examined this case before.
>>>>>>>>>>> More repetition and refusal to engage in reasoned debate.
>>>>>>>>>>> You've got
>>>>>>>>>>> nothing.
>>>>>>>>>>>
>>>>>>>>>>> /Flibble
>>>>>>>>>>
>>>>>>>>>> You are spouting off things that are not true and too ignorant to
>>>>>>>>>> understand that they are not true.
>>>>>>>>> You have not addressed my argument: simply asserting that my
>>>>>>>>> argument
>>>>>>>>> is false without explaining why just doesn't cut the mustard
>>>>>>>>> I'm afraid.
>>>>>>>>>
>>>>>>>>> You've got no argument. You've got nothing.
>>>>>>>>>
>>>>>>>>> /Flibble
>>>>>>>>>
>>>>>>>>
>>>>>>>> The execution traces prove that I am correct that you simply "do
>>>>>>>> not believe in" these execution traces is no rebuttal at all.
>>>>>>>>
>>>>>>>
>>>>>>> You mean the execution traces that aren't actually correct,
>>>>>>> because theuy don't show what the x86 cpu is actually doing?
>>>>>>
>>>>>> This is false. Why lie?
>>>>>>
>>>>>>
>>>>>
>>>>> I'm not. That is the definition of a correct trace.
>>>>>
>>>>> Why do YOU lie.
>>>>
>>>> This is showing what the x86 processor is doing therefore your claim
>>>> that it is not shown is proven to be false. WHY LIE ?
>>>>
>>>>   machine   stack     stack     machine    assembly
>>>>   address   address   data      code       language
>>>>   ========  ========  ========  =========  =============
>>>> [00001307][00102190][00000000] 55         push ebp
>>>> [00001308][00102190][00000000] 8bec       mov ebp,esp
>>>> [0000130a][0010218c][000012e7] 68e7120000 push 000012e7 // push P
>>>> [0000130f][00102188][00001314] e8d3ffffff call 000012e7 // call P
>>>> [000012e7][00102184][00102190] 55         push ebp      // enter
>>>> executed P
>>>> [000012e8][00102184][00102190] 8bec       mov ebp,esp
>>>> [000012ea][00102184][00102190] 8b4508     mov eax,[ebp+08]
>>>> [000012ed][00102180][000012e7] 50         push eax      // push P
>>>> [000012ee][00102180][000012e7] 8b4d08     mov ecx,[ebp+08]
>>>> [000012f1][0010217c][000012e7] 51         push ecx      // push P
>>>> [000012f2][00102178][000012f7] e880feffff call 00001177 // call H
>>>>
>>>>
>>>
>>>
>>> Right, so what is the next instruction in the trace, it NEEDS to be
>>> the execution of the instruciton at 00001177, as that is what the x86
>>> processor does.
>>
>>  >>>>> theuy don't show what the x86 cpu is actually doing?
>>
>> Liar
>>
>
> Really, what x86 cpu wouldn't execute the first instruction of H as its
> next instruction? (and thus what a proper trace should show).
>
> You failure to answer is proof that YOU are the LIAR.

On 11/06/2022 15:40, Mr Flibble wrote:
> Nope. A pure function always returns the same value for the same inputs:

Perhaps someone will explain why they are so bothered about "pure"
functions? These bear no interesting relation to what a TM could do, not
least because it is perfectly straightforward to imagine compiling [eg] C
code into a corresponding TM [equivalently into a representation to be
"run" by some UTM] as long as the C does not make [illicit] use of the
environment provided by the OS.

To be slightly more explicit, imagine one of the machines of around
1960 -- no disc storage, no interesting OS, just a program on paper/mag tape
or cards loaded into a compile-and-go environment with input taken from a
second tape or deck and output to a third or to a lineprinter. It can, if
it likes, use magnetic tapes as [unbounded] "scratch" storage.

Your HP task: write a program, equally for such a machine, that
will inspect those tapes/cards and determine whether or not the program
under inspection will halt. Your program can be an emulator if you like;
but it must halt and give an answer; but note that there is no recursion
specified in or by the problem, and if it is [through programming error]
"infinitely" recursive, then it doesn't meet the specification.

The "usual" proof that there can be no such program works perfectly
well, and there is no need to specify that any of the functions invoked by
your program is pure. [Perhaps worth noting that /if/ you rely on the OS
(such as it is) aborting any program that runs for longer than, say, half
an hour, /then/ you will need to explain why your emulation can run fast
enough to complete before itself being aborted.]

--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Spindler

On 6/11/22 2:43 PM, olcott wrote:
> On 6/11/2022 1:26 PM, Richard Damon wrote:
>> On 6/11/22 1:09 PM, olcott wrote:
>>> On 6/11/2022 12:04 PM, Richard Damon wrote:
>>>> On 6/11/22 12:50 PM, olcott wrote:
>>>>> On 6/11/2022 11:46 AM, Richard Damon wrote:
>>>>>> On 6/11/22 12:42 PM, olcott wrote:
>>>>>>> On 6/11/2022 11:36 AM, Richard Damon wrote:
>>>>>>>> On 6/11/22 12:21 PM, olcott wrote:
>>>>>>>>> On 6/11/2022 10:31 AM, Mr Flibble wrote:
>>>>>>>>>> On Sat, 11 Jun 2022 10:29:06 -0500
>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> On 6/11/2022 10:19 AM, Mr Flibble wrote:
>>>>>>>>>>>> On Sat, 11 Jun 2022 10:18:14 -0500
>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>> On 6/11/2022 10:12 AM, Mr Flibble wrote:
>>>>>>>>>>>>>> On Sat, 11 Jun 2022 10:11:37 -0500
>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>> On 6/11/2022 10:01 AM, Mr Flibble wrote:
>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 09:59:10 -0500
>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>> On 6/11/2022 9:55 AM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 09:52:34 -0500
>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>> On 6/11/2022 9:40 AM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 09:35:02 -0500
>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 7:03 AM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 00:03:37 -0500
>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> "H(P,P) as a pure function of its inputs is easy"
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> If H as a "pure function" doesn't return a result
>>>>>>>>>>>>>>>>>>>>>> to its
>>>>>>>>>>>>>>>>>>>>>> caller then it isn't a halt decider.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> The first H(P,P) that is invoked always returns a
>>>>>>>>>>>>>>>>>>>>> value to
>>>>>>>>>>>>>>>>>>>>> its caller. Subsequent recursive invocations are a
>>>>>>>>>>>>>>>>>>>>> part of
>>>>>>>>>>>>>>>>>>>>> infinitely nested simulation that must be aborted.
>>>>>>>>>>>>>>>>>>>> Nope. A pure function always returns the same value
>>>>>>>>>>>>>>>>>>>> for the
>>>>>>>>>>>>>>>>>>>> same inputs:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> One can assume this when one has never bothered to think
>>>>>>>>>>>>>>>>>>> infinitely nested simulation all the way through.
>>>>>>>>>>>>>>>>>>> Parroting
>>>>>>>>>>>>>>>>>>> things that textbooks say is of no use because
>>>>>>>>>>>>>>>>>>> textbooks have
>>>>>>>>>>>>>>>>>>> never addressed this.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The idea of a simulating halt decider that correctly
>>>>>>>>>>>>>>>>>>> detects
>>>>>>>>>>>>>>>>>>> infinitely nested simulation of the conventional halting
>>>>>>>>>>>>>>>>>>> problem proof counter-examples is brand new with me
>>>>>>>>>>>>>>>>>>> so you
>>>>>>>>>>>>>>>>>>> won't find any textbook that discusses it.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The outer-most H(P,P) is a pure function of its inputs.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Then the H that P calls is a different H because as I
>>>>>>>>>>>>>>>>>> just
>>>>>>>>>>>>>>>>>> stated, "a pure function always returns the same value
>>>>>>>>>>>>>>>>>> for the
>>>>>>>>>>>>>>>>>> same inputs".
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> You can't just redefine accepted computer science
>>>>>>>>>>>>>>>>>> concepts
>>>>>>>>>>>>>>>>>> such as what constitutes a pure function.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> It is the case that the outer H(P,P) is a pure function
>>>>>>>>>>>>>>>>> of its
>>>>>>>>>>>>>>>>> inputs.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> So your tactic now is simply to ignore what people say
>>>>>>>>>>>>>>>> and just
>>>>>>>>>>>>>>>> repeat yourself? What is the point of doing that? Seems
>>>>>>>>>>>>>>>> like a
>>>>>>>>>>>>>>>> waste of time to me.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> We need actual PhD computer scientists that are experts
>>>>>>>>>>>>>>> in the
>>>>>>>>>>>>>>> theory of computation to evaluate these things. You guys are
>>>>>>>>>>>>>>> merely spouting off misonceptions.
>>>>>>>>>>>>>> LOL. Appeal to authority, a logical fallacy, mate.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>
>>>>>>>>>>>>> People that only understand these things from the very shallow
>>>>>>>>>>>>> perspective of learned-by-rote can't see any of the relevant
>>>>>>>>>>>>> details.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The best that they can do is parrot the words of others never
>>>>>>>>>>>>> realizing that these words do not apply to this case. No
>>>>>>>>>>>>> one has
>>>>>>>>>>>>> ever examined this case before.
>>>>>>>>>>>> More repetition and refusal to engage in reasoned debate.
>>>>>>>>>>>> You've got
>>>>>>>>>>>> nothing.
>>>>>>>>>>>>
>>>>>>>>>>>> /Flibble
>>>>>>>>>>>
>>>>>>>>>>> You are spouting off things that are not true and too
>>>>>>>>>>> ignorant to
>>>>>>>>>>> understand that they are not true.
>>>>>>>>>> You have not addressed my argument: simply asserting that my
>>>>>>>>>> argument
>>>>>>>>>> is false without explaining why just doesn't cut the mustard
>>>>>>>>>> I'm afraid.
>>>>>>>>>>
>>>>>>>>>> You've got no argument. You've got nothing.
>>>>>>>>>>
>>>>>>>>>> /Flibble
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The execution traces prove that I am correct that you simply
>>>>>>>>> "do not believe in" these execution traces is no rebuttal at all.
>>>>>>>>>
>>>>>>>>
>>>>>>>> You mean the execution traces that aren't actually correct,
>>>>>>>> because theuy don't show what the x86 cpu is actually doing?
>>>>>>>
>>>>>>> This is false. Why lie?
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> I'm not. That is the definition of a correct trace.
>>>>>>
>>>>>> Why do YOU lie.
>>>>>
>>>>> This is showing what the x86 processor is doing therefore your
>>>>> claim that it is not shown is proven to be false. WHY LIE ?
>>>>>
>>>>>   machine   stack     stack     machine    assembly
>>>>>   address   address   data      code       language
>>>>>   ========  ========  ========  =========  =============
>>>>> [00001307][00102190][00000000] 55         push ebp
>>>>> [00001308][00102190][00000000] 8bec       mov ebp,esp
>>>>> [0000130a][0010218c][000012e7] 68e7120000 push 000012e7 // push P
>>>>> [0000130f][00102188][00001314] e8d3ffffff call 000012e7 // call P
>>>>> [000012e7][00102184][00102190] 55         push ebp      // enter
>>>>> executed P
>>>>> [000012e8][00102184][00102190] 8bec       mov ebp,esp
>>>>> [000012ea][00102184][00102190] 8b4508     mov eax,[ebp+08]
>>>>> [000012ed][00102180][000012e7] 50         push eax      // push P
>>>>> [000012ee][00102180][000012e7] 8b4d08     mov ecx,[ebp+08]
>>>>> [000012f1][0010217c][000012e7] 51         push ecx      // push P
>>>>> [000012f2][00102178][000012f7] e880feffff call 00001177 // call H
>>>>>
>>>>>
>>>>
>>>>
>>>> Right, so what is the next instruction in the trace, it NEEDS to be
>>>> the execution of the instruciton at 00001177, as that is what the
>>>> x86 processor does.
>>>
>>>  >>>>> theuy don't show what the x86 cpu is actually doing?
>>>
>>> Liar
>>>
>>
>> Really, what x86 cpu wouldn't execute the first instruction of H as
>> its next instruction? (and thus what a proper trace should show).
>>
>> You failure to answer is proof that YOU are the LIAR.
>
> You said that I didn't show what the x86 cpu is actually doing I proved
> that I do show what the x86 cpu is doing thus you are wrong.

On 6/11/2022 2:04 PM, Andy Walker wrote:
> On 11/06/2022 15:40, Mr Flibble wrote:
>> Nope. A pure function always returns the same value for the same inputs:
>
>     Perhaps someone will explain why they are so bothered about "pure"
> functions?  These bear no interesting relation to what a TM could do, not
> least because it is perfectly straightforward to imagine compiling [eg] C
> code into a corresponding TM [equivalently into a representation to be
> "run" by some UTM] as long as the C does not make [illicit] use of the
> environment provided by the OS.
>
>     To be slightly more explicit, imagine one of the machines of around
> 1960 -- no disc storage, no interesting OS, just a program on paper/mag
> tape
> or cards loaded into a compile-and-go environment with input taken from a
> second tape or deck and output to a third or to a lineprinter.  It can, if
> it likes, use magnetic tapes as [unbounded] "scratch" storage.
>
>     Your HP task:  write a program, equally for such a machine, that
> will inspect those tapes/cards and determine whether or not the program
> under inspection will halt.  Your program can be an emulator if you like;
> but it must halt and give an answer;  but note that there is no recursion
> specified in or by the problem, and if it is [through programming error]
> "infinitely" recursive, then it doesn't meet the specification.
>
>     The "usual" proof that there can be no such program works perfectly
> well, and there is no need to specify that any of the functions invoked by
> your program is pure.  [Perhaps worth noting that /if/ you rely on the OS
> (such as it is) aborting any program that runs for longer than, say, half
> an hour, /then/ you will need to explain why your emulation can run fast
> enough to complete before itself being aborted.]
>

People here told me that if H uses global or static memory to compute
the halt status of its input then this does not count. They claimed that
the scope of the halting problem only applies to computable functions.

--
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/11/22 3:09 PM, olcott wrote:
> On 6/11/2022 2:04 PM, Andy Walker wrote:
>> On 11/06/2022 15:40, Mr Flibble wrote:
>>> Nope. A pure function always returns the same value for the same inputs:
>>
>>      Perhaps someone will explain why they are so bothered about "pure"
>> functions?  These bear no interesting relation to what a TM could do, not
>> least because it is perfectly straightforward to imagine compiling [eg] C
>> code into a corresponding TM [equivalently into a representation to be
>> "run" by some UTM] as long as the C does not make [illicit] use of the
>> environment provided by the OS.
>>
>>      To be slightly more explicit, imagine one of the machines of around
>> 1960 -- no disc storage, no interesting OS, just a program on
>> paper/mag tape
>> or cards loaded into a compile-and-go environment with input taken from a
>> second tape or deck and output to a third or to a lineprinter.  It
>> can, if
>> it likes, use magnetic tapes as [unbounded] "scratch" storage.
>>
>>      Your HP task:  write a program, equally for such a machine, that
>> will inspect those tapes/cards and determine whether or not the program
>> under inspection will halt.  Your program can be an emulator if you like;
>> but it must halt and give an answer;  but note that there is no recursion
>> specified in or by the problem, and if it is [through programming error]
>> "infinitely" recursive, then it doesn't meet the specification.
>>
>>      The "usual" proof that there can be no such program works perfectly
>> well, and there is no need to specify that any of the functions
>> invoked by
>> your program is pure.  [Perhaps worth noting that /if/ you rely on the OS
>> (such as it is) aborting any program that runs for longer than, say, half
>> an hour, /then/ you will need to explain why your emulation can run fast
>> enough to complete before itself being aborted.]
>>
>
> People here told me that if H uses global or static memory to compute
> the halt status of its input then this does not count. They claimed that
> the scope of the halting problem only applies to computable functions.
>

I think the problem is that you still don't understand thye meaniing of
what you are trying to do. In part because your "design" conflates the
simulation of the input with the program doing the simulation because
you simulation doesn't seem to be an actual simulation.

In the real problem, only one copy of H is actually being executed at a
time, and all other instances of H are being simulated, and thus should
be in their own independent execution environment, so no interaction is
actually possible.

The key point is that the H called by P needs to have EXACTLY the same
algorithm as the H deciding on the input P(P) in order to meet the
requirements of the Linz proof, and can't behave differently because it
is being emulated instead of directly executed.

The fact that you seem to be mixing up executing the input under
debugging with simulation and NOT putting the program being "simulated"
into a seperate address space, brings up the possibility of H "cheating"
by seeing other levels of its operation and changing if this is an
"emulated" copy.

Perhaps the biggest issue is that the outer "debug stepping" needs to
actually be debug stepping the inner debug-stepper going through its
paces, not just handing off its own stepping to the nested copy because
that means copies seem to know if they have been handed off to or not.

The issue isn't the use of global or static memory, but the
communication between one invocation of H that changes the behavior of
another,

If H waw PROPERLY defined to take an isolated program as its input, this
wouldn't be nearly the issue (as explained) but the mixing of decider
and decided into one "program" gives you lots of issues to deal with.

On 6/11/2022 2:36 PM, Richard Damon wrote:
> On 6/11/22 3:09 PM, olcott wrote:
>> On 6/11/2022 2:04 PM, Andy Walker wrote:
>>> On 11/06/2022 15:40, Mr Flibble wrote:
>>>> Nope. A pure function always returns the same value for the same
>>>> inputs:
>>>
>>>      Perhaps someone will explain why they are so bothered about "pure"
>>> functions?  These bear no interesting relation to what a TM could do,
>>> not
>>> least because it is perfectly straightforward to imagine compiling
>>> [eg] C
>>> code into a corresponding TM [equivalently into a representation to be
>>> "run" by some UTM] as long as the C does not make [illicit] use of the
>>> environment provided by the OS.
>>>
>>>      To be slightly more explicit, imagine one of the machines of around
>>> 1960 -- no disc storage, no interesting OS, just a program on
>>> paper/mag tape
>>> or cards loaded into a compile-and-go environment with input taken
>>> from a
>>> second tape or deck and output to a third or to a lineprinter.  It
>>> can, if
>>> it likes, use magnetic tapes as [unbounded] "scratch" storage.
>>>
>>>      Your HP task:  write a program, equally for such a machine, that
>>> will inspect those tapes/cards and determine whether or not the program
>>> under inspection will halt.  Your program can be an emulator if you
>>> like;
>>> but it must halt and give an answer;  but note that there is no
>>> recursion
>>> specified in or by the problem, and if it is [through programming error]
>>> "infinitely" recursive, then it doesn't meet the specification.
>>>
>>>      The "usual" proof that there can be no such program works perfectly
>>> well, and there is no need to specify that any of the functions
>>> invoked by
>>> your program is pure.  [Perhaps worth noting that /if/ you rely on
>>> the OS
>>> (such as it is) aborting any program that runs for longer than, say,
>>> half
>>> an hour, /then/ you will need to explain why your emulation can run fast
>>> enough to complete before itself being aborted.]
>>>
>>
>> People here told me that if H uses global or static memory to compute
>> the halt status of its input then this does not count. They claimed
>> that the scope of the halting problem only applies to computable
>> functions.
>>
>
> I think the problem is that you still don't understand thye meaniing of
> what you are trying to do. In part because your "design" conflates the
> simulation of the input with the program doing the simulation because
> you simulation doesn't seem to be an actual simulation.
>
> In the real problem, only one copy of H is actually being executed at a
> time, and all other instances of H are being simulated, and thus should
> be in their own independent execution environment, so no interaction is
> actually possible.

The outer H must emulate each instruction of P and each instruction of
H(P,P) that is called by P.

This inner H does the same thing...
This forms a single connected chain or invocations and emulations.

--
Copyright 2022 Pete Olcott

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

Andy Walker <anw@cuboid.co.uk> writes:

> On 11/06/2022 15:40, Mr Flibble wrote:
>> Nope. A pure function always returns the same value for the same inputs:
>
> Perhaps someone will explain why they are so bothered about "pure"
> functions? These bear no interesting relation to what a TM could do, not
> least because it is perfectly straightforward to imagine compiling [eg] C
> code into a corresponding TM [equivalently into a representation to be
> "run" by some UTM] as long as the C does not make [illicit] use of the
> environment provided by the OS.

There's nothing interesting about pure functions from a theoretical
point of view, but PO has ditched all notions of a formal model of
computation, and since he is only interesting in getting one case
correct, he could have written:

#include <stdio.h>

typedef void (*ptr)();

int H(ptr x, ptr y)
{
void H_Hat(ptr);
return (char *)__builtin_return_address(0) - (char *)H_Hat > 36;
}

void H_Hat(ptr x)
{
if (H(x, x)) while (1);
}

int main(void)
{
printf("%d\n", H(H_Hat, H_Hat));
H_Hat(H_Hat);
}

This program prints 1 (on my system) and halts because H_Hat(H_Hat)
"halts" (i.e. returns to main) even though H_Hat is correctly
constructed from H.

My guess is that it is trickery like this that makes people worry about
functions being pure.

It would have been much simpler to defend H(H_Hat, H_Hat) == 1 and
H_Hat(H_Hat) than the opposite, but I don't think he ever thought of
doing this.

I'm not worried about pure functions because PO is told use that
H(H_Hat, H_Hat) == 0 even though H_Hat(H_Hat) halts so he's wrong by
defintion based on undisputed facts. Well. not quote, PO "disputes" the
defintion, but his basis for that "H_Hat(H_Hat) is a non-input" is just
noise needed to keep things going.

> To be slightly more explicit, imagine one of the machines of around
> 1960 -- no disc storage, no interesting OS, just a program on paper/mag tape
> or cards loaded into a compile-and-go environment with input taken from a
> second tape or deck and output to a third or to a lineprinter. It can, if
> it likes, use magnetic tapes as [unbounded] "scratch" storage.
>
> Your HP task: write a program, equally for such a machine, that
> will inspect those tapes/cards and determine whether or not the program
> under inspection will halt. Your program can be an emulator if you like;
> but it must halt and give an answer; but note that there is no recursion
> specified in or by the problem, and if it is [through programming error]
> "infinitely" recursive, then it doesn't meet the specification.
>
> The "usual" proof that there can be no such program works perfectly
> well, and there is no need to specify that any of the functions invoked by
> your program is pure. [Perhaps worth noting that /if/ you rely on the OS
> (such as it is) aborting any program that runs for longer than, say, half
> an hour, /then/ you will need to explain why your emulation can run fast
> enough to complete before itself being aborted.]

Well that's close to being a formal model, so there is no need to worry
about tricks such as the one used above.

Another approach, using C, would have been to make H take the source
code of a C program as a string, rather than elide the issue of
representation by using a code pointer but PO rejected any notion of
"encoding" as being "extraneous complexity" for years and he still does
not understand the concept.

--
Ben.

On 6/11/22 3:46 PM, olcott wrote:
> On 6/11/2022 2:36 PM, Richard Damon wrote:
>> On 6/11/22 3:09 PM, olcott wrote:
>>> On 6/11/2022 2:04 PM, Andy Walker wrote:
>>>> On 11/06/2022 15:40, Mr Flibble wrote:
>>>>> Nope. A pure function always returns the same value for the same
>>>>> inputs:
>>>>
>>>>      Perhaps someone will explain why they are so bothered about "pure"
>>>> functions?  These bear no interesting relation to what a TM could
>>>> do, not
>>>> least because it is perfectly straightforward to imagine compiling
>>>> [eg] C
>>>> code into a corresponding TM [equivalently into a representation to be
>>>> "run" by some UTM] as long as the C does not make [illicit] use of the
>>>> environment provided by the OS.
>>>>
>>>>      To be slightly more explicit, imagine one of the machines of
>>>> around
>>>> 1960 -- no disc storage, no interesting OS, just a program on
>>>> paper/mag tape
>>>> or cards loaded into a compile-and-go environment with input taken
>>>> from a
>>>> second tape or deck and output to a third or to a lineprinter.  It
>>>> can, if
>>>> it likes, use magnetic tapes as [unbounded] "scratch" storage.
>>>>
>>>>      Your HP task:  write a program, equally for such a machine, that
>>>> will inspect those tapes/cards and determine whether or not the program
>>>> under inspection will halt.  Your program can be an emulator if you
>>>> like;
>>>> but it must halt and give an answer;  but note that there is no
>>>> recursion
>>>> specified in or by the problem, and if it is [through programming
>>>> error]
>>>> "infinitely" recursive, then it doesn't meet the specification.
>>>>
>>>>      The "usual" proof that there can be no such program works
>>>> perfectly
>>>> well, and there is no need to specify that any of the functions
>>>> invoked by
>>>> your program is pure.  [Perhaps worth noting that /if/ you rely on
>>>> the OS
>>>> (such as it is) aborting any program that runs for longer than, say,
>>>> half
>>>> an hour, /then/ you will need to explain why your emulation can run
>>>> fast
>>>> enough to complete before itself being aborted.]
>>>>
>>>
>>> People here told me that if H uses global or static memory to compute
>>> the halt status of its input then this does not count. They claimed
>>> that the scope of the halting problem only applies to computable
>>> functions.
>>>
>>
>> I think the problem is that you still don't understand thye meaniing
>> of what you are trying to do. In part because your "design" conflates
>> the simulation of the input with the program doing the simulation
>> because you simulation doesn't seem to be an actual simulation.
>>
>> In the real problem, only one copy of H is actually being executed at
>> a time, and all other instances of H are being simulated, and thus
>> should be in their own independent execution environment, so no
>> interaction is actually possible.
>
> The outer H must emulate each instruction of P and each instruction of
> H(P,P) that is called by P.
>
> This inner H does the same thing...
> This forms a single connected chain or invocations and emulations.
>
>
Yes, The outer H must emulate each instruction of the PROGRAM P (which
included the H that is called by P).

The inner H needs to do the same thing, and thus need to behave the same.

If the outer H aborts its simulation, then the simulation it does of the
inner H needs to take into account that it WILL also abort its simulation.

Your "logic" about getting into an infinite chain neglects that.

H needs to have a definite algorithm about what case it will abort, and
it will either abort its simulation of P(P), or it won't, and ALL copies
will behave the same.

Your "logic" of getting into the infinite simulation envocation ignores
that the first H being emulated WILL abort its emulate at some point
past the point that the outer H stops emulating it.

The key point is that by intertwining the decider and the decided the
way you have done you create problems. First, you can't decide on inputs
as defined by x86 code, because your decided machines have a
pre-requisite of having your decider in their address space, and thus
you can NOT decide on all possible programs.

The second issue is that if the decided program uses any of the routines
in the decider (like P does with H) then these need to be done in a way
that makes sure that they don't incorrectly interact, but your design
for H seems to do that (or at least it did in your earlier code samples
when you described what it did).

The biggest error here is that when the outer H starts showing ITS trace
as being just the trace of the inner H, which is NOT correct, because
all the steps in the inner H need to be seen as having a conditional on
the inner H having not decided YET to abort its simulation, which breaks
the infinite pattern.

On 6/11/2022 3:10 PM, Ben Bacarisse wrote:
> Andy Walker <anw@cuboid.co.uk> writes:
>
>> On 11/06/2022 15:40, Mr Flibble wrote:
>>> Nope. A pure function always returns the same value for the same inputs:
>>
>> Perhaps someone will explain why they are so bothered about "pure"
>> functions? These bear no interesting relation to what a TM could do, not
>> least because it is perfectly straightforward to imagine compiling [eg] C
>> code into a corresponding TM [equivalently into a representation to be
>> "run" by some UTM] as long as the C does not make [illicit] use of the
>> environment provided by the OS.
>
> There's nothing interesting about pure functions from a theoretical
> point of view, but PO has ditched all notions of a formal model of
> computation, and since he is only interesting in getting one case
> correct, he could have written:
>
> #include <stdio.h>
>
> typedef void (*ptr)();
>
> int H(ptr x, ptr y)
> {
> void H_Hat(ptr);
> return (char *)__builtin_return_address(0) - (char *)H_Hat > 36;
> }
>
> void H_Hat(ptr x)
> {
> if (H(x, x)) while (1);
> }
>
> int main(void)
> {
> printf("%d\n", H(H_Hat, H_Hat));
> H_Hat(H_Hat);
> }
>
> This program prints 1 (on my system) and halts because H_Hat(H_Hat)
> "halts" (i.e. returns to main) even though H_Hat is correctly
> constructed from H.
>
> My guess is that it is trickery like this that makes people worry about
> functions being pure.
>
> It would have been much simpler to defend H(H_Hat, H_Hat) == 1 and
> H_Hat(H_Hat) than the opposite, but I don't think he ever thought of
> doing this.
>
> I'm not worried about pure functions because PO is told use that
> H(H_Hat, H_Hat) == 0 even though H_Hat(H_Hat) halts so he's wrong by
> defintion based on undisputed facts.

Because it is the case that H(P,P)==0 is correctly based on computing
the mapping from the actual input to its own accept or reject state on
the basis of the actual behavior of the input H(P,)==0 is correct.

All fake rebuttals to this claim that the decider must map its inputs to
an accept or reject state based on behavior that is different from the
actual behavior of the actual input.

I think that the problem is that even through I proved that the behavior
is different people assume that it must be the same thus never bother to
look at the proof.

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

int main()
{ P(P);
}

_P()
[000012e7](01) 55 push ebp
[000012e8](02) 8bec mov ebp,esp
[000012ea](03) 8b4508 mov eax,[ebp+08]
[000012ed](01) 50 push eax
[000012ee](03) 8b4d08 mov ecx,[ebp+08]
[000012f1](01) 51 push ecx
[000012f2](05) e880feffff call 00001177 // call H
[000012f7](03) 83c408 add esp,+08
[000012fa](02) 85c0 test eax,eax
[000012fc](02) 7402 jz 00001300
[000012fe](02) ebfe jmp 000012fe
[00001300](01) 5d pop ebp
[00001301](01) c3 ret
Size in bytes:(0027) [00001301]

_main()
[00001307](01) 55 push ebp
[00001308](02) 8bec mov ebp,esp
[0000130a](05) 68e7120000 push 000012e7 // push P
[0000130f](05) e8d3ffffff call 000012e7 // call P
[00001314](03) 83c404 add esp,+04
[00001317](02) 33c0 xor eax,eax
[00001319](01) 5d pop ebp
[0000131a](01) c3 ret
Size in bytes:(0020) [0000131a]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[00001307][00102190][00000000] 55 push ebp
[00001308][00102190][00000000] 8bec mov ebp,esp
[0000130a][0010218c][000012e7] 68e7120000 push 000012e7 // push P
[0000130f][00102188][00001314] e8d3ffffff call 000012e7 // call P
[000012e7][00102184][00102190] 55 push ebp // enter executed P
[000012e8][00102184][00102190] 8bec mov ebp,esp
[000012ea][00102184][00102190] 8b4508 mov eax,[ebp+08]
[000012ed][00102180][000012e7] 50 push eax // push P
[000012ee][00102180][000012e7] 8b4d08 mov ecx,[ebp+08]
[000012f1][0010217c][000012e7] 51 push ecx // push P
[000012f2][00102178][000012f7] e880feffff call 00001177 // call H

Begin Local Halt Decider Simulation Execution Trace Stored at:212244
[000012e7][00212230][00212234] 55 push ebp // enter emulated P
[000012e8][00212230][00212234] 8bec mov ebp,esp
[000012ea][00212230][00212234] 8b4508 mov eax,[ebp+08]
[000012ed][0021222c][000012e7] 50 push eax // push P
[000012ee][0021222c][000012e7] 8b4d08 mov ecx,[ebp+08]
[000012f1][00212228][000012e7] 51 push ecx // push P
[000012f2][00212224][000012f7] e880feffff call 00001177 // call H
[000012e7][0025cc58][0025cc5c] 55 push ebp // enter emulated P
[000012e8][0025cc58][0025cc5c] 8bec mov ebp,esp
[000012ea][0025cc58][0025cc5c] 8b4508 mov eax,[ebp+08]
[000012ed][0025cc54][000012e7] 50 push eax // push P
[000012ee][0025cc54][000012e7] 8b4d08 mov ecx,[ebp+08]
[000012f1][0025cc50][000012e7] 51 push ecx // push P
[000012f2][0025cc4c][000012f7] e880feffff call 00001177 // call H
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

It is completely obvious that when H(P,P) correctly emulates its input
that it must emulate the first seven instructions of P. Because the
seventh instruction of P repeats this process we know with complete
certainty that the correct and complete emulation of P by H would never
reach its final “ret” instruction, thus never halts.

[000012f7][00102184][00102190] 83c408 add esp,+08
[000012fa][00102184][00102190] 85c0 test eax,eax
[000012fc][00102184][00102190] 7402 jz 00001300
[00001300][00102188][00001314] 5d pop ebp
[00001301][0010218c][000012e7] c3 ret // executed P halts
[00001314][00102190][00000000] 83c404 add esp,+04
[00001317][00102190][00000000] 33c0 xor eax,eax
[00001319][00102194][00100000] 5d pop ebp
[0000131a][00102198][00000000] c3 ret // main() halts
Number of Instructions Executed(15900) 237 pages

> Well. not quote, PO "disputes" the
> defintion, but his basis for that "H_Hat(H_Hat) is a non-input" is just
> noise needed to keep things going.
>
>> To be slightly more explicit, imagine one of the machines of around
>> 1960 -- no disc storage, no interesting OS, just a program on paper/mag tape
>> or cards loaded into a compile-and-go environment with input taken from a
>> second tape or deck and output to a third or to a lineprinter. It can, if
>> it likes, use magnetic tapes as [unbounded] "scratch" storage.
>>
>> Your HP task: write a program, equally for such a machine, that
>> will inspect those tapes/cards and determine whether or not the program
>> under inspection will halt. Your program can be an emulator if you like;
>> but it must halt and give an answer; but note that there is no recursion
>> specified in or by the problem, and if it is [through programming error]
>> "infinitely" recursive, then it doesn't meet the specification.
>>
>> The "usual" proof that there can be no such program works perfectly
>> well, and there is no need to specify that any of the functions invoked by
>> your program is pure. [Perhaps worth noting that /if/ you rely on the OS
>> (such as it is) aborting any program that runs for longer than, say, half
>> an hour, /then/ you will need to explain why your emulation can run fast
>> enough to complete before itself being aborted.]
>
> Well that's close to being a formal model, so there is no need to worry
> about tricks such as the one used above.
>
> Another approach, using C, would have been to make H take the source
> code of a C program as a string, rather than elide the issue of
> representation by using a code pointer but PO rejected any notion of
> "encoding" as being "extraneous complexity" for years and he still does
> not understand the concept.
>

--
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/11/22 4:22 PM, olcott wrote:
> On 6/11/2022 3:10 PM, Ben Bacarisse wrote:
>> Andy Walker <anw@cuboid.co.uk> writes:
>>
>>> On 11/06/2022 15:40, Mr Flibble wrote:
>>>> Nope. A pure function always returns the same value for the same
>>>> inputs:
>>>
>>>     Perhaps someone will explain why they are so bothered about "pure"
>>> functions?  These bear no interesting relation to what a TM could do,
>>> not
>>> least because it is perfectly straightforward to imagine compiling
>>> [eg] C
>>> code into a corresponding TM [equivalently into a representation to be
>>> "run" by some UTM] as long as the C does not make [illicit] use of the
>>> environment provided by the OS.
>>
>> There's nothing interesting about pure functions from a theoretical
>> point of view, but PO has ditched all notions of a formal model of
>> computation, and since he is only interesting in getting one case
>> correct, he could have written:
>>
>>    #include <stdio.h>
>>    typedef void (*ptr)();
>>    int H(ptr x, ptr y)
>>    {
>>         void H_Hat(ptr);
>>         return (char *)__builtin_return_address(0) - (char *)H_Hat > 36;
>>    }
>>    void H_Hat(ptr x)
>>    {
>>         if (H(x, x)) while (1);
>>    }
>>    int main(void)
>>    {
>>         printf("%d\n", H(H_Hat, H_Hat));
>>         H_Hat(H_Hat);
>>    }
>>
>> This program prints 1 (on my system) and halts because H_Hat(H_Hat)
>> "halts" (i.e. returns to main) even though H_Hat is correctly
>> constructed from H.
>>
>> My guess is that it is trickery like this that makes people worry about
>> functions being pure.
>>
>> It would have been much simpler to defend H(H_Hat, H_Hat) == 1 and
>> H_Hat(H_Hat) than the opposite, but I don't think he ever thought of
>> doing this.
>>
>> I'm not worried about pure functions because PO is told use that
>> H(H_Hat, H_Hat) == 0 even though H_Hat(H_Hat) halts so he's wrong by
>> defintion based on undisputed facts.
>
> Because it is the case that H(P,P)==0 is correctly based on computing
> the mapping from the actual input to its own accept or reject state on
> the basis of the actual behavior of the input H(P,)==0 is correct.
>

But the ACTUAL INPUT is a representation of P(P), so its ACTUAL BEHAVIOR
is that of P(P).

Your arguement only works if H isn't a computation and H(P,P) behaves
differently when it is simulated then when it is executed. This isn't
allowed.

> All fake rebuttals to this claim that the decider must map its inputs to
> an accept or reject state based on behavior that is different from the
> actual behavior of the actual input.

Just shows you aren't paying attention, as the actual behavior of the
input to H(P,P) IS DEFINED to be P(P), so you are arguing with a definition.

>
> I think that the problem is that even through I proved that the behavior
> is different people assume that it must be the same thus never bother to
> look at the proof.
>

Excpet that the proof doesn't work if H is requried to be an actual
computation.

The only way the input can behave differently then P(P) is if H isn't
actually a computation and does something to make the simulation of
H(P,P) not match a call to H(P,P).

You get your choice, either H isn't correctly simulating its input, and
thus wrong, or H isn't a computation, and thus not allowed to be a Halt
Decider.

> void P(u32 x)
> {
>   if (H(x, x))
>     HERE: goto HERE;
>   return;
> }
>
> int main()
> {
>   P(P);
> }
>
> _P()
> [000012e7](01)  55              push ebp
> [000012e8](02)  8bec            mov ebp,esp
> [000012ea](03)  8b4508          mov eax,[ebp+08]
> [000012ed](01)  50              push eax
> [000012ee](03)  8b4d08          mov ecx,[ebp+08]
> [000012f1](01)  51              push ecx
> [000012f2](05)  e880feffff      call 00001177 // call H
> [000012f7](03)  83c408          add esp,+08
> [000012fa](02)  85c0            test eax,eax
> [000012fc](02)  7402            jz 00001300
> [000012fe](02)  ebfe            jmp 000012fe
> [00001300](01)  5d              pop ebp
> [00001301](01)  c3              ret
> Size in bytes:(0027) [00001301]
>
> _main()
> [00001307](01)  55              push ebp
> [00001308](02)  8bec            mov ebp,esp
> [0000130a](05)  68e7120000      push 000012e7 // push P
> [0000130f](05)  e8d3ffffff      call 000012e7 // call P
> [00001314](03)  83c404          add esp,+04
> [00001317](02)  33c0            xor eax,eax
> [00001319](01)  5d              pop ebp
> [0000131a](01)  c3              ret
> Size in bytes:(0020) [0000131a]
>
>  machine   stack     stack     machine    assembly
>  address   address   data      code       language
>  ========  ========  ========  =========  =============
> [00001307][00102190][00000000] 55         push ebp
> [00001308][00102190][00000000] 8bec       mov ebp,esp
> [0000130a][0010218c][000012e7] 68e7120000 push 000012e7 // push P
> [0000130f][00102188][00001314] e8d3ffffff call 000012e7 // call P
> [000012e7][00102184][00102190] 55         push ebp      // enter executed P
> [000012e8][00102184][00102190] 8bec       mov ebp,esp
> [000012ea][00102184][00102190] 8b4508     mov eax,[ebp+08]
> [000012ed][00102180][000012e7] 50         push eax      // push P
> [000012ee][00102180][000012e7] 8b4d08     mov ecx,[ebp+08]
> [000012f1][0010217c][000012e7] 51         push ecx      // push P
> [000012f2][00102178][000012f7] e880feffff call 00001177 // call H
>
> Begin Local Halt Decider Simulation   Execution Trace Stored at:212244
> [000012e7][00212230][00212234] 55          push ebp      // enter
> emulated P
> [000012e8][00212230][00212234] 8bec        mov ebp,esp
> [000012ea][00212230][00212234] 8b4508      mov eax,[ebp+08]
> [000012ed][0021222c][000012e7] 50          push eax      // push P
> [000012ee][0021222c][000012e7] 8b4d08      mov ecx,[ebp+08]
> [000012f1][00212228][000012e7] 51          push ecx      // push P
> [000012f2][00212224][000012f7] e880feffff  call 00001177 // call H

ERROR IN EMULATION. NEED TO SHOW EMULTED H, or at a minimum that the
following is the CONDITIONAL emulation of the code by the decider H.

> [000012e7][0025cc58][0025cc5c] 55          push ebp      // enter
> emulated P
> [000012e8][0025cc58][0025cc5c] 8bec        mov ebp,esp
> [000012ea][0025cc58][0025cc5c] 8b4508      mov eax,[ebp+08]
> [000012ed][0025cc54][000012e7] 50          push eax      // push P
> [000012ee][0025cc54][000012e7] 8b4d08      mov ecx,[ebp+08]
> [000012f1][0025cc50][000012e7] 51          push ecx      // push P
> [000012f2][0025cc4c][000012f7] e880feffff  call 00001177 // call H
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped

UNSOUND deductionn

>
> It is completely obvious that when H(P,P) correctly emulates its input
> that it must emulate the first seven instructions of P. Because the
> seventh instruction of P repeats this process we know with complete
> certainty that the correct and complete emulation of P by H would never
> reach its final “ret” instruction, thus never halts.

Nope, since H does NOT correctly emulate its input if H is simulator
that aborts its simulation.

>
> [000012f7][00102184][00102190] 83c408      add esp,+08
> [000012fa][00102184][00102190] 85c0        test eax,eax
> [000012fc][00102184][00102190] 7402        jz 00001300
> [00001300][00102188][00001314] 5d          pop ebp
> [00001301][0010218c][000012e7] c3          ret           // executed P
> halts
> [00001314][00102190][00000000] 83c404      add esp,+04
> [00001317][00102190][00000000] 33c0        xor eax,eax
> [00001319][00102194][00100000] 5d          pop ebp
> [0000131a][00102198][00000000] c3          ret           // main() halts
> Number of Instructions Executed(15900) 237 pages
>
>

The fact the HERE we see that P(P) Halted, BY DEFINITION, H(P,P) being 0
is incorrect, as for a HALT DECIDER, the DEFINITION is

On 6/11/2022 3:32 PM, Richard Damon wrote:
> On 6/11/22 4:22 PM, olcott wrote:
>> On 6/11/2022 3:10 PM, Ben Bacarisse wrote:
>>> Andy Walker <anw@cuboid.co.uk> writes:
>>>
>>>> On 11/06/2022 15:40, Mr Flibble wrote:
>>>>> Nope. A pure function always returns the same value for the same
>>>>> inputs:
>>>>
>>>>     Perhaps someone will explain why they are so bothered about "pure"
>>>> functions?  These bear no interesting relation to what a TM could
>>>> do, not
>>>> least because it is perfectly straightforward to imagine compiling
>>>> [eg] C
>>>> code into a corresponding TM [equivalently into a representation to be
>>>> "run" by some UTM] as long as the C does not make [illicit] use of the
>>>> environment provided by the OS.
>>>
>>> There's nothing interesting about pure functions from a theoretical
>>> point of view, but PO has ditched all notions of a formal model of
>>> computation, and since he is only interesting in getting one case
>>> correct, he could have written:
>>>
>>>    #include <stdio.h>
>>>    typedef void (*ptr)();
>>>    int H(ptr x, ptr y)
>>>    {
>>>         void H_Hat(ptr);
>>>         return (char *)__builtin_return_address(0) - (char *)H_Hat > 36;
>>>    }
>>>    void H_Hat(ptr x)
>>>    {
>>>         if (H(x, x)) while (1);
>>>    }
>>>    int main(void)
>>>    {
>>>         printf("%d\n", H(H_Hat, H_Hat));
>>>         H_Hat(H_Hat);
>>>    }
>>>
>>> This program prints 1 (on my system) and halts because H_Hat(H_Hat)
>>> "halts" (i.e. returns to main) even though H_Hat is correctly
>>> constructed from H.
>>>
>>> My guess is that it is trickery like this that makes people worry about
>>> functions being pure.
>>>
>>> It would have been much simpler to defend H(H_Hat, H_Hat) == 1 and
>>> H_Hat(H_Hat) than the opposite, but I don't think he ever thought of
>>> doing this.
>>>
>>> I'm not worried about pure functions because PO is told use that
>>> H(H_Hat, H_Hat) == 0 even though H_Hat(H_Hat) halts so he's wrong by
>>> defintion based on undisputed facts.
>>
>> Because it is the case that H(P,P)==0 is correctly based on computing
>> the mapping from the actual input to its own accept or reject state on
>> the basis of the actual behavior of the input H(P,)==0 is correct.
>>
>
> But the ACTUAL INPUT is a representation of P(P), so its ACTUAL BEHAVIOR
> is that of P(P).
Liar !

The actual input is a finite string of machine code
and the actual behavior of this actual input is its correct x86
emulation by H.

That you freaking simply imagine that this behavior is different than
its machine code specifies is a psychotic break from realty.

--
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/11/22 4:55 PM, olcott wrote:
> On 6/11/2022 3:32 PM, Richard Damon wrote:
>> On 6/11/22 4:22 PM, olcott wrote:
>>> On 6/11/2022 3:10 PM, Ben Bacarisse wrote:
>>>> Andy Walker <anw@cuboid.co.uk> writes:
>>>>
>>>>> On 11/06/2022 15:40, Mr Flibble wrote:
>>>>>> Nope. A pure function always returns the same value for the same
>>>>>> inputs:
>>>>>
>>>>>     Perhaps someone will explain why they are so bothered about "pure"
>>>>> functions?  These bear no interesting relation to what a TM could
>>>>> do, not
>>>>> least because it is perfectly straightforward to imagine compiling
>>>>> [eg] C
>>>>> code into a corresponding TM [equivalently into a representation to be
>>>>> "run" by some UTM] as long as the C does not make [illicit] use of the
>>>>> environment provided by the OS.
>>>>
>>>> There's nothing interesting about pure functions from a theoretical
>>>> point of view, but PO has ditched all notions of a formal model of
>>>> computation, and since he is only interesting in getting one case
>>>> correct, he could have written:
>>>>
>>>>    #include <stdio.h>
>>>>    typedef void (*ptr)();
>>>>    int H(ptr x, ptr y)
>>>>    {
>>>>         void H_Hat(ptr);
>>>>         return (char *)__builtin_return_address(0) - (char *)H_Hat >
>>>> 36;
>>>>    }
>>>>    void H_Hat(ptr x)
>>>>    {
>>>>         if (H(x, x)) while (1);
>>>>    }
>>>>    int main(void)
>>>>    {
>>>>         printf("%d\n", H(H_Hat, H_Hat));
>>>>         H_Hat(H_Hat);
>>>>    }
>>>>
>>>> This program prints 1 (on my system) and halts because H_Hat(H_Hat)
>>>> "halts" (i.e. returns to main) even though H_Hat is correctly
>>>> constructed from H.
>>>>
>>>> My guess is that it is trickery like this that makes people worry about
>>>> functions being pure.
>>>>
>>>> It would have been much simpler to defend H(H_Hat, H_Hat) == 1 and
>>>> H_Hat(H_Hat) than the opposite, but I don't think he ever thought of
>>>> doing this.
>>>>
>>>> I'm not worried about pure functions because PO is told use that
>>>> H(H_Hat, H_Hat) == 0 even though H_Hat(H_Hat) halts so he's wrong by
>>>> defintion based on undisputed facts.
>>>
>>> Because it is the case that H(P,P)==0 is correctly based on computing
>>> the mapping from the actual input to its own accept or reject state
>>> on the basis of the actual behavior of the input H(P,)==0 is correct.
>>>
>>
>> But the ACTUAL INPUT is a representation of P(P), so its ACTUAL
>> BEHAVIOR is that of P(P).
> Liar !
>
> The actual input is a finite string of machine code
> and the actual behavior of this actual input is its correct x86
> emulation by H.

Which, if it is a CORRECT x86 emulation, behaves exactly like the
program it is the code of.

>
> That you freaking simply imagine that this behavior is different than
> its machine code specifies is a psychotic break from realty.
>

Right, the machine code specifies the exact same program as P, and THUS
its emulation must match that, RIGHT?

YOU are the one saying that the emulation of the input to H, which is
the EXACT x86 code of P, somehow behaves differently than the direct
execution of P.

HOW?

P(P) has an exact x86 assembly code, that code is given to H, and
correctly emulated, so the emulation will exactly match P(P).

Where do you get a difference?

Please point to the first instruction where the CORRECT emulation of the
input and the actual execution differ.

Note, correct emulation of a Call H instruction, BY DEFINITION is
followed by the first instruction of H.

Provide a reference if you disagree. NOT just you OPINION.

On 6/11/2022 4:09 PM, Richard Damon wrote:
>
> On 6/11/22 4:55 PM, olcott wrote:
>> On 6/11/2022 3:32 PM, Richard Damon wrote:
>>> On 6/11/22 4:22 PM, olcott wrote:
>>>> On 6/11/2022 3:10 PM, Ben Bacarisse wrote:
>>>>> Andy Walker <anw@cuboid.co.uk> writes:
>>>>>
>>>>>> On 11/06/2022 15:40, Mr Flibble wrote:
>>>>>>> Nope. A pure function always returns the same value for the same
>>>>>>> inputs:
>>>>>>
>>>>>>     Perhaps someone will explain why they are so bothered about
>>>>>> "pure"
>>>>>> functions?  These bear no interesting relation to what a TM could
>>>>>> do, not
>>>>>> least because it is perfectly straightforward to imagine compiling
>>>>>> [eg] C
>>>>>> code into a corresponding TM [equivalently into a representation
>>>>>> to be
>>>>>> "run" by some UTM] as long as the C does not make [illicit] use of
>>>>>> the
>>>>>> environment provided by the OS.
>>>>>
>>>>> There's nothing interesting about pure functions from a theoretical
>>>>> point of view, but PO has ditched all notions of a formal model of
>>>>> computation, and since he is only interesting in getting one case
>>>>> correct, he could have written:
>>>>>
>>>>>    #include <stdio.h>
>>>>>    typedef void (*ptr)();
>>>>>    int H(ptr x, ptr y)
>>>>>    {
>>>>>         void H_Hat(ptr);
>>>>>         return (char *)__builtin_return_address(0) - (char *)H_Hat
>>>>> > 36;
>>>>>    }
>>>>>    void H_Hat(ptr x)
>>>>>    {
>>>>>         if (H(x, x)) while (1);
>>>>>    }
>>>>>    int main(void)
>>>>>    {
>>>>>         printf("%d\n", H(H_Hat, H_Hat));
>>>>>         H_Hat(H_Hat);
>>>>>    }
>>>>>
>>>>> This program prints 1 (on my system) and halts because H_Hat(H_Hat)
>>>>> "halts" (i.e. returns to main) even though H_Hat is correctly
>>>>> constructed from H.
>>>>>
>>>>> My guess is that it is trickery like this that makes people worry
>>>>> about
>>>>> functions being pure.
>>>>>
>>>>> It would have been much simpler to defend H(H_Hat, H_Hat) == 1 and
>>>>> H_Hat(H_Hat) than the opposite, but I don't think he ever thought of
>>>>> doing this.
>>>>>
>>>>> I'm not worried about pure functions because PO is told use that
>>>>> H(H_Hat, H_Hat) == 0 even though H_Hat(H_Hat) halts so he's wrong by
>>>>> defintion based on undisputed facts.
>>>>
>>>> Because it is the case that H(P,P)==0 is correctly based on
>>>> computing the mapping from the actual input to its own accept or
>>>> reject state on the basis of the actual behavior of the input
>>>> H(P,)==0 is correct.
>>>>
>>>
>>> But the ACTUAL INPUT is a representation of P(P), so its ACTUAL
>>> BEHAVIOR is that of P(P).
>> Liar !
>>
>> The actual input is a finite string of machine code
>> and the actual behavior of this actual input is its correct x86
>> emulation by H.
>
> Which, if it is a CORRECT x86 emulation, behaves exactly like the
> program it is the code of.
>
>>
>> That you freaking simply imagine that this behavior is different than
>> its machine code specifies is a psychotic break from realty.
>>
>
> Right, the machine code specifies the exact same program as P, and THUS
> its emulation must match that, RIGHT?
>
> YOU are the one saying that the emulation of the input to H, which is
> the EXACT x86 code of P, somehow behaves differently than the direct
> execution of P.
>
> HOW?

The HOW is beyond the intellectual capacity or everyone here so I simply
prove that it <is> different as a verified fact. Once we know that it
<is> different we don't really need to know HOW and WHY it is different.

The directly executed P(P) halts the correct complete x86 emulation of
the input to H(P,P) P would never stop running.

Proving that P(P) != the correct x86 emulation of the input to H(P,P)

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

int main()
{ P(P);
}

_P()
[000012e7](01) 55 push ebp
[000012e8](02) 8bec mov ebp,esp
[000012ea](03) 8b4508 mov eax,[ebp+08]
[000012ed](01) 50 push eax
[000012ee](03) 8b4d08 mov ecx,[ebp+08]
[000012f1](01) 51 push ecx
[000012f2](05) e880feffff call 00001177 // call H
[000012f7](03) 83c408 add esp,+08
[000012fa](02) 85c0 test eax,eax
[000012fc](02) 7402 jz 00001300
[000012fe](02) ebfe jmp 000012fe
[00001300](01) 5d pop ebp
[00001301](01) c3 ret
Size in bytes:(0027) [00001301]

_main()
[00001307](01) 55 push ebp
[00001308](02) 8bec mov ebp,esp
[0000130a](05) 68e7120000 push 000012e7 // push P
[0000130f](05) e8d3ffffff call 000012e7 // call P
[00001314](03) 83c404 add esp,+04
[00001317](02) 33c0 xor eax,eax
[00001319](01) 5d pop ebp
[0000131a](01) c3 ret
Size in bytes:(0020) [0000131a]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[00001307][00102190][00000000] 55 push ebp
[00001308][00102190][00000000] 8bec mov ebp,esp
[0000130a][0010218c][000012e7] 68e7120000 push 000012e7 // push P
[0000130f][00102188][00001314] e8d3ffffff call 000012e7 // call P
[000012e7][00102184][00102190] 55 push ebp // enter executed P
[000012e8][00102184][00102190] 8bec mov ebp,esp
[000012ea][00102184][00102190] 8b4508 mov eax,[ebp+08]
[000012ed][00102180][000012e7] 50 push eax // push P
[000012ee][00102180][000012e7] 8b4d08 mov ecx,[ebp+08]
[000012f1][0010217c][000012e7] 51 push ecx // push P
[000012f2][00102178][000012f7] e880feffff call 00001177 // call H

Begin Local Halt Decider Simulation Execution Trace Stored at:212244
[000012e7][00212230][00212234] 55 push ebp // enter emulated P
[000012e8][00212230][00212234] 8bec mov ebp,esp
[000012ea][00212230][00212234] 8b4508 mov eax,[ebp+08]
[000012ed][0021222c][000012e7] 50 push eax // push P
[000012ee][0021222c][000012e7] 8b4d08 mov ecx,[ebp+08]
[000012f1][00212228][000012e7] 51 push ecx // push P
[000012f2][00212224][000012f7] e880feffff call 00001177 // call H
[000012e7][0025cc58][0025cc5c] 55 push ebp // enter emulated P
[000012e8][0025cc58][0025cc5c] 8bec mov ebp,esp
[000012ea][0025cc58][0025cc5c] 8b4508 mov eax,[ebp+08]
[000012ed][0025cc54][000012e7] 50 push eax // push P
[000012ee][0025cc54][000012e7] 8b4d08 mov ecx,[ebp+08]
[000012f1][0025cc50][000012e7] 51 push ecx // push P
[000012f2][0025cc4c][000012f7] e880feffff call 00001177 // call H
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

It is completely obvious that when H(P,P) correctly emulates its input
that it must emulate the first seven instructions of P. Because the
seventh instruction of P repeats this process we know with complete
certainty that the correct and complete emulation of P by H would never
reach its final “ret” instruction, thus never halts.

[000012f7][00102184][00102190] 83c408 add esp,+08
[000012fa][00102184][00102190] 85c0 test eax,eax
[000012fc][00102184][00102190] 7402 jz 00001300
[00001300][00102188][00001314] 5d pop ebp
[00001301][0010218c][000012e7] c3 ret // executed P halts
[00001314][00102190][00000000] 83c404 add esp,+04
[00001317][00102190][00000000] 33c0 xor eax,eax
[00001319][00102194][00100000] 5d pop ebp
[0000131a][00102198][00000000] c3 ret // main() halts
Number of Instructions Executed(15900) 237 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/11/22 5:22 PM, olcott wrote:
> On 6/11/2022 4:09 PM, Richard Damon wrote:
>>
>> On 6/11/22 4:55 PM, olcott wrote:
>>> On 6/11/2022 3:32 PM, Richard Damon wrote:
>>>> On 6/11/22 4:22 PM, olcott wrote:
>>>>> On 6/11/2022 3:10 PM, Ben Bacarisse wrote:
>>>>>> Andy Walker <anw@cuboid.co.uk> writes:
>>>>>>
>>>>>>> On 11/06/2022 15:40, Mr Flibble wrote:
>>>>>>>> Nope. A pure function always returns the same value for the same
>>>>>>>> inputs:
>>>>>>>
>>>>>>>     Perhaps someone will explain why they are so bothered about
>>>>>>> "pure"
>>>>>>> functions?  These bear no interesting relation to what a TM could
>>>>>>> do, not
>>>>>>> least because it is perfectly straightforward to imagine
>>>>>>> compiling [eg] C
>>>>>>> code into a corresponding TM [equivalently into a representation
>>>>>>> to be
>>>>>>> "run" by some UTM] as long as the C does not make [illicit] use
>>>>>>> of the
>>>>>>> environment provided by the OS.
>>>>>>
>>>>>> There's nothing interesting about pure functions from a theoretical
>>>>>> point of view, but PO has ditched all notions of a formal model of
>>>>>> computation, and since he is only interesting in getting one case
>>>>>> correct, he could have written:
>>>>>>
>>>>>>    #include <stdio.h>
>>>>>>    typedef void (*ptr)();
>>>>>>    int H(ptr x, ptr y)
>>>>>>    {
>>>>>>         void H_Hat(ptr);
>>>>>>         return (char *)__builtin_return_address(0) - (char *)H_Hat
>>>>>> > 36;
>>>>>>    }
>>>>>>    void H_Hat(ptr x)
>>>>>>    {
>>>>>>         if (H(x, x)) while (1);
>>>>>>    }
>>>>>>    int main(void)
>>>>>>    {
>>>>>>         printf("%d\n", H(H_Hat, H_Hat));
>>>>>>         H_Hat(H_Hat);
>>>>>>    }
>>>>>>
>>>>>> This program prints 1 (on my system) and halts because H_Hat(H_Hat)
>>>>>> "halts" (i.e. returns to main) even though H_Hat is correctly
>>>>>> constructed from H.
>>>>>>
>>>>>> My guess is that it is trickery like this that makes people worry
>>>>>> about
>>>>>> functions being pure.
>>>>>>
>>>>>> It would have been much simpler to defend H(H_Hat, H_Hat) == 1 and
>>>>>> H_Hat(H_Hat) than the opposite, but I don't think he ever thought of
>>>>>> doing this.
>>>>>>
>>>>>> I'm not worried about pure functions because PO is told use that
>>>>>> H(H_Hat, H_Hat) == 0 even though H_Hat(H_Hat) halts so he's wrong by
>>>>>> defintion based on undisputed facts.
>>>>>
>>>>> Because it is the case that H(P,P)==0 is correctly based on
>>>>> computing the mapping from the actual input to its own accept or
>>>>> reject state on the basis of the actual behavior of the input
>>>>> H(P,)==0 is correct.
>>>>>
>>>>
>>>> But the ACTUAL INPUT is a representation of P(P), so its ACTUAL
>>>> BEHAVIOR is that of P(P).
>>> Liar !
>>>
>>> The actual input is a finite string of machine code
>>> and the actual behavior of this actual input is its correct x86
>>> emulation by H.
>>
>> Which, if it is a CORRECT x86 emulation, behaves exactly like the
>> program it is the code of.
>>
>>>
>>> That you freaking simply imagine that this behavior is different than
>>> its machine code specifies is a psychotic break from realty.
>>>
>>
>> Right, the machine code specifies the exact same program as P, and
>> THUS its emulation must match that, RIGHT?
>>
>> YOU are the one saying that the emulation of the input to H, which is
>> the EXACT x86 code of P, somehow behaves differently than the direct
>> execution of P.
>>
>> HOW?
>
> The HOW is beyond the intellectual capacity or everyone here so I simply
> prove that it <is> different as a verified fact. Once we know that it
> <is> different we don't really need to know HOW and WHY it is different.

Nope, but seems above your ability to try to come up with a lie to explain.

The fact that it is definitionally impossible is part of your problem.

>
> The directly executed P(P) halts the correct complete x86 emulation of
> the input to H(P,P) P would never stop running.
>

But WHY?

> Proving that P(P) != the correct x86 emulation of the input to H(P,P)
>
> void P(u32 x)
> {
>   if (H(x, x))
>     HERE: goto HERE;
>   return;
> }
>
> int main()
> {
>   P(P);
> }
>
> _P()
> [000012e7](01)  55              push ebp
> [000012e8](02)  8bec            mov ebp,esp
> [000012ea](03)  8b4508          mov eax,[ebp+08]
> [000012ed](01)  50              push eax
> [000012ee](03)  8b4d08          mov ecx,[ebp+08]
> [000012f1](01)  51              push ecx
> [000012f2](05)  e880feffff      call 00001177 // call H
> [000012f7](03)  83c408          add esp,+08
> [000012fa](02)  85c0            test eax,eax
> [000012fc](02)  7402            jz 00001300
> [000012fe](02)  ebfe            jmp 000012fe
> [00001300](01)  5d              pop ebp
> [00001301](01)  c3              ret
> Size in bytes:(0027) [00001301]
>
> _main()
> [00001307](01)  55              push ebp
> [00001308](02)  8bec            mov ebp,esp
> [0000130a](05)  68e7120000      push 000012e7 // push P
> [0000130f](05)  e8d3ffffff      call 000012e7 // call P
> [00001314](03)  83c404          add esp,+04
> [00001317](02)  33c0            xor eax,eax
> [00001319](01)  5d              pop ebp
> [0000131a](01)  c3              ret
> Size in bytes:(0020) [0000131a]
>
>  machine   stack     stack     machine    assembly
>  address   address   data      code       language
>  ========  ========  ========  =========  =============
> [00001307][00102190][00000000] 55         push ebp
> [00001308][00102190][00000000] 8bec       mov ebp,esp
> [0000130a][0010218c][000012e7] 68e7120000 push 000012e7 // push P
> [0000130f][00102188][00001314] e8d3ffffff call 000012e7 // call P
> [000012e7][00102184][00102190] 55         push ebp      // enter executed P
> [000012e8][00102184][00102190] 8bec       mov ebp,esp
> [000012ea][00102184][00102190] 8b4508     mov eax,[ebp+08]
> [000012ed][00102180][000012e7] 50         push eax      // push P
> [000012ee][00102180][000012e7] 8b4d08     mov ecx,[ebp+08]
> [000012f1][0010217c][000012e7] 51         push ecx      // push P
> [000012f2][00102178][000012f7] e880feffff call 00001177 // call H
>
> Begin Local Halt Decider Simulation   Execution Trace Stored at:212244
> [000012e7][00212230][00212234] 55          push ebp      // enter
> emulated P
> [000012e8][00212230][00212234] 8bec        mov ebp,esp
> [000012ea][00212230][00212234] 8b4508      mov eax,[ebp+08]
> [000012ed][0021222c][000012e7] 50          push eax      // push P
> [000012ee][0021222c][000012e7] 8b4d08      mov ecx,[ebp+08]
> [000012f1][00212228][000012e7] 51          push ecx      // push P
> [000012f2][00212224][000012f7] e880feffff  call 00001177 // call H

So by WHAT x86 reference manual does a call 00001177 instruction go to
000012e7?

That is your problem, and you LIE.

> [000012e7][0025cc58][0025cc5c] 55          push ebp      // enter
> emulated P
> [000012e8][0025cc58][0025cc5c] 8bec        mov ebp,esp
> [000012ea][0025cc58][0025cc5c] 8b4508      mov eax,[ebp+08]
> [000012ed][0025cc54][000012e7] 50          push eax      // push P
> [000012ee][0025cc54][000012e7] 8b4d08      mov ecx,[ebp+08]
> [000012f1][0025cc50][000012e7] 51          push ecx      // push P
> [000012f2][0025cc4c][000012f7] e880feffff  call 00001177 // call H
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>
> It is completely obvious that when H(P,P) correctly emulates its input
> that it must emulate the first seven instructions of P. Because the
> seventh instruction of P repeats this process we know with complete
> certainty that the correct and complete emulation of P by H would never
> reach its final “ret” instruction, thus never halts.
>
> [000012f7][00102184][00102190] 83c408      add esp,+08
> [000012fa][00102184][00102190] 85c0        test eax,eax
> [000012fc][00102184][00102190] 7402        jz 00001300
> [00001300][00102188][00001314] 5d          pop ebp
> [00001301][0010218c][000012e7] c3          ret           // executed P
> halts
> [00001314][00102190][00000000] 83c404      add esp,+04
> [00001317][00102190][00000000] 33c0        xor eax,eax
> [00001319][00102194][00100000] 5d          pop ebp
> [0000131a][00102198][00000000] c3          ret           // main() halts
> Number of Instructions Executed(15900) 237 pages
>
>
>

On 6/11/2022 4:34 PM, Richard Damon wrote:
>
> On 6/11/22 5:22 PM, olcott wrote:
>> On 6/11/2022 4:09 PM, Richard Damon wrote:
>>>
>>> On 6/11/22 4:55 PM, olcott wrote:
>>>> On 6/11/2022 3:32 PM, Richard Damon wrote:
>>>>> On 6/11/22 4:22 PM, olcott wrote:
>>>>>> On 6/11/2022 3:10 PM, Ben Bacarisse wrote:
>>>>>>> Andy Walker <anw@cuboid.co.uk> writes:
>>>>>>>
>>>>>>>> On 11/06/2022 15:40, Mr Flibble wrote:
>>>>>>>>> Nope. A pure function always returns the same value for the
>>>>>>>>> same inputs:
>>>>>>>>
>>>>>>>>     Perhaps someone will explain why they are so bothered about
>>>>>>>> "pure"
>>>>>>>> functions?  These bear no interesting relation to what a TM
>>>>>>>> could do, not
>>>>>>>> least because it is perfectly straightforward to imagine
>>>>>>>> compiling [eg] C
>>>>>>>> code into a corresponding TM [equivalently into a representation
>>>>>>>> to be
>>>>>>>> "run" by some UTM] as long as the C does not make [illicit] use
>>>>>>>> of the
>>>>>>>> environment provided by the OS.
>>>>>>>
>>>>>>> There's nothing interesting about pure functions from a theoretical
>>>>>>> point of view, but PO has ditched all notions of a formal model of
>>>>>>> computation, and since he is only interesting in getting one case
>>>>>>> correct, he could have written:
>>>>>>>
>>>>>>>    #include <stdio.h>
>>>>>>>    typedef void (*ptr)();
>>>>>>>    int H(ptr x, ptr y)
>>>>>>>    {
>>>>>>>         void H_Hat(ptr);
>>>>>>>         return (char *)__builtin_return_address(0) - (char
>>>>>>> *)H_Hat > 36;
>>>>>>>    }
>>>>>>>    void H_Hat(ptr x)
>>>>>>>    {
>>>>>>>         if (H(x, x)) while (1);
>>>>>>>    }
>>>>>>>    int main(void)
>>>>>>>    {
>>>>>>>         printf("%d\n", H(H_Hat, H_Hat));
>>>>>>>         H_Hat(H_Hat);
>>>>>>>    }
>>>>>>>
>>>>>>> This program prints 1 (on my system) and halts because H_Hat(H_Hat)
>>>>>>> "halts" (i.e. returns to main) even though H_Hat is correctly
>>>>>>> constructed from H.
>>>>>>>
>>>>>>> My guess is that it is trickery like this that makes people worry
>>>>>>> about
>>>>>>> functions being pure.
>>>>>>>
>>>>>>> It would have been much simpler to defend H(H_Hat, H_Hat) == 1 and
>>>>>>> H_Hat(H_Hat) than the opposite, but I don't think he ever thought of
>>>>>>> doing this.
>>>>>>>
>>>>>>> I'm not worried about pure functions because PO is told use that
>>>>>>> H(H_Hat, H_Hat) == 0 even though H_Hat(H_Hat) halts so he's wrong by
>>>>>>> defintion based on undisputed facts.
>>>>>>
>>>>>> Because it is the case that H(P,P)==0 is correctly based on
>>>>>> computing the mapping from the actual input to its own accept or
>>>>>> reject state on the basis of the actual behavior of the input
>>>>>> H(P,)==0 is correct.
>>>>>>
>>>>>
>>>>> But the ACTUAL INPUT is a representation of P(P), so its ACTUAL
>>>>> BEHAVIOR is that of P(P).
>>>> Liar !
>>>>
>>>> The actual input is a finite string of machine code
>>>> and the actual behavior of this actual input is its correct x86
>>>> emulation by H.
>>>
>>> Which, if it is a CORRECT x86 emulation, behaves exactly like the
>>> program it is the code of.
>>>
>>>>
>>>> That you freaking simply imagine that this behavior is different
>>>> than its machine code specifies is a psychotic break from realty.
>>>>
>>>
>>> Right, the machine code specifies the exact same program as P, and
>>> THUS its emulation must match that, RIGHT?
>>>
>>> YOU are the one saying that the emulation of the input to H, which is
>>> the EXACT x86 code of P, somehow behaves differently than the direct
>>> execution of P.
>>>
>>> HOW?
>>
>> The HOW is beyond the intellectual capacity or everyone here so I
>> simply prove that it <is> different as a verified fact. Once we know
>> that it <is> different we don't really need to know HOW and WHY it is
>> different.
>
> Nope, but seems above your ability to try to come up with a lie to explain.
>
> The fact that it is definitionally impossible is part of your problem.
>
>>
>> The directly executed P(P) halts the correct complete x86 emulation of
>> the input to H(P,P) P would never stop running.
>>
>
> But WHY?
>
>> Proving that P(P) != the correct x86 emulation of the input to H(P,P)
>>
>> void P(u32 x)
>> {
>>    if (H(x, x))
>>      HERE: goto HERE;
>>    return;
>> }
>>
>> int main()
>> {
>>    P(P);
>> }
>>
>> _P()
>> [000012e7](01)  55              push ebp
>> [000012e8](02)  8bec            mov ebp,esp
>> [000012ea](03)  8b4508          mov eax,[ebp+08]
>> [000012ed](01)  50              push eax
>> [000012ee](03)  8b4d08          mov ecx,[ebp+08]
>> [000012f1](01)  51              push ecx
>> [000012f2](05)  e880feffff      call 00001177 // call H
>> [000012f7](03)  83c408          add esp,+08
>> [000012fa](02)  85c0            test eax,eax
>> [000012fc](02)  7402            jz 00001300
>> [000012fe](02)  ebfe            jmp 000012fe
>> [00001300](01)  5d              pop ebp
>> [00001301](01)  c3              ret
>> Size in bytes:(0027) [00001301]
>>
>> _main()
>> [00001307](01)  55              push ebp
>> [00001308](02)  8bec            mov ebp,esp
>> [0000130a](05)  68e7120000      push 000012e7 // push P
>> [0000130f](05)  e8d3ffffff      call 000012e7 // call P
>> [00001314](03)  83c404          add esp,+04
>> [00001317](02)  33c0            xor eax,eax
>> [00001319](01)  5d              pop ebp
>> [0000131a](01)  c3              ret
>> Size in bytes:(0020) [0000131a]
>>
>>   machine   stack     stack     machine    assembly
>>   address   address   data      code       language
>>   ========  ========  ========  =========  =============
>> [00001307][00102190][00000000] 55         push ebp
>> [00001308][00102190][00000000] 8bec       mov ebp,esp
>> [0000130a][0010218c][000012e7] 68e7120000 push 000012e7 // push P
>> [0000130f][00102188][00001314] e8d3ffffff call 000012e7 // call P
>> [000012e7][00102184][00102190] 55         push ebp      // enter
>> executed P
>> [000012e8][00102184][00102190] 8bec       mov ebp,esp
>> [000012ea][00102184][00102190] 8b4508     mov eax,[ebp+08]
>> [000012ed][00102180][000012e7] 50         push eax      // push P
>> [000012ee][00102180][000012e7] 8b4d08     mov ecx,[ebp+08]
>> [000012f1][0010217c][000012e7] 51         push ecx      // push P
>> [000012f2][00102178][000012f7] e880feffff call 00001177 // call H
>>
>> Begin Local Halt Decider Simulation   Execution Trace Stored at:212244
>> [000012e7][00212230][00212234] 55          push ebp      // enter
>> emulated P
>> [000012e8][00212230][00212234] 8bec        mov ebp,esp
>> [000012ea][00212230][00212234] 8b4508      mov eax,[ebp+08]
>> [000012ed][0021222c][000012e7] 50          push eax      // push P
>> [000012ee][0021222c][000012e7] 8b4d08      mov ecx,[ebp+08]
>> [000012f1][00212228][000012e7] 51          push ecx      // push P
>> [000012f2][00212224][000012f7] e880feffff  call 00001177 // call H
>
> So by WHAT x86 reference manual does a call 00001177 instruction go to
> 000012e7?
>

On 6/11/22 5:46 PM, olcott wrote:
> On 6/11/2022 4:34 PM, Richard Damon wrote:
>>
>> On 6/11/22 5:22 PM, olcott wrote:
>>> On 6/11/2022 4:09 PM, Richard Damon wrote:
>>>>
>>>> On 6/11/22 4:55 PM, olcott wrote:
>>>>> On 6/11/2022 3:32 PM, Richard Damon wrote:
>>>>>> On 6/11/22 4:22 PM, olcott wrote:
>>>>>>> On 6/11/2022 3:10 PM, Ben Bacarisse wrote:
>>>>>>>> Andy Walker <anw@cuboid.co.uk> writes:
>>>>>>>>
>>>>>>>>> On 11/06/2022 15:40, Mr Flibble wrote:
>>>>>>>>>> Nope. A pure function always returns the same value for the
>>>>>>>>>> same inputs:
>>>>>>>>>
>>>>>>>>>     Perhaps someone will explain why they are so bothered about
>>>>>>>>> "pure"
>>>>>>>>> functions?  These bear no interesting relation to what a TM
>>>>>>>>> could do, not
>>>>>>>>> least because it is perfectly straightforward to imagine
>>>>>>>>> compiling [eg] C
>>>>>>>>> code into a corresponding TM [equivalently into a
>>>>>>>>> representation to be
>>>>>>>>> "run" by some UTM] as long as the C does not make [illicit] use
>>>>>>>>> of the
>>>>>>>>> environment provided by the OS.
>>>>>>>>
>>>>>>>> There's nothing interesting about pure functions from a theoretical
>>>>>>>> point of view, but PO has ditched all notions of a formal model of
>>>>>>>> computation, and since he is only interesting in getting one case
>>>>>>>> correct, he could have written:
>>>>>>>>
>>>>>>>>    #include <stdio.h>
>>>>>>>>    typedef void (*ptr)();
>>>>>>>>    int H(ptr x, ptr y)
>>>>>>>>    {
>>>>>>>>         void H_Hat(ptr);
>>>>>>>>         return (char *)__builtin_return_address(0) - (char
>>>>>>>> *)H_Hat > 36;
>>>>>>>>    }
>>>>>>>>    void H_Hat(ptr x)
>>>>>>>>    {
>>>>>>>>         if (H(x, x)) while (1);
>>>>>>>>    }
>>>>>>>>    int main(void)
>>>>>>>>    {
>>>>>>>>         printf("%d\n", H(H_Hat, H_Hat));
>>>>>>>>         H_Hat(H_Hat);
>>>>>>>>    }
>>>>>>>>
>>>>>>>> This program prints 1 (on my system) and halts because H_Hat(H_Hat)
>>>>>>>> "halts" (i.e. returns to main) even though H_Hat is correctly
>>>>>>>> constructed from H.
>>>>>>>>
>>>>>>>> My guess is that it is trickery like this that makes people
>>>>>>>> worry about
>>>>>>>> functions being pure.
>>>>>>>>
>>>>>>>> It would have been much simpler to defend H(H_Hat, H_Hat) == 1 and
>>>>>>>> H_Hat(H_Hat) than the opposite, but I don't think he ever
>>>>>>>> thought of
>>>>>>>> doing this.
>>>>>>>>
>>>>>>>> I'm not worried about pure functions because PO is told use that
>>>>>>>> H(H_Hat, H_Hat) == 0 even though H_Hat(H_Hat) halts so he's
>>>>>>>> wrong by
>>>>>>>> defintion based on undisputed facts.
>>>>>>>
>>>>>>> Because it is the case that H(P,P)==0 is correctly based on
>>>>>>> computing the mapping from the actual input to its own accept or
>>>>>>> reject state on the basis of the actual behavior of the input
>>>>>>> H(P,)==0 is correct.
>>>>>>>
>>>>>>
>>>>>> But the ACTUAL INPUT is a representation of P(P), so its ACTUAL
>>>>>> BEHAVIOR is that of P(P).
>>>>> Liar !
>>>>>
>>>>> The actual input is a finite string of machine code
>>>>> and the actual behavior of this actual input is its correct x86
>>>>> emulation by H.
>>>>
>>>> Which, if it is a CORRECT x86 emulation, behaves exactly like the
>>>> program it is the code of.
>>>>
>>>>>
>>>>> That you freaking simply imagine that this behavior is different
>>>>> than its machine code specifies is a psychotic break from realty.
>>>>>
>>>>
>>>> Right, the machine code specifies the exact same program as P, and
>>>> THUS its emulation must match that, RIGHT?
>>>>
>>>> YOU are the one saying that the emulation of the input to H, which
>>>> is the EXACT x86 code of P, somehow behaves differently than the
>>>> direct execution of P.
>>>>
>>>> HOW?
>>>
>>> The HOW is beyond the intellectual capacity or everyone here so I
>>> simply prove that it <is> different as a verified fact. Once we know
>>> that it <is> different we don't really need to know HOW and WHY it is
>>> different.
>>
>> Nope, but seems above your ability to try to come up with a lie to
>> explain.
>>
>> The fact that it is definitionally impossible is part of your problem.
>>
>>>
>>> The directly executed P(P) halts the correct complete x86 emulation
>>> of the input to H(P,P) P would never stop running.
>>>
>>
>> But WHY?
>>
>>> Proving that P(P) != the correct x86 emulation of the input to H(P,P)
>>>
>>> void P(u32 x)
>>> {
>>>    if (H(x, x))
>>>      HERE: goto HERE;
>>>    return;
>>> }
>>>
>>> int main()
>>> {
>>>    P(P);
>>> }
>>>
>>> _P()
>>> [000012e7](01)  55              push ebp
>>> [000012e8](02)  8bec            mov ebp,esp
>>> [000012ea](03)  8b4508          mov eax,[ebp+08]
>>> [000012ed](01)  50              push eax
>>> [000012ee](03)  8b4d08          mov ecx,[ebp+08]
>>> [000012f1](01)  51              push ecx
>>> [000012f2](05)  e880feffff      call 00001177 // call H
>>> [000012f7](03)  83c408          add esp,+08
>>> [000012fa](02)  85c0            test eax,eax
>>> [000012fc](02)  7402            jz 00001300
>>> [000012fe](02)  ebfe            jmp 000012fe
>>> [00001300](01)  5d              pop ebp
>>> [00001301](01)  c3              ret
>>> Size in bytes:(0027) [00001301]
>>>
>>> _main()
>>> [00001307](01)  55              push ebp
>>> [00001308](02)  8bec            mov ebp,esp
>>> [0000130a](05)  68e7120000      push 000012e7 // push P
>>> [0000130f](05)  e8d3ffffff      call 000012e7 // call P
>>> [00001314](03)  83c404          add esp,+04
>>> [00001317](02)  33c0            xor eax,eax
>>> [00001319](01)  5d              pop ebp
>>> [0000131a](01)  c3              ret
>>> Size in bytes:(0020) [0000131a]
>>>
>>>   machine   stack     stack     machine    assembly
>>>   address   address   data      code       language
>>>   ========  ========  ========  =========  =============
>>> [00001307][00102190][00000000] 55         push ebp
>>> [00001308][00102190][00000000] 8bec       mov ebp,esp
>>> [0000130a][0010218c][000012e7] 68e7120000 push 000012e7 // push P
>>> [0000130f][00102188][00001314] e8d3ffffff call 000012e7 // call P
>>> [000012e7][00102184][00102190] 55         push ebp      // enter
>>> executed P
>>> [000012e8][00102184][00102190] 8bec       mov ebp,esp
>>> [000012ea][00102184][00102190] 8b4508     mov eax,[ebp+08]
>>> [000012ed][00102180][000012e7] 50         push eax      // push P
>>> [000012ee][00102180][000012e7] 8b4d08     mov ecx,[ebp+08]
>>> [000012f1][0010217c][000012e7] 51         push ecx      // push P
>>> [000012f2][00102178][000012f7] e880feffff call 00001177 // call H
>>>
>>> Begin Local Halt Decider Simulation   Execution Trace Stored at:212244
>>> [000012e7][00212230][00212234] 55          push ebp      // enter
>>> emulated P
>>> [000012e8][00212230][00212234] 8bec        mov ebp,esp
>>> [000012ea][00212230][00212234] 8b4508      mov eax,[ebp+08]
>>> [000012ed][0021222c][000012e7] 50          push eax      // push P
>>> [000012ee][0021222c][000012e7] 8b4d08      mov ecx,[ebp+08]
>>> [000012f1][00212228][000012e7] 51          push ecx      // push P
>>> [000012f2][00212224][000012f7] e880feffff  call 00001177 // call H
>>
>> So by WHAT x86 reference manual does a call 00001177 instruction go to
>> 000012e7?
>>
>
> My pure function of its inputs version never invokes H from P thus there
> is no execution trace of H to show. As soon as H sees P call itself with
> its same arguments and P reaches this point in its execution trace
> unconditionally H aborts the x86 emulation of P.
>

On 6/11/2022 4:57 PM, Richard Damon wrote:
> On 6/11/22 5:46 PM, olcott wrote:
>> On 6/11/2022 4:34 PM, Richard Damon wrote:
>>>
>>> On 6/11/22 5:22 PM, olcott wrote:
>>>> On 6/11/2022 4:09 PM, Richard Damon wrote:
>>>>>
>>>>> On 6/11/22 4:55 PM, olcott wrote:
>>>>>> On 6/11/2022 3:32 PM, Richard Damon wrote:
>>>>>>> On 6/11/22 4:22 PM, olcott wrote:
>>>>>>>> On 6/11/2022 3:10 PM, Ben Bacarisse wrote:
>>>>>>>>> Andy Walker <anw@cuboid.co.uk> writes:
>>>>>>>>>
>>>>>>>>>> On 11/06/2022 15:40, Mr Flibble wrote:
>>>>>>>>>>> Nope. A pure function always returns the same value for the
>>>>>>>>>>> same inputs:
>>>>>>>>>>
>>>>>>>>>>     Perhaps someone will explain why they are so bothered
>>>>>>>>>> about "pure"
>>>>>>>>>> functions?  These bear no interesting relation to what a TM
>>>>>>>>>> could do, not
>>>>>>>>>> least because it is perfectly straightforward to imagine
>>>>>>>>>> compiling [eg] C
>>>>>>>>>> code into a corresponding TM [equivalently into a
>>>>>>>>>> representation to be
>>>>>>>>>> "run" by some UTM] as long as the C does not make [illicit]
>>>>>>>>>> use of the
>>>>>>>>>> environment provided by the OS.
>>>>>>>>>
>>>>>>>>> There's nothing interesting about pure functions from a
>>>>>>>>> theoretical
>>>>>>>>> point of view, but PO has ditched all notions of a formal model of
>>>>>>>>> computation, and since he is only interesting in getting one case
>>>>>>>>> correct, he could have written:
>>>>>>>>>
>>>>>>>>>    #include <stdio.h>
>>>>>>>>>    typedef void (*ptr)();
>>>>>>>>>    int H(ptr x, ptr y)
>>>>>>>>>    {
>>>>>>>>>         void H_Hat(ptr);
>>>>>>>>>         return (char *)__builtin_return_address(0) - (char
>>>>>>>>> *)H_Hat > 36;
>>>>>>>>>    }
>>>>>>>>>    void H_Hat(ptr x)
>>>>>>>>>    {
>>>>>>>>>         if (H(x, x)) while (1);
>>>>>>>>>    }
>>>>>>>>>    int main(void)
>>>>>>>>>    {
>>>>>>>>>         printf("%d\n", H(H_Hat, H_Hat));
>>>>>>>>>         H_Hat(H_Hat);
>>>>>>>>>    }
>>>>>>>>>
>>>>>>>>> This program prints 1 (on my system) and halts because
>>>>>>>>> H_Hat(H_Hat)
>>>>>>>>> "halts" (i.e. returns to main) even though H_Hat is correctly
>>>>>>>>> constructed from H.
>>>>>>>>>
>>>>>>>>> My guess is that it is trickery like this that makes people
>>>>>>>>> worry about
>>>>>>>>> functions being pure.
>>>>>>>>>
>>>>>>>>> It would have been much simpler to defend H(H_Hat, H_Hat) == 1 and
>>>>>>>>> H_Hat(H_Hat) than the opposite, but I don't think he ever
>>>>>>>>> thought of
>>>>>>>>> doing this.
>>>>>>>>>
>>>>>>>>> I'm not worried about pure functions because PO is told use that
>>>>>>>>> H(H_Hat, H_Hat) == 0 even though H_Hat(H_Hat) halts so he's
>>>>>>>>> wrong by
>>>>>>>>> defintion based on undisputed facts.
>>>>>>>>
>>>>>>>> Because it is the case that H(P,P)==0 is correctly based on
>>>>>>>> computing the mapping from the actual input to its own accept or
>>>>>>>> reject state on the basis of the actual behavior of the input
>>>>>>>> H(P,)==0 is correct.
>>>>>>>>
>>>>>>>
>>>>>>> But the ACTUAL INPUT is a representation of P(P), so its ACTUAL
>>>>>>> BEHAVIOR is that of P(P).
>>>>>> Liar !
>>>>>>
>>>>>> The actual input is a finite string of machine code
>>>>>> and the actual behavior of this actual input is its correct x86
>>>>>> emulation by H.
>>>>>
>>>>> Which, if it is a CORRECT x86 emulation, behaves exactly like the
>>>>> program it is the code of.
>>>>>
>>>>>>
>>>>>> That you freaking simply imagine that this behavior is different
>>>>>> than its machine code specifies is a psychotic break from realty.
>>>>>>
>>>>>
>>>>> Right, the machine code specifies the exact same program as P, and
>>>>> THUS its emulation must match that, RIGHT?
>>>>>
>>>>> YOU are the one saying that the emulation of the input to H, which
>>>>> is the EXACT x86 code of P, somehow behaves differently than the
>>>>> direct execution of P.
>>>>>
>>>>> HOW?
>>>>
>>>> The HOW is beyond the intellectual capacity or everyone here so I
>>>> simply prove that it <is> different as a verified fact. Once we know
>>>> that it <is> different we don't really need to know HOW and WHY it
>>>> is different.
>>>
>>> Nope, but seems above your ability to try to come up with a lie to
>>> explain.
>>>
>>> The fact that it is definitionally impossible is part of your problem.
>>>
>>>>
>>>> The directly executed P(P) halts the correct complete x86 emulation
>>>> of the input to H(P,P) P would never stop running.
>>>>
>>>
>>> But WHY?
>>>
>>>> Proving that P(P) != the correct x86 emulation of the input to H(P,P)
>>>>
>>>> void P(u32 x)
>>>> {
>>>>    if (H(x, x))
>>>>      HERE: goto HERE;
>>>>    return;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>>    P(P);
>>>> }
>>>>
>>>> _P()
>>>> [000012e7](01)  55              push ebp
>>>> [000012e8](02)  8bec            mov ebp,esp
>>>> [000012ea](03)  8b4508          mov eax,[ebp+08]
>>>> [000012ed](01)  50              push eax
>>>> [000012ee](03)  8b4d08          mov ecx,[ebp+08]
>>>> [000012f1](01)  51              push ecx
>>>> [000012f2](05)  e880feffff      call 00001177 // call H
>>>> [000012f7](03)  83c408          add esp,+08
>>>> [000012fa](02)  85c0            test eax,eax
>>>> [000012fc](02)  7402            jz 00001300
>>>> [000012fe](02)  ebfe            jmp 000012fe
>>>> [00001300](01)  5d              pop ebp
>>>> [00001301](01)  c3              ret
>>>> Size in bytes:(0027) [00001301]
>>>>
>>>> _main()
>>>> [00001307](01)  55              push ebp
>>>> [00001308](02)  8bec            mov ebp,esp
>>>> [0000130a](05)  68e7120000      push 000012e7 // push P
>>>> [0000130f](05)  e8d3ffffff      call 000012e7 // call P
>>>> [00001314](03)  83c404          add esp,+04
>>>> [00001317](02)  33c0            xor eax,eax
>>>> [00001319](01)  5d              pop ebp
>>>> [0000131a](01)  c3              ret
>>>> Size in bytes:(0020) [0000131a]
>>>>
>>>>   machine   stack     stack     machine    assembly
>>>>   address   address   data      code       language
>>>>   ========  ========  ========  =========  =============
>>>> [00001307][00102190][00000000] 55         push ebp
>>>> [00001308][00102190][00000000] 8bec       mov ebp,esp
>>>> [0000130a][0010218c][000012e7] 68e7120000 push 000012e7 // push P
>>>> [0000130f][00102188][00001314] e8d3ffffff call 000012e7 // call P
>>>> [000012e7][00102184][00102190] 55         push ebp      // enter
>>>> executed P
>>>> [000012e8][00102184][00102190] 8bec       mov ebp,esp
>>>> [000012ea][00102184][00102190] 8b4508     mov eax,[ebp+08]
>>>> [000012ed][00102180][000012e7] 50         push eax      // push P
>>>> [000012ee][00102180][000012e7] 8b4d08     mov ecx,[ebp+08]
>>>> [000012f1][0010217c][000012e7] 51         push ecx      // push P
>>>> [000012f2][00102178][000012f7] e880feffff call 00001177 // call H
>>>>
>>>> Begin Local Halt Decider Simulation   Execution Trace Stored at:212244
>>>> [000012e7][00212230][00212234] 55          push ebp      // enter
>>>> emulated P
>>>> [000012e8][00212230][00212234] 8bec        mov ebp,esp
>>>> [000012ea][00212230][00212234] 8b4508      mov eax,[ebp+08]
>>>> [000012ed][0021222c][000012e7] 50          push eax      // push P
>>>> [000012ee][0021222c][000012e7] 8b4d08      mov ecx,[ebp+08]
>>>> [000012f1][00212228][000012e7] 51          push ecx      // push P
>>>> [000012f2][00212224][000012f7] e880feffff  call 00001177 // call H
>>>
>>> So by WHAT x86 reference manual does a call 00001177 instruction go
>>> to 000012e7?
>>>
>>
>> My pure function of its inputs version never invokes H from P thus
>> there is no execution trace of H to show. As soon as H sees P call
>> itself with its same arguments and P reaches this point in its
>> execution trace unconditionally H aborts the x86 emulation of P.
>>
>
> ???? Is this NOT showing a trace with your pure function version, if
> not, what it this, and why>
>

On 6/11/22 6:08 PM, olcott wrote:
> On 6/11/2022 4:57 PM, Richard Damon wrote:
>> On 6/11/22 5:46 PM, olcott wrote:
>>> On 6/11/2022 4:34 PM, Richard Damon wrote:
>>>>
>>>> On 6/11/22 5:22 PM, olcott wrote:
>>>>> On 6/11/2022 4:09 PM, Richard Damon wrote:
>>>>>>
>>>>>> On 6/11/22 4:55 PM, olcott wrote:
>>>>>>> On 6/11/2022 3:32 PM, Richard Damon wrote:
>>>>>>>> On 6/11/22 4:22 PM, olcott wrote:
>>>>>>>>> On 6/11/2022 3:10 PM, Ben Bacarisse wrote:
>>>>>>>>>> Andy Walker <anw@cuboid.co.uk> writes:
>>>>>>>>>>
>>>>>>>>>>> On 11/06/2022 15:40, Mr Flibble wrote:
>>>>>>>>>>>> Nope. A pure function always returns the same value for the
>>>>>>>>>>>> same inputs:
>>>>>>>>>>>
>>>>>>>>>>>     Perhaps someone will explain why they are so bothered
>>>>>>>>>>> about "pure"
>>>>>>>>>>> functions?  These bear no interesting relation to what a TM
>>>>>>>>>>> could do, not
>>>>>>>>>>> least because it is perfectly straightforward to imagine
>>>>>>>>>>> compiling [eg] C
>>>>>>>>>>> code into a corresponding TM [equivalently into a
>>>>>>>>>>> representation to be
>>>>>>>>>>> "run" by some UTM] as long as the C does not make [illicit]
>>>>>>>>>>> use of the
>>>>>>>>>>> environment provided by the OS.
>>>>>>>>>>
>>>>>>>>>> There's nothing interesting about pure functions from a
>>>>>>>>>> theoretical
>>>>>>>>>> point of view, but PO has ditched all notions of a formal
>>>>>>>>>> model of
>>>>>>>>>> computation, and since he is only interesting in getting one case
>>>>>>>>>> correct, he could have written:
>>>>>>>>>>
>>>>>>>>>>    #include <stdio.h>
>>>>>>>>>>    typedef void (*ptr)();
>>>>>>>>>>    int H(ptr x, ptr y)
>>>>>>>>>>    {
>>>>>>>>>>         void H_Hat(ptr);
>>>>>>>>>>         return (char *)__builtin_return_address(0) - (char
>>>>>>>>>> *)H_Hat > 36;
>>>>>>>>>>    }
>>>>>>>>>>    void H_Hat(ptr x)
>>>>>>>>>>    {
>>>>>>>>>>         if (H(x, x)) while (1);
>>>>>>>>>>    }
>>>>>>>>>>    int main(void)
>>>>>>>>>>    {
>>>>>>>>>>         printf("%d\n", H(H_Hat, H_Hat));
>>>>>>>>>>         H_Hat(H_Hat);
>>>>>>>>>>    }
>>>>>>>>>>
>>>>>>>>>> This program prints 1 (on my system) and halts because
>>>>>>>>>> H_Hat(H_Hat)
>>>>>>>>>> "halts" (i.e. returns to main) even though H_Hat is correctly
>>>>>>>>>> constructed from H.
>>>>>>>>>>
>>>>>>>>>> My guess is that it is trickery like this that makes people
>>>>>>>>>> worry about
>>>>>>>>>> functions being pure.
>>>>>>>>>>
>>>>>>>>>> It would have been much simpler to defend H(H_Hat, H_Hat) == 1
>>>>>>>>>> and
>>>>>>>>>> H_Hat(H_Hat) than the opposite, but I don't think he ever
>>>>>>>>>> thought of
>>>>>>>>>> doing this.
>>>>>>>>>>
>>>>>>>>>> I'm not worried about pure functions because PO is told use that
>>>>>>>>>> H(H_Hat, H_Hat) == 0 even though H_Hat(H_Hat) halts so he's
>>>>>>>>>> wrong by
>>>>>>>>>> defintion based on undisputed facts.
>>>>>>>>>
>>>>>>>>> Because it is the case that H(P,P)==0 is correctly based on
>>>>>>>>> computing the mapping from the actual input to its own accept
>>>>>>>>> or reject state on the basis of the actual behavior of the
>>>>>>>>> input H(P,)==0 is correct.
>>>>>>>>>
>>>>>>>>
>>>>>>>> But the ACTUAL INPUT is a representation of P(P), so its ACTUAL
>>>>>>>> BEHAVIOR is that of P(P).
>>>>>>> Liar !
>>>>>>>
>>>>>>> The actual input is a finite string of machine code
>>>>>>> and the actual behavior of this actual input is its correct x86
>>>>>>> emulation by H.
>>>>>>
>>>>>> Which, if it is a CORRECT x86 emulation, behaves exactly like the
>>>>>> program it is the code of.
>>>>>>
>>>>>>>
>>>>>>> That you freaking simply imagine that this behavior is different
>>>>>>> than its machine code specifies is a psychotic break from realty.
>>>>>>>
>>>>>>
>>>>>> Right, the machine code specifies the exact same program as P, and
>>>>>> THUS its emulation must match that, RIGHT?
>>>>>>
>>>>>> YOU are the one saying that the emulation of the input to H, which
>>>>>> is the EXACT x86 code of P, somehow behaves differently than the
>>>>>> direct execution of P.
>>>>>>
>>>>>> HOW?
>>>>>
>>>>> The HOW is beyond the intellectual capacity or everyone here so I
>>>>> simply prove that it <is> different as a verified fact. Once we
>>>>> know that it <is> different we don't really need to know HOW and
>>>>> WHY it is different.
>>>>
>>>> Nope, but seems above your ability to try to come up with a lie to
>>>> explain.
>>>>
>>>> The fact that it is definitionally impossible is part of your problem.
>>>>
>>>>>
>>>>> The directly executed P(P) halts the correct complete x86 emulation
>>>>> of the input to H(P,P) P would never stop running.
>>>>>
>>>>
>>>> But WHY?
>>>>
>>>>> Proving that P(P) != the correct x86 emulation of the input to H(P,P)
>>>>>
>>>>> void P(u32 x)
>>>>> {
>>>>>    if (H(x, x))
>>>>>      HERE: goto HERE;
>>>>>    return;
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>>    P(P);
>>>>> }
>>>>>
>>>>> _P()
>>>>> [000012e7](01)  55              push ebp
>>>>> [000012e8](02)  8bec            mov ebp,esp
>>>>> [000012ea](03)  8b4508          mov eax,[ebp+08]
>>>>> [000012ed](01)  50              push eax
>>>>> [000012ee](03)  8b4d08          mov ecx,[ebp+08]
>>>>> [000012f1](01)  51              push ecx
>>>>> [000012f2](05)  e880feffff      call 00001177 // call H
>>>>> [000012f7](03)  83c408          add esp,+08
>>>>> [000012fa](02)  85c0            test eax,eax
>>>>> [000012fc](02)  7402            jz 00001300
>>>>> [000012fe](02)  ebfe            jmp 000012fe
>>>>> [00001300](01)  5d              pop ebp
>>>>> [00001301](01)  c3              ret
>>>>> Size in bytes:(0027) [00001301]
>>>>>
>>>>> _main()
>>>>> [00001307](01)  55              push ebp
>>>>> [00001308](02)  8bec            mov ebp,esp
>>>>> [0000130a](05)  68e7120000      push 000012e7 // push P
>>>>> [0000130f](05)  e8d3ffffff      call 000012e7 // call P
>>>>> [00001314](03)  83c404          add esp,+04
>>>>> [00001317](02)  33c0            xor eax,eax
>>>>> [00001319](01)  5d              pop ebp
>>>>> [0000131a](01)  c3              ret
>>>>> Size in bytes:(0020) [0000131a]
>>>>>
>>>>>   machine   stack     stack     machine    assembly
>>>>>   address   address   data      code       language
>>>>>   ========  ========  ========  =========  =============
>>>>> [00001307][00102190][00000000] 55         push ebp
>>>>> [00001308][00102190][00000000] 8bec       mov ebp,esp
>>>>> [0000130a][0010218c][000012e7] 68e7120000 push 000012e7 // push P
>>>>> [0000130f][00102188][00001314] e8d3ffffff call 000012e7 // call P
>>>>> [000012e7][00102184][00102190] 55         push ebp      // enter
>>>>> executed P
>>>>> [000012e8][00102184][00102190] 8bec       mov ebp,esp
>>>>> [000012ea][00102184][00102190] 8b4508     mov eax,[ebp+08]
>>>>> [000012ed][00102180][000012e7] 50         push eax      // push P
>>>>> [000012ee][00102180][000012e7] 8b4d08     mov ecx,[ebp+08]
>>>>> [000012f1][0010217c][000012e7] 51         push ecx      // push P
>>>>> [000012f2][00102178][000012f7] e880feffff call 00001177 // call H
>>>>>
>>>>> Begin Local Halt Decider Simulation   Execution Trace Stored at:212244
>>>>> [000012e7][00212230][00212234] 55          push ebp      // enter
>>>>> emulated P
>>>>> [000012e8][00212230][00212234] 8bec        mov ebp,esp
>>>>> [000012ea][00212230][00212234] 8b4508      mov eax,[ebp+08]
>>>>> [000012ed][0021222c][000012e7] 50          push eax      // push P
>>>>> [000012ee][0021222c][000012e7] 8b4d08      mov ecx,[ebp+08]
>>>>> [000012f1][00212228][000012e7] 51          push ecx      // push P
>>>>> [000012f2][00212224][000012f7] e880feffff  call 00001177 // call H
>>>>
>>>> So by WHAT x86 reference manual does a call 00001177 instruction go
>>>> to 000012e7?
>>>>
>>>
>>> My pure function of its inputs version never invokes H from P thus
>>> there is no execution trace of H to show. As soon as H sees P call
>>> itself with its same arguments and P reaches this point in its
>>> execution trace unconditionally H aborts the x86 emulation of P.
>>>
>>
>> ???? Is this NOT showing a trace with your pure function version, if
>> not, what it this, and why>
>>
>
> I haven't written it yet.
>
>> The above program has main calling P calling H(P,P), and that needs to
>> be the actual same H(P,P) as when you call H(P,P) directlu.
>>
>
> The execution of P(P) and the correct x86 emulation of the input to
> H(P,P) use the exact same finite string byte sequence at the exact same
> machine address.