*straw man*
An intentionally misrepresented proposition that is set up because it is
easier to defeat than an opponent's real argument.
https://www.lexico.com/en/definition/straw_man

H correctly determines the halt status specified by its arguments.

The deceptive "rebuttals" don't even try to rebut this claim instead
they claim that that H does not correctly determine the halt status of
something besides its actual arguments.

void P(ptr x)
{ int Halt_Status = H(x, x);
if (Halt_Status)
HERE: goto HERE;
return;
}

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

--
Copyright 2022 Pete Olcott

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

On Friday, August 5, 2022 at 10:48:23 PM UTC-4, olcott wrote:
> *straw man*
> An intentionally misrepresented proposition that is set up because it is
> easier to defeat than an opponent's real argument.
> https://www.lexico.com/en/definition/straw_man
>
> H correctly determines the halt status specified by its arguments.

We know from your prior statements that when you say this, you mean "H determines whether there exists an implementation of the function H that can simulate the function call given by its arguments to a final state".

>
> The deceptive "rebuttals" don't even try to rebut this claim instead
> they claim that that H does not correctly determine the halt status of
> something besides its actual arguments.

We accept that in the case of H(P,P), it correctly determines that there is no implementation of the function H that can simulate the function call P(P) to a final state, and correctly answer that question.

We also point out that this has nothing to do with the halting problem, as it is not the question that the halting problem asks.

A universal halt decider, *if one exists*, maps the halting function. That means it must implement the following specification:

H(X,Y)==1 if and only if X(Y) halts, and
H(X,Y)==0 if and only if X(Y) does not halt

Your H does not perform this mapping. Therefore it is not a halt decider.

It may be a correct "can an alternate implementation of myself simulate this function call to a final state" decider, but that is irrelevant to the halting problem.

On 8/5/2022 10:12 PM, Dennis Bush wrote:
> On Friday, August 5, 2022 at 10:48:23 PM UTC-4, olcott wrote:
>> *straw man*
>> An intentionally misrepresented proposition that is set up because it is
>> easier to defeat than an opponent's real argument.
>> https://www.lexico.com/en/definition/straw_man
>>
>> H correctly determines the halt status specified by its arguments.
>
> We know from your prior statements that when you say this, you mean "H determines whether there exists an implementation of the function H that can simulate the function call given by its arguments to a final state".
>
>>
>> The deceptive "rebuttals" don't even try to rebut this claim instead
>> they claim that that H does not correctly determine the halt status of
>> something besides its actual arguments.
>
> We accept that in the case of H(P,P), it correctly determines that there is no implementation of the function H that can simulate the function call P(P) to a final state, and correctly answer that question.

H is correct, it is P that doesn't halt.

>
> We also point out that this has nothing to do with the halting problem, as it is not the question that the halting problem asks.
>
> A universal halt decider, *if one exists*, maps the halting function. That means it must implement the following specification:
>
> H(X,Y)==1 if and only if X(Y) halts, and
> H(X,Y)==0 if and only if X(Y) does not halt
>
> Your H does not perform this mapping. Therefore it is not a halt decider.
>
> It may be a correct "can an alternate implementation of myself simulate this function call to a final state" decider, but that is irrelevant to the halting problem.

--
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 Fri, 5 Aug 2022 21:48:16 -0500
olcott <NoOne@NoWhere.com> wrote:

> *straw man*
> An intentionally misrepresented proposition that is set up because it
> is easier to defeat than an opponent's real argument.
> https://www.lexico.com/en/definition/straw_man
>
> H correctly determines the halt status specified by its arguments.
>
> The deceptive "rebuttals" don't even try to rebut this claim instead
> they claim that that H does not correctly determine the halt status
> of something besides its actual arguments.
>
> void P(ptr x)
> {
> int Halt_Status = H(x, x);
> if (Halt_Status)
> HERE: goto HERE;
> return;
> }
>
> int main()
> {
> Output("Input_Halts = ", H(P, P));
> }
>
>

void Px(ptr x)
{ int Halt_Status = H(x, x);
(void)Halt_Status;
return;
}

Until your SHD can correctly handle the above case (i.e. a decision of
halts) it is worthless.

/Flibble

On Saturday, 6 August 2022 at 10:48:23 UTC+8, olcott wrote:
> *straw man*
> An intentionally misrepresented proposition that is set up because it is
> easier to defeat than an opponent's real argument.
> https://www.lexico.com/en/definition/straw_man
>
> H correctly determines the halt status specified by its arguments.
>
> The deceptive "rebuttals" don't even try to rebut this claim instead
> they claim that that H does not correctly determine the halt status of
> something besides its actual arguments.
>
> void P(ptr x)
> {
> int Halt_Status = H(x, x);
> if (Halt_Status)
> HERE: goto HERE;
> return;
> }
>
> int main()
> {
> Output("Input_Halts = ", H(P, P));
> }
>
>
> --
> Copyright 2022 Pete Olcott
>
> "Talent hits a target no one else can hit;
> Genius hits a target no one else can see."
> Arthur Schopenhauer

If you are not talking about the Halting Problem as in this post, you might be
right but its POOH, not very interesting. But I believe you intend to refute
the HP. As posted many times, your H cannot report the right answer about P(P):

int main()
{ Output("Input_Halts = ", H(P, P));
P(P);
} --------------
I am going to say something for general readers.
olcott reads a lots, but just words (by rote). His understanding is 'linguistic'.
His basic logic required for science is seriously flawed (the logic implication
is the same as logic AND, and more). So his words is highly questionable even
it reads right, e.g. when he says the sum(4,5) must return the sum of 4 and 5,
don't assume he thinks what normal people would think, others like C/TM/x86/OS/
simulation/pure function,... no one has correct meaning.

olcott pre-determined the HP is 'refuted'. If everybody attacks a point long
enough for him to think it won't pass the review, he would simply and
effortlessly change to another 'linguistic' reason leaving the replyers gnash
(this is his EXHAUSTIVE strategy for his patent. 'correctness' is not important
or different in his understanding).
My understanding of his appeal is: He DECIDED the liar's paradox as an invalid
(pathological) question (input), e.g. proposition B: "I am lying", so the HP and
other similar proofs are refuted in his understand. He only searches for 'linguistic' reasons, no logic.

On 8/6/22 12:25 AM, olcott wrote:
> On 8/5/2022 10:12 PM, Dennis Bush wrote:
>> On Friday, August 5, 2022 at 10:48:23 PM UTC-4, olcott wrote:
>>> *straw man*
>>> An intentionally misrepresented proposition that is set up because it is
>>> easier to defeat than an opponent's real argument.
>>> https://www.lexico.com/en/definition/straw_man
>>>
>>> H correctly determines the halt status specified by its arguments.
>>
>> We know from your prior statements that when you say this, you mean "H
>> determines whether there exists an implementation of the function H
>> that can simulate the function call given by its arguments to a final
>> state".
>>
>>>
>>> The deceptive "rebuttals" don't even try to rebut this claim instead
>>> they claim that that H does not correctly determine the halt status of
>>> something besides its actual arguments.
>>
>> We accept that in the case of H(P,P), it correctly determines that
>> there is no implementation of the function H that can simulate the
>> function call P(P) to a final state, and correctly answer that question.
>
>
> H is correct, it is P that doesn't halt.

Except that even YOU have agreed that P does halt.

What doesn't reach the final state is the PARTIAL simulation of P by H,
but that doesn't mean anything.

You have also shown that NO H by your template can ever simulate to that
final state, but again, that doesn't mean anything, just that H can
NEVER prove that this sort of input will halt.

The definition of Halting looks at the actual Turing Machine (or in the
more general case, the actual program) and that does halt.

YOU are the one putting forward the Strawman of looking at the partial
simulation done by H, or the simulation done by a different H that never
halts but that H can't ever report that fact.

You also use UNSOUND and INVALID logic to try to prove that P(P) won't
halt, but the fact that we know it will shows that logic to be wrong.

YOU are thus the one who is wrong.

>
>>
>> We also point out that this has nothing to do with the halting
>> problem, as it is not the question that the halting problem asks.
>>
>> A universal halt decider, *if one exists*, maps the halting function.
>> That means it must implement the following specification:
>>
>> H(X,Y)==1 if and only if X(Y) halts, and
>> H(X,Y)==0 if and only if X(Y) does not halt
>>
>> Your H does not perform this mapping.  Therefore it is not a halt
>> decider.
>>
>> It may be a correct "can an alternate implementation of myself
>> simulate this function call to a final state" decider, but that is
>> irrelevant to the halting problem.
>
>

On 8/5/22 10:48 PM, olcott wrote:
> *straw man*
> An intentionally misrepresented proposition that is set up because it is
> easier to defeat than an opponent's real argument.
> https://www.lexico.com/en/definition/straw_man
>
> H correctly determines the halt status specified by its arguments.
>
> The deceptive "rebuttals" don't even try to rebut this claim instead
> they claim that that H does not correctly determine the halt status of
> something besides its actual arguments.

And if you are going to claim that H(P,P) doesn't ask about P(P), then
why does P make that call to determine that exact fact.

Remember, P is DEFINED to call H about itself with its input so that it
can do the opposite.

Also, since BY DEFINITION, a Halt Decider to be correct, needs to be
able to be asked about ANY computation, how do we ask H to decide on P(P)?

If we can't, you H just fails to even get out of the starting gate.

>
> void P(ptr x)
> {
>   int Halt_Status = H(x, x);
>   if (Halt_Status)
>     HERE: goto HERE;
>   return;
> }
>
> int main()
> {
>   Output("Input_Halts = ", H(P, P));
> }
>
>

On 8/6/2022 6:46 AM, wij wrote:
> On Saturday, 6 August 2022 at 10:48:23 UTC+8, olcott wrote:
>> *straw man*
>> An intentionally misrepresented proposition that is set up because it is
>> easier to defeat than an opponent's real argument.
>> https://www.lexico.com/en/definition/straw_man
>>
>> H correctly determines the halt status specified by its arguments.
>>
>> The deceptive "rebuttals" don't even try to rebut this claim instead
>> they claim that that H does not correctly determine the halt status of
>> something besides its actual arguments.
>>
>> void P(ptr x)
>> {
>> int Halt_Status = H(x, x);
>> if (Halt_Status)
>> HERE: goto HERE;
>> return;
>> }
>>
>> int main()
>> {
>> Output("Input_Halts = ", H(P, P));
>> }
>>
>>
>> --
>> Copyright 2022 Pete Olcott
>>
>> "Talent hits a target no one else can hit;
>> Genius hits a target no one else can see."
>> Arthur Schopenhauer
>
> If you are not talking about the Halting Problem as in this post, you might be
> right but its POOH, not very interesting. But I believe you intend to refute
> the HP. As posted many times, your H cannot report the right answer about P(P):
>

You still dodged the question !!!
You still dodged the question !!!
You still dodged the question !!!
You still dodged the question !!!
You still dodged the question !!!

The question is whether or not H(P,P) correctly determines that halt
status of its arguments. Like everyone else you respond with the
strawman deception as your rebuttal.

I am not asking whether or not H(P,P) should determine the halt status
of its arguments (according to the HP) or should determine the halt
status of something else (according to the HP).

I am asking: Can you see that H(P,P) does correctly determine the halt
status of its arguments?

WE MUST GO THOUGH MY PROOF POINT-BY-POINT AND STEP-BY-STEP.
EVERYONE LEAPS AHEAD PREVENTING CLOSURE ON EVEN A SINGLE POINT.

WE MUST GO THOUGH MY PROOF POINT-BY-POINT AND STEP-BY-STEP.
EVERYONE LEAPS AHEAD PREVENTING CLOSURE ON EVEN A SINGLE POINT.

WE MUST GO THOUGH MY PROOF POINT-BY-POINT AND STEP-BY-STEP.
EVERYONE LEAPS AHEAD PREVENTING CLOSURE ON EVEN A SINGLE POINT.

WE MUST GO THOUGH MY PROOF POINT-BY-POINT AND STEP-BY-STEP.
EVERYONE LEAPS AHEAD PREVENTING CLOSURE ON EVEN A SINGLE POINT.

> int main()
> {
> Output("Input_Halts = ", H(P, P));
> P(P);
> }
> --------------
> I am going to say something for general readers.
> olcott reads a lots, but just words (by rote). His understanding is 'linguistic'.
> His basic logic required for science is seriously flawed (the logic implication
> is the same as logic AND, and more). So his words is highly questionable even
> it reads right, e.g. when he says the sum(4,5) must return the sum of 4 and 5,
> don't assume he thinks what normal people would think, others like C/TM/x86/OS/
> simulation/pure function,... no one has correct meaning.
>
> olcott pre-determined the HP is 'refuted'. If everybody attacks a point long
> enough for him to think it won't pass the review, he would simply and
> effortlessly change to another 'linguistic' reason leaving the replyers gnash
> (this is his EXHAUSTIVE strategy for his patent. 'correctness' is not important
> or different in his understanding).
> My understanding of his appeal is: He DECIDED the liar's paradox as an invalid
> (pathological) question (input), e.g. proposition B: "I am lying", so the HP and
> other similar proofs are refuted in his understand. He only searches for 'linguistic' reasons, no logic.
>

--
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 8/7/22 5:12 PM, olcott wrote:
> On 8/6/2022 6:46 AM, wij wrote:
>> On Saturday, 6 August 2022 at 10:48:23 UTC+8, olcott wrote:
>>> *straw man*
>>> An intentionally misrepresented proposition that is set up because it is
>>> easier to defeat than an opponent's real argument.
>>> https://www.lexico.com/en/definition/straw_man
>>>
>>> H correctly determines the halt status specified by its arguments.
>>>
>>> The deceptive "rebuttals" don't even try to rebut this claim instead
>>> they claim that that H does not correctly determine the halt status of
>>> something besides its actual arguments.
>>>
>>> void P(ptr x)
>>> {
>>> int Halt_Status = H(x, x);
>>> if (Halt_Status)
>>> HERE: goto HERE;
>>> return;
>>> }
>>>
>>> int main()
>>> {
>>> Output("Input_Halts = ", H(P, P));
>>> }
>>>
>>>
>>> --
>>> Copyright 2022 Pete Olcott
>>>
>>> "Talent hits a target no one else can hit;
>>> Genius hits a target no one else can see."
>>> Arthur Schopenhauer
>>
>> If you are not talking about the Halting Problem as in this post, you
>> might be
>> right but its POOH, not very interesting. But I believe you intend to
>> refute
>> the HP. As posted many times, your H cannot report the right answer
>> about P(P):
>>
>
> You still dodged the question !!!
> You still dodged the question !!!
> You still dodged the question !!!
> You still dodged the question !!!
> You still dodged the question !!!
>
> The question is whether or not H(P,P) correctly determines that halt
> status of its arguments. Like everyone else you respond with the
> strawman deception as your rebuttal.

Which it doesn't since the CORRECT Halt Status of its input is defined
by P(P) or your P isn't defined right, and P(P) will Halt if H(P,P)
returns 0.

SO H is WRONG by definition.

>
> I am not asking whether or not H(P,P) should determine the halt status
> of its arguments (according to the HP) or should determine the halt
> status of something else (according to the HP).
>
> I am asking: Can you see that H(P,P) does correctly determine the halt
> status of its arguments?

We can see that it doesn't

>
> WE MUST GO THOUGH MY PROOF POINT-BY-POINT AND STEP-BY-STEP.
> EVERYONE LEAPS AHEAD PREVENTING CLOSURE ON EVEN A SINGLE POINT.

Because you don't accept our answers when we do go step by step.

H can prove that H can't simulate its input to a final state, and in
fact, that NO machine in the "H family" can do this.

That is NOT the definition of Halting, the behavior of the actual
machine is, and P(P) (the input) Halts if H(P,P) returns 0, so that
answer is BY DEFINITION wrong to be given.

>
> WE MUST GO THOUGH MY PROOF POINT-BY-POINT AND STEP-BY-STEP.
> EVERYONE LEAPS AHEAD PREVENTING CLOSURE ON EVEN A SINGLE POINT.
>
> WE MUST GO THOUGH MY PROOF POINT-BY-POINT AND STEP-BY-STEP.
> EVERYONE LEAPS AHEAD PREVENTING CLOSURE ON EVEN A SINGLE POINT.
>
> WE MUST GO THOUGH MY PROOF POINT-BY-POINT AND STEP-BY-STEP.
> EVERYONE LEAPS AHEAD PREVENTING CLOSURE ON EVEN A SINGLE POINT.
>
>> int main()
>> {
>> Output("Input_Halts = ", H(P, P));
>> P(P);
>> }
>> --------------
>> I am going to say something for general readers.
>> olcott reads a lots, but just words (by rote). His understanding is
>> 'linguistic'.
>> His basic logic required for science is seriously flawed (the logic
>> implication
>>   is the same as logic AND, and more). So his words is highly
>> questionable even
>> it reads right, e.g. when he says the sum(4,5) must return the sum of
>> 4 and 5,
>> don't assume he thinks what normal people would think, others like
>> C/TM/x86/OS/
>> simulation/pure function,... no one has correct meaning.
>>
>> olcott pre-determined the HP is 'refuted'. If everybody attacks a
>> point long
>> enough for him to think it won't pass the review, he would simply and
>> effortlessly change to another 'linguistic' reason leaving the
>> replyers gnash
>> (this is his EXHAUSTIVE strategy for his patent. 'correctness' is not
>> important
>> or different in his understanding).
>> My understanding of his appeal is: He DECIDED the liar's paradox as an
>> invalid
>> (pathological) question (input), e.g. proposition B: "I am lying", so
>> the HP and
>> other similar proofs are refuted in his understand. He only searches
>> for 'linguistic' reasons, no logic.
>>
>
>

On Monday, 8 August 2022 at 05:12:59 UTC+8, olcott wrote:
> On 8/6/2022 6:46 AM, wij wrote:
> > On Saturday, 6 August 2022 at 10:48:23 UTC+8, olcott wrote:
> >> *straw man*
> >> An intentionally misrepresented proposition that is set up because it is
> >> easier to defeat than an opponent's real argument.
> >> https://www.lexico.com/en/definition/straw_man
> >>
> >> H correctly determines the halt status specified by its arguments.
> >>
> >> The deceptive "rebuttals" don't even try to rebut this claim instead
> >> they claim that that H does not correctly determine the halt status of
> >> something besides its actual arguments.
> >>
> >> void P(ptr x)
> >> {
> >> int Halt_Status = H(x, x);
> >> if (Halt_Status)
> >> HERE: goto HERE;
> >> return;
> >> }
> >>
> >> int main()
> >> {
> >> Output("Input_Halts = ", H(P, P));
> >> }
> >>
> >>
> >> --
> >> Copyright 2022 Pete Olcott
> >>
> >> "Talent hits a target no one else can hit;
> >> Genius hits a target no one else can see."
> >> Arthur Schopenhauer
> >
> > If you are not talking about the Halting Problem as in this post, you might be
> > right but its POOH, not very interesting. But I believe you intend to refute
> > the HP. As posted many times, your H cannot report the right answer about P(P):
> >
> You still dodged the question !!!
> You still dodged the question !!!
> You still dodged the question !!!
> You still dodged the question !!!
> You still dodged the question !!!
>
> The question is whether or not H(P,P) correctly determines that halt
> status of its arguments. Like everyone else you respond with the
> strawman deception as your rebuttal.
>
> I am not asking whether or not H(P,P) should determine the halt status
> of its arguments (according to the HP) or should determine the halt
> status of something else (according to the HP).
>
> I am asking: Can you see that H(P,P) does correctly determine the halt
> status of its arguments?
>
> WE MUST GO THOUGH MY PROOF POINT-BY-POINT AND STEP-BY-STEP.
> EVERYONE LEAPS AHEAD PREVENTING CLOSURE ON EVEN A SINGLE POINT.
>
> WE MUST GO THOUGH MY PROOF POINT-BY-POINT AND STEP-BY-STEP.
> EVERYONE LEAPS AHEAD PREVENTING CLOSURE ON EVEN A SINGLE POINT.
>
> WE MUST GO THOUGH MY PROOF POINT-BY-POINT AND STEP-BY-STEP.
> EVERYONE LEAPS AHEAD PREVENTING CLOSURE ON EVEN A SINGLE POINT.
>
> WE MUST GO THOUGH MY PROOF POINT-BY-POINT AND STEP-BY-STEP.
> EVERYONE LEAPS AHEAD PREVENTING CLOSURE ON EVEN A SINGLE POINT.
> > int main()
> > {
> > Output("Input_Halts = ", H(P, P));
> > P(P);
> > }
> > --------------
> > I am going to say something for general readers.
> > olcott reads a lots, but just words (by rote). His understanding is 'linguistic'.
> > His basic logic required for science is seriously flawed (the logic implication
> > is the same as logic AND, and more). So his words is highly questionable even
> > it reads right, e.g. when he says the sum(4,5) must return the sum of 4 and 5,
> > don't assume he thinks what normal people would think, others like C/TM/x86/OS/
> > simulation/pure function,... no one has correct meaning.
> >
> > olcott pre-determined the HP is 'refuted'. If everybody attacks a point long
> > enough for him to think it won't pass the review, he would simply and
> > effortlessly change to another 'linguistic' reason leaving the replyers gnash
> > (this is his EXHAUSTIVE strategy for his patent. 'correctness' is not important
> > or different in his understanding).
> > My understanding of his appeal is: He DECIDED the liar's paradox as an invalid
> > (pathological) question (input), e.g. proposition B: "I am lying", so the HP and
> > other similar proofs are refuted in his understand. He only searches for 'linguistic' reasons, no logic.
> >
> --
> Copyright 2022 Pete Olcott
>
> "Talent hits a target no one else can hit;
> Genius hits a target no one else can see."
> Arthur Schopenhauer

What is the halting property of P? If we say P halts, doesn't that mean P(P) halts?
In your case P halts means H(P,P)=1, why is the POO Halt interesting?

On 8/8/2022 4:05 AM, wij wrote:
> On Monday, 8 August 2022 at 05:12:59 UTC+8, olcott wrote:
>> On 8/6/2022 6:46 AM, wij wrote:
>>> On Saturday, 6 August 2022 at 10:48:23 UTC+8, olcott wrote:
>>>> *straw man*
>>>> An intentionally misrepresented proposition that is set up because it is
>>>> easier to defeat than an opponent's real argument.
>>>> https://www.lexico.com/en/definition/straw_man
>>>>
>>>> H correctly determines the halt status specified by its arguments.
>>>>
>>>> The deceptive "rebuttals" don't even try to rebut this claim instead
>>>> they claim that that H does not correctly determine the halt status of
>>>> something besides its actual arguments.
>>>>
>>>> void P(ptr x)
>>>> {
>>>> int Halt_Status = H(x, x);
>>>> if (Halt_Status)
>>>> HERE: goto HERE;
>>>> return;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>> Output("Input_Halts = ", H(P, P));
>>>> }
>>>>
>>>>
>>>> --
>>>> Copyright 2022 Pete Olcott
>>>>
>>>> "Talent hits a target no one else can hit;
>>>> Genius hits a target no one else can see."
>>>> Arthur Schopenhauer
>>>
>>> If you are not talking about the Halting Problem as in this post, you might be
>>> right but its POOH, not very interesting. But I believe you intend to refute
>>> the HP. As posted many times, your H cannot report the right answer about P(P):
>>>
>> You still dodged the question !!!
>> You still dodged the question !!!
>> You still dodged the question !!!
>> You still dodged the question !!!
>> You still dodged the question !!!
>>
>> The question is whether or not H(P,P) correctly determines that halt
>> status of its arguments. Like everyone else you respond with the
>> strawman deception as your rebuttal.
>>
>> I am not asking whether or not H(P,P) should determine the halt status
>> of its arguments (according to the HP) or should determine the halt
>> status of something else (according to the HP).
>>
>> I am asking: Can you see that H(P,P) does correctly determine the halt
>> status of its arguments?
>>
>> WE MUST GO THOUGH MY PROOF POINT-BY-POINT AND STEP-BY-STEP.
>> EVERYONE LEAPS AHEAD PREVENTING CLOSURE ON EVEN A SINGLE POINT.
>>
>> WE MUST GO THOUGH MY PROOF POINT-BY-POINT AND STEP-BY-STEP.
>> EVERYONE LEAPS AHEAD PREVENTING CLOSURE ON EVEN A SINGLE POINT.
>>
>> WE MUST GO THOUGH MY PROOF POINT-BY-POINT AND STEP-BY-STEP.
>> EVERYONE LEAPS AHEAD PREVENTING CLOSURE ON EVEN A SINGLE POINT.
>>
>> WE MUST GO THOUGH MY PROOF POINT-BY-POINT AND STEP-BY-STEP.
>> EVERYONE LEAPS AHEAD PREVENTING CLOSURE ON EVEN A SINGLE POINT.
>>> int main()
>>> {
>>> Output("Input_Halts = ", H(P, P));
>>> P(P);
>>> }
>>> --------------
>>> I am going to say something for general readers.
>>> olcott reads a lots, but just words (by rote). His understanding is 'linguistic'.
>>> His basic logic required for science is seriously flawed (the logic implication
>>> is the same as logic AND, and more). So his words is highly questionable even
>>> it reads right, e.g. when he says the sum(4,5) must return the sum of 4 and 5,
>>> don't assume he thinks what normal people would think, others like C/TM/x86/OS/
>>> simulation/pure function,... no one has correct meaning.
>>>
>>> olcott pre-determined the HP is 'refuted'. If everybody attacks a point long
>>> enough for him to think it won't pass the review, he would simply and
>>> effortlessly change to another 'linguistic' reason leaving the replyers gnash
>>> (this is his EXHAUSTIVE strategy for his patent. 'correctness' is not important
>>> or different in his understanding).
>>> My understanding of his appeal is: He DECIDED the liar's paradox as an invalid
>>> (pathological) question (input), e.g. proposition B: "I am lying", so the HP and
>>> other similar proofs are refuted in his understand. He only searches for 'linguistic' reasons, no logic.
>>>
>> --
>> Copyright 2022 Pete Olcott
>>
>> "Talent hits a target no one else can hit;
>> Genius hits a target no one else can see."
>> Arthur Schopenhauer
>
> What is the halting property of P? If we say P halts, doesn't that mean P(P) halts?

No it does not as I prove right here:

Example 05: P(P) halts because H(P,P) correctly determines that its
input never halts

This conclusively proves that H(P,P) correctly simulates its input and
that the behavior of the correctly simulated P is very different than
the directly executed P(P).

The correctly simulated P cannot possibly terminate normally by reaching
its own "return" instruction. The executed P does terminate normally and
reaches its own "return" instruction.

If you are not an expert in the x86 language then you lack the basis to
determine that the input to H(P,P) is not simulated correctly. The
strongest claim that you can make is that on the basis that you do not
understand the x86 language you do not understand the proof.

typedef void (*ptr)();
int H(ptr p, ptr i); // simulating halt decider

void P(ptr x)
{ int Halt_Status = H(x, x);
if (Halt_Status)
HERE: goto HERE;
return;
}

int main()
{ P(P);
}

_P()
[0000143b](01) 55 push ebp
[0000143c](02) 8bec mov ebp,esp
[0000143e](01) 51 push ecx
[0000143f](03) 8b4508 mov eax,[ebp+08]
[00001442](01) 50 push eax
[00001443](03) 8b4d08 mov ecx,[ebp+08]
[00001446](01) 51 push ecx
[00001447](05) e8affcffff call 000010fb
[0000144c](03) 83c408 add esp,+08
[0000144f](03) 8945fc mov [ebp-04],eax
[00001452](04) 837dfc00 cmp dword [ebp-04],+00
[00001456](02) 7402 jz 0000145a
[00001458](02) ebfe jmp 00001458
[0000145a](02) 8be5 mov esp,ebp
[0000145c](01) 5d pop ebp
[0000145d](01) c3 ret
Size in bytes:(0035) [0000145d]

_main()
[0000146b](01) 55 push ebp
[0000146c](02) 8bec mov ebp,esp
[0000146e](05) 683b140000 push 0000143b
[00001473](05) e8c3ffffff call 0000143b
[00001478](03) 83c404 add esp,+04
[0000147b](02) 33c0 xor eax,eax
[0000147d](01) 5d pop ebp
[0000147e](01) c3 ret
Size in bytes:(0020) [0000147e]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[0000146b][00102428][00000000] 55 push ebp
[0000146c][00102428][00000000] 8bec mov ebp,esp
[0000146e][00102424][0000143b] 683b140000 push 0000143b // push P
[00001473][00102420][00001478] e8c3ffffff call 0000143b // call P
with argument on stack
[0000143b][0010241c][00102428] 55 push ebp // enter
executed P
[0000143c][0010241c][00102428] 8bec mov ebp,esp
[0000143e][00102418][00000000] 51 push ecx
[0000143f][00102418][00000000] 8b4508 mov eax,[ebp+08] // load eax
with argument to P
[00001442][00102414][0000143b] 50 push eax // push P
from eax
[00001443][00102414][0000143b] 8b4d08 mov ecx,[ebp+08] // load ecx
with argument to P
[00001446][00102410][0000143b] 51 push ecx // push P
from ecx
[00001447][0010240c][0000144c] e8affcffff call 000010fb // call
executed H with arguments on stack

H: Begin Simulation Execution Trace Stored at:1124d4
Address_of_H:10fb
[0000143b][001124c0][001124c4] 55 push ebp // enter
emulated P
[0000143c][001124c0][001124c4] 8bec mov ebp,esp
[0000143e][001124bc][00102490] 51 push ecx
[0000143f][001124bc][00102490] 8b4508 mov eax,[ebp+08] // load eax
with argument to P
[00001442][001124b8][0000143b] 50 push eax // push P
from eax
[00001443][001124b8][0000143b] 8b4d08 mov ecx,[ebp+08] // load ecx
with argument to P
[00001446][001124b4][0000143b] 51 push ecx // push P
from ecx
[00001447][001124b0][0000144c] e8affcffff call 000010fb // call
emulated H with arguments on stack
H: Infinitely Recursive Simulation Detected Simulation Stopped

When simulating halt decider H(P,P) simulates its input it can see that:
(1) Function H() is called from P().
(2) With the same arguments to H().
(3) With no instructions in P preceding its invocation of H(P,P) that
could escape repeated simulations.

On Mon, 8 Aug 2022 09:56:17 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 8/8/2022 4:05 AM, wij wrote:
> > On Monday, 8 August 2022 at 05:12:59 UTC+8, olcott wrote:
> >> On 8/6/2022 6:46 AM, wij wrote:
> >>> On Saturday, 6 August 2022 at 10:48:23 UTC+8, olcott wrote:
> >>>> *straw man*
> >>>> An intentionally misrepresented proposition that is set up
> >>>> because it is easier to defeat than an opponent's real argument.
> >>>> https://www.lexico.com/en/definition/straw_man
> >>>>
> >>>> H correctly determines the halt status specified by its
> >>>> arguments.
> >>>>
> >>>> The deceptive "rebuttals" don't even try to rebut this claim
> >>>> instead they claim that that H does not correctly determine the
> >>>> halt status of something besides its actual arguments.
> >>>>
> >>>> void P(ptr x)
> >>>> {
> >>>> int Halt_Status = H(x, x);
> >>>> if (Halt_Status)
> >>>> HERE: goto HERE;
> >>>> return;
> >>>> }
> >>>>
> >>>> int main()
> >>>> {
> >>>> Output("Input_Halts = ", H(P, P));
> >>>> }
> >>>>
> >>>>
> >>>> --
> >>>> Copyright 2022 Pete Olcott
> >>>>
> >>>> "Talent hits a target no one else can hit;
> >>>> Genius hits a target no one else can see."
> >>>> Arthur Schopenhauer
> >>>
> >>> If you are not talking about the Halting Problem as in this post,
> >>> you might be right but its POOH, not very interesting. But I
> >>> believe you intend to refute the HP. As posted many times, your H
> >>> cannot report the right answer about P(P):
> >> You still dodged the question !!!
> >> You still dodged the question !!!
> >> You still dodged the question !!!
> >> You still dodged the question !!!
> >> You still dodged the question !!!
> >>
> >> The question is whether or not H(P,P) correctly determines that
> >> halt status of its arguments. Like everyone else you respond with
> >> the strawman deception as your rebuttal.
> >>
> >> I am not asking whether or not H(P,P) should determine the halt
> >> status of its arguments (according to the HP) or should determine
> >> the halt status of something else (according to the HP).
> >>
> >> I am asking: Can you see that H(P,P) does correctly determine the
> >> halt status of its arguments?
> >>
> >> WE MUST GO THOUGH MY PROOF POINT-BY-POINT AND STEP-BY-STEP.
> >> EVERYONE LEAPS AHEAD PREVENTING CLOSURE ON EVEN A SINGLE POINT.
> >>
> >> WE MUST GO THOUGH MY PROOF POINT-BY-POINT AND STEP-BY-STEP.
> >> EVERYONE LEAPS AHEAD PREVENTING CLOSURE ON EVEN A SINGLE POINT.
> >>
> >> WE MUST GO THOUGH MY PROOF POINT-BY-POINT AND STEP-BY-STEP.
> >> EVERYONE LEAPS AHEAD PREVENTING CLOSURE ON EVEN A SINGLE POINT.
> >>
> >> WE MUST GO THOUGH MY PROOF POINT-BY-POINT AND STEP-BY-STEP.
> >> EVERYONE LEAPS AHEAD PREVENTING CLOSURE ON EVEN A SINGLE POINT.
> >>> int main()
> >>> {
> >>> Output("Input_Halts = ", H(P, P));
> >>> P(P);
> >>> }
> >>> --------------
> >>> I am going to say something for general readers.
> >>> olcott reads a lots, but just words (by rote). His understanding
> >>> is 'linguistic'. His basic logic required for science is
> >>> seriously flawed (the logic implication is the same as logic AND,
> >>> and more). So his words is highly questionable even it reads
> >>> right, e.g. when he says the sum(4,5) must return the sum of 4
> >>> and 5, don't assume he thinks what normal people would think,
> >>> others like C/TM/x86/OS/ simulation/pure function,... no one has
> >>> correct meaning.
> >>>
> >>> olcott pre-determined the HP is 'refuted'. If everybody attacks a
> >>> point long enough for him to think it won't pass the review, he
> >>> would simply and effortlessly change to another 'linguistic'
> >>> reason leaving the replyers gnash (this is his EXHAUSTIVE
> >>> strategy for his patent. 'correctness' is not important or
> >>> different in his understanding). My understanding of his appeal
> >>> is: He DECIDED the liar's paradox as an invalid (pathological)
> >>> question (input), e.g. proposition B: "I am lying", so the HP and
> >>> other similar proofs are refuted in his understand. He only
> >>> searches for 'linguistic' reasons, no logic.
> >> --
> >> Copyright 2022 Pete Olcott
> >>
> >> "Talent hits a target no one else can hit;
> >> Genius hits a target no one else can see."
> >> Arthur Schopenhauer
> >
> > What is the halting property of P? If we say P halts, doesn't that
> > mean P(P) halts?
>
> No it does not as I prove right here:
>
> Example 05: P(P) halts because H(P,P) correctly determines that
> its input never halts
>
> This conclusively proves that H(P,P) correctly simulates its input
> and that the behavior of the correctly simulated P is very different
> than the directly executed P(P).
>
> The correctly simulated P cannot possibly terminate normally by
> reaching its own "return" instruction. The executed P does terminate
> normally and reaches its own "return" instruction.
>
> If you are not an expert in the x86 language then you lack the basis
> to determine that the input to H(P,P) is not simulated correctly. The
> strongest claim that you can make is that on the basis that you do
> not understand the x86 language you do not understand the proof.
>
> typedef void (*ptr)();
> int H(ptr p, ptr i); // simulating halt decider
>
> void P(ptr x)
> {
> int Halt_Status = H(x, x);
> if (Halt_Status)
> HERE: goto HERE;
> return;
> }
>
> int main()
> {
> P(P);
> }
>
> _P()
> [0000143b](01) 55 push ebp
> [0000143c](02) 8bec mov ebp,esp
> [0000143e](01) 51 push ecx
> [0000143f](03) 8b4508 mov eax,[ebp+08]
> [00001442](01) 50 push eax
> [00001443](03) 8b4d08 mov ecx,[ebp+08]
> [00001446](01) 51 push ecx
> [00001447](05) e8affcffff call 000010fb
> [0000144c](03) 83c408 add esp,+08
> [0000144f](03) 8945fc mov [ebp-04],eax
> [00001452](04) 837dfc00 cmp dword [ebp-04],+00
> [00001456](02) 7402 jz 0000145a
> [00001458](02) ebfe jmp 00001458
> [0000145a](02) 8be5 mov esp,ebp
> [0000145c](01) 5d pop ebp
> [0000145d](01) c3 ret
> Size in bytes:(0035) [0000145d]
>
> _main()
> [0000146b](01) 55 push ebp
> [0000146c](02) 8bec mov ebp,esp
> [0000146e](05) 683b140000 push 0000143b
> [00001473](05) e8c3ffffff call 0000143b
> [00001478](03) 83c404 add esp,+04
> [0000147b](02) 33c0 xor eax,eax
> [0000147d](01) 5d pop ebp
> [0000147e](01) c3 ret
> Size in bytes:(0020) [0000147e]
>
> machine stack stack machine assembly
> address address data code language
> ======== ======== ======== ========= ============> [0000146b][00102428][00000000] 55 push ebp
> [0000146c][00102428][00000000] 8bec mov ebp,esp
> [0000146e][00102424][0000143b] 683b140000 push 0000143b // push P
> [00001473][00102420][00001478] e8c3ffffff call 0000143b // call P
> with argument on stack
> [0000143b][0010241c][00102428] 55 push ebp // enter
> executed P
> [0000143c][0010241c][00102428] 8bec mov ebp,esp
> [0000143e][00102418][00000000] 51 push ecx
> [0000143f][00102418][00000000] 8b4508 mov eax,[ebp+08] // load
> eax with argument to P
> [00001442][00102414][0000143b] 50 push eax // push P
> from eax
> [00001443][00102414][0000143b] 8b4d08 mov ecx,[ebp+08] // load
> ecx with argument to P
> [00001446][00102410][0000143b] 51 push ecx // push P
> from ecx
> [00001447][0010240c][0000144c] e8affcffff call 000010fb // call
> executed H with arguments on stack
>
> H: Begin Simulation Execution Trace Stored at:1124d4
> Address_of_H:10fb
> [0000143b][001124c0][001124c4] 55 push ebp // enter
> emulated P
> [0000143c][001124c0][001124c4] 8bec mov ebp,esp
> [0000143e][001124bc][00102490] 51 push ecx
> [0000143f][001124bc][00102490] 8b4508 mov eax,[ebp+08] // load
> eax with argument to P
> [00001442][001124b8][0000143b] 50 push eax // push P
> from eax
> [00001443][001124b8][0000143b] 8b4d08 mov ecx,[ebp+08] // load
> ecx with argument to P
> [00001446][001124b4][0000143b] 51 push ecx // push P
> from ecx
> [00001447][001124b0][0000144c] e8affcffff call 000010fb // call
> emulated H with arguments on stack
> H: Infinitely Recursive Simulation Detected Simulation Stopped
>
> When simulating halt decider H(P,P) simulates its input it can see
> that: (1) Function H() is called from P().
> (2) With the same arguments to H().
> (3) With no instructions in P preceding its invocation of H(P,P) that
> could escape repeated simulations.
>
> The above shows that the simulated P cannot possibly (reachs its
> “return” instruction and) terminate normally.
> H(P,P) simulates its input then P calls H(P,P) to simulate itself
> again. When H sees that this otherwise infinitely
> nested simulation would never end it aborts its simulation of P and
> rejects P as non-halting.
>
> [0000144c][00102418][00000000] 83c408 add esp,+08 //
> return to executed P
> [0000144f][00102418][00000000] 8945fc mov [ebp-04],eax //
> load Halt_Status with return value
> [00001452][00102418][00000000] 837dfc00 cmp dword [ebp-04],+00 //
> if Halt_Status == 0
> [00001456][00102418][00000000] 7402 jz 0000145a //
> goto 0000145a
> [0000145a][0010241c][00102428] 8be5 mov esp,ebp
> [0000145c][00102420][00001478] 5d pop ebp
> [0000145d][00102424][0000143b] c3 ret //
> return from executed P to main
> [00001478][00102428][00000000] 83c404 add esp,+04
> [0000147b][00102428][00000000] 33c0 xor eax,eax //
> set eax to 0
> [0000147d][0010242c][00000018] 5d pop ebp
> [0000147e][00102430][00000000] c3 ret //
> return from main to operating system
> Number of Instructions Executed(998) == 15 Pages
>
> The correctly simulated input to H(P,P) calls H(P,P) in infinite
> recursion thus H never returns to P and P never reaches its own
> "return" statement. The directly executed P(P) calls H(P,P) *not* in
> infinite recursion thus H(P,P) returns to P.

On Sunday, August 7, 2022 at 2:12:59 PM UTC-7, olcott wrote:
>
> WE MUST GO THOUGH MY PROOF POINT-BY-POINT AND STEP-BY-STEP.
> EVERYONE LEAPS AHEAD PREVENTING CLOSURE ON EVEN A SINGLE POINT.
>
That would something devoutly to be desired. It has never been attempted.
First off, what are we trying to prove? Second off, how does the mapping
to C work?

On 8/8/2022 2:36 PM, dklei...@gmail.com wrote:
> On Sunday, August 7, 2022 at 2:12:59 PM UTC-7, olcott wrote:
>>
>> WE MUST GO THOUGH MY PROOF POINT-BY-POINT AND STEP-BY-STEP.
>> EVERYONE LEAPS AHEAD PREVENTING CLOSURE ON EVEN A SINGLE POINT.
>>
> That would something devoutly to be desired. It has never been attempted.
> First off, what are we trying to prove? Second off, how does the mapping
> to C work?

*computation that halts* … the Turing machine will halt whenever it
enters a final state. (Linz:1990:234)

Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company. (317-320)

It is self-evident that when H(P,P) correctly simulates its first
argument with an x86 emulator that the correctly simulated input would
never reach its "return" instruction (final state) and halt.

(a) H(P,P) is executed in main() and simulates its first argument.
(b) The simulated P calls a simulated H(P,P) that simulates its first
argument.
(c) The simulated P calls a simulated H(P,P) that simulates its first
argument ... P never reaches any point after its call to H(P,P).

This logically entails that when H(P,P) correctly matches this
non-halting behavior pattern that it can abort the simulation of its
input and reject it as non-halting.

typedef void (*ptr)();
int H(ptr p, ptr i); // simulating halt decider

void P(ptr x)
{ int Halt_Status = H(x, x);
if (Halt_Status)
HERE: goto HERE;
return;
}

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

--
Copyright 2022 Pete Olcott

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

On Monday, August 8, 2022 at 3:56:28 PM UTC+1, olcott wrote:
> >>> On Saturday, 6 August 2022 at 10:48:23 UTC+8, olcott wrote:
> >>>> *straw man*
> >>>> An intentionally misrepresented proposition that is set up because it is
> >>>> easier to defeat than an opponent's real argument.
> >>>> https://www.lexico.com/en/definition/straw_man

> This conclusively proves that H(P,P) correctly simulates its input and
> that the behavior of the correctly simulated P is very different than
> the directly executed P(P).

You have stated numerous times, including just above, that your simulation produces different results from the thing it is simulating, and yet you still claim the simulation is correct. That's perfectly easy to defeat on its own, there is no need to misrepresent your arguments.

On 8/8/2022 2:52 PM, Paul N wrote:
> On Monday, August 8, 2022 at 3:56:28 PM UTC+1, olcott wrote:
>>>>> On Saturday, 6 August 2022 at 10:48:23 UTC+8, olcott wrote:
>>>>>> *straw man*
>>>>>> An intentionally misrepresented proposition that is set up because it is
>>>>>> easier to defeat than an opponent's real argument.
>>>>>> https://www.lexico.com/en/definition/straw_man
>
>> This conclusively proves that H(P,P) correctly simulates its input and
>> that the behavior of the correctly simulated P is very different than
>> the directly executed P(P).
>
> You have stated numerous times, including just above, that your simulation produces different results from the thing it is simulating, and yet you still claim the simulation is correct. That's perfectly easy to defeat on its own, there is no need to misrepresent your arguments.

Although it is perfectly easy to make the utterly baseless claim:
"That's perfectly easy to defeat on its own" yet when one compares the
line-by-line execution trace of the simulated input to the x86
source-code for P it is utterly impossible to find any mistake.

*The "don't bother to look at what I said" is*
*the most popular fake rebuttal of my work*

Example 05: P(P) halts because H(P,P) correctly determines that its
input never halts

This conclusively proves that H(P,P) correctly simulates its input and
that the behavior of the correctly simulated P is very different than
the directly executed P(P).

The correctly simulated P cannot possibly terminate normally by reaching
its own "return" instruction. The executed P does terminate normally and
reaches its own "return" instruction.

If you are not an expert in the x86 language then you lack the basis to
determine that the input to H(P,P) is not simulated correctly. The
strongest claim that you can make is that on the basis that you do not
understand the x86 language you do not understand the proof.

typedef void (*ptr)();
int H(ptr p, ptr i); // simulating halt decider

void P(ptr x)
{ int Halt_Status = H(x, x);
if (Halt_Status)
HERE: goto HERE;
return;
}

int main()
{ P(P);
}

_P()
[0000143b](01) 55 push ebp
[0000143c](02) 8bec mov ebp,esp
[0000143e](01) 51 push ecx
[0000143f](03) 8b4508 mov eax,[ebp+08]
[00001442](01) 50 push eax
[00001443](03) 8b4d08 mov ecx,[ebp+08]
[00001446](01) 51 push ecx
[00001447](05) e8affcffff call 000010fb
[0000144c](03) 83c408 add esp,+08
[0000144f](03) 8945fc mov [ebp-04],eax
[00001452](04) 837dfc00 cmp dword [ebp-04],+00
[00001456](02) 7402 jz 0000145a
[00001458](02) ebfe jmp 00001458
[0000145a](02) 8be5 mov esp,ebp
[0000145c](01) 5d pop ebp
[0000145d](01) c3 ret
Size in bytes:(0035) [0000145d]

_main()
[0000146b](01) 55 push ebp
[0000146c](02) 8bec mov ebp,esp
[0000146e](05) 683b140000 push 0000143b
[00001473](05) e8c3ffffff call 0000143b
[00001478](03) 83c404 add esp,+04
[0000147b](02) 33c0 xor eax,eax
[0000147d](01) 5d pop ebp
[0000147e](01) c3 ret
Size in bytes:(0020) [0000147e]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[0000146b][00102428][00000000] 55 push ebp
[0000146c][00102428][00000000] 8bec mov ebp,esp
[0000146e][00102424][0000143b] 683b140000 push 0000143b // push P
[00001473][00102420][00001478] e8c3ffffff call 0000143b // call P
with argument on stack
[0000143b][0010241c][00102428] 55 push ebp // enter
executed P
[0000143c][0010241c][00102428] 8bec mov ebp,esp
[0000143e][00102418][00000000] 51 push ecx
[0000143f][00102418][00000000] 8b4508 mov eax,[ebp+08] // load eax
with argument to P
[00001442][00102414][0000143b] 50 push eax // push P
from eax
[00001443][00102414][0000143b] 8b4d08 mov ecx,[ebp+08] // load ecx
with argument to P
[00001446][00102410][0000143b] 51 push ecx // push P
from ecx
[00001447][0010240c][0000144c] e8affcffff call 000010fb // call
executed H with arguments on stack

H: Begin Simulation Execution Trace Stored at:1124d4
Address_of_H:10fb
[0000143b][001124c0][001124c4] 55 push ebp // enter
emulated P
[0000143c][001124c0][001124c4] 8bec mov ebp,esp
[0000143e][001124bc][00102490] 51 push ecx
[0000143f][001124bc][00102490] 8b4508 mov eax,[ebp+08] // load eax
with argument to P
[00001442][001124b8][0000143b] 50 push eax // push P
from eax
[00001443][001124b8][0000143b] 8b4d08 mov ecx,[ebp+08] // load ecx
with argument to P
[00001446][001124b4][0000143b] 51 push ecx // push P
from ecx
[00001447][001124b0][0000144c] e8affcffff call 000010fb // call
emulated H with arguments on stack
H: Infinitely Recursive Simulation Detected Simulation Stopped

When simulating halt decider H(P,P) simulates its input it can see that:
(1) Function H() is called from P().
(2) With the same arguments to H().
(3) With no instructions in P preceding its invocation of H(P,P) that
could escape repeated simulations.

The above shows that the simulated P cannot possibly (reachs its
“return” instruction and) terminate normally.
H(P,P) simulates its input then P calls H(P,P) to simulate itself again.
When H sees that this otherwise infinitely
nested simulation would never end it aborts its simulation of P and
rejects P as non-halting.

[0000144c][00102418][00000000] 83c408 add esp,+08 //
return to executed P
[0000144f][00102418][00000000] 8945fc mov [ebp-04],eax // load
Halt_Status with return value
[00001452][00102418][00000000] 837dfc00 cmp dword [ebp-04],+00 // if
Halt_Status == 0
[00001456][00102418][00000000] 7402 jz 0000145a // goto
0000145a
[0000145a][0010241c][00102428] 8be5 mov esp,ebp
[0000145c][00102420][00001478] 5d pop ebp
[0000145d][00102424][0000143b] c3 ret //
return from executed P to main
[00001478][00102428][00000000] 83c404 add esp,+04
[0000147b][00102428][00000000] 33c0 xor eax,eax // set
eax to 0
[0000147d][0010242c][00000018] 5d pop ebp
[0000147e][00102430][00000000] c3 ret //
return from main to operating system
Number of Instructions Executed(998) == 15 Pages

The correctly simulated input to H(P,P) calls H(P,P) in infinite
recursion thus H never returns to P and P never reaches its own "return"
statement. The directly executed P(P) calls H(P,P) *not* in infinite
recursion thus H(P,P) returns to P.

--
Copyright 2022 Pete Olcott

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

On Monday, August 8, 2022 at 9:01:33 PM UTC+1, olcott wrote:
> On 8/8/2022 2:52 PM, Paul N wrote:
> > On Monday, August 8, 2022 at 3:56:28 PM UTC+1, olcott wrote:
> >>>>> On Saturday, 6 August 2022 at 10:48:23 UTC+8, olcott wrote:
> >>>>>> *straw man*
> >>>>>> An intentionally misrepresented proposition that is set up because it is
> >>>>>> easier to defeat than an opponent's real argument.
> >>>>>> https://www.lexico.com/en/definition/straw_man
> >
> >> This conclusively proves that H(P,P) correctly simulates its input and
> >> that the behavior of the correctly simulated P is very different than
> >> the directly executed P(P).
> >
> > You have stated numerous times, including just above, that your simulation produces different results from the thing it is simulating, and yet you still claim the simulation is correct. That's perfectly easy to defeat on its own, there is no need to misrepresent your arguments.
> Although it is perfectly easy to make the utterly baseless claim:
> "That's perfectly easy to defeat on its own" yet when one compares the
> line-by-line execution trace of the simulated input to the x86
> source-code for P it is utterly impossible to find any mistake.
>
> *The "don't bother to look at what I said" is*
> *the most popular fake rebuttal of my work*
> Example 05: P(P) halts because H(P,P) correctly determines that its
> input never halts

I'm looking at exactly what you said - even in a post as short as this one you have said it twice:

> This conclusively proves that H(P,P) correctly simulates its input and
> that the behavior of the correctly simulated P is very different than
> the directly executed P(P).

So the simulation is alleged to be correct, and also alleged to be incorrect, giving the wrong behaviour when simulating P(P). As you say yourself, "very different" behaviour.

> The correctly simulated P cannot possibly terminate normally by reaching
> its own "return" instruction. The executed P does terminate normally and
> reaches its own "return" instruction.
>
> If you are not an expert in the x86 language then you lack the basis to
> determine that the input to H(P,P) is not simulated correctly. The
> strongest claim that you can make is that on the basis that you do not
> understand the x86 language you do not understand the proof.

On the contrary, you have said it is giving the wrong results (or at least, you have said that "the behavior of the correctly simulated P is very different than the directly executed P(P)") and so it can seen that the simulation is incorrect.

> typedef void (*ptr)();
> int H(ptr p, ptr i); // simulating halt decider
>
> void P(ptr x)
> {
> int Halt_Status = H(x, x);
> if (Halt_Status)
> HERE: goto HERE;
> return;
> }
>
> int main()
> {
> P(P);
> }
>
> _P()
> [0000143b](01) 55 push ebp
> [0000143c](02) 8bec mov ebp,esp
> [0000143e](01) 51 push ecx
> [0000143f](03) 8b4508 mov eax,[ebp+08]
> [00001442](01) 50 push eax
> [00001443](03) 8b4d08 mov ecx,[ebp+08]
> [00001446](01) 51 push ecx
> [00001447](05) e8affcffff call 000010fb
> [0000144c](03) 83c408 add esp,+08
> [0000144f](03) 8945fc mov [ebp-04],eax
> [00001452](04) 837dfc00 cmp dword [ebp-04],+00
> [00001456](02) 7402 jz 0000145a
> [00001458](02) ebfe jmp 00001458
> [0000145a](02) 8be5 mov esp,ebp
> [0000145c](01) 5d pop ebp
> [0000145d](01) c3 ret
> Size in bytes:(0035) [0000145d]
>
> _main()
> [0000146b](01) 55 push ebp
> [0000146c](02) 8bec mov ebp,esp
> [0000146e](05) 683b140000 push 0000143b
> [00001473](05) e8c3ffffff call 0000143b
> [00001478](03) 83c404 add esp,+04
> [0000147b](02) 33c0 xor eax,eax
> [0000147d](01) 5d pop ebp
> [0000147e](01) c3 ret
> Size in bytes:(0020) [0000147e]
>
> machine stack stack machine assembly
> address address data code language
> ======== ======== ======== ========= =============
> [0000146b][00102428][00000000] 55 push ebp
> [0000146c][00102428][00000000] 8bec mov ebp,esp
> [0000146e][00102424][0000143b] 683b140000 push 0000143b // push P
> [00001473][00102420][00001478] e8c3ffffff call 0000143b // call P
> with argument on stack
> [0000143b][0010241c][00102428] 55 push ebp // enter
> executed P
> [0000143c][0010241c][00102428] 8bec mov ebp,esp
> [0000143e][00102418][00000000] 51 push ecx
> [0000143f][00102418][00000000] 8b4508 mov eax,[ebp+08] // load eax
> with argument to P
> [00001442][00102414][0000143b] 50 push eax // push P
> from eax
> [00001443][00102414][0000143b] 8b4d08 mov ecx,[ebp+08] // load ecx
> with argument to P
> [00001446][00102410][0000143b] 51 push ecx // push P
> from ecx
> [00001447][0010240c][0000144c] e8affcffff call 000010fb // call
> executed H with arguments on stack
>
> H: Begin Simulation Execution Trace Stored at:1124d4
> Address_of_H:10fb
> [0000143b][001124c0][001124c4] 55 push ebp // enter
> emulated P
> [0000143c][001124c0][001124c4] 8bec mov ebp,esp
> [0000143e][001124bc][00102490] 51 push ecx
> [0000143f][001124bc][00102490] 8b4508 mov eax,[ebp+08] // load eax
> with argument to P
> [00001442][001124b8][0000143b] 50 push eax // push P
> from eax
> [00001443][001124b8][0000143b] 8b4d08 mov ecx,[ebp+08] // load ecx
> with argument to P
> [00001446][001124b4][0000143b] 51 push ecx // push P
> from ecx
> [00001447][001124b0][0000144c] e8affcffff call 000010fb // call
> emulated H with arguments on stack
> H: Infinitely Recursive Simulation Detected Simulation Stopped
>
> When simulating halt decider H(P,P) simulates its input it can see that:
> (1) Function H() is called from P().
> (2) With the same arguments to H().
> (3) With no instructions in P preceding its invocation of H(P,P) that
> could escape repeated simulations.
>
> The above shows that the simulated P cannot possibly (reachs its
> “return” instruction and) terminate normally.
> H(P,P) simulates its input then P calls H(P,P) to simulate itself again.
> When H sees that this otherwise infinitely
> nested simulation would never end it aborts its simulation of P and
> rejects P as non-halting.
>
> [0000144c][00102418][00000000] 83c408 add esp,+08 //
> return to executed P
> [0000144f][00102418][00000000] 8945fc mov [ebp-04],eax // load
> Halt_Status with return value
> [00001452][00102418][00000000] 837dfc00 cmp dword [ebp-04],+00 // if
> Halt_Status == 0
> [00001456][00102418][00000000] 7402 jz 0000145a // goto
> 0000145a
> [0000145a][0010241c][00102428] 8be5 mov esp,ebp
> [0000145c][00102420][00001478] 5d pop ebp
> [0000145d][00102424][0000143b] c3 ret //
> return from executed P to main
> [00001478][00102428][00000000] 83c404 add esp,+04
> [0000147b][00102428][00000000] 33c0 xor eax,eax // set
> eax to 0
> [0000147d][0010242c][00000018] 5d pop ebp
> [0000147e][00102430][00000000] c3 ret //
> return from main to operating system
> Number of Instructions Executed(998) == 15 Pages
>
>
> The correctly simulated input to H(P,P) calls H(P,P) in infinite
> recursion thus H never returns to P and P never reaches its own "return"
> statement. The directly executed P(P) calls H(P,P) *not* in infinite
> recursion thus H(P,P) returns to P.

"dklei...@gmail.com" <dkleinecke@gmail.com> writes:

> On Sunday, August 7, 2022 at 2:12:59 PM UTC-7, olcott wrote:
>>
>> WE MUST GO THOUGH MY PROOF POINT-BY-POINT AND STEP-BY-STEP.
>> EVERYONE LEAPS AHEAD PREVENTING CLOSURE ON EVEN A SINGLE POINT.
>>
> That would something devoutly to be desired. It has never been attempted.
> First off, what are we trying to prove? Second off, how does the mapping
> to C work?

That's, at best, about third of fourth!

First you'd have to teach PO what a proof is. He still maintains that
if A,B,C ⊦ X then A,B,C,~A ⊬ X.

But, in fact, he's no trying to prove anything. He's just searching for
words to obscure the fact that he's claiming the wrong answer is the
right one.

A while back he realised that no algorithm, H, exists such that H(X,Y)
== true iff X(Y) "halts" (or returns to it's caller if you prefer), so
what to do?

Well he just decided a few years ago to assert that H(P,P) == false is
"correct even though P(P) halts" (his words). Originally a sketch of H
was posted, and H(P,P) == false was justified because P(P) /wouldn't/
halt "if line 15 (of H) were commented out" (his words). No shit,
Sherlock! Indeed it would not. But that made the ruse too clear. So
we had "P(P) only halts because H stops is". Yup. Also true. Also why
H(P,P) == false is wrong. Also too clear.

But he is learning that being clear is not helpful, so the latest mantra
(well, latest but one, probably) is that "the input to H(P,P) does not
halt" despite the "input to H(P,P)" being just two pointers and that
halting (or otherwise) is not a property of pointers.

--
Ben.

On 8/8/2022 4:50 PM, Paul N wrote:
> On Monday, August 8, 2022 at 9:01:33 PM UTC+1, olcott wrote:
>> On 8/8/2022 2:52 PM, Paul N wrote:
>>> On Monday, August 8, 2022 at 3:56:28 PM UTC+1, olcott wrote:
>>>>>>> On Saturday, 6 August 2022 at 10:48:23 UTC+8, olcott wrote:
>>>>>>>> *straw man*
>>>>>>>> An intentionally misrepresented proposition that is set up because it is
>>>>>>>> easier to defeat than an opponent's real argument.
>>>>>>>> https://www.lexico.com/en/definition/straw_man
>>>
>>>> This conclusively proves that H(P,P) correctly simulates its input and
>>>> that the behavior of the correctly simulated P is very different than
>>>> the directly executed P(P).
>>>
>>> You have stated numerous times, including just above, that your simulation produces different results from the thing it is simulating, and yet you still claim the simulation is correct. That's perfectly easy to defeat on its own, there is no need to misrepresent your arguments.
>> Although it is perfectly easy to make the utterly baseless claim:
>> "That's perfectly easy to defeat on its own" yet when one compares the
>> line-by-line execution trace of the simulated input to the x86
>> source-code for P it is utterly impossible to find any mistake.
>>
>> *The "don't bother to look at what I said" is*
>> *the most popular fake rebuttal of my work*
>> Example 05: P(P) halts because H(P,P) correctly determines that its
>> input never halts
>
> I'm looking at exactly what you said - even in a post as short as this one you have said it twice:
>
>> This conclusively proves that H(P,P) correctly simulates its input and
>> that the behavior of the correctly simulated P is very different than
>> the directly executed P(P).
>
> So the simulation is alleged to be correct,

It is proven to be correct in that the line-by-line execution trace of
the simulation exactly matches the line-by-line x86 source-code of P.

> and also alleged to be incorrect,

By fools that don't have a clue and are simply too dumb to verify that
the line-by-line execution trace exactly matches the line-by-line
source-code of P.

> giving the wrong behaviour when simulating P(P). As you say yourself, "very different" behaviour.
>
>> The correctly simulated P cannot possibly terminate normally by reaching
>> its own "return" instruction. The executed P does terminate normally and
>> reaches its own "return" instruction.
>>
>> If you are not an expert in the x86 language then you lack the basis to
>> determine that the input to H(P,P) is not simulated correctly. The
>> strongest claim that you can make is that on the basis that you do not
>> understand the x86 language you do not understand the proof.
>
> On the contrary, you have said it is giving the wrong results (or at least, you have said that "the behavior of the correctly simulated P is very different than the directly executed P(P)") and so it can seen that the simulation is incorrect.
>
>> typedef void (*ptr)();
>> int H(ptr p, ptr i); // simulating halt decider
>>
>> void P(ptr x)
>> {
>> int Halt_Status = H(x, x);
>> if (Halt_Status)
>> HERE: goto HERE;
>> return;
>> }
>>
>> int main()
>> {
>> P(P);
>> }
>>
>> _P()
>> [0000143b](01) 55 push ebp
>> [0000143c](02) 8bec mov ebp,esp
>> [0000143e](01) 51 push ecx
>> [0000143f](03) 8b4508 mov eax,[ebp+08]
>> [00001442](01) 50 push eax
>> [00001443](03) 8b4d08 mov ecx,[ebp+08]
>> [00001446](01) 51 push ecx
>> [00001447](05) e8affcffff call 000010fb
>> [0000144c](03) 83c408 add esp,+08
>> [0000144f](03) 8945fc mov [ebp-04],eax
>> [00001452](04) 837dfc00 cmp dword [ebp-04],+00
>> [00001456](02) 7402 jz 0000145a
>> [00001458](02) ebfe jmp 00001458
>> [0000145a](02) 8be5 mov esp,ebp
>> [0000145c](01) 5d pop ebp
>> [0000145d](01) c3 ret
>> Size in bytes:(0035) [0000145d]
>>
>> _main()
>> [0000146b](01) 55 push ebp
>> [0000146c](02) 8bec mov ebp,esp
>> [0000146e](05) 683b140000 push 0000143b
>> [00001473](05) e8c3ffffff call 0000143b
>> [00001478](03) 83c404 add esp,+04
>> [0000147b](02) 33c0 xor eax,eax
>> [0000147d](01) 5d pop ebp
>> [0000147e](01) c3 ret
>> Size in bytes:(0020) [0000147e]
>>
>> machine stack stack machine assembly
>> address address data code language
>> ======== ======== ======== ========= =============
>> [0000146b][00102428][00000000] 55 push ebp
>> [0000146c][00102428][00000000] 8bec mov ebp,esp
>> [0000146e][00102424][0000143b] 683b140000 push 0000143b // push P
>> [00001473][00102420][00001478] e8c3ffffff call 0000143b // call P
>> with argument on stack
>> [0000143b][0010241c][00102428] 55 push ebp // enter
>> executed P
>> [0000143c][0010241c][00102428] 8bec mov ebp,esp
>> [0000143e][00102418][00000000] 51 push ecx
>> [0000143f][00102418][00000000] 8b4508 mov eax,[ebp+08] // load eax
>> with argument to P
>> [00001442][00102414][0000143b] 50 push eax // push P
>> from eax
>> [00001443][00102414][0000143b] 8b4d08 mov ecx,[ebp+08] // load ecx
>> with argument to P
>> [00001446][00102410][0000143b] 51 push ecx // push P
>> from ecx
>> [00001447][0010240c][0000144c] e8affcffff call 000010fb // call
>> executed H with arguments on stack
>>
>> H: Begin Simulation Execution Trace Stored at:1124d4
>> Address_of_H:10fb
>> [0000143b][001124c0][001124c4] 55 push ebp // enter
>> emulated P
>> [0000143c][001124c0][001124c4] 8bec mov ebp,esp
>> [0000143e][001124bc][00102490] 51 push ecx
>> [0000143f][001124bc][00102490] 8b4508 mov eax,[ebp+08] // load eax
>> with argument to P
>> [00001442][001124b8][0000143b] 50 push eax // push P
>> from eax
>> [00001443][001124b8][0000143b] 8b4d08 mov ecx,[ebp+08] // load ecx
>> with argument to P
>> [00001446][001124b4][0000143b] 51 push ecx // push P
>> from ecx
>> [00001447][001124b0][0000144c] e8affcffff call 000010fb // call
>> emulated H with arguments on stack
>> H: Infinitely Recursive Simulation Detected Simulation Stopped
>>
>> When simulating halt decider H(P,P) simulates its input it can see that:
>> (1) Function H() is called from P().
>> (2) With the same arguments to H().
>> (3) With no instructions in P preceding its invocation of H(P,P) that
>> could escape repeated simulations.
>>
>> The above shows that the simulated P cannot possibly (reachs its
>> “return” instruction and) terminate normally.
>> H(P,P) simulates its input then P calls H(P,P) to simulate itself again.
>> When H sees that this otherwise infinitely
>> nested simulation would never end it aborts its simulation of P and
>> rejects P as non-halting.
>>
>> [0000144c][00102418][00000000] 83c408 add esp,+08 //
>> return to executed P
>> [0000144f][00102418][00000000] 8945fc mov [ebp-04],eax // load
>> Halt_Status with return value
>> [00001452][00102418][00000000] 837dfc00 cmp dword [ebp-04],+00 // if
>> Halt_Status == 0
>> [00001456][00102418][00000000] 7402 jz 0000145a // goto
>> 0000145a
>> [0000145a][0010241c][00102428] 8be5 mov esp,ebp
>> [0000145c][00102420][00001478] 5d pop ebp
>> [0000145d][00102424][0000143b] c3 ret //
>> return from executed P to main
>> [00001478][00102428][00000000] 83c404 add esp,+04
>> [0000147b][00102428][00000000] 33c0 xor eax,eax // set
>> eax to 0
>> [0000147d][0010242c][00000018] 5d pop ebp
>> [0000147e][00102430][00000000] c3 ret //
>> return from main to operating system
>> Number of Instructions Executed(998) == 15 Pages
>>
>>
>> The correctly simulated input to H(P,P) calls H(P,P) in infinite
>> recursion thus H never returns to P and P never reaches its own "return"
>> statement. The directly executed P(P) calls H(P,P) *not* in infinite
>> recursion thus H(P,P) returns to P.

--
Copyright 2022 Pete Olcott

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

On Monday, August 8, 2022 at 6:20:04 PM UTC-4, olcott wrote:
> On 8/8/2022 4:50 PM, Paul N wrote:
> > On Monday, August 8, 2022 at 9:01:33 PM UTC+1, olcott wrote:
> >> On 8/8/2022 2:52 PM, Paul N wrote:
> >>> On Monday, August 8, 2022 at 3:56:28 PM UTC+1, olcott wrote:
> >>>>>>> On Saturday, 6 August 2022 at 10:48:23 UTC+8, olcott wrote:
> >>>>>>>> *straw man*
> >>>>>>>> An intentionally misrepresented proposition that is set up because it is
> >>>>>>>> easier to defeat than an opponent's real argument.
> >>>>>>>> https://www.lexico.com/en/definition/straw_man
> >>>
> >>>> This conclusively proves that H(P,P) correctly simulates its input and
> >>>> that the behavior of the correctly simulated P is very different than
> >>>> the directly executed P(P).
> >>>
> >>> You have stated numerous times, including just above, that your simulation produces different results from the thing it is simulating, and yet you still claim the simulation is correct. That's perfectly easy to defeat on its own, there is no need to misrepresent your arguments.
> >> Although it is perfectly easy to make the utterly baseless claim:
> >> "That's perfectly easy to defeat on its own" yet when one compares the
> >> line-by-line execution trace of the simulated input to the x86
> >> source-code for P it is utterly impossible to find any mistake.
> >>
> >> *The "don't bother to look at what I said" is*
> >> *the most popular fake rebuttal of my work*
> >> Example 05: P(P) halts because H(P,P) correctly determines that its
> >> input never halts
> >
> > I'm looking at exactly what you said - even in a post as short as this one you have said it twice:
> >
> >> This conclusively proves that H(P,P) correctly simulates its input and
> >> that the behavior of the correctly simulated P is very different than
> >> the directly executed P(P).
> >
> > So the simulation is alleged to be correct,
> It is proven to be correct in that the line-by-line execution trace of
> the simulation exactly matches the line-by-line x86 source-code of P.

It is also proven that the line-by-line execution trace of the simulated input to Ha3(N,5) by Ha3 exactly matches the line-by-line x86 source-code of N.

Since it's obvious that Ha3(N,5)==0 is wrong, this proves that the fact that H(P,P) fit this same criteria is meaningless.

> > and also alleged to be incorrect,
> By fools that don't have a clue and are simply too dumb to verify that
> the line-by-line execution trace exactly matches the line-by-line
> source-code of P.

Just like how the line-by-line execution trace of the simulated input to Ha3(N,5) by Ha3 exactly matches the line-by-line x86 source-code of N? So the fact that H(P,P) does the same doesn't prove anything.

On 8/8/22 10:56 AM, olcott wrote:
> On 8/8/2022 4:05 AM, wij wrote:
>> On Monday, 8 August 2022 at 05:12:59 UTC+8, olcott wrote:
>>> On 8/6/2022 6:46 AM, wij wrote:
>>>> On Saturday, 6 August 2022 at 10:48:23 UTC+8, olcott wrote:
>>>>> *straw man*
>>>>> An intentionally misrepresented proposition that is set up because
>>>>> it is
>>>>> easier to defeat than an opponent's real argument.
>>>>> https://www.lexico.com/en/definition/straw_man
>>>>>
>>>>> H correctly determines the halt status specified by its arguments.
>>>>>
>>>>> The deceptive "rebuttals" don't even try to rebut this claim instead
>>>>> they claim that that H does not correctly determine the halt status of
>>>>> something besides its actual arguments.
>>>>>
>>>>> void P(ptr x)
>>>>> {
>>>>> int Halt_Status = H(x, x);
>>>>> if (Halt_Status)
>>>>> HERE: goto HERE;
>>>>> return;
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>> Output("Input_Halts = ", H(P, P));
>>>>> }
>>>>>
>>>>>
>>>>> --
>>>>> Copyright 2022 Pete Olcott
>>>>>
>>>>> "Talent hits a target no one else can hit;
>>>>> Genius hits a target no one else can see."
>>>>> Arthur Schopenhauer
>>>>
>>>> If you are not talking about the Halting Problem as in this post,
>>>> you might be
>>>> right but its POOH, not very interesting. But I believe you intend
>>>> to refute
>>>> the HP. As posted many times, your H cannot report the right answer
>>>> about P(P):
>>>>
>>> You still dodged the question !!!
>>> You still dodged the question !!!
>>> You still dodged the question !!!
>>> You still dodged the question !!!
>>> You still dodged the question !!!
>>>
>>> The question is whether or not H(P,P) correctly determines that halt
>>> status of its arguments. Like everyone else you respond with the
>>> strawman deception as your rebuttal.
>>>
>>> I am not asking whether or not H(P,P) should determine the halt status
>>> of its arguments (according to the HP) or should determine the halt
>>> status of something else (according to the HP).
>>>
>>> I am asking: Can you see that H(P,P) does correctly determine the halt
>>> status of its arguments?
>>>
>>> WE MUST GO THOUGH MY PROOF POINT-BY-POINT AND STEP-BY-STEP.
>>> EVERYONE LEAPS AHEAD PREVENTING CLOSURE ON EVEN A SINGLE POINT.
>>>
>>> WE MUST GO THOUGH MY PROOF POINT-BY-POINT AND STEP-BY-STEP.
>>> EVERYONE LEAPS AHEAD PREVENTING CLOSURE ON EVEN A SINGLE POINT.
>>>
>>> WE MUST GO THOUGH MY PROOF POINT-BY-POINT AND STEP-BY-STEP.
>>> EVERYONE LEAPS AHEAD PREVENTING CLOSURE ON EVEN A SINGLE POINT.
>>>
>>> WE MUST GO THOUGH MY PROOF POINT-BY-POINT AND STEP-BY-STEP.
>>> EVERYONE LEAPS AHEAD PREVENTING CLOSURE ON EVEN A SINGLE POINT.
>>>> int main()
>>>> {
>>>> Output("Input_Halts = ", H(P, P));
>>>> P(P);
>>>> }
>>>> --------------
>>>> I am going to say something for general readers.
>>>> olcott reads a lots, but just words (by rote). His understanding is
>>>> 'linguistic'.
>>>> His basic logic required for science is seriously flawed (the logic
>>>> implication
>>>> is the same as logic AND, and more). So his words is highly
>>>> questionable even
>>>> it reads right, e.g. when he says the sum(4,5) must return the sum
>>>> of 4 and 5,
>>>> don't assume he thinks what normal people would think, others like
>>>> C/TM/x86/OS/
>>>> simulation/pure function,... no one has correct meaning.
>>>>
>>>> olcott pre-determined the HP is 'refuted'. If everybody attacks a
>>>> point long
>>>> enough for him to think it won't pass the review, he would simply and
>>>> effortlessly change to another 'linguistic' reason leaving the
>>>> replyers gnash
>>>> (this is his EXHAUSTIVE strategy for his patent. 'correctness' is
>>>> not important
>>>> or different in his understanding).
>>>> My understanding of his appeal is: He DECIDED the liar's paradox as
>>>> an invalid
>>>> (pathological) question (input), e.g. proposition B: "I am lying",
>>>> so the HP and
>>>> other similar proofs are refuted in his understand. He only searches
>>>> for 'linguistic' reasons, no logic.
>>>>
>>> --
>>> Copyright 2022 Pete Olcott
>>>
>>> "Talent hits a target no one else can hit;
>>> Genius hits a target no one else can see."
>>> Arthur Schopenhauer
>>
>> What is the halting property of P? If we say P halts, doesn't that
>> mean P(P) halts?
>
> No it does not as I prove right here:
>
> Example 05:     P(P) halts because H(P,P) correctly determines that its
> input never halts

And thus you ADMIT that P(P) Halts, and thus H(P,P) needs to return 1 to
be correct.

It doesn't matter WHY P(P) Halts, that fact that it does is all that is
being asked about.

If you tryu to claim otherwise, you are just talking about your POOP.

>
> This conclusively proves that H(P,P) correctly simulates its input and
> that the behavior of the correctly simulated P is very different than
> the directly executed P(P).

Nope.

>
> The correctly simulated P cannot possibly terminate normally by reaching
> its own "return" instruction. The executed P does terminate normally and
> reaches its own "return" instruction.

Except you just said it will! That is the COMPLETELY and correctly
simulated P that uses the H that you claim you are using that returns 0
for H(P,P). The fact that H can't do that is irrelevent, that just shows
that H was wrong.

>
> If you are not an expert in the x86 language then you lack the basis to
> determine that the input to H(P,P) is not simulated correctly. The
> strongest claim that you can make is that on the basis that you do not
> understand the x86 language you do not understand the proof.

And the x86 code OF THE FULL PROGRAM shows that P(P) will Halt.

>
> typedef void (*ptr)();
> int H(ptr p, ptr i); // simulating halt decider
>
> void P(ptr x)
> {
>   int Halt_Status = H(x, x);
>   if (Halt_Status)
>     HERE: goto HERE;
>   return;
> }
>
> int main()
> {
>   P(P);
> }
>
> _P()
> [0000143b](01)  55             push ebp
> [0000143c](02)  8bec           mov ebp,esp
> [0000143e](01)  51             push ecx
> [0000143f](03)  8b4508         mov eax,[ebp+08]
> [00001442](01)  50             push eax
> [00001443](03)  8b4d08         mov ecx,[ebp+08]
> [00001446](01)  51             push ecx
> [00001447](05)  e8affcffff     call 000010fb
> [0000144c](03)  83c408         add esp,+08
> [0000144f](03)  8945fc         mov [ebp-04],eax
> [00001452](04)  837dfc00       cmp dword [ebp-04],+00
> [00001456](02)  7402           jz 0000145a
> [00001458](02)  ebfe           jmp 00001458
> [0000145a](02)  8be5           mov esp,ebp
> [0000145c](01)  5d             pop ebp
> [0000145d](01)  c3             ret
> Size in bytes:(0035) [0000145d]
>
> _main()
> [0000146b](01)  55             push ebp
> [0000146c](02)  8bec           mov ebp,esp
> [0000146e](05)  683b140000     push 0000143b
> [00001473](05)  e8c3ffffff     call 0000143b
> [00001478](03)  83c404         add esp,+04
> [0000147b](02)  33c0           xor eax,eax
> [0000147d](01)  5d             pop ebp
> [0000147e](01)  c3             ret
> Size in bytes:(0020) [0000147e]
>
>  machine   stack     stack     machine    assembly
>  address   address   data      code       language
>  ========  ========  ========  =========  =============
> [0000146b][00102428][00000000] 55         push ebp
> [0000146c][00102428][00000000] 8bec       mov ebp,esp
> [0000146e][00102424][0000143b] 683b140000 push 0000143b    // push P
> [00001473][00102420][00001478] e8c3ffffff call 0000143b    // call P
> with argument on stack
> [0000143b][0010241c][00102428] 55         push ebp         // enter
> executed P
> [0000143c][0010241c][00102428] 8bec       mov ebp,esp
> [0000143e][00102418][00000000] 51         push ecx
> [0000143f][00102418][00000000] 8b4508     mov eax,[ebp+08] // load eax
> with argument to P
> [00001442][00102414][0000143b] 50         push eax         // push P
> from eax
> [00001443][00102414][0000143b] 8b4d08     mov ecx,[ebp+08] // load ecx
> with argument to P
> [00001446][00102410][0000143b] 51         push ecx         // push P
> from ecx
> [00001447][0010240c][0000144c] e8affcffff call 000010fb    // call
> executed H with arguments on stack
>
> H: Begin Simulation   Execution Trace Stored at:1124d4
> Address_of_H:10fb
> [0000143b][001124c0][001124c4] 55         push ebp         // enter
> emulated P
> [0000143c][001124c0][001124c4] 8bec       mov ebp,esp
> [0000143e][001124bc][00102490] 51         push ecx
> [0000143f][001124bc][00102490] 8b4508     mov eax,[ebp+08] // load eax
> with argument to P
> [00001442][001124b8][0000143b] 50         push eax         // push P
> from eax
> [00001443][001124b8][0000143b] 8b4d08     mov ecx,[ebp+08] // load ecx
> with argument to P
> [00001446][001124b4][0000143b] 51         push ecx         // push P
> from ecx
> [00001447][001124b0][0000144c] e8affcffff call 000010fb    // call
> emulated H with arguments on stack
> H: Infinitely Recursive Simulation Detected Simulation Stopped

On 8/8/22 3:52 PM, olcott wrote:
> On 8/8/2022 2:36 PM, dklei...@gmail.com wrote:
>> On Sunday, August 7, 2022 at 2:12:59 PM UTC-7, olcott wrote:
>>>
>>> WE MUST GO THOUGH MY PROOF POINT-BY-POINT AND STEP-BY-STEP.
>>> EVERYONE LEAPS AHEAD PREVENTING CLOSURE ON EVEN A SINGLE POINT.
>>>
>> That would something devoutly to be desired. It has never been attempted.
>> First off, what are we trying to prove? Second off, how does the mapping
>> to C work?
>
> *computation that halts* … the Turing machine will halt whenever it
> enters a final state. (Linz:1990:234)
>
> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
> Lexington/Toronto: D. C. Heath and Company. (317-320)
>
> It is self-evident that when H(P,P) correctly simulates its first
> argument with an x86 emulator that the correctly simulated input would
> never reach its "return" instruction (final state) and halt.
>
> (a) H(P,P) is executed in main() and simulates its first argument.
> (b) The simulated P calls a simulated H(P,P) that simulates its first
> argument.
> (c) The simulated P calls a simulated H(P,P) that simulates its first
> argument ... P never reaches any point after its call to H(P,P).

Except that this isn't what happens with your H, so you logic is just a LIE.

It should be:

(a) H(P,P) is execute in main() and simulates it first arguement
(b) The simulated P calls a simulated H(P,P) that would simulate its
first argument.

(c) but H aborts its simulation, thinking the input will not halt, and
return 0 to main

(d) but the CORRECT simulation would continue and actuall simulate that
H(P,P) which will simulate its first arguement

(e) that simulated H(P,P) will simulate its first argument to a call to
H(P.P)

(f) just like in (c) this H(P,P) will abort it simulation and return a 0
to the simulated P(P)

(g) That simulated P(P) will then reach its return statement, and HALT.

THus showing that the CORRECT AND COMPLETE simulation of the input to
H(P,P) WILL Halt, and thus the fact that H(P,P) returned 0 is proven
incorrect.

>
> This logically entails that when H(P,P) correctly matches this
> non-halting behavior pattern that it can abort the simulation of its
> input and reject it as non-halting.

Except that the pattern ISN'T a CORRECT non-halting pattern, as it
creates a P that calls the H with that pattern that Halts, as shown above.

>
> typedef void (*ptr)();
> int H(ptr p, ptr i); // simulating halt decider
>
> void P(ptr x)
> {
>   int Halt_Status = H(x, x);
>   if (Halt_Status)
>     HERE: goto HERE;
>   return;
> }
>
> int main()
> {
>   Output("Input_Halts = ", H(P, P));
> }
>
>

On 8/8/22 6:19 PM, olcott wrote:
> On 8/8/2022 4:50 PM, Paul N wrote:
>> On Monday, August 8, 2022 at 9:01:33 PM UTC+1, olcott wrote:
>>> On 8/8/2022 2:52 PM, Paul N wrote:
>>>> On Monday, August 8, 2022 at 3:56:28 PM UTC+1, olcott wrote:
>>>>>>>> On Saturday, 6 August 2022 at 10:48:23 UTC+8, olcott wrote:
>>>>>>>>> *straw man*
>>>>>>>>> An intentionally misrepresented proposition that is set up
>>>>>>>>> because it is
>>>>>>>>> easier to defeat than an opponent's real argument.
>>>>>>>>> https://www.lexico.com/en/definition/straw_man
>>>>
>>>>> This conclusively proves that H(P,P) correctly simulates its input and
>>>>> that the behavior of the correctly simulated P is very different than
>>>>> the directly executed P(P).
>>>>
>>>> You have stated numerous times, including just above, that your
>>>> simulation produces different results from the thing it is
>>>> simulating, and yet you still claim the simulation is correct.
>>>> That's perfectly easy to defeat on its own, there is no need to
>>>> misrepresent your arguments.
>>> Although it is perfectly easy to make the utterly baseless claim:
>>> "That's perfectly easy to defeat on its own" yet when one compares the
>>> line-by-line execution trace of the simulated input to the x86
>>> source-code for P it is utterly impossible to find any mistake.
>>>
>>> *The "don't bother to look at what I said" is*
>>> *the most popular fake rebuttal of my work*
>>> Example 05: P(P) halts because H(P,P) correctly determines that its
>>> input never halts
>>
>> I'm looking at exactly what you said - even in a post as short as this
>> one you have said it twice:
>>
>>> This conclusively proves that H(P,P) correctly simulates its input and
>>> that the behavior of the correctly simulated P is very different than
>>> the directly executed P(P).
>>
>> So the simulation is alleged to be correct,
>
> It is proven to be correct in that the line-by-line execution trace of
> the simulation exactly matches the line-by-line x86 source-code of P.
>
>

No, the line where P(P) calls H(P,P) is incorrect simulated, since H
determine that it calls a function that will be infinitely recursive
when the actual H(P,P) isn't

Thus the simulation is incorrect.

>> and also alleged to be incorrect,
>
> By fools that don't have a clue and are simply too dumb to verify that
> the line-by-line execution trace exactly matches the line-by-line
> source-code of P.

Except that YOU are the fool, since the error HAS been pointed out but
you just refuse to see it.

A man that will not see is no better than that man that can not see.

You are just ignorant of the basics, or a pathological liar.

On Monday, August 8, 2022 at 12:52:27 PM UTC-7, olcott wrote:
> On 8/8/2022 2:36 PM, dklei...@gmail.com wrote:
> > On Sunday, August 7, 2022 at 2:12:59 PM UTC-7, olcott wrote:
> >>
> >> WE MUST GO THOUGH MY PROOF POINT-BY-POINT AND STEP-BY-STEP.
> >> EVERYONE LEAPS AHEAD PREVENTING CLOSURE ON EVEN A SINGLE POINT.
> >>
> > That would something devoutly to be desired. It has never been attempted.
> > First off, what are we trying to prove?

You haven't answered that question. What are you trying to prove?

Perhaps your goal is:
>
> when H(P,P) correctly matches this
> non-halting behavior pattern it can abort the simulation of its
> input and reject it as non-halting.
>
But we can entertain such a goal only after we define what, in
this statement, is meant by:
H(P,P)
match
non-halting behavior pattern
abort
simulation
input
reject
non-halting
>
>> Second off, how does the mapping
> > to C work?
And you made no attempt to answer this. What I asking
for is: Given a C statement what Turing Machine process
does it map to and given a Turing Machine statement
what C statement does it map to.

Incidentally I think that what I imagine is your goal is
trivially true. But expounding it takes a decent expansion
of Turing Machine facts as foundation. I have no idea
whether Linz or one of the others provides such a goal.
You haven't.

On 8/9/2022 6:43 PM, dklei...@gmail.com wrote:
> On Monday, August 8, 2022 at 12:52:27 PM UTC-7, olcott wrote:
>> On 8/8/2022 2:36 PM, dklei...@gmail.com wrote:
>>> On Sunday, August 7, 2022 at 2:12:59 PM UTC-7, olcott wrote:
>>>>
>>>> WE MUST GO THOUGH MY PROOF POINT-BY-POINT AND STEP-BY-STEP.
>>>> EVERYONE LEAPS AHEAD PREVENTING CLOSURE ON EVEN A SINGLE POINT.
>>>>
>>> That would something devoutly to be desired. It has never been attempted.
>>> First off, what are we trying to prove?
>
> You haven't answered that question. What are you trying to prove?
>
> Perhaps your goal is:
>>
>> when H(P,P) correctly matches this
>> non-halting behavior pattern it can abort the simulation of its
>> input and reject it as non-halting.
>>
> But we can entertain such a goal only after we define what, in
> this statement, is meant by:
> H(P,P)
> match
> non-halting behavior pattern
> abort
> simulation
> input
> reject
> non-halting

And we can't begin to answer that until after we have
"entertain"
"such"
"a"
"goal"
"only"
"after"
"we"
"define"
"what"
"in"
"this"
"statement"
"is"
"meant"
and
"by"
defined.

This goes on recursively until one of us dies thus totally avoiding the
point.

In computability theory, the halting problem is the problem
of determining, from a description of an arbitrary computer
program and an input, whether the program will finish running,
or continue to run forever. Alan Turing proved in 1936 that a
general algorithm to solve the halting problem for all possible
program-input pairs cannot exist.

For any program H that might determine if programs halt, a
"pathological" program P, called with some input, can pass
its own source and its input to H and then specifically do the
opposite of what H predicts P will do.
*No H can exist that handles this case*
https://en.wikipedia.org/wiki/Halting_problem

typedef void (*ptr)();
int H(ptr p, ptr i); // simulating halt decider

void P(ptr x)
{ int Halt_Status = H(x, x);
if (Halt_Status)
HERE: goto HERE;
return;
}

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

I created a C function based on an x86 emulator (look it up) that
correctly determines the halt status of the above HP "impossible" input.

>>
>>> Second off, how does the mapping
>>> to C work?
>
> And you made no attempt to answer this. What I asking
> for is: Given a C statement what Turing Machine process
> does it map to and given a Turing Machine statement
> what C statement does it map to.
>
> Incidentally I think that what I imagine is your goal is
> trivially true. But expounding it takes a decent expansion
> of Turing Machine facts as foundation. I have no idea
> whether Linz or one of the others provides such a goal.
> You haven't.

--
Copyright 2022 Pete Olcott

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