Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: olcott <polcott333@gmail.com>
Newsgroups: comp.theory
Subject: Re: Incorrect requirements --- Computing the mapping from the input
 to HHH(DD)
Date: Fri, 9 May 2025 18:43:55 -0500
Organization: A noiseless patient Spider
Lines: 154
Message-ID: <vvm3vr$340f4$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>
 <vvjcge$27753$2@dont-email.me> <87a57mek8r.fsf@nosuchdomain.example.com>
 <vvjgh7$28g5i$4@dont-email.me> <87seled0zy.fsf@nosuchdomain.example.com>
 <vvjobj$28g5i$11@dont-email.me> <87zffmbeyt.fsf@nosuchdomain.example.com>
 <vvm1ih$33907$1@dont-email.me>
 <b88ec9161c701a2d7a4dfd1954aaeb221b427e45@i2pn2.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 10 May 2025 01:43:56 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="7be348abb5bc2ec0a70724586a3ca680";
	logging-data="3277284"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+N3jiZalIxop/AU6xxPkg/"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:9SDCpmkTPG5F9Z8Ur/iyH0NMphE=
Content-Language: en-US
X-Antivirus: Norton (VPS 250509-6, 5/9/2025), Outbound message
In-Reply-To: <b88ec9161c701a2d7a4dfd1954aaeb221b427e45@i2pn2.org>
X-Antivirus-Status: Clean
Bytes: 8296

On 5/9/2025 6:36 PM, Richard Damon wrote:
> On 5/9/25 7:02 PM, olcott wrote:
>> On 5/8/2025 11:11 PM, Keith Thompson wrote:
>>> olcott <polcott333@gmail.com> writes:
>>>> On 5/8/2025 8:30 PM, Keith Thompson wrote:
>>>>> olcott <polcott333@gmail.com> writes:
>>>>>> On 5/8/2025 6:49 PM, Keith Thompson wrote:
>>>>>>> olcott <polcott333@gmail.com> writes:
>>>>>>> [...]
>>>>>>>> void DDD()
>>>>>>>> {
>>>>>>>>      HHH(DDD);
>>>>>>>>      return;
>>>>>>>> }
>>>>>>>>
>>>>>>>> If you are a competent C programmer then you
>>>>>>>> know that DDD correctly simulated by HHH cannot
>>>>>>>> possibly each its own "return" instruction.
>>>>>>> "cannot possibly each"?
>>>>>>> I am a competent C programmer (and I don't believe you can make
>>>>>>> the same claim).  I don't know what HHH is.  The name "HHH" tells
>>>>>>> me nothing about what it's supposed to do.  Without knowing what
>>>>>>> HHH is, I can't say much about your code (or is it pseudo-code?).
>>>>>>>
>>>>>>
>>>>>> For the purpose of this discussion HHH is exactly
>>>>>> what I said it is. It correctly simulates DDD.
>>>>> Does HHH correctly simulate DDD *and do nothing else*?
>>>>> Does HHH correctly simulate *every* function whose address is passed
>>>>> to it?  Must the passed function be one that takes no arguments
>>>>> and does not return a value?
>>>>> Can HHH just *call* the function whose address is passed to it?
>>>>> If it's a correct simulation, there should be no difference between
>>>>> calling the function and "correctly simulating" it.
>>>>> My knowledge of C tells me nothing about *how* HHH might simulate
>>>>> DDD.
>>>>
>>>> HHH can only simulate a function that take no arguments
>>>> and has no return value. HHH also simulates the entire
>>>> chain of functions that this function calls. These can
>>>> take arguments or not and have return values or not.
>>>>
>>>> Thus HHH ends up simulating itself (and everything
>>>> that HHH calls) simulating DDD in an infinite
>>>> sequence of recursive emulation until OOM error.
>>>>
>>>>>> We need not know anything else about HHH to
>>>>>> know that DDD correctly simulated by HHH cannot
>>>>>> possibly REACH its own "return" instruction.
>>>>> 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;
>>>>>       }
>>>>
>>>> Exactly. None of these people on comp.theory could
>>>> get that even after three years.
>>>
>>> I find that difficult to believe.
>>>
>>>>> Then the return statement (which is unnecessary anyway) will never be
>>>>> reached.
>>>>
>>>> It is only there to mark a final halt state.
>>>
>>> The closing "}" does that equally well.
>>>
>>>>> 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.
>>>>>
>>>>
>>>> Yes you totally have this correctly.
>>>> None of the dozens of comp.theory people could
>>>> ever achieve that level of understanding even
>>>> after three years. That is why I needed to post
>>>> on comp.lang.c.
>>>
>>> I'll note that I've posted in comp.theory, not in comp.lang.c.
>>> I never see anything you post in comp.lang.c.
>>>
>>>>> This conclusion relies on my understanding of what you've said about
>>>>> your code, which I consider to be unreliable.
>>>>
>>>> I am not even talking about my code. I am
>>>> talking about the purely hypothetical code
>>>> that you just agreed to.
>>>
>>> Do not overestimate what I've agreed to.  I must still consider the
>>> possibility that I've been led into a logical trap of some sort,
>>> and that I've missed some subtle flaw.
>>>
>>>>> No doubt you believe that there is some significance to the
>>>>> apparent fact that the return statement will never be reached,
>>>>> assuming that's a correct and relevant conclusion.  I don't know
>>>>> what that significance might be.
>>>>
>>>> I will tell you that later after you understand
>>>> some prerequisite ideas first.
>>>>
>>>> int DD()
>>>> {
>>>>    int Halt_Status = HHH(DD);
>>>>    if (Halt_Status)
>>>>      HERE: goto HERE;
>>>>    return Halt_Status;
>>>> }
>>>
>>> So now HHH returns an int result, and you store that result
>>> in a variable named "Halt_Status".  You haven't said here what
>>> the meaning of that result might be, and I decline to make any
>>> assumptions based on what you've called it.  You could rename
>>> "Halt_Status" to "Foo" and have effectively identical code.
>>>
>>> Previously DDD would "correctly simulate" the function whose address is
>>> passed to it.  Now it does that and returns an int result.
>>>
>>> If you want to say anything about the meaning of the result returned
>>> by HHH, feel free to say it.
>>>
>>>> The same thing that applied to DDD equally
>>>> applies to the more complicated DD.
>>>>
>>>> When 1 or more instructions of DD are correctly
>>>> simulated by HHH the correctly simulated DD
>>>> cannot possibly get past its call to HHH(DD).
>>>> Thus DD also never reaches its "return" instruction.
>>>
>>> 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.
>>>
>>
>> Correctly emulating one or more instructions <is>
>> the correct emulation of 1 or more instructions
>> of DD. This is a truism.
> 
> No, Correctly Emulating *ALL* of the instructions is the definition of 
> correct emulation.
> 

In other words it is waaayyy over your head that
when correctly emulating an infinite number of
instructions of DD is not enough for DD correctly
emulated by HHH to reach its own final halt
state that fewer than infinity might be enough?


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