On 8/16/22 7:19 PM, olcott wrote:
> This is an explanation of a possible new insight into the halting
> problem provided in the language of software engineering. Technical
> computer science terms are explained using software engineering terms.
> No knowledge of the halting problem is required.
No knowledge of the Halting Problem is ALLOWED, because knowledge of it
shows the errors in the definitions and logic.
>
> When the conventional “pathological” input (that does the opposite of
> whatever the halt decider decides) is the first argument to a simulating
> halt decider then this input becomes decidable as specifying infinitely
> recursive simulation.
Except it isn't, as shown by an ACTUAL correct and complete trace of the
H, if the H answers the problem as non-halting.
Except if that IS what H does, then H never answer, and so isn't a decider.
>
> When H(P,P) correctly predicts that its correct and complete x86
> emulation of its input would never halt, then H aborts the simulation of
> this input and correctly reports non-halting.
>
Excpet that when it does THAT, then it doesn't actually do a correct and
complete simulation of its input, and the ACTUAL correct and complete
simulation of the input will trace the behavior of that input past the
point that H aborted its simulation of it, to the point where the H in
the simulation does that same abort, and then sees it return to its
caller and the input halt.
> Since we can see that the correct and complete x86 emulation by H(P,P)
> of its first argument would never halt, H can be adapted to see this too.
Excpet that the input only never halts if H never aborts. Since P, by
DEFINITION, is using the exact same algorithm in its copy of H as the H
that you claim is being correct in deciding,
>
> A halt decider must compute the mapping from its arguments to an accept
> or reject state on the basis of the actual behavior that is actually
> specified by these arguments. The correct x86 emulation by H(P,P) of its
> first argument is the correct measure of the behavior of P.
Nope. The ACUTAL correct and complete simulation of the input is. If H
doesn't do that, then we need to look at a simulation that does.
The only H you have proven generates a non-halting P, is the H that
NEVER aborts its simulation, and that one never gives the "correct" answer.
For any H that does abort, the input is now different than what was seen
in that case, since it is based on the H that is aborting, and we just
showed that for THAT input, it Halts, so H is incorrect.
Just more of your lies, as explained above.
This has been explained to you MANY times, and you still don't seem to
understand it.
Either you are just mentally dificient and just can't learn these basic
facts, or you are just a pathelogical liar that doesn't care about what
is true.
You logic is JUST WRONG.
It is NOT "Correct Software Engineering Principles", it is just ERROR.