Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: "Fred. Zwarts" <F.Zwarts@HetNet.nl>
Newsgroups: comp.theory
Subject: Re: Incorrect requirements --- Computing the mapping from the input
 to HHH(DD)
Date: Sat, 10 May 2025 10:25:28 +0200
Organization: A noiseless patient Spider
Lines: 128
Message-ID: <vvn2hq$3dv8d$6@dont-email.me>
References: <vv97ft$3fg66$1@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> <vvkffn$2m36t$4@dont-email.me>
 <vvl84g$2rl0l$10@dont-email.me>
 <c0b0db5de5c7f7ccb24b06d44108deb41fbde8dc@i2pn2.org>
 <vvlm2k$30idv$1@dont-email.me> <vvlnad$2uvnf$5@dont-email.me>
 <vvlnpj$30vce$1@dont-email.me> <vvlsp5$31vqc$1@dont-email.me>
 <vvlv04$32kt3$1@dont-email.me> <87r00xchn5.fsf@nosuchdomain.example.com>
 <23a27379d226b7b3b9f8c303a492f66edc9019ff.camel@gmail.com>
 <vvmgtr$3a34p$7@dont-email.me>
 <5b613cbbf5464cced9768f517ff31c2b8bb34490@i2pn2.org>
 <vvmjoh$3atmt$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 10 May 2025 10:25:30 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="6132ef5c9a5712f5fb4e052234097a74";
	logging-data="3603725"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18bTnXPTxaoBt8ZkSW1a/GI"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:6a0vjZquPTRXezeMNTV6Lc4idWU=
In-Reply-To: <vvmjoh$3atmt$2@dont-email.me>
Content-Language: nl, en-GB
Bytes: 7897

Op 10.mei.2025 om 06:13 schreef olcott:
> On 5/9/2025 10:53 PM, Richard Damon wrote:
>> On 5/9/25 11:24 PM, olcott wrote:
>>> On 5/9/2025 10:13 PM, wij wrote:
>>>> On Fri, 2025-05-09 at 19:40 -0700, Keith Thompson wrote:
>>>>> olcott <polcott333@gmail.com> writes:
>>>>>> On 5/9/2025 4:40 PM, Richard Heathfield wrote:
>>>>>>> On 09/05/2025 21:15, olcott wrote:
>>>>>>>> On 5/9/2025 3:07 PM, Richard Heathfield wrote:
>>>>>>>>> On 09/05/2025 20:46, olcott wrote:
>>>>>>>>>> We have not begun to get into any of those points.
>>>>>>>>>> We are only asking can DDD correctly simulated
>>>>>>>>>> by any HHH that can exist ever reach its own
>>>>>>>>>> "return" instruction.
>>>>>>>>>
>>>>>>>>> DDD can't be correctly simulated by itself (which is effectively
>>>>>>>>> what you're trying to do when you fire up the simulation from
>>>>>>>>> inside DDD).
>>>>>>>>
>>>>>>>> How the Hell did you twist my words to say that?
>>>>>>> I haven't touched your words. What I have done is to observe that
>>>>>>> DDD's /only/ action is to call a simulator. Since DDD isn't itself a
>>>>>>> simulator, there is nothing to simulate except a call to a
>>>>>>> simulator.
>>>>>>> It's recursion without a base case - a rookie error.
>>>>>>> HHH cannot successfully complete its task, because it never regains
>>>>>>> control after the first recursion. To return, it must abort the
>>>>>>> simulation, which means the simulation fails.
>>>>>>>
>>>>>>>> void DDD()
>>>>>>>> {
>>>>>>>>     HHH(DDD);
>>>>>>>>     return;
>>>>>>>> }
>>>>>>>>
>>>>>>>> When 1 or more statements of DDD are correctly
>>>>>>>> simulated by HHH then this correctly simulated
>>>>>>>> DDD cannot possibly reach its own “return statement”.
>>>>>>> On what grounds can you persuade an extraordinarily sceptical
>>>>>>> readership that HHH 'correctly simulated' DDD?
>>>>>>
>>>>>> Any competent C programmer can see that
>>>>>> the call from DDD to HHH(DDD) (its own simulator)
>>>>>> is equivalent to infinite recursion.
>>>>>>
>>>>>> On 5/8/2025 8:30 PM, Keith Thompson wrote:
>>>>>>> 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;
>>>>>>>       }
>>>>>>>
>>>>>>> Then the return statement (which is unnecessary anyway) will 
>>>>>>> never be
>>>>>>> reached.  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.
>>>>>
>>>>> I had not intended to post again, but I feel the need to make
>>>>> a clarification.
>>>>>
>>>>> I acknowledged that the return statement would never be reached
>>>>> *given the assumption* that HHH correctly simulates DDD.  Given
>>>>> that assumption, a call to DDD() should be equivalent to a call
>>>>> to HHH(DDD).
>>>>>
>>>>> I did not address whether the assumption is valid.  I merely
>>>>> temporarily accepted it for the sake of discussion, just as I would
>>>>> accept that if I were ten feet tall I would bump my head against
>>>>> the ceiling in my house.
>>>>>
>>>>> The discussion I had with olcott did not reach the point of
>>>>> discussing *how* HHH could correctly simulate DDD, or whether it
>>>>> would even be logically possible for it to do so.  I also did not
>>>>> address any issues of partial simulation, where olcott claims that
>>>>> HHH can "accurately simulate" only a few x86 instructions rather
>>>>> than simulating its entire execution.  I did not participate in
>>>>> any discussion that would require knowledge of x86 machine or
>>>>> assembly code.  (I have no doubt that I could learn x86 machine
>>>>> and assembly code reasonably well if motivated to do so, but I am
>>>>> not so motivated.)
>>>>>
>>>>> What I acknowledged was barely more than "if HHH correctly simulates
>>>>> DDD, then HHH correctly simulates DDD".  (My understanding from
>>>>> posts by others, whom I presume to be sufficiently knowledgeable,
>>>>> is that HHH logically cannot accurately simulate DDD.)  I would
>>>>> prefer that olcott refrain from using my words to support any of
>>>>> his arguments beyond the scope of what he and I directly discussed.
>>>>
>>>> Don't know why you people stick on the 'simulation' stuff so long.
>>>> The HP simply asks for such an H (in function form. POOH does not
>>>> resemble TM):
>>>>   H(D)=1 if D() halt.
>>>>   H(D)=0 if D() not halt.
>>>
>>> My invention of a simulating termination
>>> analyzer shows exactly how to compute the
>>> mapping that the input that HHH(DD) specifies
>>> into a correct answer for the halting problem's
>>> otherwise impossible input.
>>>
>>> All rebuttals are based on failing to compute
>>> this mapping correctly.
>>>
>>
>> The problem is you don't compute the correct mapping, as you LIE by 
>> changing the defined mapping with your strawman,
>>
>> Termination Analyzer, BY THEIR DEFINITION, determine if the program 
>> represented by their input will halt when run. PERIOD.
>>
> 
> When definitions contradict each other at
> least one of them is wrong.
> 
> HHH(DDD) computes the mapping from its input finite
> string according to the rules of the x86 language
> thus obtains the actual behavior THAT THIS INPUT STRING SPECIFIES.
> 
But ignores the most important part of the input that specifies that the 
program aborts and halt. So, the mapping is incorrect. A correct mapping 
uses the full input, not only an irrelevant part of the finite string.
It seems that you are unable to accept verifiable facts when they 
disturb your dreams.