Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Richard Damon <news.x.richarddamon@xoxy.net>
Newsgroups: comp.theory
Subject: Re: Incorrect requirements --- Computing the mapping from the input
 to HHH(DD)
Date: Thu, 8 May 2025 23:01:18 -0400
Organization: A noiseless patient Spider
Lines: 104
Message-ID: <vvjr60$2gfbv$1@dont-email.me>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 09 May 2025 05:01:21 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="fea077e568fa646b84f5730c24866ea3";
	logging-data="2637183"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19F/hL5j4cJuB7Np+o0m3Ezpd3n2UKEb54="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:h7tXD8hEu14Cld5E8fvxq08zq6w=
Content-Language: en-US
In-Reply-To: <87bjs2cyj6.fsf@nosuchdomain.example.com>

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.

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:


int HHH(void (*p)()) {
   static int flag = 0;
   if (flag) return 0;
   flag = 1;
   /* then the rest of the code that he uses to simulate the input */

Such an HHH obviously can "correctly simulate" a call to itself in the 
same memory space to the return of DDD.

But, since HHH has been stipulated to be a pure function, it can't 
access memory that wasn't part of its input, and thus his first 
definition can't be used, and when we use the second definiton, it is 
clear that each of his HHH's get different input, so is ploy to show 
that the HHH that does correctly emulate the input which show that "the" 
DDD is non-halting also shows that the HHH that does abort, and was 
given the "same" input can also conclude that.

Of course, different inputs can behavie differently and thus he is just 
using his projection that HHH(DDD) is just like the sum(2,3) that 
returned 7 as the sum of 2 + 5 since it "changed" the input to something 
it wasn't.

His goal is to ge this "fact" agreed to in the abstract case, so he can 
claim it must also be true when HHH is now defined to be that HHH that 
aborts by his equivocation.

The HHH that correctly emulates its input can only do its job when the 
input includes all the code it is to emulate as a valid part of its input.

If you look at some of his other posts, what he really is trying to do 
is say that HHH can "correctly" emulate the call to HHH(DDD) as actually 
starting a new level of emulation within the actual emulator instead of 
actually emulating the emulator emulating the input, as that "gets too 
long" and thus hidding that the emulation WILL be aborted by his actual 
HHH and not create the claimed infinite recursion, which only exists in 
his "hypothectical" HHH that isn't what he will actually define it to be.