Deutsch   English   Français   Italiano  
<v3f9ha$2qh0t$1@dont-email.me>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!feeds.phibee-telecom.net!2.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: olcott <polcott333@gmail.com>
Newsgroups: comp.theory,sci.logic
Subject: Re: Two dozen people were simply wrong --- Try to prove otherwise ---
 pinned down
Date: Sat, 1 Jun 2024 09:00:08 -0500
Organization: A noiseless patient Spider
Lines: 166
Message-ID: <v3f9ha$2qh0t$1@dont-email.me>
References: <v3501h$lpnh$1@dont-email.me> <v37bpa$15n0b$1@dont-email.me>
 <v37i9p$lls$1@news.muc.de> <87y17smqnq.fsf@bsb.me.uk>
 <v37sap$18mfo$1@dont-email.me> <v38eq4$2foi0$1@i2pn2.org>
 <v38fe0$1bndb$1@dont-email.me> <v38g31$2foi0$11@i2pn2.org>
 <v38gi5$1bndb$3@dont-email.me> <v38ici$2fohv$2@i2pn2.org>
 <v38j17$1c8ir$2@dont-email.me> <v38jgo$2foi0$14@i2pn2.org>
 <v38jv9$1c8ir$4@dont-email.me> <v39agi$1jiql$1@dont-email.me>
 <v39v3h$1mtd9$5@dont-email.me> <v3b9kj$2im02$1@i2pn2.org>
 <v3bale$222n5$1@dont-email.me> <v3bbs2$2im01$1@i2pn2.org>
 <v3bcre$22a8n$1@dont-email.me> <v3bduk$2im01$2@i2pn2.org>
 <v3bedb$22f8h$1@dont-email.me> <v3bfbm$2im01$3@i2pn2.org>
 <v3bg39$22o6m$1@dont-email.me> <v3cbhu$2k3ld$1@i2pn2.org>
 <v3clo2$28p7n$1@dont-email.me> <v3dft1$2lfup$1@i2pn2.org>
 <v3dhob$2dio8$1@dont-email.me> <v3dk0d$2lfup$2@i2pn2.org>
 <v3dkf2$2e2po$1@dont-email.me> <v3dmnc$2lfup$3@i2pn2.org>
 <v3do66$2ejq2$1@dont-email.me>
 <MPG.40c4fbcb474992459896fd@reader.eternal-september.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 01 Jun 2024 16:00:11 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="5617c6a52e82e3edb2307f1199229213";
	logging-data="2966557"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX199gEns5EJTEIPOQapcES/Q"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:UWyM2dP792TkwcgSfgJ/f0xC9ak=
Content-Language: en-US
In-Reply-To: <MPG.40c4fbcb474992459896fd@reader.eternal-september.org>
Bytes: 8543

On 6/1/2024 3:36 AM, Wasell wrote:
> On Fri, 31 May 2024 18:57:57 -0500, in article <v3do66$2ejq2$1@dont-email.me>,
> olcott wrote:
>>
>> On 5/31/2024 6:33 PM, Richard Damon wrote:
> 
> [...]
> 
>>> Never said it could. But haven't looked hard enough to be willing to say
>>> it can't, but then, who cares, it doesn't say a thing about the real
>>> halting problem, since H's simulation isn't "correct" by a definition
>>> that relates simulation to non-halting behavior,
>>
>> "...the Turing machine will halt whenever it enters a final state."
>> Linz(1990:234)
>>
>> *If DD correctly simulated by HH can't possibly reach its own*
>> *final state then DD correctly simulated by HH is non-halting*
> 
> You keep using this quote as if it means that the /only/ way a TM
> can halt, is if it enters a final state. You never quote the
> context:
> 
>    "A Turing machine is said to halt whenever it reaches a
>    configuration for which \delta is not defined; this is possible
>    because \delta is a partial function. In fact, we will assume that
>    no transitions are defined for any final state, so the Turing
>    machine will halt whenever it enters a final state."
>      (p. 227 in my copy)
> 
> This means that a TM /will/ halt if it enters a final state, but it
> can also halt in other states. This interpretation is confirmed in
> other places in Linz:
> 
>    "The machine can halt in a nonfinal state or it can enter an
>    infinite loop and never halt. [...] we halt in a nonfinal state.
>    [...] the machine will halt in the nonfinal state q_0 , since
>    \delta(q_0,1) is undefined." (p. 232)
> 
>    "[...] the computation will halt in a nonfinal state." (p. 233)
> 
>    "Other input not in the language will also lead to a nonfinal
>    halting state" (p. 234)
> 
>    "[...] that will halt in a nonfinal state q_n if x < y." (p. 237)
> 
>    etc, etc.
> 
> Can I expect you to never use this deceptive out-of-context quote
> ever again?

DD correctly simulated by HH remains stuck in recursive simulation
all the time it is simulated even when an infinite number of steps
are simulated.

According to the words that you quoted it would be more accurate to
provide a longer definition. I will attempt that yet this may be too
difficult for my short-attention space reviewers.

"δ is the transition function" (Linz:1990:233) ...
"A Turing machine is said to halt whenever it reaches a
configuration for which δ is not defined; (Linz:1990:234)

DD correctly simulated by HH never reaches any point where δ
is not defined. My target audience of software engineers may be
dumbfounded by that. Software engineers will not allow false
assumptions to override verified facts.

DD correctly simulated by HH has behavior that is isomorphic
to Infinite_Recursion simulated by HH.

void Infinite_Recursion(u32 N)
{
   Infinite_Recursion(N);
}

Since the idea of a simulating halt decider is brand new with me
there is not any preexisting literature on simulating halt deciders.

The above proves that we cannot construe that stopping running
because of stopping being simulated is any kind of halting behavior.



Introduction to the Theory of Computation, by Michael Sipser
https://www.amazon.com/Introduction-Theory-Computation-Michael-Sipser/dp/113318779X/

On 10/13/2022 11:29:23 AM
MIT Professor Michael Sipser agreed that these verbatim words are correct
(He has neither reviewed nor agreed to anything else in this paper)

<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.
</Sipser agreed>

Because my reviewers tend to be much more interested in rebuttal (even
when this rebuttal directly contradicts verified facts) I must make
my words unequivocal and clear. Even when make my words unequivocally
prove my point with verified facts they still disagree.

After three years of discussion with Richard on the one point that DD
correctly simulated by HH never reaches its own final state he finally
admitted that he just doesn't.

I had to confront him with the x86 machine code of DD to get him to
concede that he doesn't know. This took three years.

Prior to confronting him with this machine code he (and two dozen
other people) persistently disagreed with what a correct simulation
is. Now that the machine code is presented no one can get away with
saying that DD correctly simulated by HH can possibly reach its own
machine address of 00001c47 (or any other point where δ is undefined).

typedef int (*ptr)();  // ptr is pointer to int function in C
00       int HH(ptr p, ptr i);
01       int DD(ptr p)
02       {
03         int Halt_Status = HH(p, p);
04         if (Halt_Status)
05           HERE: goto HERE;
06         return Halt_Status;
07       }

It is clear that DD correctly simulated by HH using an x86 emulator
cannot possibly reach past its own line 03 for 1 to ∞ steps of correct
simulation.

Four experts in the C language concurred with my own expert assessment.
It really is dead obvious to anyone with sufficient knowledge of the C
programming language thus all those that disagree could only be playing
trollish head games.

Finally when confronted with the x86 machine language of DD where lying
would look ridiculously foolish Richard backed down and admitted that
he just doesn't know.

_DD()
[00001c22] 55         push ebp
[00001c23] 8bec       mov ebp,esp
[00001c25] 51         push ecx
[00001c26] 8b4508     mov eax,[ebp+08]
[00001c29] 50         push eax        ; push DD 1c22
[00001c2a] 8b4d08     mov ecx,[ebp+08]
[00001c2d] 51         push ecx        ; push DD 1c22
[00001c2e] e80ff7ffff call 00001342   ; call HH
[00001c33] 83c408     add esp,+08
[00001c36] 8945fc     mov [ebp-04],eax
[00001c39] 837dfc00   cmp dword [ebp-04],+00
[00001c3d] 7402       jz 00001c41
[00001c3f] ebfe       jmp 00001c3f
[00001c41] 8b45fc     mov eax,[ebp-04]
[00001c44] 8be5       mov esp,ebp
[00001c46] 5d         pop ebp
[00001c47] c3         ret
Size in bytes:(0038) [00001c47]


========== REMAINDER OF ARTICLE TRUNCATED ==========