Every rebuttal of H(P,P)==0 uses the strawman deception

[olcott]

*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

[Dennis Bush]

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.

[olcott]

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.

[Mr Flibble]

On Fri, 5 Aug 2022 21:48:16 -0500
olcott <No...@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

[wij]

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.

[Richard Damon]

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.

[Richard Damon]

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.

[olcott]

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

[Richard Damon]

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.

[wij]

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?

[olcott]

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.

[Mr Flibble]

void Px(ptr x)

{
int Halt_Status = H(x, x);

(void)Halt_Status;
return;
}

Until your halt decider correctly decides the above (Px always halts)
then it isn't actually a halt decider, it is just a worthless mess.

/Flibble

[dklei...@gmail.com]

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?

[olcott]

*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

[Paul N]

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.

[olcott]

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

[Paul N]

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.

[Ben Bacarisse]

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.

[olcott]

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.

[Dennis Bush]

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.

[Richard Damon]

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.

And we see that H is INCORRECTLY simulating this result, since we KNOW
from below that the ACTUAL H will return 0 from the call to H(P,P), so
clearly H simulated the call to some other function, and thus is incorrect.

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

And (3) is just WRONG, proving you are just IGNORANT or a LIAR.

[Richard Damon]

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.

[Richard Damon]

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.

[dklei...@gmail.com]

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.

[olcott]

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.

[Dennis Bush]

I.E. X and Y

> whether the program will finish running,
> or continue to run forever.

In other words:

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

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

So your H can perform the following mapping?

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

> >>

[dklei...@gmail.com]

These are terms of the meta-language. The words I listed are technical
meaning they have no meanings in the meta-language and must be
suppled with definitions. This is standard everywhere in human
communication.

By the way no recursion is involved - your list is not defined the
same way as they themselves enter into definition.

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

In ordinary use "the halting theorem" is a concept of Turing
Machine theory. The Turing Machine was described by Turing
and exists in its own little Turing world. It can be emulated or
encoded in mathematical/logical terms. We call the process
defined in the machine "run" or "execute" but we have no
concept of what those mean other than that supplied by
emulation. One of the attributes of an emulation is a set
(possibly empty) of final states. An emulation "halts" if it
reaches a final state. The halting question is whether a
particular emulation halts.

We can encode the code, data and control (states) in a
form compatible with Turing Machine data. But there
is no machine whose emulation halts and indicates
whether the encoded code, data and control when
emulated will halt.

[olcott]

So you asked for concretely what I mean, and then when I provide this
concretely you simply ignore it.

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));
}

[Richard Damon]

So, how does that show you are right?

By the definition:

H(P,P) must return 1 if P(P) Halts in a finite number of steps, and ]
H(P,P) must return 0 if P(P) never Halts in an unbounded number of steps.

You NEVER bother to TEST you answers, so you can't "prove" your are right.

Change Main to be:

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

P(P);
Output(" But P(P) Halts");
}

Which will print:

Input_Halts = 0 But P(P) Halts.

Thus H was WRONG by the definition of a Halt Decider.

[dklei...@gmail.com]

On Tuesday, August 9, 2022 at 8:30:49 PM UTC-7, olcott wrote:
>
> So you asked for concretely what I mean, and then when I provide this
> concretely you simply ignore it.
>
> 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));
> }
>

If that is what you mean of course I ignored it

It just a fragment of trivial C program. Meaning what?

[olcott]

If you don't immediately recognize that as the halting problem's
"impossible" input, then you hardly know the HP much at all.

[dklei...@gmail.com]

On Thursday, August 11, 2022 at 10:28:31 PM UTC-7, olcott wrote:
> On 8/11/2022 11:57 PM, dklei...@gmail.com wrote:
> > On Tuesday, August 9, 2022 at 8:30:49 PM UTC-7, olcott wrote:
> >>
> >> So you asked for concretely what I mean, and then when I provide this
> >> concretely you simply ignore it.
> >>
> >> 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));
> >> }
> >>
> > If that is what you mean of course I ignored it
> >
> > It just a fragment of trivial C program. Meaning what?
>
> If you don't immediately recognize that as the halting problem's
> "impossible" input, then you hardly know the HP much at all.
>

Without any knowledge of what H does your code is meaningless.

For example H(X,Y) {return 0};

[olcott]

Of course everyone knows that a simulating halt decider only dances the
jig and nothing else because the word "simulate" only has the one
meaning of {dancing the jig}.

I have explained all of these things 10,000 times. Please read my paper.

*Halting problem proofs refuted on the basis of software engineering* ?
https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering

[dklei...@gmail.com]

What we have here is failure to communicate. You haven't, in your code,
even made a clear comment that H is a simulating halt decider much
less what that phrase means.