Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: dbush <dbush.mobile@gmail.com>
Newsgroups: comp.theory
Subject: Re: Incorrect requirements --- Computing the mapping from the input
 to HHH(DD)
Date: Fri, 9 May 2025 18:31:45 -0400
Organization: A noiseless patient Spider
Lines: 118
Message-ID: <vvlvog$2pnkn$1@dont-email.me>
References: <vv97ft$3fg66$1@dont-email.me> <vvgr22$1ag3a$2@dont-email.me>
 <vvgt36$1auqp$2@dont-email.me> <vvgtbe$1b0li$1@dont-email.me>
 <vvguot$1auqp$3@dont-email.me> <vvh0t2$1b939$1@dont-email.me>
 <vvhap5$1hp80$1@dont-email.me> <vvhf20$1ihs9$1@dont-email.me>
 <vvhfnd$1hvei$3@dont-email.me> <vvil99$1ugd5$1@dont-email.me>
 <vvinvp$1vglb$1@dont-email.me> <vviv75$222r6$1@dont-email.me>
 <vvj1fp$22a62$1@dont-email.me> <vvj2j6$23gk7$1@dont-email.me>
 <as9TP.251456$lZjd.93653@fx05.ams4> <87msbmeo3b.fsf@nosuchdomain.example.com>
 <vvjc9b$27753$1@dont-email.me> <87ecwyekg2.fsf@nosuchdomain.example.com>
 <vvjg6a$28g5i$3@dont-email.me>
 <d577d485d0f5dfab26315f54f91eb84f25eecc40@i2pn2.org>
 <87bjs2cyj6.fsf@nosuchdomain.example.com> <vvkffn$2m36t$4@dont-email.me>
 <vvl84g$2rl0l$10@dont-email.me>
 <c0b0db5de5c7f7ccb24b06d44108deb41fbde8dc@i2pn2.org>
 <vvlm2k$30idv$1@dont-email.me> <vvlnad$2uvnf$5@dont-email.me>
 <vvlnpj$30vce$1@dont-email.me> <vvlsp5$31vqc$1@dont-email.me>
 <vvlv04$32kt3$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 10 May 2025 00:31:44 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="bd74c3991261d909052bf71d3a970463";
	logging-data="2940567"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+eIMILSDOg824lLg/jLy17"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:qwdkAKzMvwhY3/z6fUEksX3U4UY=
Content-Language: en-US
In-Reply-To: <vvlv04$32kt3$1@dont-email.me>

On 5/9/2025 6:18 PM, olcott wrote:
> On 5/9/2025 4:40 PM, Richard Heathfield wrote:
>> On 09/05/2025 21:15, olcott wrote:
>>> On 5/9/2025 3:07 PM, Richard Heathfield wrote:
>>>> On 09/05/2025 20:46, olcott wrote:
>>>>> We have not begun to get into any of those points.
>>>>> We are only asking can DDD correctly simulated
>>>>> by any HHH that can exist ever reach its own
>>>>> "return" instruction.
>>>>
>>>> DDD can't be correctly simulated by itself (which is effectively 
>>>> what you're trying to do when you fire up the simulation from inside 
>>>> DDD).
>>>>
>>>
>>> How the Hell did you twist my words to say that?
>>
>> I haven't touched your words. What I have done is to observe that 
>> DDD's /only/ action is to call a simulator. Since DDD isn't itself a 
>> simulator, there is nothing to simulate except a call to a simulator.
>>
>> It's recursion without a base case - a rookie error.
>>
>> HHH cannot successfully complete its task, because it never regains 
>> control after the first recursion. To return, it must abort the 
>> simulation, which means the simulation fails.
>>
>>>
>>> void DDD()
>>> {
>>>    HHH(DDD);
>>>    return;
>>> }
>>>
>>> When 1 or more statements of DDD are correctly
>>> simulated by HHH then this correctly simulated
>>> DDD cannot possibly reach its own “return statement”.
>>
>> On what grounds can you persuade an extraordinarily sceptical 
>> readership that HHH 'correctly simulated' DDD?
>>
> 
> Any competent C programmer can see that
> the call from DDD to HHH(DDD) (its own simulator)
> is equivalent to infinite recursion.
> 
> On 5/8/2025 8:30 PM, Keith Thompson wrote:
>  > Assuming that HHH(DDD) "correctly simulates" DDD, and assuming it
>  > does nothing else, your code would be equivalent to this:
>  >
>  >      void DDD(void) {
>  >          DDD();
>  >          return;
>  >      }
>  >
>  > Then the return statement (which is unnecessary anyway) will never be
>  > reached.  In practice, the program will likely crash due to a stack
>  > overflow, unless the compiler implements tail-call optimization, in
>  > which case the program might just run forever -- which also means the
>  > unnecessary return statement will never be reached.
> 
> 

But if it aborts it's not a correct simulation:

On 5/9/2025 12:11 AM, Keith Thompson wrote:
 > Now you're talking about simulating "1 or more instructions"
 > of DD.  I thought that HHH was supposed to "accurately simulate"
 > the function whose argument is passed to it.  Emulating just "1 or
 > more instructions" is not accurate simulation.

Which you have admitted on the record:


On 5/5/2025 8:24 AM, dbush wrote:
 > On 5/4/2025 11:03 PM, dbush wrote:
 >> On 5/4/2025 10:05 PM, olcott wrote:
 >>> On 5/4/2025 7:23 PM, Richard Damon wrote:
 >>>> But HHH doesn't correct emulated DD by those rules, as those rules
 >>>> do not allow HHH to stop its emulation,
 >>>
 >>> Sure they do you freaking moron...
 >>
 >> Then show where in the Intel instruction manual that the execution of
 >> any instruction other than a HLT is allowed to stop instead of
 >> executing the next instruction.
 >>
 >> Failure to do so in your next reply, or within one hour of your next
 >> post on this newsgroup, will be taken as you official on-the-record
 >> admission that there is no such allowance and that HHH does NOT
 >> correctly simulate DD.
 >
 > Let the record show that Peter Olcott made the following post in this
 > newsgroup after the above message:
 >
 > On 5/4/2025 11:04 PM, olcott wrote:
 >  > D *WOULD NEVER STOP RUNNING UNLESS*
 >  > indicates that professor Sipser was agreeing
 >  > to hypotheticals AS *NOT CHANGING THE INPUT*
 >  >
 >  > You are taking
 >  > *WOULD NEVER STOP RUNNING UNLESS*
 >  > to mean *NEVER STOPS RUNNING* that is incorrect.
 >
 > And has made no attempt after over 9 hours to show where in the Intel
 > instruction manual that execution is allowed to stop after any
 > instruction other than HLT.
 >
 > Therefore, as per the above criteria:
 >
 > LET THE RECORD SHOW
 >
 > That Peter Olcott
 >
 > Has *officially* admitted
 >
 > That DD is NOT correctly simulated by HHH