Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: olcott <polcott333@gmail.com>
Newsgroups: comp.theory
Subject: Re: Sufficient knowledge of C proves that DD specifies
 non-terminating behavior to HHH
Date: Sun, 9 Feb 2025 09:33:54 -0600
Organization: A noiseless patient Spider
Lines: 161
Message-ID: <voaht2$m3dj$9@dont-email.me>
References: <vnumf8$24cq0$1@dont-email.me>
 <vnv4tf$2a40b$1@raubtier-asyl.eternal-september.org>
 <vnvv32$2e9m1$1@dont-email.me>
 <vo2pd4$31nli$1@raubtier-asyl.eternal-september.org>
 <vo2us8$32kg8$1@dont-email.me>
 <228a9804d6919149bac728ccf08134ed90db121e@i2pn2.org>
 <vo3cf0$35449$1@dont-email.me>
 <6f15178eda69b13fae9cbfef29acad05c9c6aeb3@i2pn2.org>
 <vo3t3n$37kcg$1@dont-email.me>
 <1454e934b709b66a0cb9de9e9796cb46fed0425c@i2pn2.org>
 <vo5c8c$3ipo2$2@dont-email.me>
 <f7f9c03f97de054f6393139c74f595f68400ede5@i2pn2.org>
 <vo6b14$3o0uo$1@dont-email.me>
 <274abb70abec9d461ac3eb34c0980b7421f5fabd@i2pn2.org>
 <vo6rhd$3tsq7$1@dont-email.me> <vo79pq$8vq$2@dont-email.me>
 <vo7qqb$36ra$2@dont-email.me> <vo8jr6$7fbd$2@dont-email.me>
 <vo9gth$fuct$2@dont-email.me>
 <37ebed5ce8ac62406687fabafa17b46e6a618173@i2pn2.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 09 Feb 2025 16:33:55 +0100 (CET)
Injection-Info: dont-email.me; posting-host="0d7b7e128809f1e0bad2050f21bb5c16";
	logging-data="724403"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX199v81i7yE+gg39Pc8rZHem"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:iLdPaB+5TsVq24ltvJC4qu+061Y=
Content-Language: en-US
X-Antivirus-Status: Clean
X-Antivirus: Norton (VPS 250209-2, 2/9/2025), Outbound message
In-Reply-To: <37ebed5ce8ac62406687fabafa17b46e6a618173@i2pn2.org>
Bytes: 8509

On 2/9/2025 7:08 AM, Richard Damon wrote:
> On 2/9/25 1:10 AM, olcott wrote:
>> On 2/8/2025 3:54 PM, Fred. Zwarts wrote:
>>> Op 08.feb.2025 om 15:47 schreef olcott:
>>>> On 2/8/2025 3:57 AM, Fred. Zwarts wrote:
>>>>> Op 08.feb.2025 om 06:53 schreef olcott:
>>>>>> On 2/7/2025 7:27 PM, Richard Damon wrote:
>>>>>>> On 2/7/25 8:12 PM, olcott wrote:
>>>>>>>> On 2/7/2025 5:56 PM, Richard Damon wrote:
>>>>>>>>> On 2/7/25 11:26 AM, olcott wrote:
>>>>>>>>>> On 2/7/2025 6:20 AM, Richard Damon wrote:
>>>>>>>>>>> On 2/6/25 10:02 PM, olcott wrote:
>>>>>>>>>>>> On 2/6/2025 8:21 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 2/6/25 5:18 PM, olcott wrote:
>>>>>>>>>>>>>> On 2/6/2025 1:51 PM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 2/6/25 1:26 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 2/6/2025 10:52 AM, Bonita Montero wrote:
>>>>>>>>>>>>>>>>> Am 05.02.2025 um 16:11 schrieb olcott:
>>>>>>>>>>>>>>>>>> On 2/5/2025 1:44 AM, Bonita Montero wrote:
>>>>>>>>>>>>>>>>>>> Am 05.02.2025 um 04:38 schrieb olcott:
>>>>>>>>>>>>>>>>>>>> This treatment does not typically last very long and
>>>>>>>>>>>>>>>>>>>> will be immediately followed by a riskier fourth line
>>>>>>>>>>>>>>>>>>>> of treatment that has an initial success rate much 
>>>>>>>>>>>>>>>>>>>> higher
>>>>>>>>>>>>>>>>>>>> than its non progression mortality rate.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Halting problem solved !
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The halting problem proof input does specify non-halting
>>>>>>>>>>>>>>>>>> behavior to its decider.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> https://www.researchgate.net/ 
>>>>>>>>>>>>>>>>>> publication/369971402_Simulating_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_D
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> LOOOOOOOOL
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Anyone that understands the C programming language
>>>>>>>>>>>>>>>> sufficiently well (thus not confused by the unreachable
>>>>>>>>>>>>>>>> "if" statement) correctly understands that DD simulated
>>>>>>>>>>>>>>>> by HHH cannot possibly reach its own return instruction.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> And anyone that understand the halting problem knows that 
>>>>>>>>>>>>>>> isn't the question being asked. The quesiton you NEED to 
>>>>>>>>>>>>>>> ask is will the program described by the input halt when 
>>>>>>>>>>>>>>> run?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Since you start off with the wrong question, you logic is 
>>>>>>>>>>>>>>> just faulty.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Everyone that thinks my question is incorrect is wrong.
>>>>>>>>>>>>>> It has always been a mathematical mapping from finite
>>>>>>>>>>>>>> strings to behaviors. That people do not comprehend this
>>>>>>>>>>>>>> shows the shallowness of the depth of the learned-by-rote
>>>>>>>>>>>>>> (lack of) understanding.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> No, you are just incorreect as you don't know what you are 
>>>>>>>>>>>>> talking about.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Yes, it is a mapping of the string to the behavior, and 
>>>>>>>>>>>>> that mapping is DEFINED to be the halting behavior of the 
>>>>>>>>>>>>> program the string describes.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> No this is incorrect. The input finite string specifies
>>>>>>>>>>>> (not merely describes) non halting behavior to its decider.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> No, since the definition of "Halting Behavior" is the 
>>>>>>>>>>> behavior of the progran being run.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> It may seem that way to people that have learned-by-rote
>>>>>>>>>> as their only basis. It is actually nothing like that.
>>>>>>>>>
>>>>>>>>> No, that *IS* the definition.
>>>>>>>>>
>>>>>>>>
>>>>>>>> A termination analyzer computes the mapping from finite
>>>>>>>> strings to the actual behavior that these finite strings
>>>>>>>> specify. That this is not dead obvious to everyone here
>>>>>>>> merely proves that learned-by-rote does not involve any
>>>>>>>> actual comprehension.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> And the behavior the finite string specifies is the behavior of 
>>>>>>> running the program. 
>>>>>>
>>>>>> That is verifiably factually incorrect.
>>>>>> The running program has a different execution trace
>>>>>> than the behavior that DD specifies to HHH.
>>>>>>
>>>>>
>>>>> If so, then it proves the failure of the simulation. The simulation 
>>>>> aborts too soon on unsound grounds, one cycle before the normal 
>>>>> termination of the program.
>>>>>
>>>>
>>>> This proves that you simply don't have sufficient
>>>> understanding of the C programming language.
>>>> DD simulated by HHH cannot possibly terminate normally
>>>> is a verified fact.
>>>>
>>>
>>> Which proves that HHH fails to make a correct decision about DD's 
>>> halting behaviour. All other methods (direct execution, simulation by 
>>> a world class simulator, etc.) show that DD halts. But HHH fails to 
>>> see it. Everyone with sufficient understanding of programming sees 
>>> that HHH is not correctly programmed when it aborts one cycle before 
>>> the simulation would end normally.
>>
>> typedef void (*ptr)();
>> int HHH(ptr P);
>>
>> int DD()
>> {
>>    int Halt_Status = HHH(DD);
>>    if (Halt_Status)
>>      HERE: goto HERE;
>>    return Halt_Status;
>> }
>>
>> int main()
>> {
>>    HHH(DD);
>> }
>>
>> You lack the ability to do the execution trace
>> of HHH simulating DD calling HHH(DD) simulating DD...
>>
>> If you have no idea what recursion is you will not be
>> able to understand what I am saying.
>>
> 
> No, YOU lack the understanding of what a program is.
> 
> Your first problem is that function "DD" isn't a "program" by itself, 
> but only becomes one when you include as part of it the code for HHH. 
> And thus, the specific HHH that exists at this exact point IS HHH, and 
> it can not be changed.
> 

It is this same way for every halting problem instance.
It is an easily verified fact that DD cannot possibly reach
its own "if" statement when-so-ever HHH is a simulating
termination analyzer.

The only reason that the halting problem proof has never
been refuted before is that everyone always rejected
simulation as a basis out-of-hand without review. They
simply did not bother to think things all-the-way through.


-- 
========== REMAINDER OF ARTICLE TRUNCATED ==========