Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: dbush <dbush.mobile@gmail.com>
Newsgroups: comp.theory
Subject: Re: Every sufficiently competent C programmer knows --- Semantic
 Property of Finite String
Date: Wed, 12 Mar 2025 23:13:46 -0400
Organization: A noiseless patient Spider
Lines: 170
Message-ID: <vqtiha$2t2hb$4@dont-email.me>
References: <vqntaq$1jut5$1@dont-email.me> <vqp388$1tvqa$1@dont-email.me>
 <vqpdv9$202b2$2@dont-email.me> <vqperb$20c9k$2@dont-email.me>
 <E6mcnWv3nMa66036nZ2dnZfqnPWdnZ2d@brightview.co.uk>
 <vqqnk5$28jtr$1@dont-email.me> <vqqonm$28lh2$1@dont-email.me>
 <vqqq09$28kp8$1@dont-email.me> <vqqq7s$29buv$2@dont-email.me>
 <vqqqu3$28kp8$2@dont-email.me> <vqqrl7$29meg$2@dont-email.me>
 <vqqror$29k3n$1@dont-email.me> <vqqrv9$29meg$4@dont-email.me>
 <vqqs14$29k3n$3@dont-email.me> <vqqs5j$29meg$6@dont-email.me>
 <vqqs8p$29k3n$4@dont-email.me> <vqqshn$29meg$7@dont-email.me>
 <vqsmid$2onvs$1@dont-email.me> <vqsqqu$2pu66$1@dont-email.me>
 <vqss8u$2po1m$1@dont-email.me> <vqsus5$2qopi$1@dont-email.me>
 <vqt0ao$2q8jp$1@dont-email.me> <vqt1v6$2rc3e$1@dont-email.me>
 <vqt293$2q8jp$2@dont-email.me> <vqt5ak$2s3s0$1@dont-email.me>
 <vqt5mb$2q8jp$3@dont-email.me> <vqt8lj$2spcd$2@dont-email.me>
 <vqtaad$2t2hb$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 13 Mar 2025 04:13:46 +0100 (CET)
Injection-Info: dont-email.me; posting-host="bfda177ea2e5d824256b51a2c43e6950";
	logging-data="3050027"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18BDFEt37WuiFyoI9bgC7xe"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:pKH3mEwq6uOVrlYra6fZ5Q7SIHw=
Content-Language: en-US
In-Reply-To: <vqtaad$2t2hb$1@dont-email.me>
Bytes: 9031

On 3/12/2025 8:53 PM, dbush wrote:
> On 3/12/2025 8:25 PM, olcott wrote:
>> On 3/12/2025 6:34 PM, dbush wrote:
>>> On 3/12/2025 7:28 PM, olcott wrote:
>>>> On 3/12/2025 5:36 PM, dbush wrote:
>>>>> On 3/12/2025 6:31 PM, olcott wrote:
>>>>>> On 3/12/2025 5:03 PM, dbush wrote:
>>>>>>> On 3/12/2025 5:38 PM, olcott wrote:
>>>>>>>> On 3/12/2025 3:53 PM, dbush wrote:
>>>>>>>>> On 3/12/2025 4:29 PM, olcott wrote:
>>>>>>>>>> On 3/12/2025 2:16 PM, dbush wrote:
>>>>>>>>>>> On 3/11/2025 10:46 PM, olcott wrote:
>>>>>>>>>>>> On 3/11/2025 9:41 PM, dbush wrote:
>>>>>>>>>>>>> On 3/11/2025 10:39 PM, olcott wrote:
>>>>>>>>>>>>>> On 3/11/2025 9:37 PM, dbush wrote:
>>>>>>>>>>>>>>> On 3/11/2025 10:36 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 3/11/2025 9:32 PM, dbush wrote:
>>>>>>>>>>>>>>>>> On 3/11/2025 10:31 PM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 3/11/2025 9:18 PM, dbush wrote:
>>>>>>>>>>>>>>>>>>> On 3/11/2025 10:06 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 3/11/2025 9:02 PM, dbush wrote:
>>>>>>>>>>>>>>>>>>>>> On 3/11/2025 9:41 PM, Richard Heathfield wrote:
>>>>>>>>>>>>>>>>>>>>>> On 12/03/2025 01:22, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>> DDD correctly simulated by HHH never reaches its
>>>>>>>>>>>>>>>>>>>>>>> own "return" instruction and terminates normally
>>>>>>>>>>>>>>>>>>>>>>> in any finite or infinite number of correctly
>>>>>>>>>>>>>>>>>>>>>>> simulated steps.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> If it correctly simulates infinitely many steps, 
>>>>>>>>>>>>>>>>>>>>>> it doesn't terminate. Look up "infinite".
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> But your task is to decide for /any/ program, not 
>>>>>>>>>>>>>>>>>>>>>> just DDD. That, as you are so fond of saying, is 
>>>>>>>>>>>>>>>>>>>>>> 'stipulated', and you can't get out of it. The 
>>>>>>>>>>>>>>>>>>>>>> whole point of the Entscheidungsproblem is its 
>>>>>>>>>>>>>>>>>>>>>> universality. Ignore that, and you have nothing.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Given that his code has HHH(DD) returning 0, 
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> THESE ARE THE WORDS ANYONE THAT DODGES THESE
>>>>>>>>>>>>>>>>>>>> WORDS WILL BE TAKEN FOR A LIAR
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> void DDD()
>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>    HHH(DDD);
>>>>>>>>>>>>>>>>>>>>    return;
>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> DDD correctly simulated by HHH never reaches its
>>>>>>>>>>>>>>>>>>>> own "return" instruction and terminates normally
>>>>>>>>>>>>>>>>>>>> in any finite or infinite number of correctly
>>>>>>>>>>>>>>>>>>>> simulated steps.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Changing the input is not allowed.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> *You are simply lying that any input was ever changed*
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> You did precisely that when you hypothesize different 
>>>>>>>>>>>>>>>>> code for HHH.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Changing the input is not allowed.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> *THIS IS WHAT MY ORIGINAL WORDS MEANT*
>>>>>>>>>>>>>>>> HHH is the infinite set of every possible C function
>>>>>>>>>>>>>>>> that correctly emulates N steps of its input where
>>>>>>>>>>>>>>>> N any finite positive integer.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> In other words, you're changing the input.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Changing the input is not allowed.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It is an infinite set of HHH/DDD pairs having the
>>>>>>>>>>>>>> property that DDD[0] ... DDD[N] never halts.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> In other words, you're not answering the question that a 
>>>>>>>>>>>>> solution to the halting problem is required to answer:
>>>>>>>>>>>>>
>>>>>>>>>>>>> (<X>,Y) maps to 1 if and only if X(Y) halts when executed 
>>>>>>>>>>>>> directly
>>>>>>>>>>>>> (<X>,Y) maps to 0 if and only if X(Y) does not halt when 
>>>>>>>>>>>>> executed directly
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Yes I am yet you refuse to pay anywhere near close
>>>>>>>>>>>> enough attention to see how I already fully addressed this.
>>>>>>>>>>>> If you pay 100% perfect attention you might get it.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> False.  (<DDD>,null) maps to 1 as per the above requirements, 
>>>>>>>>>>> but your HHH maps (<DDD>,null) to 0, therefore it fails to 
>>>>>>>>>>> meet the requirements.
>>>>>>>>>>
>>>>>>>>>> <unrelated copy-paste response>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> So no response?  I'll take it that you agree with the above.
>>>>>>>>
>>>>>>>> Making sure to always give credit where credit is due this
>>>>>>>> point in our conversation is the point where I first translated
>>>>>>>> my perspective into the semantic property of a finite string.
>>>>>>>>
>>>>>>>> A decider is required to report on a semantic (or syntactic)
>>>>>>>> property of its input finite string (even if Rice incorrectly
>>>>>>>> says this is impossible in this case) and not allowed to report
>>>>>>>> on any damn thing else.
>>>>>>>>
>>>>>>>> The fact that DDD calls HHH(DDD) in recursive emulation
>>>>>>>> <is> an aspect of the semantics of the input finite string
>>>>>>>> that cannot be correctly ignored.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> Remember the stipulative definition of a solution to the halting 
>>>>>>> problem:
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Is to map the input finite string to the semantic property
>>>>>> of this finite string. Any other mapping contradicts the
>>>>>> definition of a decider.
>>>>>
>>>>> And that property is as follows:
>>>>>
>>>>> (<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
>>>>> (<X>,Y) maps to 0 if and only if X(Y) does not halt when executed 
>>>>> directly
>>>>>
>>>>> I should also point out that I never mentioned anything about a 
>>>>> "decider", simply "a solution to the halting problem".  Neither did 
>>>>> Linz.
>>>>>
>>>>
>>>> <sarcasm>
>>>> Sure everyone knows that a halt decider is not kind of decider at all.
>>>> </sarcasm>
>>>>
>>>>
>>>
>>> So no answer.  Then you accept that HHH(DDD)==0 is wrong because it 
>>> isn't performing the above mapping required to be a solution to the 
>>> halting problem.
>>
>> A {halt decider} must be a {decider} or it is incorrect.
>>
> 
> This *is* a semantic property of the input:
> 
> (<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
> (<X>,Y) maps to 0 if and only if X(Y) does not halt when executed
> 
> 
> And even if your claim is correct (it isn't) it doesn't matter because 
> we're talking about a solution to the halting problem.
> 
> That's also what Linz is talking about.  Try to find the word "decider" 
> anywhere in the Linz proof.
> 
========== REMAINDER OF ARTICLE TRUNCATED ==========