Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD)

On 5/10/25 4:26 PM, olcott wrote:

On 5/10/2025 3:07 PM, Alan Mackenzie wrote:

Mr Flibble <flibble@red-dwarf.jmc.corp> wrote:

On Sat, 10 May 2025 18:48:12 +0000, Alan Mackenzie wrote:

>

olcott <polcott333@gmail.com> wrote:

On 5/10/2025 7:37 AM, Bonita Montero wrote:

>

[ .... ]

>

I guess that not even a professor of theoretical computer science
would spend years working on so few lines of code.

>
>

I created a whole x86utm operating system.
It correctly determines that the halting problem's otherwise
"impossible" input is actually non halting.

>

You've spent over 20 years on this matter.  Compare this with Alan
Turing's solution of the Entscheidungsproblem.  He published this in
1936 when he was just 24 years old.

>

Turing didn't solve anything: what he published contained a mistake: the
category (type) error that I have described previously in this forum.

>
What arrogant self-important ignorance!  Turing indeed solved the
Entscheidungsproblem.  His procedure has been verified by hundreds of
thousands of mathematicians over the last century, and none of them have
found flaws in it.
>
It is overwhelmingly likely that your lack of mathematical training has
led you to delude yourself about finding an error.  The same applies to
Peter Olcott.
>

/Flibble

>

 Once we understand that functions computed
by models of computation must apply the sequence
of steps of an algorithm to derive their output
from their input then we have one key element.

Yes, but non-computable functions do not.

 Then we also need to understand that termination
analyzers are required to compute the mapping from
this input to the behavior ACTUALLY SPECIFIED by
this input.

And that behavior is SPECIFIED as the behavior of the program their input represents when it is actually run, (with any and all input for a termination analyser)

 The last step is understanding is that computing
the mapping to the behavior specified by this
input finite string must be according to the
model's computation language.

Only what the computation the generates, not the mapping for the CORRECT answer.

 This means that HHH is correct to reject its
input DD because DD emulated by HHH according
to the rules of the x86 language specifies
recursive emulation (non halting behavior).

Nope. As the input represents a program that will HALT since the decider it uses says it will not halt.
Of course, this requires that you actually built a program as the input, and as the decider, and thus they both have fixed behavior.
That means that when we correctly emulate that D, it *WILL* use the algorithm form the H that returned non-halting, and thus get that answer and thus halt.
THe fact that H's incorrect emulation didn't get there is irrelevent.

 *Likewise for the Linz Proof*
 When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
 (a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩  ...
 ⟨Ĥ⟩ correctly simulated by embedded_H cannot possibly
ever reach its own simulated final state ⟨Ĥ.qn⟩
 

But ⟨Ĥ⟩ isn't correctly simulated by embedded_H, as the H that it is a copy of has been said to abort and go to qn, is it will also.
You are just showing that you believe it is ok to lie in your logic.