Path: news.eternal-september.org!eternal-september.org!feeder3.eternal-september.org!news.quux.org!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory
Subject: Re: Incorrect requirements --- Computing the mapping from the input
 to HHH(DD)
Date: Fri, 9 May 2025 22:20:28 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <fd7bd4fb8797300a4a3982bbafd7f9decaee2c77@i2pn2.org>
References: <vv97ft$3fg66$1@dont-email.me> <vvgqgl$15i5e$27@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> <vvm69v$34ivd$1@dont-email.me>
 <vvm7o3$34mm4$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 02:35:37 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="3883114"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
Content-Language: en-US
In-Reply-To: <vvm7o3$34mm4$1@dont-email.me>
X-Spam-Checker-Version: SpamAssassin 4.0.0

On 5/9/25 8:48 PM, olcott wrote:
> On 5/9/2025 7:23 PM, Mike Terry wrote:
>> On 09/05/2025 03:23, Keith Thompson wrote:
>>> Richard Damon <richard@damon-family.org> writes:
>>>> On 5/8/25 7:53 PM, olcott wrote:
>>> [...]
>>>>> void DDD()
>>>>> {
>>>>>     HHH(DDD);
>>>>>     return;
>>>>> }
>>>>> We don't need to look at any of my code for me
>>>>> to totally prove my point. For example when
>>>>> the above DDD is correctly simulated by HHH
>>>>> this simulated DDD cannot possibly reach its own
>>>>> "return" instruction.
>>>>
>>>> And thus not correctly simulatd.
>>>>
>>>> Sorry, there is no "OS Exemption" to correct simulaiton;.
>>>
>>> Perhaps I've missed something.  I don't see anything in the above that
>>> implies that HHH does not correctly simulate DDD.  Richard, you've read
>>> far more of olcott's posts than I have, so perhaps you can clarify.
>>>
>>> If we assume that HHH correctly simulates DDD, then the above code is
>>> equivalent to:
>>>
>>>      void DDD()
>>>      {
>>>        DDD();
>>>        return;
>>>      }
>>>
>>> which is a trivial case of infinite recursion.  As far as I can tell,
>>> assuming that DDD() is actually called at some point, neither the
>>> outer execution of DDD nor the nested (simulated) execution of DDD
>>> can reach the return statement.  Infinite recursion might either
>>> cause a stack overflow and a probable program crash, or an unending
>>> loop if the compiler implements tail call optimization.
>>>
>>> I see no contradiction, just an uninteresting case of infinite
>>> recursion, something that's well understood by anyone with a
>>> reasonable level of programming experience.  (And it has nothing to
>>> do with the halting problem as far as I can tell, though of course
>>> olcott has discussed the halting problem elsewhere.)
>>>
>>> Richard, what am I missing?
>>>
>>
>> Depends on what you've picked up on.
>>
>> Do you get that HHH's simulation is a /partial/ simulation?  HHH is free 
> 
> That was not in the specification that he responded to.
> Thus within this specification DDD correctly simulated
> by HHH cannot possibly reach its final halt state in an
> infinite number of steps.

Excpet that no HHH CAN correct emulate the DDD that you give it, as the 
input for DDD just isn't a complete program, and thus the attempt to 
simulate hits a category error of using undefined (to the input) memory.

> 
> If an infinite number steps steps is insufficient
> then how can less an infinite steps possibly help?

But you HHH can't do an infinite number of steps, as by your definition 
of the input, it can't go beyond the call to HHH, as the code to emulate 
wasn't given.

> 
>> to simulate a few x86 instructions of DDD, and then simply abandon the 
>> simulation and return.  Since such a simulation is obviously NOT 
>> equivalent to a direct call to DDD, and above you argue that it is, 
>> I'd say you've missed that.
>>
>> The other thing to be aware of is that use of terminology "simulation" 
>> varies considerably between posters!  This in turn affects what 
>> different posters consider a "correct" simulation.
>>
> 
> <snip>
> 
>>
>> PO is a (b)(c) guy.  Since his HHH (more or less) simulates individual 
>> instructions correctly, PO claims HHH "correctly" simulates DDD.  
>> Others who are in (a) or (d) camps would say that HHH does not 
>> correctly simulate DDD, because either HHH performs a /partial/ 
>> simulation [for them an error in its own right] or because HHH decides 
>> nothalt when in fact PO's DDD halts.
>>
> 
> _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]
> 
> Try to show how DDD simulated by HHH according to the
> rules of the x86 language reaches its own "ret"
> instruction final state and you already know that
> you will fail. You dodge this question so that
> you can remain disagreeable.
> 
>> Terminology usage is not a right/wrong issue, but the different 
>> possibilities maximise misunderstandings if not resolved.  E.g. as I 
>> said PO's simulations are nearly always taken to be partial.  Richard 
>> D. knows that, but as he is in (b) camp he points out that PO is lying 
>> every time he says "HHH correctly simulates DDD".  PO then says RD is 
>> playing head games and challenges RD to point out an error, and so it 
>> goes on for hundreds of posts.  To be fair, PO should be well aware 
>> that RD is in camp (a), but does nothing to resolve the terminology 
>> issue, so both posters get what they deserve!
>>
> 
> I resolved the terminology issue long ago and
> you and everyone else ignores this so that you
> can remain disagreeable.
> 
> When one or more instructions of DDD are emulated
> by HHH according to the rules of the x86 language
> this emulated DDD cannot possibly reach its own
> final halt state because it calls HHH(DDD) in
> recursive emulation.
> 
>> FTR I am in the (b)(c) camp...  I could explain why I think that's 
>> more logical, but that's going OT I think.
>>
>> Other posters have suggested that what you're missing is some 
>> variation of "once you answer PO's current question (about whether the 
>> simulation by HHH progresses as far as DDD's return) PO will go on to 
>> do something else wrong". Well, of course he will, but that's hardly 
>> something you're missing if he's not done it yet!  :)  I'd also say 
>> it's no reason not to answer PO's question honestly, acknowledging 
>> that he is talking about /partial/ simulations...  The time to 
>> challenge future mistakes he will go on to make, is when he makes them.
>>
>>
>> Mike.
>>
> 
>