Deutsch   English   Français   Italiano  
<vveh6e$89u0$8@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: olcott <polcott333@gmail.com>
Newsgroups: comp.theory
Subject: Re: Halting Problem: What Constitutes Pathological Input
Date: Tue, 6 May 2025 21:40:14 -0500
Organization: A noiseless patient Spider
Lines: 124
Message-ID: <vveh6e$89u0$8@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>
 <bf914e91ee1c9d27536cfebf811930e24014cdf3@i2pn2.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 07 May 2025 04:40:15 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="ee5137430f56269cd3e6381ddf24cf46";
	logging-data="272320"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19I+lliFNR3vBbRlq1FUfgN"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:d60zo64ireCbO95hAKIikIc+9Po=
Content-Language: en-US
X-Antivirus-Status: Clean
X-Antivirus: Norton (VPS 250506-6, 5/6/2025), Outbound message
In-Reply-To: <bf914e91ee1c9d27536cfebf811930e24014cdf3@i2pn2.org>
Bytes: 6049

On 5/6/2025 6:00 PM, Richard Damon wrote:
> On 5/6/25 1:54 PM, olcott wrote:
>> 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.
>>
> 
> Right, but a correct simulation of D does halt, 

How the Hell is breaking the rules specified
by the x86 language possibly correct?

I could say that the sum of 5 + 7 is a dirty sock
according to the rules of random gibberish.

When I go by the rules of arithmetic I am proved
wrong.

DD <is> emulated by HHH according to the rules
of the x86 language that specify the HHH also
emulates itself emulating DD

until HHH determines that for the hypothetical
HHH/DD pair where the hypothetical HHH never
aborts DD would never stop running.

<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 the hypothetical HHH/DD pair where
     HHH never aborts its simulation.



-- 
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer