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: Thu, 8 May 2025 23:56:53 -0500
Organization: A noiseless patient Spider
Lines: 85
Message-ID: <vvk1ul$2ibbd$2@dont-email.me>
References: <vv97ft$3fg66$1@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> <vvjr60$2gfbv$1@dont-email.me>
 <87o6w2begg.fsf@nosuchdomain.example.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 09 May 2025 06:56:54 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="b8226b0a928845ead4a9adb4b3b34c7d";
	logging-data="2698605"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18Nj7FlVOhMdlNVLo9b1QdQ"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:Mv4YKJgJltqBq+8HwtKpbmdzuas=
X-Antivirus-Status: Clean
X-Antivirus: Norton (VPS 250508-4, 5/8/2025), Outbound message
In-Reply-To: <87o6w2begg.fsf@nosuchdomain.example.com>
Content-Language: en-US
Bytes: 5558

On 5/8/2025 11:22 PM, Keith Thompson wrote:
> Richard Damon <news.x.richarddamon@xoxy.net> writes:
>> On 5/8/25 10:23 PM, 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?
>>>
>>
>> You are missing the equivocation he is using on what is "DDD()"
>>
>> First, he tries to define it as just the code of the function, and not
>> including any of the code that it calls. He does this so all the
>> various HHH that he talks about are given the "same" input.
>>
>> Then he tries to also say that when those functions look at DDD, they
>> can follow the memory chain to the functions that it calls, that
>> weren't actually part of the input.
>>
>> This means the "behavior" of his input isn't actually defined by the input.
> 
> I haven't seen any of that in the posts to which I've recently replied
> (and I absolutely do not have the patience to read everything he's
> posted here).
> 
> What I've seen in the articles to which I've recently replied has been
> just a strangely little C function and some claims about simulation.
> Viewed in isolation, I don't think any of that (again, ignoring the vast
> majority of what he's posted in this newsgroup) seems contradictory so far.
> 
>> He has also, to get around other objections about what he is doing,
>> stipulated that his functions must be pure functions, and thus only
>> dependent on their direct input, other wise we can add the following
>> code to the beginning of HHH to make his statement false:
> 
> I've seen no mention of pure functions in the posts to which I've
> recently replied.
> 
> [...]
> 
You are seeing some of the same misdirection that I have been seeing.
Most people here change the subject when they come across difficult
and crucial material.

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