Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups: comp.theory
Subject: Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD)
Date: Thu, 08 May 2025 21:22:39 -0700
Organization: None to speak of
Lines: 80
Message-ID: <87o6w2begg.fsf@nosuchdomain.example.com>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 09 May 2025 06:22:40 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="302a6dd640940106301f9e87fdade96e";
	logging-data="2680540"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18Zd9BV+ffiXYN/cEHah2bw"
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:eOjDqkmM71jZ7mzmE8jKDAO9AtI=
	sha1:O7p1LXW0e6s+lMkHkIDTMhRxwVk=

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.

[...]

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */