Re: How Partial Simulations correctly determine non-halting ---Mike Terry Error

On 6/5/2024 4:32 AM, joes wrote:

Am Tue, 04 Jun 2024 17:16:48 -0500 schrieb olcott:

On 6/4/2024 4:26 PM, joes wrote:

Am Tue, 04 Jun 2024 13:02:03 -0500 schrieb olcott:

On 6/4/2024 11:58 AM, Mike Terry wrote:

On 04/06/2024 11:52, Fred. Zwarts wrote:

Op 04.jun.2024 om 12:29 schreef Fred. Zwarts:

Op 03.jun.2024 om 23:24 schreef olcott:

On 6/3/2024 3:09 PM, Fred. Zwarts wrote:

Op 03.jun.2024 om 14:20 schreef olcott:

On 6/3/2024 4:42 AM, Ben Bacarisse wrote:

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

 

None of their /simulations by H/ reach their final state.  Obviously
there's a huge distinction between the abstract concept of a
computation/halting, and a partial simulation of that computation by
some other program, and I'm surprised anyone (not you specifically)
tolerates confusion on that point.
>
Suppose P(I) is some computation that halts after 13422 steps.
Clearly a partial simulation of P(I) by H could be abandoned
("aborted") after 8333 steps.  So the /partial simulation by H/ "does
not halt", but the computation P(I) of course halts.
>
I'm not trying to suggest that considering the "halting" behaviour of
a partial simulation by a specific program is a /useful/ thing to be
looking at, but none the less that is what PO is doing...
>

The meaning of these words prove that I am correct about how partial
simulations correctly determine the halt status of their non-halting
inputs.
<Professor Sipser agreed>
</Professor Sipser agreed>

>
You completely missed the point. The simulator absolutely can keep
track of repeating states; it just can't halt if its input doesn't,

>
You don't seem to know the first thing about deciders, in that they must
always halt.

You don't seem to know the first thing about simulators, in that they can
never abort.

I am apparently the sole inventor of a simulating halt decider.
A simulator correctly simulates and typically does not halt
when its input does not halt. A halt decider must always halt.
When we combine these two terms together then we get a simulator
that always halts.
<Professor Sipser agreed>
   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.
</Professor Sipser agreed>
Ben Bacarisse checked Professor Sipser really did agree to those
verbatim words, he did not agree or disagree with any other words
in any of his communications with me.

So why can't reach past line 4 if H halts and returns from infinite
recursion?
 

Anyone with sufficient expertise in the semantics of either C
or x86 language or both already knows why and everyone else does
not have the required prerequisite knowledge to understand why.
*Here is the complete proof all over again all in one place*
https://liarparadox.org/DD_correctly_simulated_by_HH_is_Proven.pdf

because that is a difference in behaviour which it is not allowed to
have.

 

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