On 5/24/22 10:40 AM, olcott wrote:
> All of the recent discussions are simply disagreement with an easily
> verifiable fact. Any smart software engineer with a sufficient technical
> background can easily confirm that H(P,P)==0 is correct:

This is an incorrect statement, showable by the fact that NO "Smart
Software Engineers" have agreed with you, thus you prove your claim to
be a lie.

It has been shown that it is easy to verify that H(P,P) is NOT correct,
when you actually use the DEFINITIONS that apply, which you fail to do.

>
> Where H is a C function that correctly emulates its input pair of finite
> strings of the x86 machine code of function P and criterion for
> returning 0 is that the simulated P would never reach its "ret"
> instruction.

No, H does NOT correctly emulate its input, as it aborts it before it
reaches its end, so you claim is just a lie, showing that you don't know
what you are talking about.

The fact that YOU have previously posted a CORRECT trace of the input to
H(P,P) showing that it halts, is proof that you are wrong.

>
> (1) Good software engineering proves that H(P,P)==0 is correct.

WHAT "Good software engineering?" Faulty traces?

>
> The only other remaining objection is whether or not a halt decider must
> compute the mapping of its input finite strings to an accept or reject
> state on the basis of the actual behavior actually specified by its
> input OR SOME OTHER MEASURE.

Since the DEFINITION of the behavior of the input to H(P,P), is the
behaior of P(P), which can be verified with UTM(P,P) (and actual correct
emulatior with the same input) shows you are wrong.

>
> A decider must compute the mapping from its inputs finite strings to an
> accept of reject state. A computable function must compute the mapping
> of from inputs finite strings to its corresponding output.
> https://en.wikipedia.org/wiki/Computable_function

Right, and to be a "Something" decider, that mapping must be the
"Something" function, and the Halting FUnction is based the behavior of
a machine applied to an input. The attempted Halt Decider being given a
representation of these to decide on.

>
> (2) Good computer science shows that a halt decider must
> compute the mapping from its input finite strings to an accept or
> reject state on the basis of the actual behavior actually specified by
> its input. Since P(P) is not an input to H(P,P) it is excluded.
>
>

Except that the representation of it IS the input, and the fact that
UTM(P,P) can get the desired behavior show that it can be the behavior
of that input. The problem is that H can do it in finite time, and so
fails to be a decider.

>
>
> Halting problem undecidability and infinitely nested simulation (V5)
>
> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>
>

A bunch of lies and faulty logic.