Path: ...!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 --- canonical
Date: Sun, 2 Jun 2024 13:39:34 -0500
Organization: A noiseless patient Spider
Lines: 148
Message-ID: <v3ie96$3f571$5@dont-email.me>
References: <v3501h$lpnh$1@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>
 <v3f9ha$2qh0t$1@dont-email.me> <v3ffpc$2n53n$3@i2pn2.org>
 <v3fgfb$2riae$2@dont-email.me> <v3fh1a$2n53o$5@i2pn2.org>
 <v3fhkr$2rsbs$2@dont-email.me> <v3fig4$2n53n$6@i2pn2.org>
 <v3fj8h$2rsbs$6@dont-email.me> <v3g0bg$2n53n$18@i2pn2.org>
 <v3g0n2$2v3lp$2@dont-email.me> <v3g329$2n53n$21@i2pn2.org>
 <v3g3np$2vk55$1@dont-email.me> <v3hdoq$39nv5$3@dont-email.me>
 <v3i0m9$3cpu7$3@dont-email.me> <v3iddo$3f51j$4@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 02 Jun 2024 20:39:35 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="3e1a2626012d6c432c11247ed1bf0353";
	logging-data="3642593"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+J5SraKoxE5J1w8vTS7x0E"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:BD5mLvhybVcNQHOi3Eq+qTVAv3Q=
In-Reply-To: <v3iddo$3f51j$4@dont-email.me>
Content-Language: en-US
Bytes: 7858

On 6/2/2024 1:24 PM, Fred. Zwarts wrote:
> Op 02.jun.2024 om 16:47 schreef olcott:
>> On 6/2/2024 4:24 AM, Fred. Zwarts wrote:
>>> Op 01.jun.2024 om 23:27 schreef olcott:
>>>> On 6/1/2024 4:15 PM, Richard Damon wrote:
>>>>> On 6/1/24 4:35 PM, olcott wrote:
>>>>>> On 6/1/2024 3:29 PM, Richard Damon wrote:
>>>>>>> On 6/1/24 12:46 PM, olcott wrote:
>>>>>>>> On 6/1/2024 11:33 AM, Richard Damon wrote:
>>>>>>>>> On 6/1/24 12:18 PM, olcott wrote:
>>>>>>>>>> On 6/1/2024 11:08 AM, Richard Damon wrote:
>>>>>>>>>>> On 6/1/24 11:58 AM, olcott wrote:
>>>>>>>>>>>> On 6/1/2024 10:46 AM, Richard Damon wrote:
>>>>>>>>>>>>> On 6/1/24 10:00 AM, olcott wrote: >> 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.
>>>>>>>>>>>>>
>>>>>>>>>>>>> So, are you admitting that HH just gets stuck and doesn't 
>>>>>>>>>>>>> answer when asked HH(DD,DD)?
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Every DD correctly simulated by any HH remains stuck in 
>>>>>>>>>>>> recursive simulation for 1 to ∞ steps of correct simulation.
>>>>>>>>>>>
>>>>>>>>>>> So? Since you definition of "Correct Simulation" is 
>>>>>>>>>>> non-canonical, that doesn't mean anything.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> *When the "canonical" definition tries to get away with 
>>>>>>>>>> refuting this*
>>>>>>>>>>
>>>>>>>>>> DD correctly emulated by HH with an x86 emulator cannot possibly
>>>>>>>>>> reach past its own machine instruction [00001c2e] in any finite
>>>>>>>>>> number of steps of correct emulation.
>>>>>>>>>
>>>>>>>>> No, it doesn't "Refute" that, 
>>>>>>>>
>>>>>>>> *Then what I said stands unrefuted*
>>>>>>>> *Then what I said stands unrefuted*
>>>>>>>> *Then what I said stands unrefuted*
>>>>>>>
>>>>>>> And unproven, and still meaningless.
>>>>>>>
>>>>>>>>
>>>>>>>> *We can't move on to any other point until*
>>>>>>>> (a) You acknowledge that my above statement about the behavior 
>>>>>>>> of the
>>>>>>>> x86 machine code of DD is irrefutable and applies to the C 
>>>>>>>> source code version of DD and applies to the Linz proof.
>>>>>>>>
>>>>>>>> (b) You correctly refute what I said above about the behavior of 
>>>>>>>> the
>>>>>>>> x86 machine code of DD.
>>>>>>>
>>>>>>> But why do we care about the fact that all your HH that answer 
>>>>>>> just gave up on their simulation before the actual canonically 
>>>>>>> correct simulation would have reached a final state, 
>>>>>> It seems to me (and I may be wrong you may be confused)
>>>>>> That we cannot move on to any other point simply because
>>>>>> you are simply too freaking dishonest.
>>>>>>
>>>>>> You use moving on to other points to endlessly avoid any
>>>>>> closure on any point.
>>>>>>
>>>>>
>>>>>
>>>>> We can not move on, because you want to base your arguement on 
>>>>> falsehoods.
>>>>>
>>>>
>>>> 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       }
>>>> 08
>>>> 09       int main()
>>>> 10       {
>>>> 11         HH(DD,DD);
>>>> 12         return 0;
>>>> 13       }
>>>>
>>>> Every DD correctly simulated by any HH of the infinite set of HH/DD
>>>> pairs that match the above template never reaches past its own 
>>>> simulated
>>>> line 03 in 1 to ∞ steps of correct simulation of DD by HH.
>>>
>>> Similarly:
>>> Every HH correctly simulated by itself of the infinite set of HH/DD
>>> pairs that match the above template never reaches past its own simulated
>>> return in 1 to ∞ steps of correct simulation of HH by HH.
>>>
>>
>> DD correctly simulated by HH includes HH correctly simulating itself
>> simulating DD as an intrinsic aspect of DD correctly simulated by HH. 
>> > *It is only the outermost directly executed HH that is required to 
>> halt*
> 
> It might be possible to use the following criteria to see whether a 
> program halts:
> a) The direct executed program halts.
> b) The simulation of the program by HH reaches its final state.
> 
> If you choose a then both DD and HH halt.
> If you choose b then neither DD, nor HH halt.
> 
> Choosing different criteria for different functions only because you 
> need it in your claim would be dishonest.
> 
>>
>> When an input DD gets instances of itself HH stuck in recursive
>> simulation this input is rejected as non-halting.
> 
> Similarly, when the partial input HH (part of DD) gets instances of 
> itself HH stuck in recursive simulation this partial input is rejected 
> as non-halting.
> 
> 

*I always use this same criteria* People here verified that
I really did contact professor Sipser.

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 this verbatim paragraph is
correct (He has neither reviewed nor agreed to anything else in this paper)

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

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