Path: ...!weretis.net!feeder9.news.weretis.net!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 12:52:58 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <e335c630571eeaac796de650705508fae4ef2814@i2pn2.org>
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>
 <28aa41aee538a585d6a4d47af5100c3fbdfff2b5@i2pn2.org>
 <vvl68h$2rl0l$5@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 9 May 2025 17:55:21 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="3833168"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
X-Spam-Checker-Version: SpamAssassin 4.0.0
In-Reply-To: <vvl68h$2rl0l$5@dont-email.me>
Content-Language: en-US
Bytes: 6755
Lines: 117

On 5/9/25 11:16 AM, olcott wrote:
> On 5/9/2025 5:59 AM, Richard Damon wrote:
>> On 5/9/25 12:22 AM, 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.
>>
>> The problem is the subtile one that he needs all "versions" of the 
>> input "DDD" to be the "same input" no matter what decider he uses, 
>> which means he can't include the code for the decider called as part 
>> of the input.
>>
>> But also, as I explained, he needs to define the decider to be a pure 
>> function to outlaw the trivial solution of the decider short-cutting 
>> itself when it is called by the input with a static variable, which 
>> means it can't do the job without it being part of the input.
>>
>>>
>>>> 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.
>>
>> Again, that is because that side of the equivocation hasn't been 
>> argued recently. Perhaps when he starts to argue that the decider is 
>> allowed to look at the "non-input" code, we will get back to that.
>>
> 
> void DDD()
> {
>    HHH(DDD);
>    return;
> }
> 
> *Subtle strawman deception change away from this exact subject*
> DDD correctly simulated by HHH cannot possibly
> reach its own "return" instruction.
> 


HHH can not correct emulate that input, so your statment is just 
nonsense, and you prove that your concept of "logic" is likewise just 
full of error.

The input doesn't contain the code for HHH, and thus HHH can not be the 
required pure function required, as it hasn't been given the code to 
emulate.

Sorry, You are just proving how must of a pathological liar you are.