| Deutsch English Français Italiano |
|
<6c04bded5a9d14ab3b027ef32e26318396c2f6d9@i2pn2.org> View for Bookmarking (what is this?) Look up another Usenet article |
Path: news.eternal-september.org!eternal-september.org!feeder3.eternal-september.org!news.quux.org!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory
Subject: Re: Halting Problem: What Constitutes Pathological Input
Date: Tue, 6 May 2025 21:50:53 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <6c04bded5a9d14ab3b027ef32e26318396c2f6d9@i2pn2.org>
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, 7 May 2025 02:26:12 -0000 (UTC)
Injection-Info: i2pn2.org;
logging-data="3455903"; mail-complaints-to="usenet@i2pn2.org";
posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
In-Reply-To: <vvdnni$3k2gc$4@dont-email.me>
Content-Language: en-US
X-Spam-Checker-Version: SpamAssassin 4.0.0
On 5/6/25 3:25 PM, olcott wrote:
> 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, it is the hypothetical HHH applied to the actual DD.
After all, the input D is the input which is a SPECIFIC set of
instruction consting *ALL* the code that it uses, and thus contains the
code of that original H.
You are just so stupid that you don't understand that essential property
of programs, which is what makes your whole arguement a category error
based on lies and equivocation.
You just can't be consistant on the existance of the code for HHH from
Halt7.c being part of the definition.
If it is, then DD uses that specific code which can't be changed without
changing the input.
If it isn't, then DD just isn't a complete program and you "prove" fails
on a category error.
You are stuck having checkmated yourself, and are trying to lie your way
out of it by trying to change the meaning of the terms of art of the
system, which just proves your ignorance and that you are just a
pathological liar.