P(P) halts because H(P,P) correctly determines that its input never halt

[olcott]

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

[Richard Damon]

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.

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.

yes, it does, if the CORRECT simulator simulated through the H code and
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.

You have proved you lack of understanding the x86 language.

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.

(3) is INCORRECT and it invalidates your arguement. You have been told
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.

But it ISN'T infinitely nested simulation BECAUSE H is declaired to be a
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.

[olcott]

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?

[Richard Damon]

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.


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.

[Mr Flibble]

[Strachey 1965] and the proofs based on it do not contain any infinite
recursion.

/Flibble

[David Brown]

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

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

[olcott]

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.

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

[olcott]

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

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.

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

[Richard Damon]

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.

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.

What nuances. Pure Functiona ALWAYS return the same value to ALL callers
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.

You mean the fact that if the input to H(P,P) doesn't represent P(P)
then you P is defined incorrectly?

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

You've been done logically for decades (because you have no base to
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.

[Manu Raju]

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

[olcott]

Try and find even a single software engineering flaw in the first page
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

[David Brown]

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.

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

You are not interested in closure, or of honest feedback - you want
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.

[Richard Damon]

You haven't answered my complaints about your
(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.

[olcott]

OK I will do that now.
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.

[olcott]

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

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.

[Richard Damon]

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.

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.

(I think you mean in infinte recursion)

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.

Nope, you don't show that, because you are using FAULTY logic.

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

Right, and when we trace main calling P(P) calling H(P,P) you will get
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();

And it uses that EXACT SAME ability to return to P, thus

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

But there is nothing that lets the simulating halt decider break any of
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.

Right, which shows that H used INCORRECT LOGIC to determine that this
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.

[olcott]

Yet this violates the verified fact of software engineering that every
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.

[Richard Damon]

Nope, it jsut shows that the P -> H => P loop is NOT an infinite
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.

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.

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

[olcott]

It is the case that the correctly simulated input (I see that Mike
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.
>

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.

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

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

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.

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.

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

[Mr Dribble]

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

[Richard Damon]

Nope. you even posted the trace of this.

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.

And because you are ignorant of what you talk about because you don't
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.

To "prove" something contrary to another prove without disproving the
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).

WHAT EXCEPTIONS. THERE ARE NONE. Your "provable correct simulation" has
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.

No, there is much evidence, you are just ignoring it, proving your
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.

You still don't understand do you. I think you are just to stupid to see
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.

[olcott]

So you don't give a rat's ass about verified facts.

[Richard Damon]

A care about ACTUALLY verified facts, not your garbage.

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.

[Mr Flibble]

How am I even worse? If you think my ideas are flawed then kindly point
out those flaws rather than just indulge in wand waving.

/Flibble

[olcott]

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

I responded in email again last night at
Jul 16, 2022, 7:11 PM (12 hours ago)

[David Brown]

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.

[olcott]

Flibble is clueless, SkepDick seems mostly clueless, Richard is only
clueless on the most important points.

[Mr Flibble]

On Sat, 16 Jul 2022 19:32:53 +0200
David Brown <david...@hesbynett.no> wrote:

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

[Mr Flibble]

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
following correctly whilst your naive decider does not?

void Px(void (*x)())
{
(void) H(x, x);
return;
}

/Flibble

[olcott]

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

Our email dialogue seems to be going so well that I may get closure
very soon and not need to talk on USENET about this.

[olcott]

I agree, this seems to not be the case with David Brown, he seems to
have actual reasoning to back up what he says. One must have deep
understanding to see new exceptions to old rules.

[olcott]

Your signalling decider is utterly useless until is explicitly specifies
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).

[Mr Flibble]

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

[olcott]

I am moving my replies to your pasts back to comp.theory.

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

[Jeff Barnett]

That's a fair question and comment. But what about the rest of the
message? Do you think David Brown is so off target that he can be ignored?
--
Jeff Barnett