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: Halting Problem: What Constitutes Pathological Input
Date: Wed, 7 May 2025 07:45:55 -0400
Organization: A noiseless patient Spider
Lines: 163
Message-ID: <vvfh5i$10b0m$1@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>
 <vveh6e$89u0$8@dont-email.me> <vvehho$etf4$2@dont-email.me>
 <vveoqs$lgd3$1@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 13:45:55 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="3013d96e0ac4b7dd359f7afe652f4ce0";
	logging-data="1059862"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/z4llVvXMGrPDGtM/SnSYU"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:772+xlNusuDKtfaqNdmjqrX0ExY=
In-Reply-To: <vveoqs$lgd3$1@dont-email.me>
Content-Language: en-US
Bytes: 7554

On 5/7/2025 12:50 AM, olcott wrote:
> On 5/6/2025 9:46 PM, dbush wrote:
>> On 5/6/2025 10:40 PM, olcott wrote:
>>> 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
>>
>> False, as you yourself have admitted on the record:
>>
> You confused the words that I said with the words that others said.
> 
> DD <is> emulated by HHH according to the rules
> of the x86 language 

And again you lie, as you have admitted it does not on the record:


On 5/5/2025 8:24 AM, dbush wrote:
 > On 5/4/2025 11:03 PM, dbush wrote:
 >> On 5/4/2025 10:05 PM, olcott wrote:
 >>> On 5/4/2025 7:23 PM, Richard Damon wrote:
 >>>> But HHH doesn't correct emulated DD by those rules, as those rules
 >>>> do not allow HHH to stop its emulation,
 >>>
 >>> Sure they do you freaking moron...
 >>
 >> Then show where in the Intel instruction manual that the execution of
 >> any instruction other than a HLT is allowed to stop instead of
 >> executing the next instruction.
 >>
 >> Failure to do so in your next reply, or within one hour of your next
 >> post on this newsgroup, will be taken as you official on-the-record
 >> admission that there is no such allowance and that HHH does NOT
 >> correctly simulate DD.
 >
 > Let the record show that Peter Olcott made the following post in this
 > newsgroup after the above message:
 >
 > On 5/4/2025 11:04 PM, olcott wrote:
 >  > D *WOULD NEVER STOP RUNNING UNLESS*
 >  > indicates that professor Sipser was agreeing
 >  > to hypotheticals AS *NOT CHANGING THE INPUT*
 >  >
 >  > You are taking
 >  > *WOULD NEVER STOP RUNNING UNLESS*
 >  > to mean *NEVER STOPS RUNNING* that is incorrect.
 >
 > And has made no attempt after over 9 hours to show where in the Intel
 > instruction manual that execution is allowed to stop after any
 > instruction other than HLT.
 >
 > Therefore, as per the above criteria:
 >
 > LET THE RECORD SHOW
 >
 > That Peter Olcott
 >
 > Has *officially* admitted
 >
 > That DD is NOT correctly simulated by HHH