30 views

Skip to first unread message

Jul 16, 2022, 11:10:34 AMJul 16

to

This conclusively proves that H(P,P) correctly simulates its input and

that 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 (reach 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

--

Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;

Genius hits a target no one else can see."

Arthur Schopenhauer

that 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 (reach 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

--

Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;

Genius hits a target no one else can see."

Arthur Schopenhauer

Jul 16, 2022, 11:33:23 AMJul 16

to

On 7/16/22 11:10 AM, olcott wrote:

> This conclusively proves that H(P,P) correctly simulates its input and

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

> than the directly executed P(P).

The you have just invaldated your proof as you P isn't defined right.
> This conclusively proves that H(P,P) correctly simulates its input and

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

> than the directly executed P(P).

P is DEFINED to call H to decide on P(P). If H(P,P) isn't the way to ask

the question, your P is NOT the required program, and you counter

example is INVALID. The behavior of the input to H(P,P) MUST be the

behavior of P(P) or you aren't doing the right problem, and you proofs

that try to show that it doesn't mean that just PROVE that H and P

aren't the correct machines.

Sorry you wasted all those years on such a simple mistake.

>

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

sees it aborting its simulation and returning the 0 to the simulated P

and then it halting.

YES, it is impossible to create an H that does this simulation, as if H

doesn't ever abort its simulation, the P(P) becomes non-halting, but

H(P,P) never returns the 0 to indicate this.

Once H is changed to abort this simulation, then the P that calls THIS H

(which is now THE H) will get the 0 return value and halt, and this H

has failed to be a correct simulator so can not be looked on as a sourct

of the truth.

Note, if we define the previous H as Hn that never aborts its

simulation, and the new H as Ha that does abort its simulationm and the

P's that call these Pn and Pa respectfully. We do have that

Hn(Pa,Pa) will correctly simulated Pa(Pa) to the final halting state

proving that Ha(Pa,Pa) returning 0 is incorrect, and

Ha(Pn,Pn) wil correctly detect that its input will never halt giving the

correct answer that Hn(Pn,Pn) didn't give, but neither of these are the

required case, as H isn't deciding on the P based on IT.

>

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

The fact that you think that a call to an H(P,P) that has conditional

logic in it so it can abort its simulation is identical to a call to

P(P) just proves your ignorance.

this before, and you contined claim proves that you are not actually

competent to do logic.

Please quote your source for this statement!

The ACTUAL rule will look at ALL the code in the loop, INCLUDEING that

of the H that is being called, and that WILL find the conditional that

escapes the infinite simulation.

>

> The above shows that the simulated P cannot possibly (reach 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.

pure function, so if THIS H(P,P) aborts its simulation, so will the one

being simulated.

Yes, if H doesn't abort is simulation, the input would be infinitely

nested and non-halting, but then because H is a pure function, so will

this copy of H.

If this copy of H has the code to abort its simulation, so will the copy

being called in the simuation, so it is incorrect to presume the

simulation will be infinitely nested.

You are using the fallacy of assuming a false premise to make your

arguement, and thus your logic is unsound.

Jul 16, 2022, 11:38:39 AMJul 16

to

On 7/16/2022 10:33 AM, Richard Damon wrote:

> On 7/16/22 11:10 AM, olcott wrote:

>> This conclusively proves that H(P,P) correctly simulates its input and

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

>> than the directly executed P(P).

>

> The you have just invaldated your proof as you P isn't defined right.

So then you are ridiculously stupidly saying that the complete proof
> On 7/16/22 11:10 AM, olcott wrote:

>> This conclusively proves that H(P,P) correctly simulates its input and

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

>> than the directly executed P(P).

>

> The you have just invaldated your proof as you P isn't defined right.

that I am correct is proof that I am incorrect.

HOW MUCH MORE STUPID CAN YOU POSSIBLY GET?

ARE YOU TRYING AS HARD AS YOU CAN TO BE AS STUPID AS POSSIBLE?

Jul 16, 2022, 11:53:12 AMJul 16

to

On 7/16/22 11:38 AM, olcott wrote:

> On 7/16/2022 10:33 AM, Richard Damon wrote:

>> On 7/16/22 11:10 AM, olcott wrote:

>>> This conclusively proves that H(P,P) correctly simulates its input

>>> and that that the behavior of the correctly simulated P is very

>>> different than the directly executed P(P).

>>

>> The you have just invaldated your proof as you P isn't defined right.

> So then you are ridiculously stupidly saying that the complete proof

> that I am correct is proof that I am incorrect.

>

> HOW MUCH MORE STUPID CAN YOU POSSIBLY GET?

> ARE YOU TRYING AS HARD AS YOU CAN TO BE AS STUPID AS POSSIBLE?

>

No, if P isn't the requried P, or H doesn't meet the requirments of H,
> On 7/16/2022 10:33 AM, Richard Damon wrote:

>> On 7/16/22 11:10 AM, olcott wrote:

>>> This conclusively proves that H(P,P) correctly simulates its input

>>> and that that the behavior of the correctly simulated P is very

>>> different than the directly executed P(P).

>>

>> The you have just invaldated your proof as you P isn't defined right.

> So then you are ridiculously stupidly saying that the complete proof

> that I am correct is proof that I am incorrect.

>

> HOW MUCH MORE STUPID CAN YOU POSSIBLY GET?

> ARE YOU TRYING AS HARD AS YOU CAN TO BE AS STUPID AS POSSIBLE?

>

how does your proof mean anything.

P is DEFINED to ask H about itself called with its input. Thus since

P(P) calls H(P,P) to say that the input to H(P,P) doesn't actually

represent P(P) says you are just lying. PERIOD.

Since P(P) WILL HALT when H(P,P) return 0, that can't be the correct answer.

WHICH STATEMENT IS WRONG?

NO DISHONEST DODGES.

I have pointed out the "statement" in your proof that are incorrect, and

you nave made ZERO rebuttal to those statements.

That implies that you have no rebuttal and know that your claims are

invalid.

You claim apparently impossible things, and I have shown what you could

demonstrate to show that you have actually done the impossible.

You have not even attempted, this shows that you likely know that your

claims are, in fact, not true statements.

YOU are the one showing your stupidity.

YOU are the one trying to claim the impossible, and thus needing to

provide actual proof.

When your errors are show, you ignore them and just repeat them.

YOU are the DEFINITION of insanity, you keep on attempting the same

thing over and over the same way and expect that at some point you will

get a different result.

You keep on trying to HIDE your errors with glib words, and deceptive

definitons. You rely on convoluted proofs to try to show things that

simple definition show to be incorrect.

H(P,P) returning 0 CAN NOT BE CORRECT, if P(P) halts when H(P,P) returns

0. DEFINITION.

If you don't believe that a counter example disproves a proof, why are

you trying to do that yourself (and failing).

For H to be a counter example, it MUST meet the definition of the Halt

Decider in the proof, and the "impossible program" that it is deciding

must meet the program in the proof.

YOU FAIL TO MEET THIS, because you keep on claiming that it is

impossible to meet the condtions of the proof, which actually PROVES the

proof, that such an H is actually impossible to construct.

Jul 16, 2022, 12:01:15 PMJul 16

to

recursion.

/Flibble

Jul 16, 2022, 1:33:09 PMJul 16

to

On 16/07/2022 17:33, Richard Damon wrote:

> On 7/16/22 11:10 AM, olcott wrote:

>> This conclusively proves that H(P,P) correctly simulates its input and

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

>> than the directly executed P(P).

>

> The you have just invaldated your proof as you P isn't defined right.

>

> On 7/16/22 11:10 AM, olcott wrote:

>> This conclusively proves that H(P,P) correctly simulates its input and

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

>> than the directly executed P(P).

>

> The you have just invaldated your proof as you P isn't defined right.

>

> Sorry you wasted all those years on such a simple mistake.

>

Richard, will you /please/ just give it a break? The guy is a
>

trisector. His "proof" is bogus - he doesn't even have a clear idea of

what he is trying to prove. But he is obsessed about it, having spent

far too much time and effort over the years, and he cannot admit to

himself that it is fundamentally flawed. Instead, he is looking for

attention and posting more repetitively, more aggressively, and more

often in places where many people have specifically asked him not to.

He cannot refute your points but in his distorted mindset, he is

convinced he is correct - therefore others who disagree must be

technically incompetent, stupid, or malicious.

Everyone here (in all three groups) knows /you/ understand the theory

involved here. Everyone knows Olcott is wrong. Everyone who has any

interest and knowledge on the topic, already knows /how/ he is wrong,

why his ideas cannot work, and where to find real information about the

halting problem.

So nobody gains anything from these threads. At the start, it might

have been interesting or entertaining - that stage is long gone. You

and Olcott are going round in circles, writing nothing new. Mr. Flibble

is even worse, bringing his own equally (but differently) flawed ideas

into the mix.

If you stop replying to Olcott, it will not stop him posting - but it

will greatly reduce the quantity of drivel he posts. So please stop -

find yourself a different hobby (or work on /real/ computability theory

topics, as it is an interesting field). Or post about C and C++ in the

C and C++ newsgroups. The same applies to Skep Dick, Chris Thomasson,

and others who encourage this online vandal.

(My email address is valid if you want to comment directly.)

Jul 16, 2022, 1:53:35 PMJul 16

to

On 7/16/2022 12:32 PM, David Brown wrote:

> On 16/07/2022 17:33, Richard Damon wrote:

>> On 7/16/22 11:10 AM, olcott wrote:

>>> This conclusively proves that H(P,P) correctly simulates its input

>>> and that that the behavior of the correctly simulated P is very

>>> different than the directly executed P(P).

>>

>> The you have just invaldated your proof as you P isn't defined right.

>>

>> Sorry you wasted all those years on such a simple mistake.

>>

>

>

> On 16/07/2022 17:33, Richard Damon wrote:

>> On 7/16/22 11:10 AM, olcott wrote:

>>> This conclusively proves that H(P,P) correctly simulates its input

>>> and that that the behavior of the correctly simulated P is very

>>> different than the directly executed P(P).

>>

>> The you have just invaldated your proof as you P isn't defined right.

>>

>> Sorry you wasted all those years on such a simple mistake.

>>

>

>

> Everyone here (in all three groups) knows /you/ understand the theory

> involved here. Everyone knows Olcott is wrong.

No one here has correctly pointed out a single mistake in the last two
> involved here. Everyone knows Olcott is wrong.

months.

Richard is stuck on the notion that a function called in infinite

recursion must return a value to its caller. Everyone here knows that is

incorrect.

There are some subtle nuances of pure/computable functions that need to

be worked out on this issue.

*Those issues can be worked out on comp.theory*

Others here are stuck on the notion that a halt decider must make its

halt status decision on some other basis than the actual behavior that

is actually specified by actual its inputs. THAT IS CLEARLY FALSE.

*The sooner that I can get closure the sooner I will be done here*

*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

Jul 16, 2022, 2:01:02 PMJul 16

to

On 7/16/2022 10:52 AM, Richard Damon wrote:

> On 7/16/22 11:38 AM, olcott wrote:

>> On 7/16/2022 10:33 AM, Richard Damon wrote:

>>> On 7/16/22 11:10 AM, olcott wrote:

>>>> This conclusively proves that H(P,P) correctly simulates its input

>>>> and that that the behavior of the correctly simulated P is very

>>>> different than the directly executed P(P).

>>>

>>> The you have just invaldated your proof as you P isn't defined right.

>> So then you are ridiculously stupidly saying that the complete proof

>> that I am correct is proof that I am incorrect.

>>

>> HOW MUCH MORE STUPID CAN YOU POSSIBLY GET?

>> ARE YOU TRYING AS HARD AS YOU CAN TO BE AS STUPID AS POSSIBLE?

>>

>

> No, if P isn't the requried P, or H doesn't meet the requirments of H,

> how does your proof mean anything.

>

> On 7/16/22 11:38 AM, olcott wrote:

>> On 7/16/2022 10:33 AM, Richard Damon wrote:

>>> On 7/16/22 11:10 AM, olcott wrote:

>>>> This conclusively proves that H(P,P) correctly simulates its input

>>>> and that that the behavior of the correctly simulated P is very

>>>> different than the directly executed P(P).

>>>

>>> The you have just invaldated your proof as you P isn't defined right.

>> So then you are ridiculously stupidly saying that the complete proof

>> that I am correct is proof that I am incorrect.

>>

>> HOW MUCH MORE STUPID CAN YOU POSSIBLY GET?

>> ARE YOU TRYING AS HARD AS YOU CAN TO BE AS STUPID AS POSSIBLE?

>>

>

> No, if P isn't the requried P, or H doesn't meet the requirments of H,

> how does your proof mean anything.

>

Others here are stuck on the notion that a halt decider must make its

halt status decision on some other basis than the actual behavior that

is actually specified by its actual inputs. THAT IS CLEARLY FALSE.
halt status decision on some other basis than the actual behavior that

Mike already agreed that H(P,P) does simulate the steps that it

simulates correctly. Like you Mike did not bother to see that the

correctly simulated P cannot ever reach its "return" instruction even if

it is simulated until the heat death of the universe.

*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

Jul 16, 2022, 2:05:44 PMJul 16

to

On 7/16/22 1:53 PM, olcott wrote:

> On 7/16/2022 12:32 PM, David Brown wrote:

>> On 16/07/2022 17:33, Richard Damon wrote:

>>> On 7/16/22 11:10 AM, olcott wrote:

>>>> This conclusively proves that H(P,P) correctly simulates its input

>>>> and that that the behavior of the correctly simulated P is very

>>>> different than the directly executed P(P).

>>>

>>> The you have just invaldated your proof as you P isn't defined right.

>>>

>>> Sorry you wasted all those years on such a simple mistake.

>>>

>>

>>

>> Everyone here (in all three groups) knows /you/ understand the theory

>> involved here. Everyone knows Olcott is wrong.

>

> No one here has correctly pointed out a single mistake in the last two

> months.

>

> Richard is stuck on the notion that a function called in infinite

> recursion must return a value to its caller. Everyone here knows that is

> incorrect.

No, I am stuck pointing out that a Pure Function must behave the same to
> On 7/16/2022 12:32 PM, David Brown wrote:

>> On 16/07/2022 17:33, Richard Damon wrote:

>>> On 7/16/22 11:10 AM, olcott wrote:

>>>> This conclusively proves that H(P,P) correctly simulates its input

>>>> and that that the behavior of the correctly simulated P is very

>>>> different than the directly executed P(P).

>>>

>>> The you have just invaldated your proof as you P isn't defined right.

>>>

>>> Sorry you wasted all those years on such a simple mistake.

>>>

>>

>>

>> Everyone here (in all three groups) knows /you/ understand the theory

>> involved here. Everyone knows Olcott is wrong.

>

> No one here has correctly pointed out a single mistake in the last two

> months.

>

> Richard is stuck on the notion that a function called in infinite

> recursion must return a value to its caller. Everyone here knows that is

> incorrect.

all callers.

Which H do you have, the one that doesn't abort and becomes infinitely

recursive, and doesn't answer to EITHER P or main, or

the one that DOES abort, and thus ISN'T infinitely recursive (so the

rule doesn't apply) and just gives the wrong answer about the behavior

of its input, the representation of P(P) which Halts if H(P,P) returns 0

so that answer is incorrect.

>

> There are some subtle nuances of pure/computable functions that need to

> be worked out on this issue.

for the same input. A given set of values will either make that function

non-returning to ALL callers or it will be returning to ALL callers.

You problem is you have two different H's that you keep on confusing,

perhaps one that you code actually is, and a second one which you

imagine as the specifiection for the code, and that H assumes

(incorrectly) that it meets.

>

> *Those issues can be worked out on comp.theory*

>

> Others here are stuck on the notion that a halt decider must make its

> halt status decision on some other basis than the actual behavior that

> is actually specified by actual its inputs. THAT IS CLEARLY FALSE.

then you P is defined incorrectly?

>

> *The sooner that I can get closure the sooner I will be done here*

stand on). From you other claims, you should be done in the not to

distent future (physically)

You will NEVER complete your proof, as it has more holes in it then a

wheel of swiss cheese, including ones that just go to its core.

The fact that you don't understand the meaning of most of the technical

words you use is probably your greatest handicap.

Jul 16, 2022, 2:10:45 PMJul 16

to

On 16/07/2022 18:32, David Brown wrote:

>

> Richard, will you /please/ just give it a break? The guy is a

> trisector. His "proof" is bogus - he doesn't even have a clear idea of

> what he is trying to prove.

What made you think that he is trying to prove anything? Olcott is
>

> Richard, will you /please/ just give it a break? The guy is a

> trisector. His "proof" is bogus - he doesn't even have a clear idea of

> what he is trying to prove.

trying to prove nothing. He is here to destroy these two newsgroups by

posting and flooding with his irrelevant stuff.

Comp.theory people have stopped responding to him so he is now here

because there are people still responding to him. They seem to be

enjoying to do the same thing as Olcott wants to do, i.e. destroy these

two newsgroups.

Anybody who is serious about his work won't spend time here because he

should know that he won't get any meaningful response on these

newsgroups. He'll get Fliber and Damon to validate his work. This should

tell you everything yo need to know! Have you come across any world

class researcher spending time on newsgroups in the 21st century?

Jul 16, 2022, 2:20:44 PMJul 16

to

of my paper. I am only here because the key basis of my proof is

anchored in software engineering.

*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

Jul 16, 2022, 2:27:00 PMJul 16

to

On 16/07/2022 19:53, olcott wrote:

> On 7/16/2022 12:32 PM, David Brown wrote:

>> On 16/07/2022 17:33, Richard Damon wrote:

>>> On 7/16/22 11:10 AM, olcott wrote:

>>>> This conclusively proves that H(P,P) correctly simulates its input

>>>> and that that the behavior of the correctly simulated P is very

>>>> different than the directly executed P(P).

>>>

>>> The you have just invaldated your proof as you P isn't defined right.

>>>

>>> Sorry you wasted all those years on such a simple mistake.

>>>

>>

>>

>> Everyone here (in all three groups) knows /you/ understand the theory

>> involved here. Everyone knows Olcott is wrong.

>

> No one here has correctly pointed out a single mistake in the last two

> months.

>

I did, by email - you did not respond.
> On 7/16/2022 12:32 PM, David Brown wrote:

>> On 16/07/2022 17:33, Richard Damon wrote:

>>> On 7/16/22 11:10 AM, olcott wrote:

>>>> This conclusively proves that H(P,P) correctly simulates its input

>>>> and that that the behavior of the correctly simulated P is very

>>>> different than the directly executed P(P).

>>>

>>> The you have just invaldated your proof as you P isn't defined right.

>>>

>>> Sorry you wasted all those years on such a simple mistake.

>>>

>>

>>

>> Everyone here (in all three groups) knows /you/ understand the theory

>> involved here. Everyone knows Olcott is wrong.

>

> No one here has correctly pointed out a single mistake in the last two

> months.

>

>

> *The sooner that I can get closure the sooner I will be done here*

someone to lie to you and tell you you are right. Perhaps someone could

do that, and maybe then you'll go away?

If you are genuinely interested in comments, criticisms and help, feel

free to respond to my email. Otherwise, please shut up.

Jul 16, 2022, 2:41:06 PMJul 16

to

(3) With no instructions in P preceding its invocation of H(P,P).

since the actual rule you are thinking of doesn't include the "preceding

its invocation of H(P,P)".

Since H does have the needed conditional, that you even claim is used to

stop the cycle, shows that the call to H(P,P) ISN'T infinitely recursive

for ANY H that does abort its simulation and return 0.

You failure to deal with that problem kills your proof, just like you

are killing yourself.

Jul 16, 2022, 2:51:17 PMJul 16

to

Almost all of my posts use a dummy email.

I see your reply in my USENET only email.

I only made about six posts using this email.

Jul 16, 2022, 2:57:59 PMJul 16

to

On 7/16/2022 1:05 PM, Richard Damon wrote:

> On 7/16/22 1:53 PM, olcott wrote:

>> On 7/16/2022 12:32 PM, David Brown wrote:

>>> On 16/07/2022 17:33, Richard Damon wrote:

>>>> On 7/16/22 11:10 AM, olcott wrote:

>>>>> This conclusively proves that H(P,P) correctly simulates its input

>>>>> and that that the behavior of the correctly simulated P is very

>>>>> different than the directly executed P(P).

>>>>

>>>> The you have just invaldated your proof as you P isn't defined right.

>>>>

>>>> Sorry you wasted all those years on such a simple mistake.

>>>>

>>>

>>>

>>> Everyone here (in all three groups) knows /you/ understand the theory

>>> involved here. Everyone knows Olcott is wrong.

>>

>> No one here has correctly pointed out a single mistake in the last two

>> months.

>>

>> Richard is stuck on the notion that a function called in infinite

>> recursion must return a value to its caller. Everyone here knows that

>> is incorrect.

>

> No, I am stuck pointing out that a Pure Function must behave the same to

> all callers.

>

That does not precisely correspond to the actual definition of a pure
> On 7/16/22 1:53 PM, olcott wrote:

>> On 7/16/2022 12:32 PM, David Brown wrote:

>>> On 16/07/2022 17:33, Richard Damon wrote:

>>>> On 7/16/22 11:10 AM, olcott wrote:

>>>>> This conclusively proves that H(P,P) correctly simulates its input

>>>>> and that that the behavior of the correctly simulated P is very

>>>>> different than the directly executed P(P).

>>>>

>>>> The you have just invaldated your proof as you P isn't defined right.

>>>>

>>>> Sorry you wasted all those years on such a simple mistake.

>>>>

>>>

>>>

>>> Everyone here (in all three groups) knows /you/ understand the theory

>>> involved here. Everyone knows Olcott is wrong.

>>

>> No one here has correctly pointed out a single mistake in the last two

>> months.

>>

>> Richard is stuck on the notion that a function called in infinite

>> recursion must return a value to its caller. Everyone here knows that

>> is incorrect.

>

> No, I am stuck pointing out that a Pure Function must behave the same to

> all callers.

>

function:

"the function return values are identical for identical arguments"

https://en.wikipedia.org/wiki/Pure_function

We also know that it is an immutable fact that no function called in

finite recursion ever returns any value to its caller.

We can see by the correct partial execution trace that the simulation

that H(P,P) performs on its input could never correctly return any value

to the simulated P.

We can see by the correct complete execution trace that H(P,P) does

return a value to main().

If H was not a halt decider with the ability to abort the simulation of

its input then H(P,P) would not be able to return to main();

In the unique case of a simulating halt decider that must abort the

simulation of all inputs that would never terminate normally the

behavior on the same arguments when called in infinite recursion must

differ from the behavior on these same inputs when not called in

infinite recursion.

Technically the second call is not actually made it is aborted before it

is allowed to change any internal process state.

Jul 16, 2022, 3:24:48 PMJul 16

to

On 7/16/22 2:57 PM, olcott wrote:

> On 7/16/2022 1:05 PM, Richard Damon wrote:

>> On 7/16/22 1:53 PM, olcott wrote:

>>> On 7/16/2022 12:32 PM, David Brown wrote:

>>>> On 16/07/2022 17:33, Richard Damon wrote:

>>>>> On 7/16/22 11:10 AM, olcott wrote:

>>>>>> This conclusively proves that H(P,P) correctly simulates its input

>>>>>> and that that the behavior of the correctly simulated P is very

>>>>>> different than the directly executed P(P).

>>>>>

>>>>> The you have just invaldated your proof as you P isn't defined right.

>>>>>

>>>>> Sorry you wasted all those years on such a simple mistake.

>>>>>

>>>>

>>>>

>>>> Everyone here (in all three groups) knows /you/ understand the

>>>> theory involved here. Everyone knows Olcott is wrong.

>>>

>>> No one here has correctly pointed out a single mistake in the last

>>> two months.

>>>

>>> Richard is stuck on the notion that a function called in infinite

>>> recursion must return a value to its caller. Everyone here knows that

>>> is incorrect.

>>

>> No, I am stuck pointing out that a Pure Function must behave the same

>> to all callers.

>>

>

> That does not precisely correspond to the actual definition of a pure

> function:

>

> "the function return values are identical for identical arguments"

> https://en.wikipedia.org/wiki/Pure_function

And "Not returning" turns out to be a "return value" for such a function.
> On 7/16/2022 1:05 PM, Richard Damon wrote:

>> On 7/16/22 1:53 PM, olcott wrote:

>>> On 7/16/2022 12:32 PM, David Brown wrote:

>>>> On 16/07/2022 17:33, Richard Damon wrote:

>>>>> On 7/16/22 11:10 AM, olcott wrote:

>>>>>> This conclusively proves that H(P,P) correctly simulates its input

>>>>>> and that that the behavior of the correctly simulated P is very

>>>>>> different than the directly executed P(P).

>>>>>

>>>>> The you have just invaldated your proof as you P isn't defined right.

>>>>>

>>>>> Sorry you wasted all those years on such a simple mistake.

>>>>>

>>>>

>>>>

>>>> Everyone here (in all three groups) knows /you/ understand the

>>>> theory involved here. Everyone knows Olcott is wrong.

>>>

>>> No one here has correctly pointed out a single mistake in the last

>>> two months.

>>>

>>> Richard is stuck on the notion that a function called in infinite

>>> recursion must return a value to its caller. Everyone here knows that

>>> is incorrect.

>>

>> No, I am stuck pointing out that a Pure Function must behave the same

>> to all callers.

>>

>

> That does not precisely correspond to the actual definition of a pure

> function:

>

> "the function return values are identical for identical arguments"

> https://en.wikipedia.org/wiki/Pure_function

Yes, we don't know that the INTERNAL behavior will be the same, but the

EXTERNAL behavior will be.

In other words, if main call H(P,P) and it returns 0 to it, the if H is

a pure function, when P calls H(P,P) it MUST also return 0 to it.

>

> We also know that it is an immutable fact that no function called in

> finite recursion ever returns any value to its caller.

Right, if the behavior of H(P,P) creates ACTUAL infinite recursion, it

will not return to its caller.

Note, the fact that when H is called by main, it has the smarts to

identify that it needs to abort to avoid getting into infinite

recursion, says it also has the smarts to do that when P calls it, and

thus your apparent infinite recursion never ACTUALLY happens.

>

> We can see by the correct partial execution trace that the simulation

> that H(P,P) performs on its input could never correctly return any value

> to the simulated P.

Your rule (3) is WRONG, and this is even one of the cases that proves it

wrong.

>

> We can see by the correct complete execution trace that H(P,P) does

> return a value to main().

that exact same trace, thus PROVING that P(P) is a halting computation.

Also, since by the definition of P, P calls H to decide on P(P), that

for that call to H(P,P) the inputs must actually correspond to the

behavior of P(P) or you haven't written P correctly.

>

> If H was not a halt decider with the ability to abort the simulation of

> its input then H(P,P) would not be able to return to main();

>

> In the unique case of a simulating halt decider that must abort the

> simulation of all inputs that would never terminate normally the

> behavior on the same arguments when called in infinite recursion must

> differ from the behavior on these same inputs when not called in

> infinite recursion.

the rules. H(P,P) must ALWAYS return the same value (or not return) to

all callers. If it returns 0 to main, it returns 0 to P(P), which makes

P(P) halting, and thus makes H(P,P) returning 0 incorrect.

If H(P,P) doesn't return to P(P) then it doesn't return to main, and H

just fails to be a decider.

Second, H(P,P) MUST be refering to the behavior of P(P) or H and P don't

meet the definiton of the programs they need to be. If you try to prove

it can't be that, all you are doing is proving that your H can't exist

and meet the requirments, it doesn't give you the right to change them.

FAILURE IS A OPTION here, there is NO requirement that an H that does

this actually exist, and in fact the theorem show it doesn't so you have

to actually establish existance that meets the requirments to be a

counter example. Showing the requirements can't be meet just proves the

theorem, not refute it.

>

> Technically the second call is not actually made it is aborted before it

> is allowed to change any internal process state.

call will never return, because we know from the other traces that it will!

You can't prove something when your logic is based on errors.

H decides, incorrectly, that H(P,P) must be stuck in infinite recursion

when it isn't so that its conclusion that P(P) is non-halting is

incorrect, and BECAUSE it made that error, it makes P(P) Halting.

By what logic can you claim that a function call to be pure function

that has been proved to return witht the same parameters doesn't return

for one case.

THAT IS AN IMPOSSIBLE CLAIM.

Your problem is you mix two different INCOMPATIBLE definitions of what H

is does. This gives you the wrong answer.

Jul 16, 2022, 6:15:19 PMJul 16

to

function called in infinite recursion cannot possibly correctly return

any value to its caller.

So it seems to be the case that for simulating halt deciders that are

invoked with pathological arguments we have possibly a single exception

to the rule where the correct simulation of an input does not match the

behavior of the correct direct execution of this input.

Because we know that a halt decider must base its halt status decision

on the actual behavior that is actually specified by its actual input

and we know that the correct simulation of this input by H(P,P) <is> the

actual behavior of this input then we know that H(P,P)==0 is the correct

halt status of this input.

Now we move on to whether or not H(P,P) is a pure function.

https://en.wikipedia.org/wiki/Pure_function

The instance of H(P,P) that is called by the simulated P is essentially

aborted before it is actually invoked. This seems to be another

exception to the rule of conventional understandings.

I can't think of any other example than a simulating halt decider that

would not be totally stuck in infinite recursion on the same inputs no

matter how it was initially invoked as long as one invocation on these

same inputs is infinitely recursive.

The ultimate measure of whether or not it it Turing computable would be

to translate it into a Turing equivalent architecture such as a RASP

machine. The ultimate measure is definitely not the mere dogmatic words

of any textbook(s).

The only reason that H(P,P) returns to main() is that the H in main can

abort the simulation of its input otherwise the H in main() would never

return from P.

Jul 16, 2022, 7:14:36 PMJul 16

to

recursion because your H has a safety valve in it the DOES trip and stop

the loop.

THe problem is you use bad logic, like that faulty rule (2), to convince

yourself of something that isn't true.

>

> So it seems to be the case that for simulating halt deciders that are

> invoked with pathological arguments we have possibly a single exception

> to the rule where the correct simulation of an input does not match the

> behavior of the correct direct execution of this input.

>

> Because we know that a halt decider must base its halt status decision

> on the actual behavior that is actually specified by its actual input

> and we know that the correct simulation of this input by H(P,P) <is> the

> actual behavior of this input then we know that H(P,P)==0 is the correct

> halt status of this input.

P(P) since that comes from the definition of a Halt Decider and the

"impossible program" P. All your "proof' that the input to H(P,P) has

different behavior than P(P) does is show that your H is wrong.

>

> Now we move on to whether or not H(P,P) is a pure function.

> https://en.wikipedia.org/wiki/Pure_function

>

> The instance of H(P,P) that is called by the simulated P is essentially

> aborted before it is actually invoked. This seems to be another

> exception to the rule of conventional understandings.

the program actually does.

Since P(P) calls H(P,P) and will get the 0 return, the simulation of the

call, to be "correct" needs to be compatible with that.

H's analysis that this H will not return says that H is either using

incorrect logic, that it is a incorrect simulator, or that H isn't

actually the pure function it needs to be and its simulation behaves

different then its actual execution.

All three show H to be WRONG.

>

> I can't think of any other example than a simulating halt decider that

> would not be totally stuck in infinite recursion on the same inputs no

> matter how it was initially invoked as long as one invocation on these

> same inputs is infinitely recursive.

abort its simulation, THIS H never gets stuck in infinite recursion, so

it doesn't matter what happens to the "other H" that isn't actually present.

>

> The ultimate measure of whether or not it it Turing computable would be

> to translate it into a Turing equivalent architecture such as a RASP

> machine. The ultimate measure is definitely not the mere dogmatic words

> of any textbook(s).

>

code fragments are not necessarily computations.

Yes, you can translate the Halting Problem to such architectures, but

the wording needs to be much more detailed to spell out the requirements

that the pieces being used are actually computations.

>

>

> The only reason that H(P,P) returns to main() is that the H in main can

> abort the simulation of its input otherwise the H in main() would never

> return from P.

>

be correct its simulstion needs to reflect that same behavior. ad that

means the behavior of the input is halting.

ALL the H's can abort the simulation because ALL the H's need to be the

SAME ALGORIGTHM and compute the same function. Since in your model they

are all calling the exact same function, that says that (if H is the

claimed pure function) all the calls WILL behave the same.

Jul 16, 2022, 7:53:09 PMJul 16

to

corrected you on this) would never terminate normally by reaching its

"return" statement, thus is correctly determined to be non-halting.

>>

>> So it seems to be the case that for simulating halt deciders that are

>> invoked with pathological arguments we have possibly a single

>> exception to the rule where the correct simulation of an input does

>> not match the behavior of the correct direct execution of this input.

>>

>> Because we know that a halt decider must base its halt status decision

>> on the actual behavior that is actually specified by its actual input

>> and we know that the correct simulation of this input by H(P,P) <is>

>> the actual behavior of this input then we know that H(P,P)==0 is the

>> correct halt status of this input.

>

> And the actual behavior of the input to H(P,P) must be the behavior of

> P(P) since that comes from the definition of a Halt Decider and the

> "impossible program" P. All your "proof' that the input to H(P,P) has

> different behavior than P(P) does is show that your H is wrong.

>

>>

>> Now we move on to whether or not H(P,P) is a pure function.

>> https://en.wikipedia.org/wiki/Pure_function

>>

>> The instance of H(P,P) that is called by the simulated P is

>> essentially aborted before it is actually invoked. This seems to be

>> another exception to the rule of conventional understandings.

>

> BUT, for your simulation to be "correct" its behavior must match what

> the program actually does.

>

reasoning you will never get this. If enough people of high enough

authority proclaimed that all white cats are black dogs many people

would simply accept that as true.

> Since P(P) calls H(P,P) and will get the 0 return, the simulation of the

> call, to be "correct" needs to be compatible with that.

>

> H's analysis that this H will not return says that H is either using

> incorrect logic, that it is a incorrect simulator, or that H isn't

> actually the pure function it needs to be and its simulation behaves

> different then its actual execution.

>

> All three show H to be WRONG.

>

>>

>> I can't think of any other example than a simulating halt decider that

>> would not be totally stuck in infinite recursion on the same inputs no

>> matter how it was initially invoked as long as one invocation on these

>> same inputs is infinitely recursive.

>

> But it isn't an allowed exception. As I pointed out, since H decides to

> abort its simulation, THIS H never gets stuck in infinite recursion, so

> it doesn't matter what happens to the "other H" that isn't actually

> present.

>

The provably correct simulation of the input to H(P,P) have provably

correct different behavior that the provably correct behavior of the

direct execution of P(P).

The no one here has the technical understanding of the x86 language

(except possibly Mike) to verify this is zero evidence what-so-ever that

I am incorrect.

>>

>> The ultimate measure of whether or not it it Turing computable would

>> be to translate it into a Turing equivalent architecture such as a

>> RASP machine. The ultimate measure is definitely not the mere dogmatic

>> words of any textbook(s).

>>

>

> Note, RASP architectures have exactly the same traps as the x86 that

> code fragments are not necessarily computations.

>

> Yes, you can translate the Halting Problem to such architectures, but

> the wording needs to be much more detailed to spell out the requirements

> that the pieces being used are actually computations.

>

>>

>>

>> The only reason that H(P,P) returns to main() is that the H in main

>> can abort the simulation of its input otherwise the H in main() would

>> never return from P.

>>

>

> Right, and since it does, it will do the same when P(P) calls it, so to

> be correct its simulstion needs to reflect that same behavior. ad that

> means the behavior of the input is halting.

>

> ALL the H's can abort the simulation because ALL the H's need to be the

> SAME ALGORIGTHM and compute the same function.

abort criteria first and when it aborts its simulation none of the inner

H's see anything at all because they are never invoked.

> Since in your model they

> are all calling the exact same function, that says that (if H is the

> claimed pure function) all the calls WILL behave the same.

>

>

Jul 16, 2022, 8:16:11 PMJul 16

to

On 7/16/2022 8:10 AM, olcott wrote:

> This conclusively proves that H(P,P) correctly simulates its input and

Post it 154,517 more times you retarded mouthload of Bolivian donkey
> This conclusively proves that H(P,P) correctly simulates its input and

testicles.

Jul 16, 2022, 8:34:20 PMJul 16

to

If H(P,P) returns 0, as you claim it does to main, it will do the same

to P(P) and that makes P(P) Halt.

Since P(P) Halts, a correct simulation of the input to H will also halt

since the input to H(P,P) IS the representation of P(P) and if you want

to claim otherwise, you have just declaired that P isn't writen right.

Yes, there IS a case of a design for H where the correctly simulated

input never terminates, and that is the case when H NEVER aborts its

simulation, and thus H(P,P) never returns to main and thus fails to be a

Decider.

Which H are you claiming, the one that gives the wrong answer or the one

that fails to be a decider?

>

>>>

>>> So it seems to be the case that for simulating halt deciders that are

>>> invoked with pathological arguments we have possibly a single

>>> exception to the rule where the correct simulation of an input does

>>> not match the behavior of the correct direct execution of this input.

>>>

>>> Because we know that a halt decider must base its halt status

>>> decision on the actual behavior that is actually specified by its

>>> actual input and we know that the correct simulation of this input by

>>> H(P,P) <is> the actual behavior of this input then we know that

>>> H(P,P)==0 is the correct halt status of this input.

>>

>> And the actual behavior of the input to H(P,P) must be the behavior of

>> P(P) since that comes from the definition of a Halt Decider and the

>> "impossible program" P. All your "proof' that the input to H(P,P) has

>> different behavior than P(P) does is show that your H is wrong.

>>

>>>

>>> Now we move on to whether or not H(P,P) is a pure function.

>>> https://en.wikipedia.org/wiki/Pure_function

>>>

>>> The instance of H(P,P) that is called by the simulated P is

>>> essentially aborted before it is actually invoked. This seems to be

>>> another exception to the rule of conventional understandings.

>>

>> BUT, for your simulation to be "correct" its behavior must match what

>> the program actually does.

>>

>

> Because you know these things on the basis of dogma rather than

> reasoning you will never get this. If enough people of high enough

> authority proclaimed that all white cats are black dogs many people

> would simply accept that as true.

know what anything means, you will never understand what yoy are writing

about.

I don't take these facts as "dogma", but becuase they ARE the definition.

H(M,x) must accept if M(x) halts, and renect if M(x) never halts.

By construction, P(P) will halt if H(P,P) rejects (returns 0), (and loop

forever if H(P,P) accepts) so H(P,P) rejecting is NEVER a correct answer.

What is the error in that arguement. Not how do you show something else,

what it the error.

Remember, if two contradictory statements can both be proved true, the

logic system is inconsistent. Thus you "proving" something contrary to

some other statement without showing the actual logical error in it just

shows tha tyou are using a inconsisten logic system.

>

>> Since P(P) calls H(P,P) and will get the 0 return, the simulation of

>> the call, to be "correct" needs to be compatible with that.

>>

>> H's analysis that this H will not return says that H is either using

>> incorrect logic, that it is a incorrect simulator, or that H isn't

>

> These are provably correct yet beyond your capacity to verify.

original just proves that you logic system is inconsistent.

Since you system includes "rules" beyond the generally accepted theries,

all you have done it prove that you have added some inconsistent rule.

>

>> actually the pure function it needs to be and its simulation behaves

>> different then its actual execution.

>>

>> All three show H to be WRONG.

>>

>>>

>>> I can't think of any other example than a simulating halt decider

>>> that would not be totally stuck in infinite recursion on the same

>>> inputs no matter how it was initially invoked as long as one

>>> invocation on these same inputs is infinitely recursive.

>>

>> But it isn't an allowed exception. As I pointed out, since H decides

>> to abort its simulation, THIS H never gets stuck in infinite

>> recursion, so it doesn't matter what happens to the "other H" that

>> isn't actually present.

>>

>

> *It is already provable that it definitely has another exception*

> The provably correct simulation of the input to H(P,P) have provably

> correct different behavior that the provably correct behavior of the

> direct execution of P(P).

had logical errors pointed out that you have not corrected. You are just

proving you incabablility to perform correct logic.

>

> The no one here has the technical understanding of the x86 language

> (except possibly Mike) to verify this is zero evidence what-so-ever that

> I am incorrect.

stupidity.

I would actually challange you to a duel of technical knowledge, but I

have a policy of not fighting an unarmed foe.

>

>>>

>>> The ultimate measure of whether or not it it Turing computable would

>>> be to translate it into a Turing equivalent architecture such as a

>>> RASP machine. The ultimate measure is definitely not the mere

>>> dogmatic words of any textbook(s).

>>>

>>

>> Note, RASP architectures have exactly the same traps as the x86 that

>> code fragments are not necessarily computations.

>>

>> Yes, you can translate the Halting Problem to such architectures, but

>> the wording needs to be much more detailed to spell out the

>> requirements that the pieces being used are actually computations.

>>

>>>

>>>

>>> The only reason that H(P,P) returns to main() is that the H in main

>>> can abort the simulation of its input otherwise the H in main() would

>>> never return from P.

>>>

>>

>> Right, and since it does, it will do the same when P(P) calls it, so

>> to be correct its simulstion needs to reflect that same behavior. ad

>> that means the behavior of the input is halting.

>>

>> ALL the H's can abort the simulation because ALL the H's need to be

>> the SAME ALGORIGTHM and compute the same function.

>

> All H's can abort the simulation, yet the only the outermost H sees the

> abort criteria first and when it aborts its simulation none of the inner

> H's see anything at all because they are never invoked.

anything that doesn't match your erroneous believes.

There are TWO different "outermost" H's in view, one from the call to

main, and one in the test program where main calls P(P) which calls H.

Both of those should show that H(P,P) returns 0, and the second shows

that when this happens to the actual machine, P(P) Halts.

Since the DEFINITION of a correct simuation is one that matches that

actual machine, the correct simulation of the input to H(P,P) by a real

correct and complete simulator will also Halt.

The fact that H thinks it doesn't just proves that H is wrong. As I

said, it can be wrong serveral ways.

1) It can use incorrect logic, like your incorrect rule (3), to reach a

bad conclusion of its input.

2) It can be that H does an incorrect emulation of its input, this is

related to 1) as your emulator thinks that H(P,P) never returns, when we

have previous show that, as long as H is a pure function, that H(P,P)

will always return 0.

3) It could be that H just isn't a pure function and not qualified to be

a decider.

Since we don't have the code for H, we can't tell, but we KNOW that case

1 is at least partly true based on your claims, since you DO quote the

incorrect rule.

Jul 16, 2022, 8:40:26 PMJul 16

to

Jul 16, 2022, 9:07:57 PMJul 16

to

As I said, YOU have posted a trace of P(P) being simulated by a correct

simulator that traced it to its final return, which actually DOES prove

that P(P) is halting when H(P,P) returns 0.

(Admittedly, the impossible progra was called H_Hat at the time, but it

was the same program).

Since you have NEVER pointed out an actual flaw in most of the

rebuttals, YOU are the one shown to not care about facts.

It is absolutely established that P(P) will Halt if H(P,P) returns 0.

It is true BY DEFINITION, that the behavior of the input to H(P,P) must

be the behavior of P(P) since that is what P uses to ask about P(P).

You "proof" that it must be something different actually just proves

that your H and P don't match the requirements and thus your proof is

worthless.

YOU don't know what truth is, you think you do, but you are mistaken.

You prove this every time you ignore an error pointed out in your logic

and your failure to correct them.

You have been given many opertunities to provide evidence for your

claims, but you refuse, but instead show your "intelgence" by just

repeating your disproven claims again.

It seems you think that by just repeating your lie often enough, some

people might begin to believe it.

In the not to distant future, based on what you have been saying, you

are going to have a meeting with the Truth, and from what I see, you are

going to be sorely disapointed.

As you have said, those that live a life filled with lies are condemned

to distruction, so that will be your fate. (Maybe you don't actually

believe that, but that just shows more of your lying). There IS a truth,

and it doesn't matter what people think, the Truth IS the Truth.

Spending decades trying to prove something that isn't true isn't the way

to find the real Truth.

Jul 17, 2022, 5:28:17 AMJul 17

to

out those flaws rather than just indulge in wand waving.

/Flibble

Jul 17, 2022, 8:48:15 AMJul 17

to

On 7/16/2022 12:32 PM, David Brown wrote:

Jul 16, 2022, 7:11 PM (12 hours ago)

Jul 17, 2022, 9:25:20 AMJul 17

to

and c.l.c++, and have apparently ruined comp.theory. We do not want

them here.

If people want to discuss Olcott's theories with him in a serious

manner, then they can do so by email. (We have had a couple of emails

back and forth, outside this newsgroup. Whether we make any progress

remains to be seen, but it is not bothering other people.) If you do

not get useful responses from him by email, you certainly will not do so

here in these Usenet groups.

So please, Olcott, Flibble, and others - stick to email, or find a

different and /appropriate/ forum for these discussions. It is not

really asking too much, just basic politeness and human decency.

Jul 17, 2022, 9:33:53 AMJul 17

to

clueless on the most important points.

Jul 17, 2022, 9:38:39 AMJul 17

to

> (or work on /real/ computability

> theory topics, as it is an interesting field).

A field is no longer interesting if so called experts in that field,
> theory topics, as it is an interesting field).

people who have invested years of their life into it, dismiss anything

that contradicts what they consider to be "accepted", "solved" or

"settled" when all it actually is is something that they have learned by

rote.

/Flibble

Jul 17, 2022, 9:41:06 AMJul 17

to

On Sun, 17 Jul 2022 08:33:36 -0500

olcott <No...@NoWhere.com> wrote:

> On 7/17/2022 8:25 AM, David Brown wrote:

> > On 17/07/2022 14:48, olcott wrote:

> >> On 7/16/2022 12:32 PM, David Brown wrote:

> >

> >>> (My email address is valid if you want to comment directly.)

> >>

> >> I responded in email again last night at

> >> Jul 16, 2022, 7:11 PM (12 hours ago)

> >>

> >

> > To be clear here - these threads are entirely inappropriate for

> > c.l.c and c.l.c++, and have apparently ruined comp.theory. We do

> > not want them here.

> >

> > If people want to discuss Olcott's theories with him in a serious

> > manner, then they can do so by email. (We have had a couple of

> > emails back and forth, outside this newsgroup. Whether we make any

> > progress remains to be seen, but it is not bothering other people.)

> > If you do not get useful responses from him by email, you

> > certainly will not do so here in these Usenet groups.

> >

> > So please, Olcott, Flibble, and others - stick to email, or find a

> > different and /appropriate/ forum for these discussions. It is not

> > really asking too much, just basic politeness and human decency.

>

> Flibble is clueless, SkepDick seems mostly clueless, Richard is only

> clueless on the most important points.

If I am clueless then explain why my signaling decider answers the
olcott <No...@NoWhere.com> wrote:

> On 7/17/2022 8:25 AM, David Brown wrote:

> > On 17/07/2022 14:48, olcott wrote:

> >> On 7/16/2022 12:32 PM, David Brown wrote:

> >

> >>> (My email address is valid if you want to comment directly.)

> >>

> >> I responded in email again last night at

> >> Jul 16, 2022, 7:11 PM (12 hours ago)

> >>

> >

> > To be clear here - these threads are entirely inappropriate for

> > c.l.c and c.l.c++, and have apparently ruined comp.theory. We do

> > not want them here.

> >

> > If people want to discuss Olcott's theories with him in a serious

> > manner, then they can do so by email. (We have had a couple of

> > emails back and forth, outside this newsgroup. Whether we make any

> > progress remains to be seen, but it is not bothering other people.)

> > If you do not get useful responses from him by email, you

> > certainly will not do so here in these Usenet groups.

> >

> > So please, Olcott, Flibble, and others - stick to email, or find a

> > different and /appropriate/ forum for these discussions. It is not

> > really asking too much, just basic politeness and human decency.

>

> Flibble is clueless, SkepDick seems mostly clueless, Richard is only

> clueless on the most important points.

following correctly whilst your naive decider does not?

void Px(void (*x)())

{

(void) H(x, x);

return;

}

/Flibble

Jul 17, 2022, 10:03:56 AMJul 17

to

On 7/17/2022 8:25 AM, David Brown wrote:

very soon and not need to talk on USENET about this.

Jul 17, 2022, 10:06:42 AMJul 17

to

have actual reasoning to back up what he says. One must have deep

understanding to see new exceptions to old rules.

Jul 17, 2022, 10:10:29 AMJul 17

to

every single detail of the criterion measure that it uses to trigger the

signal. My criterion measure says YES or NO you would have to weaken my

criterion measure to say I_DONT_KNOW (aka pathological input).

Jul 17, 2022, 11:04:45 AMJul 17

to

On Sun, 17 Jul 2022 09:10:11 -0500

I don't have to weaken anything: my signaling decider has three

outcomes:

1) decision halts;

2) decision does not halt;

3) exception (pathological input).

Even if we ignore the false positive your decider gives for Px above,

you are still wrong to map pathological input to (2).

/Flibble

outcomes:

1) decision halts;

2) decision does not halt;

3) exception (pathological input).

Even if we ignore the false positive your decider gives for Px above,

you are still wrong to map pathological input to (2).

/Flibble

Jul 17, 2022, 11:30:31 AMJul 17

to

My criteria says DOES NOT HALT.

to transform this to PATHOLOGICAL SELF-REFERENCE

one wouLd be essentially saying I DON'T KNOW.

I DON'T KNOW is a weaker answer than NO

Jul 17, 2022, 2:06:04 PMJul 17

to

message? Do you think David Brown is so off target that he can be ignored?

--

Jeff Barnett

Reply all

Reply to author

Forward

0 new messages