Re: Halting Problem: What Constitutes Pathological Input

On 5/6/25 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 OUTPUTS must correspond
to INPUTS. This requires that outputs must be
derived from INPUTS.

Nope. It helps to be correct, but if the mapping that it is computing doesn't actually depend on one of the inputs, then it doesn't need to use it.

 When DD is correctly emulated by HHH it is only
allowed to apply the specific sequence specified
by the x86 language to derive the behavior specified
by this input.

But HHH doesn't correctly emulate DD, so you are just shown to be a liar.
THe problem is your HHH stops when it sees the call instruciton, but the x86 language doesn't say to do that, it says to continue on at the called instruction.

 Everyone here seems to think that HHH is allowed
to ignore the "call" instruction in DD and jump
directly to the "ret" instruction in DD.
 

No, in needs to FULLY EMULATE it, which you don't do.
Part of your problem is you don't understand that HHH is a SPECIFIC program, not an "infinite set" of them, as it has been stipulated to be exactly the one specified in your published halt7.c
Sorry, you are just proving that you are just a damned liar that doesn't care about what is actually true.