Deutsch   English   Français   Italiano  
<vvfdao$v837$3@dont-email.me>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!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: Halting Problem: What Constitutes Pathological Input
Date: Wed, 7 May 2025 12:40:23 +0200
Organization: A noiseless patient Spider
Lines: 107
Message-ID: <vvfdao$v837$3@dont-email.me>
References: <GE4SP.47558$VBab.42930@fx08.ams4> <vvamqc$o6v5$4@dont-email.me>
 <5b84f927f8052f5392b625cef9642140d439d1c7@i2pn2.org>
 <vvbs6b$1us1f$3@dont-email.me>
 <1a99b2ee77f8c0d1ff37e5febb47c5be17b2d4fb@i2pn2.org>
 <vvdidg$3cbpq$8@dont-email.me> <vvdn67$3huo6$6@dont-email.me>
 <vvdnni$3k2gc$4@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 07 May 2025 12:40:24 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="1f8f63a6b9b5f3b438700d1281f1281f";
	logging-data="1024103"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18um/aAwYYhHXEVIooFOZcu"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:W8PhO/K9NhzA/UD0ekhleZMf1Pc=
In-Reply-To: <vvdnni$3k2gc$4@dont-email.me>
Content-Language: nl, en-GB
Bytes: 5488

Op 06.mei.2025 om 21:25 schreef olcott:
> On 5/6/2025 2:16 PM, Fred. Zwarts wrote:
>> Op 06.mei.2025 om 19:54 schreef olcott:
>>> On 5/6/2025 6:06 AM, Richard Damon wrote:
>>>> On 5/5/25 10:29 PM, olcott wrote:
>>>>> On 5/5/2025 8:06 PM, Richard Damon wrote:
>>>>>> On 5/5/25 11:51 AM, olcott wrote:
>>>>>>> On 5/5/2025 10:17 AM, Mr Flibble wrote:
>>>>>>>> What constitutes halting problem pathological input:
>>>>>>>>
>>>>>>>> Input that would cause infinite recursion when using a decider 
>>>>>>>> of the
>>>>>>>> simulating kind.
>>>>>>>>
>>>>>>>> Such input forms a category error which results in the halting 
>>>>>>>> problem
>>>>>>>> being ill-formed as currently defined.
>>>>>>>>
>>>>>>>> /Flibble
>>>>>>>
>>>>>>> I prefer to look at it as a counter-example that refutes
>>>>>>> all of the halting problem proofs.
>>>>>>>
>>>>>>> int DD()
>>>>>>> {
>>>>>>>    int Halt_Status = HHH(DD);
>>>>>>>    if (Halt_Status)
>>>>>>>      HERE: goto HERE;
>>>>>>>    return Halt_Status;
>>>>>>> }
>>>>>>
>>>>>> Which isn't a program until you include the SPECIFIC HHH that it 
>>>>>> refutes, and thus your talk about correctly emulated by HHH is 
>>>>>> just a lie.
>>>>>>
>>>>>>>
>>>>>>> https://github.com/plolcott/x86utm
>>>>>>>
>>>>>>> The x86utm operating system includes fully
>>>>>>> operational HHH and DD.
>>>>>>> https://github.com/plolcott/x86utm/blob/master/Halt7.c
>>>>>>>
>>>>>>> When HHH computes the mapping from *its input* to
>>>>>>> the behavior of DD emulated by HHH this includes
>>>>>>> HHH emulating itself emulating DD. This matches
>>>>>>> the infinite recursion behavior pattern.
>>>>>>>
>>>>>>
>>>>>> And *ITS INPUT*, for the HHH that answers 0, is the representation 
>>>>>> of a program 
>>>>>
>>>>> Not at all. This has always been stupidly wrong.
>>>>> The input is actually a 100% perfectly precise
>>>>> sequence of steps. With pathological self-reference
>>>>> some of these steps are inside the termination analyzer.
>>>>>
>>>>
>>>> Can't be, as the input needs to be about a program, which must, by 
>>>> the definition of a program, include all its algorithm.
>>>>
>>>> Yes, there are steps that also occur in the termination analyzer, 
>>>> but they have been effectively copied into the program the input 
>>>> describes.
>>>>
>>>> Note, nothing says that the representation of the program has to be 
>>>> an assembly level description of it. It has to be a complete 
>>>> description, that 100% defines the results the code will generate 
>>>> (and if it will generate) but it doesn't need to be the exact 
>>>> assembly code,
>>>>
>>>> YOU even understand that, as you present the code as "C" code, which 
>>>> isn't assembly.
>>>>
>>>> What you forget is that the input program INCLUDES as its definiton, 
>>>> all of the code it uses, and thus the call to the decider it is 
>>>> built on includes that code into the decider, and that is a FIXED 
>>>> and DETERMINDED version of the decider, the one that THIS version of 
>>>> the input is designed to make wrong.
>>>>
>>>> This doesn't change when you hypothosize a different decider looking 
>>>> at THIS input.
>>>>
>>>
>>> <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>>      If simulating halt decider H correctly simulates its
>>>      input D until H correctly determines that its simulated D
>>>      *would never stop running unless aborted* then
>>>
>>> *would never stop running unless aborted*
>>> Refers to a hypothetical HHH/DD pair of the same HHH that
>>> DD calls except that this hypothetical HHH never aborts.
>>>
>>
>>
>> HHH should decide about its actual input, not about a hypothetical input.
> 
> That is not what Professor Sipser agreed to.
> 
> *would never stop running unless aborted*
> is the hypothetical HHH/DD pair where HHH
> and DD are exactly the same except that
> this hypothetical HHH never aborts.
> 

No Sipser did not agree to this self-contradicting sentence.  A 
hypothetical HHH that never aborts is not exactly the same, but 
fundamentally different.