Re: Analysis of Flibble’s Latest: Detecting vs. Simulating Infinite Recursion ZFC

On 5/23/25 2:48 PM, olcott wrote:

On 5/23/2025 1:37 PM, Keith Thompson wrote:

Ben Bacarisse <ben@bsb.me.uk> writes:

Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:

[...]

And the big picture is that this can be done because false is the
correct halting decision for some halting computations.  He has said
this explicitly (as I have posted before) but he has also explained it
in words:
>
| When-so-ever a halt decider correctly determines that its input would
| never halt unless forced to halt by this halt decider this halt
| decider has made a correct not-halting determination.

>
Hmm.  I don't read that the way you do.  Did I miss something?
>
It assumes that the input is a non-halting computation ("its input
would never halt") and asserts that, in certain circumstances,
his mythical halt decider correctly determines that the input
is non-halting.
>
When his mythical halt decider correctly determines that its input
doesn't halt, it has made a correct non-halting determination.
It's just a tautology.
>

 It is a tautology that a dozen people here
have been trying to get away with denying
for two and one half years.

Yes, but a tautology you don't understand, as the input needs to be the represetation of a program, and thus its behavior doesn't change when you hypotosize the decider on aborting.

 <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
     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
      H can abort its simulation of D and correctly report that D
     specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
 _DDD()
[00002192] 55             push ebp
[00002193] 8bec           mov ebp,esp
[00002195] 6892210000     push 00002192
[0000219a] e833f4ffff     call 000015d2  // call HHH
[0000219f] 83c404         add esp,+04
[000021a2] 5d             pop ebp
[000021a3] c3             ret
Size in bytes:(0018) [000021a3]

WHich is an INVALID input, proving that you are just a stupid LIAR.
DDD, as a program, and an input representing it, must include ALL the code that it uses, including the code for HHH.

 DDD emulated by HHH according to the semantics of the x86
language cannot possibly reach its own "ret" instruction.
A dozen people here have lied about that for 2.5 years.

But since your HHH doesn't actually emulate DDD according to the semantics of the x86 language, your statement is just a LIE, proving your stupidity.
Since HHH has been stipulated to return 0 as what you claim to be the "correct" answer, that must be the code of HHH. PERIOD.
When we correctly emulate this code, it halts, therefore it is just a *LIE* that HHH correctly determined that the simulation of this input will never halt.
And, since you have stipulated that the above is the complete represention of the non-program DDD< then it is just a lie that ANY HHH can correctly emulate it, as it is impossible to correctly emulate THE INPUT past the call HHH instruction, as the input doesn't specify what is at that location, and that is all that a correct emulation of the input can look at.
Sorry, you are just proving that you are nothing but a blantant stupid liar that doesn't understand what he is talking about, and just doesn't care about truth.
You have sunk your reputation, and your ideas into the lake of fire by your stupid and illogical claims, and seem to be bound to join them in the near future.

 

This kind of determination can be made in specific cases (but of
course not in general).  A simple program like `int main(void)
{ while (1); }` is non-halting.  If I run it, it will never halt
unless I force it to halt, e.g. by typing Control-C or pulling the
power plug.
>
(I'm assuming that "when-so-ever" means the same as "when".)
>
[...]
>