Re: Halting Problem: What Constitutes Pathological Input

Op 06.mei.2025 om 22:49 schreef olcott:

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 input can actually do the
opposite of whatever value its decider returns.
THIS ASSUMPTION IS FALSE.
THE "DOING THE OPPOSITE" CODE IS UNREACHABLE.
 

The code is not unreachable, but the programmer decided to add code to abort before it could reach it. That error does not change the behaviour of the program specified in the input.