84 views

Skip to first unread message

Aug 5, 2022, 10:48:23 PMAug 5

to

*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

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

Aug 5, 2022, 11:12:28 PMAug 5

to

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

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.

Aug 6, 2022, 12:25:26 AMAug 6

to

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

Aug 6, 2022, 3:35:19 AMAug 6

to

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

> }

>

>

{

int Halt_Status = H(x, x);

(void)Halt_Status;
int Halt_Status = H(x, x);

return;

}

Until your SHD can correctly handle the above case (i.e. a decision of

halts) it is worthless.

/Flibble

Aug 6, 2022, 7:46:30 AMAug 6

to

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

}

--------------

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.

Aug 6, 2022, 7:55:52 AMAug 6

to

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

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.

Aug 6, 2022, 8:01:31 AMAug 6

to

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

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.

Aug 7, 2022, 5:12:59 PMAug 7

to

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.

>

Aug 7, 2022, 6:22:00 PMAug 7

to

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 MUST GO THOUGH MY PROOF POINT-BY-POINT AND STEP-BY-STEP.

> EVERYONE LEAPS AHEAD PREVENTING CLOSURE ON EVEN A SINGLE POINT.

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.

Aug 8, 2022, 5:05:14 AMAug 8

to

In your case P halts means H(P,P)=1, why is the POO Halt interesting?

Aug 8, 2022, 10:56:28 AMAug 8

to

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

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

Aug 8, 2022, 12:51:00 PMAug 8

to

{

int Halt_Status = H(x, x);

(void)Halt_Status;
int Halt_Status = H(x, x);

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

Aug 8, 2022, 3:36:56 PMAug 8

to

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

> WE MUST GO THOUGH MY PROOF POINT-BY-POINT AND STEP-BY-STEP.

> EVERYONE LEAPS AHEAD PREVENTING CLOSURE ON EVEN A SINGLE POINT.

>

First off, what are we trying to prove? Second off, how does the mapping

to C work?

Aug 8, 2022, 3:52:27 PMAug 8

to

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

Aug 8, 2022, 3:52:56 PMAug 8

to

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

> >>> 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.
> that the behavior of the correctly simulated P is very different than

> the directly executed P(P).

Aug 8, 2022, 4:01:33 PMAug 8

to

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

that the behavior of the correctly simulated P is very different than

the directly executed P(P).

Aug 8, 2022, 5:50:24 PMAug 8

to

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

Aug 8, 2022, 6:09:06 PMAug 8

to

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.

Aug 8, 2022, 6:20:04 PMAug 8

to

the simulation exactly matches the line-by-line x86 source-code of P.

> and also alleged to be incorrect,

the line-by-line execution trace exactly matches the line-by-line

source-code of P.

Aug 8, 2022, 6:27:37 PMAug 8

to

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.

Aug 8, 2022, 8:20:59 PMAug 8

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

>

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

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.

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.

Aug 8, 2022, 8:26:35 PMAug 8

to

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

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.

creates a P that calls the H with that pattern that Halts, as shown above.

Aug 8, 2022, 8:42:22 PMAug 8

to

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.

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.

Aug 9, 2022, 7:43:11 PMAug 9

to

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

Perhaps your goal is:

>

> when H(P,P) correctly matches this

> non-halting behavior pattern it can abort the simulation of its
> when H(P,P) correctly matches this

> 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
>> Second off, how does the mapping

> > to C work?

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.

Aug 9, 2022, 8:32:07 PMAug 9

to

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

"entertain"

"such"

"a"

"goal"

"only"

"after"

"we"

"define"

"what"

"in"
"such"

"a"

"goal"

"only"

"after"

"we"

"define"

"what"

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

}

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.

Aug 9, 2022, 9:46:48 PMAug 9

to

> whether the program will finish running,

> or continue to run forever.

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

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

> >>

Aug 9, 2022, 11:18:50 PMAug 9

to

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

>

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.

Aug 9, 2022, 11:30:49 PMAug 9

to

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

}

Aug 10, 2022, 12:06:54 AMAug 10

to

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

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.

Aug 12, 2022, 12:57:17 AMAug 12

to

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
>

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

> }

>

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

Aug 12, 2022, 1:28:31 AMAug 12

to

"impossible" input, then you hardly know the HP much at all.

Aug 12, 2022, 4:22:05 PMAug 12

to

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

>

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

Aug 12, 2022, 4:41:22 PMAug 12

to

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

Aug 13, 2022, 12:22:39 AMAug 13

to

even made a clear comment that H is a simulating halt decider much

less what that phrase means.

Reply all

Reply to author

Forward

0 new messages