XPost: comp.theory, sci.logic

On 2/7/2023 5:32 AM, Paul N wrote:

On Sunday, February 5, 2023 at 8:47:16 PM UTC, Mr Flibble wrote:

On Sun, 05 Feb 2023 21:21:32 +0100, Python wrote:

Le 05/02/2023 à 21:11, Mr Flibble a écrit :

On Sun, 05 Feb 2023 14:51:18 -0500, Richard Damon wrote:

...

You are just showing you are as ignorant about the subject as Olcott, >>>>> I think he has gaslit you just like he has done to himself.

My research is entirely independent of Olcott's

Well so it's a kind of coincidence. You just happen to be as stupid as
each other Olcott and you.

You are completely missing the point: Olcott believes what he posts whilst >> I am just trolling, and quite successfully too.

It's amazing how few people have actually spotted this point, given that both you and me have pointed it out several times.

Olcott has posted lots of stuff about how he has disproved the Halting Problem, so you post stuff saying about how you have (nearly) solved it.
Olcott repeats his posts over and over again, ignoring the fact that the errors have been pointed out, so you repost your stuff unchanged.
Olcott now changes tack and says that the Halting Problem is invalid. So you do too.

Incidentally, I rather have doubts as to whether Olcott does actually believe what he posts. It seems more likely he is just doing it to get attention - and successfully, it seems.

*You have already agreed that P correctly simulated by H never halts*
*thus meeting its halt status criterion measure*

(a) If simulating halt decider H correctly simulates its input D until
H correctly determines that its simulated D would never stop running
unless aborted then (b) H can abort its simulation of D and correctly
report that D specifies a non-halting sequence of configurations.

In comp.lang.c++
On 6/14/2022 6:47 AM, Paul N wrote:

On Monday, June 13, 2022 at 7:46:22 PM UTC+1, olcott wrote:

Begin Local Halt Decider Simulation Execution Trace Stored at:212352
// H emulates the first seven instructions of P
...[00001352][0021233e][00212342] 55 push ebp // enter P
...[00001353][0021233e][00212342] 8bec mov ebp,esp
...[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08]
...[00001358][0021233a][00001352] 50 push eax // push P
...[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08]
...[0000135c][00212336][00001352] 51 push ecx // push P
...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H

// The emulated H emulates the first seven instructions of P
...[00001352][0025cd66][0025cd6a] 55 push ebp // enter P
...[00001353][0025cd66][0025cd6a] 8bec mov ebp,esp
...[00001355][0025cd66][0025cd6a] 8b4508 mov eax,[ebp+08]
...[00001358][0025cd62][00001352] 50 push eax // push P
...[00001359][0025cd62][00001352] 8b4d08 mov ecx,[ebp+08]
...[0000135c][0025cd5e][00001352] 51 push ecx // push P
...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

It is completely obvious that when H(P,P) correctly emulates
its input that it must emulate the first seven instructions
of P. Because the seventh instruction of P repeats this
process we can know with complete certainty that the emulated
P never reaches its final “ret” instruction, thus never halts.

Yes, it is clear to us humans watching it that the program is
repeating itself. Thus we can appreciate that it will never reach
the final "ret" - indeed, it won't even get to the infinite loop
identified above. But does the computer itself know this? If the
emulator simply emulates the instructions given, it will not
realise that it is doing the same thing over and over again. If
it does look out for this, spotting a repeated state, then it can
tell that the program under consideration will not halt. The answer
to whether it spots this lies in the emulator, which you haven't
shown the code for.

*Here is the code, it compiles under*
*Microsoft Visual Studio Community Edition 2017* https://liarparadox.org/2023_02_07.zip
The current halt status algorithm is in Halt7.c

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.theory, sci.logic

On 2/8/23 10:44 AM, olcott wrote:

*You have already agreed that P correctly simulated by H never halts*
*thus meeting its halt status criterion measure*

So, WHICH H are you defining your H to actually Be?

The one that ACTUALLY doesn't abort its simulation until it can
CORRECTLY prove its input is non-halting, and thus never aborts its
simulation and doesn't answer, Yes, for THAT H, P(P) is non-Halting, but
H isn't correct, as it never abswers.

Or, is H the program that THINKS it is that H, and because that aborts
its simulation INCORRECTLY, and returns 0, which makes the P(P) built on
THAT H halting, and thus H wrong.

It seems you don't understand that those are two different sets of
assembly instructions, and thus the second H is INCORRECT, in part
because it doesn't look into the H called to see what it actually does.

If you think the two are actually identical instructions, what is the
first actual assembly instruction executed in the two paths

main -> P(P) -> H(P,P) that acts like the first
and
main -> H(P,P) that acts like the second

Where the two H's have IDENTICAL assembly code and the function H only
depends on the explicit parameters given

Where the two paths diverge. Since the second returns in finite time and
the first does not, there MUST be a difference, and thus there MUST be a
first difference.

This has been asked a number of times in the past, and the fact you
haven't answered just PROVES that you are LYING in your claims.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)