# Re: Concise refutation of halting problem proofs V52 [ THE KEY QUESTION ]

1 view

### olcott

Jan 29, 2022, 3:29:48 PMJan 29
to
On 1/29/2022 11:34 AM, Ben Bacarisse wrote:
> Richard Damon <Ric...@Damon-Family.org> writes:
>
>> And the 'actual behavior of its actual inputs' is DEFINED to be what
>> the computation the input actually does when run as an independent
>> machine, or what a UTM will do when simulating that input.
>>
>> If that isn't the meaning you are using, then you are just lying that
>> you are working on the halting problem, which is what seems to be the
>> case. (That you are lying that is).
>
> It is certainly true that PO is not addressing the halting problem. He
> has been 100% clear that false is, in his "opinion", the correct result
> for at least one halting computation. This is not in dispute (unless
> he's retracted that and I missed it).
>

THIS POINT ADDRESSES THE KEY QUESTION
Which state does Ĥ applied to ⟨Ĥ⟩ transition to correctly ?

The following simplifies the syntax for the definition of the Linz
Turing machine Ĥ, it is now a single machine with a single start state.
A copy of Linz H is embedded at Ĥ.qx.

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

There are no finite number of steps of the pure simulation of ⟨Ĥ⟩
applied to ⟨Ĥ⟩ by embedded_H such that this simulated input meets the
Linz definition of halting:

computation that halts … the Turing machine will halt whenever it enters
a final state. (Linz:1990:234)

Therefore it is correct to say that the input to embedded_H specifies a
sequence of configurations that never halts.

https://www.researchgate.net/publication/358009319_Halting_problem_undecidability_and_infinitely_nested_simulation_V3

> To you and I, this means that he's not working on the halting problem,
> but I am not sure you can say he is lying about that. For one thing,
> how can he be intending to deceive (a core part of lying) when he's been
> clear the he accepts the wrong answer as being the right one? If
> someone claims to be working on "the addition problem", and also claims
> that 2+2=5 is correct, it's hard to consider either claim to be a lie.
> The person is just deeply confused.
>
> But what sort of confused can explain this nonsense? I think the answer
> lies in PO's background. The "binary square root" function is not
> computable as far as a mathematician is concerned because no TM can halt
> with, say, sqrt(0b10) on the tape. But to an engineer, the function
> poses no problem because we can get as close as we like. If
> 0b1.01101010000 is not good enough, just add more digits.
>
> The point is I think PO does not know what a formal, mathematical
> problem really is. To him, anything about code, machines or programs is
> about solving an engineering problem "well enough" -- with "well enough"
> open to be defined by PO himself.
>
> More disturbing to me is that he is not even talking about Turing
> machines, again as evidenced by his own plain words. It is not in
> dispute that he claims that two (deterministic) TMs, one an identical
> copy of the other, can transition to different states despite both being
> presented with identical input. These are not Turing machines but Magic
> machines, and I can't see how any discussion can be had while the action
> of the things being considered is not a simple function of the input and
> the state transition graph.
>

THIS POINT ADDRESSES A SIDE ISSUE NOT RELEVANT TO THE KEY QUESTION:
What are the details of how ⟨Ĥ⟩ applied to ⟨Ĥ⟩ behaves?

H and embedded_H are not identical, one has an infinite loop appended to
its accept state.

I will not tolerate digression into this side issue until after mutual
agreement is achieved on the first point. Until then these side issues
are no more than a dishonest dodge distraction away from the main point.

> This is why I stopped replying. While there are things to say about
> PO's Other Halting problem (principally that even the POOH problem can't
> be solved), I had nothing more to say while the "machines" being
> discussed are magic.
>

--