Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD)

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