Path: 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: Tue, 6 May 2025 17:19:40 -0400
Organization: A noiseless patient Spider
Lines: 181
Message-ID: <vvdudc$3lapa$10@dont-email.me>
References: <GE4SP.47558$VBab.42930@fx08.ams4> <vvamqc$o6v5$4@dont-email.me>
 <vvan7q$o4v0$1@dont-email.me> <ts5SP.113145$_Npd.41800@fx01.ams4>
 <vvat0g$vtiu$1@dont-email.me> <vvatf3$o4v0$3@dont-email.me>
 <vvaut0$vtiu$4@dont-email.me> <vvav6o$o4v0$4@dont-email.me>
 <vvb329$15u5b$1@dont-email.me> <vvb37g$1451r$1@dont-email.me>
 <vvb43f$15u5b$4@dont-email.me> <vvb8fm$1a9jr$1@dont-email.me>
 <vvc4ok$26dgq$1@dont-email.me> <vvcubb$2sk4a$2@dont-email.me>
 <vvdlu8$3j2mn$1@dont-email.me> <vvdof1$3lapa$2@dont-email.me>
 <vvdrn6$3n3t4$2@dont-email.me> <vvds7a$3lapa$4@dont-email.me>
 <vvdsl3$3n3t4$6@dont-email.me> <vvdsru$3lapa$7@dont-email.me>
 <vvdtgd$3q7i2$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 06 May 2025 23:19:41 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="80f1b624b2b67f0b720d14d0d7fce339";
	logging-data="3844906"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19ldhNaDNwKg7IZyzY1W1uJ"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:6Jnq0aS0k7WMux2dQZ95MCgOcD8=
In-Reply-To: <vvdtgd$3q7i2$2@dont-email.me>
Content-Language: en-US

On 5/6/2025 5:04 PM, olcott wrote:
> On 5/6/2025 3:53 PM, dbush wrote:
>> On 5/6/2025 4:49 PM, olcott wrote:
>>> On 5/6/2025 3:42 PM, dbush wrote:
>>>> On 5/6/2025 4:33 PM, olcott wrote:
>>>>> On 5/6/2025 2:38 PM, dbush wrote:
>>>>>> On 5/6/2025 2:55 PM, olcott wrote:
>>>>>>> On 5/6/2025 7:12 AM, dbush wrote:
>>>>>>>> On 5/6/2025 12:55 AM, olcott wrote:
>>>>>>>>> On 5/5/2025 3:53 PM, Richard Heathfield wrote:
>>>>>>>>>> On 05/05/2025 20:38, olcott wrote:
>>>>>>>>>>> On 5/5/2025 2:23 PM, Richard Heathfield wrote:
>>>>>>>>>>>> On 05/05/2025 20:20, olcott wrote:
>>>>>>>>>>>>> Is "halts" the correct answer for H to return?  NO
>>>>>>>>>>>>> Is "does not halt" the correct answer for H to return?  NO
>>>>>>>>>>>>> Both Boolean return values are the wrong answer
>>>>>>>>>>>>
>>>>>>>>>>>> Or to put it another way, the answer is undecidable, QED.
>>>>>>>>>>>>
>>>>>>>>>>>> See? You got there in the end.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Is this sentence true or false: "What time is it?"
>>>>>>>>>>
>>>>>>>>>> 20:45GMT, give or take.
>>>>>>>>>>
>>>>>>>>>>> is also "undecidable" because it is not a proposition
>>>>>>>>>>> having a truth value.
>>>>>>>>>>
>>>>>>>>>> No, it's computable and therefore decidable. Your computer is 
>>>>>>>>>> perfectly capable of displaying its interpretation of the time.
>>>>>>>>>>
>>>>>>>>>>> Is this sentence true or false: "This sentence is untrue."
>>>>>>>>>>> is also "undecidable" because it is not a semantically sound
>>>>>>>>>>> proposition having a truth value.
>>>>>>>>>>
>>>>>>>>>> But we know that it halts at the full stop.
>>>>>>>>>>
>>>>>>>>>>> Can Carol correctly answer “no” to this (yes/no) question?
>>>>>>>>>>
>>>>>>>>>> You have, I see, learned that not all yes/no questions are 
>>>>>>>>>> decidable. Well done! You're coming along nicely.
>>>>>>>>>>
>>>>>>>>>>> Both Yes and No are the wrong answer proving that
>>>>>>>>>>> the question is incorrect when the context of who
>>>>>>>>>>> is asked is understood to be a linguistically required
>>>>>>>>>>> aspect of the full meaning of the question.
>>>>>>>>>>
>>>>>>>>>> The question is grammatically and syntactically unremarkable. 
>>>>>>>>>> I see no grounds for claiming that it's 'incorrect'. It's just 
>>>>>>>>>> undecidable.
>>>>>>>>>>
>>>>>>>>>> You appear to be trying to overturn the Halting Problem by 
>>>>>>>>>> claiming that Turing somehow cheated. You're entitled to hold 
>>>>>>>>>> that opinion, but it's not one that will gain any traction 
>>>>>>>>>> with peer reviewers when you try to publish.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> *EVERYONE IGNORES THIS*
>>>>>>>>> It is very simple the mapping from inputs to outputs
>>>>>>>>> must have a well defined sequence of steps.
>>>>>>>>>
>>>>>>>>
>>>>>>>> FALSE!!!
>>>>>>>>
>>>>>>>> There is no requirement that mappings have steps to compute them.
>>>>>>>>
>>>>>>>
>>>>>>> The requirement is that 
>>>>>>
>>>>>> Assuming that an algorithm exists that can compute the following 
>>>>>> mapping:
>>>>>>
>>>>>>
>>>>>> Given any algorithm (i.e. a fixed immutable sequence of 
>>>>>> instructions) X described as <X> with input Y:
>>>>>>
>>>>>> A solution to the halting problem is an algorithm H that computes 
>>>>>> the following mapping:
>>>>>>
>>>>>> (<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
>>>>>> (<X>,Y) maps to 0 if and only if X(Y) does not halt when executed 
>>>>>> directly
>>>>>>
>>>>>>
>>>>>>> OUTPUTS must correspond
>>>>>>> to INPUTS. This requires that outputs must be
>>>>>>> derived from INPUTS.
>>>>>>
>>>>>> And when a contradiction is reached that proves the above 
>>>>>> assumption false, as Linz and others have proved, and you have 
>>>>>> *explicitly* admitted is correct.
>>>>>
>>>>> As I already said Linz is only correct when the halting
>>>>> problem proof is construed as 
>>>>
>>>> After assuming that an algorithm exists to map the halting function
>>>>
>>>>> having an input that can
>>>>> actually do the opposite of whatever value the termination
>>>>> analyzer returns. Since this is false,
>>>>
>>>> That proves the above assumption false, as Linz and others have 
>>>> proved and as you have *explicitly* agreed is correct.
>>>>
>>>
>>> The fundamental basic assumption of all of the halting
>>> problem proofs is that
>>
>> An algorithm exists that can compute the following mapping:
>>
>>
>> Given any algorithm (i.e. a fixed immutable sequence of instructions) 
>> X described as <X> with input Y:
>>
>> A solution to the halting problem is an algorithm H that computes the 
>> following mapping:
>>
>> (<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
>> (<X>,Y) maps to 0 if and only if X(Y) does not halt when executed 
>> directly
>>
>>
>>> THIS ASSUMPTION IS FALSE.
>>
>> As Linz and others have proved, and as you have *explicitly* agreed is 
>> correct.
> 
> Liar


Wrong again:


On 3/24/2025 10:07 PM, olcott wrote:
 > A halt decider cannot exist

On 4/28/2025 2:47 PM, olcott wrote:
 > On 4/28/2025 11:54 AM, dbush wrote:
 >> And the halting function below is not a computable function:
 >>
 >
 > It is NEVER a computable function
 >
 >> Given any algorithm (i.e. a fixed immutable sequence of 
instructions) X described as <X> with input Y:
 >>
 >> A solution to the halting problem is an algorithm H that computes 
the following mapping:
 >>
 >> (<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
 >> (<X>,Y) maps to 0 if and only if X(Y) does not halt when executed 
directly

On 3/14/2025 1:19 PM, olcott wrote:
 > When we define the HP as having H return a value
 > corresponding to the halting behavior of input D
 > and input D can actually does the opposite of whatever
 > value that H returns, then we have boxed ourselves
 > in to a problem having no solution.

On 6/21/2024 1:22 PM, olcott wrote:
 > the logical impossibility of specifying a halt decider H
 > that correctly reports the halt status of input D that is
 > defined to do the opposite of whatever value that H reports.
 > Of course this is impossible.

On 7/4/2023 12:57 AM, olcott wrote:
 > If you frame the problem in that a halt decider must divide up finite
 > strings pairs into those that halt when directly executed and those that
========== REMAINDER OF ARTICLE TRUNCATED ==========