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

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.

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

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

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

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?

--
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

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

On Sat, 16 Jul 2022 10:10:16 -0500
olcott <NoOne@NoWhere.com> 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 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

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

/Flibble

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

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

--
Copyright 2022 Pete Olcott

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

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

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

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.

On 7/16/2022 1:26 PM, David Brown wrote:
> 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.
>

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.

--
Copyright 2022 Pete Olcott

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

On 7/16/2022 2:24 PM, Richard Damon wrote:
> 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.

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.

--
Copyright 2022 Pete Olcott

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

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

On Sat, 16 Jul 2022 19:32:53 +0200
David Brown <david.brown@hesbynett.no> 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.
> >
>
> 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.

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

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

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

--
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

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

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.

--
Copyright 2022 Pete Olcott

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

On Sat, 16 Jul 2022 19:32:53 +0200
David Brown <david.brown@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

On Sun, 17 Jul 2022 08:33:36 -0500
olcott <NoOne@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

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.

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.

--
Copyright 2022 Pete Olcott

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

On 7/17/2022 8:38 AM, Mr Flibble wrote:
> On Sat, 16 Jul 2022 19:32:53 +0200
> David Brown <david.brown@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
>
>

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.

--
Copyright 2022 Pete Olcott

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

On 7/17/2022 8:40 AM, Mr Flibble wrote:
> On Sun, 17 Jul 2022 08:33:36 -0500
> olcott <NoOne@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
>

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

--
Copyright 2022 Pete Olcott

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

[ Newsgroups: reset ]

In comp.theory Mr Flibble <flibble@reddwarf.jmc.corp> wrote:
> On Sat, 16 Jul 2022 19:32:53 +0200
> David Brown <david.brown@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,
> ....

We're not talking about "so called" experts. We're talking about real
genuine experts.

> people who have invested years of their life into it, dismiss anything
> that contradicts what they consider to be "accepted", "solved" or
> "settled" ....

No, they dismiss what is known to be untrue, disproved, and quite
frankly, garbage. Like geographers, who dismiss the flat-Earth
"theory".

> ..... when all it actually is is something that they have learned by
> rote.

Not at all. These experts have learned by deep, fundamental
understanding of their areas of expertise.

What you are trying to say is that these things are just a matter of
opinion, and that your opinion is as good as anybody else's, no matter
how expert. That is a crank attitude and is fundamentally wrong.

If you had actually undertaken a formal course in mathematical logic,
you would have got past the things you are now asserting to be valid in
the first few days of it, and wouldn't now be parroting them as though
they were somehow original and interesting. They're not.

You wouldn't follow the advice of a "so called doctor", somebody who
claimed to have "new, fresh ideas", yet didn't have medical
certificates, would you?

What is so different about mathematical logic?

> /Flibble

--
Alan Mackenzie (Nuremberg, Germany).

On 7/17/2022 9:40 AM, Alan Mackenzie wrote:
> [ Newsgroups: reset ]
>
> In comp.theory Mr Flibble <flibble@reddwarf.jmc.corp> wrote:
>> On Sat, 16 Jul 2022 19:32:53 +0200
>> David Brown <david.brown@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,
>> ....
>
> We're not talking about "so called" experts. We're talking about real
> genuine experts.
>
>> people who have invested years of their life into it, dismiss anything
>> that contradicts what they consider to be "accepted", "solved" or
>> "settled" ....
>
> No, they dismiss what is known to be untrue, disproved, and quite
> frankly, garbage. Like geographers, who dismiss the flat-Earth
> "theory".
>
>> ..... when all it actually is is something that they have learned by
>> rote.
>
> Not at all. These experts have learned by deep, fundamental
> understanding of their areas of expertise.
>
> What you are trying to say is that these things are just a matter of
> opinion, and that your opinion is as good as anybody else's, no matter
> how expert. That is a crank attitude and is fundamentally wrong.
>
> If you had actually undertaken a formal course in mathematical logic,
> you would have got past the things you are now asserting to be valid in
> the first few days of it, and wouldn't now be parroting them as though
> they were somehow original and interesting. They're not.
>
> You wouldn't follow the advice of a "so called doctor", somebody who
> claimed to have "new, fresh ideas", yet didn't have medical
> certificates, would you?
>
> What is so different about mathematical logic?
>
>> /Flibble
>

My latest proof is much easier to validate:

*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

--
Copyright 2022 Pete Olcott

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

On 7/17/2022 9:53 AM, olcott wrote:
> On 7/17/2022 9:40 AM, Alan Mackenzie wrote:
>> [ Newsgroups: reset ]
>>
>> In comp.theory Mr Flibble <flibble@reddwarf.jmc.corp> wrote:
>>> On Sat, 16 Jul 2022 19:32:53 +0200
>>> David Brown <david.brown@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,
>>> ....
>>
>> We're not talking about "so called" experts.  We're talking about real
>> genuine experts.
>>
>>> people who have invested years of their life into it, dismiss anything
>>> that contradicts what they consider to be "accepted", "solved" or
>>> "settled" ....
>>
>> No, they dismiss what is known to be untrue, disproved, and quite
>> frankly, garbage.  Like geographers, who dismiss the flat-Earth
>> "theory".
>>
>>> ..... when all it actually is is something that they have learned by
>>> rote.
>>
>> Not at all.  These experts have learned by deep, fundamental
>> understanding of their areas of expertise.
>>
>> What you are trying to say is that these things are just a matter of
>> opinion, and that your opinion is as good as anybody else's, no matter
>> how expert.  That is a crank attitude and is fundamentally wrong.
>>
>> If you had actually undertaken a formal course in mathematical logic,
>> you would have got past the things you are now asserting to be valid in
>> the first few days of it, and wouldn't now be parroting them as though
>> they were somehow original and interesting.  They're not.
>>
>> You wouldn't follow the advice of a "so called doctor", somebody who
>> claimed to have "new, fresh ideas", yet didn't have medical
>> certificates, would you?
>>
>> What is so different about mathematical logic?
>>
>>> /Flibble
>>
>
> My latest proof is much easier to validate:
>

The gist of the whole proof is shown on its first page.
None of the remaining pages are required.

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

--
Copyright 2022 Pete Olcott

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

On Sun, 17 Jul 2022 09:10:11 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 7/17/2022 8:40 AM, Mr Flibble wrote:
> > On Sun, 17 Jul 2022 08:33:36 -0500
> > olcott <NoOne@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
> >
>
> 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).

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