Deutsch   English   Français   Italiano  
<67e5d0e921d2806ed5b30ed4432ea124d9e5e28f@i2pn2.org>

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

Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory,sci.logic,comp.ai.philosophy
Subject: Re: Sequence of sequence, selection and iteration matters
Date: Sun, 7 Jul 2024 13:28:46 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <67e5d0e921d2806ed5b30ed4432ea124d9e5e28f@i2pn2.org>
References: <v6e7va$c4sv$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 7 Jul 2024 17:28:47 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="2480388"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
X-Spam-Checker-Version: SpamAssassin 4.0.0
In-Reply-To: <v6e7va$c4sv$1@dont-email.me>
Content-Language: en-US
Bytes: 3950
Lines: 65

On 7/7/24 10:16 AM, olcott wrote:
> _DDD()
> [00002172] 55               push ebp      ; housekeeping
> [00002173] 8bec             mov ebp,esp   ; housekeeping
> [00002175] 6872210000       push 00002172 ; push DDD
> [0000217a] e853f4ffff       call 000015d2 ; call HHH(DDD)
> [0000217f] 83c404           add esp,+04
> [00002182] 5d               pop ebp
> [00002183] c3               ret
> Size in bytes:(0018) [00002183]
> 
> Sufficient knowledge of the x86 language conclusively proves
> that the call from DDD correctly emulated by HHH to HHH(DDD)
> cannot possibly return for any pure function HHH.
No, you don;t understand the difference between the partial simulation 
of DDD done by HHH from the actual behavior of DDD.

Since HHH is a pure function, then if HHH returns to main, it will also 
return to DDD, so HHH can NOT POSSIBLE correctly determine that DDD will 
not halt if HHH eventually will return an answer. PERIOD.

YOU LOGIC IS JUST INCORRECT.


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

Remember, and you keep on ignoring this fact, to the point it has become 
a LIE, that Professor Sipser, like most people in the field define that 
a "Correct Simulation" is a simulation is a simulaition that exactly 
reproduces the behavior of the program represented by the input, and 
thus, is a simulator that never stops simulating until it reaches a 
final state.

Your H neither does this, nor correctly predict the behavior of such a 
simulation of its input, it can not use the second paragraph.

> 
> (a) HHH determines that it must abort DDD
> (b) HHH reports that DDD will not stop unless aborted
> (c) HHH aborts its simulation of DDD
> 
> If HHH reported that it did not need to abort DDD before HHH
> aborts DDD this is like you need groceries and report that
> you do not need groceries before you got more groceries: a lie.
> 

But HHH lies to itself (which means you as the programmer LIED), as DDD 
when actualy CORRECTLY SIMULATED shows that DDD will call HHH(DDD) and 
then that HHH will INCORREECTLY determine that it must abort its 
simulation of DD (which doesn't affect the DDD that is calling it) then 
it return to DDD the INCORRECT ANSWER that DDD doesn't halt, and then 
DDD halts.

Thus step (a) never occured, at least for the grounds required. HHH just 
met the programmed conditions which are a false positive for non-halting.

Thus, this, like most of your logic, is based on LIES.