On 4/12/22 12:34 AM, olcott wrote:
> On 4/11/2022 11:29 PM, André G. Isaak wrote:
>> On 2022-04-11 22:15, olcott wrote:
>>> On 4/11/2022 11:12 PM, André G. Isaak wrote:
>>>> On 2022-04-11 20:59, olcott wrote:
>>>>> On 4/11/2022 9:55 PM, André G. Isaak wrote:
>>>>>> On 2022-04-11 20:32, olcott wrote:
>>>>>>> On 4/11/2022 9:21 PM, André G. Isaak wrote:
>>>>>>>> On 2022-04-11 20:03, olcott wrote:
>>>>>>>>
>>>>>>>>> There is an inherent hole the the logic specified by Linz
>>>>>>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qy
>>>>>>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qn
>>>>>>>>>
>>>>>>>>> The Linz text basically says "magic happens here" ⊢*
>>>>>>>>> at the second wild card state transition shown above:
>>>>>>>>> https://www.liarparadox.org/Linz_Proof.pdf
>>>>>>>>
>>>>>>>> That's *not* what this notation means.
>>>>>>>>
>>>>>>>
>>>>>>> Page 237
>>>>>>> The symbols ⊢* and ⊢+ have the usual meaning of an arbitrary
>>>>>>> number of moves.
>>>>>>
>>>>>> Yes, I am aware of that.
>>>>>>
>>>>>>> Once I hit the first mistake I comment and then ignore the rest.
>>>>>>
>>>>>> There is a big difference between a "mistake" and something which
>>>>>> you simply did not understand.
>>>>>>
>>>>>>> The second ⊢* in Ĥ means an arbitrary number of (unspecified) moves
>>>>>>> Thus ⊢* really is the conventional notion of "magic happens here".
>>>>>>
>>>>>> Clearly, you didn't even read what I wrote.
>>>>>>
>>>>>> The purpose of a specification is to indicate WHAT a TM is
>>>>>> required to do rather than HOW it does that.
>>>>>
>>>>> That is why I am switching back to H(P,P).
>>>>
>>>> But if you don't even know *how* to read a specification
>>>
>>> Which is untrue, yet now we have complete x86 source-code, not merely
>>> ⊢* AKA some-thing-or-other-goes-here.
>>
>> But that is *not* what it means. This specification:
>>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>
> The claim is that Ĥ ⟨Ĥ⟩ gets the wrong answer.
>

No, because H^ isn't a decider, so it can't have teh wrong ANSWER.

The claim is that the behavior of H^ is contradictory to the requirements.

It is H that gets the "wrong answer" or alternatively "doesn't exist" as
a machine to meet the specifications

If H IS a correct Halt Decider than if H <H^> <H^> -> Qn then it must be
the case that H^ <H^> never halts, but it does, so H CAN'T go to Qn for
that input. Similarly if H <H^> <H^> -> Qy then H^ <H^< MUST Halt, but
if this is what H does, then its H^ will go to H^.Qy which goes into an
infinite loop and never halts, thus this path is also not possible.

We also know that H is defined to be a decider, so it MUST go to one of
those two states in finite time, but it can't do either.

Therefore H can't exist, as it is impossible for there to be an actual
machine to do what is required.

It can't be in the steps transforming H to H^ as those are well definied
and always possible, so it must be that H doesn't actually exist.

The fact you don't understand this points out the flaw in your thinking
ability, I don't think you understand how specifications work, or how
they can be impossible to meet.

On 4/11/22 11:05 PM, olcott wrote:
> On 4/11/2022 9:55 PM, André G. Isaak wrote:
>> On 2022-04-11 20:32, olcott wrote:
>>> On 4/11/2022 9:21 PM, André G. Isaak wrote:
>>>> On 2022-04-11 20:03, olcott wrote:
>>>>
>>>>> There is an inherent hole the the logic specified by Linz
>>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qy
>>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qn
>>>>>
>>>>> The Linz text basically says "magic happens here" ⊢*
>>>>> at the second wild card state transition shown above:
>>>>> https://www.liarparadox.org/Linz_Proof.pdf
>>>>
>>>> That's *not* what this notation means.
>>>>
>>>
>>> Page 237
>>> The symbols ⊢* and ⊢+ have the usual meaning of an arbitrary number
>>> of moves.
>>
>> Yes, I am aware of that.
>>
>>> Once I hit the first mistake I comment and then ignore the rest.
>>
>> There is a big difference between a "mistake" and something which you
>> simply did not understand.
>>
>>> The second ⊢* in Ĥ means an arbitrary number of (unspecified) moves
>>> Thus ⊢* really is the conventional notion of "magic happens here".
>>
>> Clearly, you didn't even read what I wrote.
>>
>> The purpose of a specification is to indicate WHAT a TM is required to
>> do rather than HOW it does that.
>
> That is why I am switching back to H(P,P)

So, since you don't understand what is a specification, how do you know
that your H meets the specification for the Turing Machine H?

It doesn't, so you FAIL.

>
> The simulated input to H(P,P) cannot possibly reach its own final state.
>
> _P()
> [00000956](01)  55              push ebp
> [00000957](02)  8bec            mov ebp,esp
> [00000959](03)  8b4508          mov eax,[ebp+08]
> [0000095c](01)  50              push eax       // push P
> [0000095d](03)  8b4d08          mov ecx,[ebp+08]
> [00000960](01)  51              push ecx       // push P
> [00000961](05)  e8c0feffff      call 00000826  // call H(P,P)
> The above keeps repeating until aborted

What is aborting it? A Correct Simulation does not abort. FAIL

Note, this is exactly the same issue as Ben pointed out.

If H DOES abort its simulation, then it is incorrect to do so, as we
then know that H(P,P) WOULD HAVE RETURNED if given a bit more time, so H
is incorrect in doing so. H needs to recognize that it is simulating a
copy of its self and increase it simulation threshold

But, if H doesn't abort its simulation it fails to give an answer.

THis is exactly the sort of issue as asking for the next x above a given
x in Q.

>
> [00000966](03)  83c408          add esp,+08
> [00000969](02)  85c0            test eax,eax
> [0000096b](02)  7402            jz 0000096f
> [0000096d](02)  ebfe            jmp 0000096d
> [0000096f](01)  5d              pop ebp
> [00000970](01)  c3              ret    // final state.
> Size in bytes:(0027) [00000970]
>
> Pages 4-5
> https://www.researchgate.net/publication/356105750_Halting_problem_undecidability_and_infinitely_nested_simulation_V2
>
>
>
>

On 4/11/22 10:59 PM, olcott wrote:
> On 4/11/2022 9:55 PM, André G. Isaak wrote:
>> On 2022-04-11 20:32, olcott wrote:
>>> On 4/11/2022 9:21 PM, André G. Isaak wrote:
>>>> On 2022-04-11 20:03, olcott wrote:
>>>>
>>>>> There is an inherent hole the the logic specified by Linz
>>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qy
>>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qn
>>>>>
>>>>> The Linz text basically says "magic happens here" ⊢*
>>>>> at the second wild card state transition shown above:
>>>>> https://www.liarparadox.org/Linz_Proof.pdf
>>>>
>>>> That's *not* what this notation means.
>>>>
>>>
>>> Page 237
>>> The symbols ⊢* and ⊢+ have the usual meaning of an arbitrary number
>>> of moves.
>>
>> Yes, I am aware of that.
>>
>>> Once I hit the first mistake I comment and then ignore the rest.
>>
>> There is a big difference between a "mistake" and something which you
>> simply did not understand.
>>
>>> The second ⊢* in Ĥ means an arbitrary number of (unspecified) moves
>>> Thus ⊢* really is the conventional notion of "magic happens here".
>>
>> Clearly, you didn't even read what I wrote.
>>
>> The purpose of a specification is to indicate WHAT a TM is required to
>> do rather than HOW it does that.
>
> That is why I am switching back to H(P,P).
>
>

Right, because you don't understand how to specify deal with the
specification of a Turing Machine, so you switch to a domain which you
can't even show that your 'program' meets the requirments to be the
equivalent of a Turing Machine (you don't understand the specification
of Church-Turing).

On 4/12/22 12:15 AM, olcott wrote:
> On 4/11/2022 11:12 PM, André G. Isaak wrote:
>> On 2022-04-11 20:59, olcott wrote:
>>> On 4/11/2022 9:55 PM, André G. Isaak wrote:
>>>> On 2022-04-11 20:32, olcott wrote:
>>>>> On 4/11/2022 9:21 PM, André G. Isaak wrote:
>>>>>> On 2022-04-11 20:03, olcott wrote:
>>>>>>
>>>>>>> There is an inherent hole the the logic specified by Linz
>>>>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qy
>>>>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qn
>>>>>>>
>>>>>>> The Linz text basically says "magic happens here" ⊢*
>>>>>>> at the second wild card state transition shown above:
>>>>>>> https://www.liarparadox.org/Linz_Proof.pdf
>>>>>>
>>>>>> That's *not* what this notation means.
>>>>>>
>>>>>
>>>>> Page 237
>>>>> The symbols ⊢* and ⊢+ have the usual meaning of an arbitrary number
>>>>> of moves.
>>>>
>>>> Yes, I am aware of that.
>>>>
>>>>> Once I hit the first mistake I comment and then ignore the rest.
>>>>
>>>> There is a big difference between a "mistake" and something which
>>>> you simply did not understand.
>>>>
>>>>> The second ⊢* in Ĥ means an arbitrary number of (unspecified) moves
>>>>> Thus ⊢* really is the conventional notion of "magic happens here".
>>>>
>>>> Clearly, you didn't even read what I wrote.
>>>>
>>>> The purpose of a specification is to indicate WHAT a TM is required
>>>> to do rather than HOW it does that.
>>>
>>> That is why I am switching back to H(P,P).
>>
>> But if you don't even know *how* to read a specification
>
> Which is untrue, yet now we have complete x86 source-code, not merely ⊢*
> AKA some-thing-or-other-goes-here.
>
>

But it doesn't meet the requirements of H.

So it just FAILS.

olcott <NoOne@NoWhere.com> writes:

> On 4/11/2022 8:02 PM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 4/11/2022 6:55 PM, Ben wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 4/10/2022 7:05 PM, Ben wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 4/10/2022 4:18 PM, Ben wrote:
>>
>>>>>>>> The truth is not determined by who does or does not agree with
>>>>>>>> something. But to find the truth of the matter you must first stop
>>>>>>>> talking literal nonsense. The arguments to H (what you call the
>>>>>>>> "input") are two pointers. What does simulating two pointers mean?
>>>>>>>> What you mean, I hope, is simulating calling the first pointer with the
>>>>>>>> second as it's argument. That simulation, according to you, will halt
>>>>>>>> (or "reach it's final state" in your flamboyant, sciencey, language).
>>>>>>>> It will halt because the direct call P(P) halts. Everything here halts
>>>>>>>> (according to you). That's why H is wrong.
>>>>>>>
>>>>>>> You simply are ignoring the actual execution trace that conclusively
>>>>>>> proves that the simulated input to H cannot possibly reach its final
>>>>>>> own state.
>>>>>> The traces that matter are the one of P(P) halting (you made the mistake
>>>>>> of posting it once), and the one of H(P,P) return false (you posted that
>>>>>> as well). You a free to retract any of these at any time, but until you
>>>>>> do, your H is wrong by your own supplied traces.
>>>>>
>>>>> It is never the case that the simulated input to H(P,P) ever reaches
>>>>> its own final state.
>>>>
>>>> Waffle. HP(P) halts so (P,P) == false is wrong. You can retract
>> typo: "so H(P,P) == false is wrong"
>>>> these facts (since they come from you in the first place). Until
>>>> then, you've told us that your H is wrong.
>>>
>>> It is the case that the simulated input never reaches its [00000970]
>>> machine address, no waffle there merely an easily verified fact.
>> You can verify a thousand more irrelevant facts. The facts that matter
>> are already known: that P(P) halts and that H(P,P) == false. Are you
>> presenting any verified facts that corrects this mistake? If so, just
>> say and I'll stop quoting it.
>
> The sequence of configurations specified by P(P) intuitively seems
> like it must be identical to the correct simulation of the input to
> H(P,P). It turns out that intuition is incorrect.

So which fact are you retracting? That P(P) halts or that H(P,P) ==
false?

--
Ben.

olcott <NoOne@NoWhere.com> writes:

> On 4/11/2022 8:17 PM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 4/11/2022 6:52 PM, Ben wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 4/10/2022 7:00 PM, Ben wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 4/10/2022 4:41 PM, Ben wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>>>> The above means this:
>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>>>>>>>> That's funny! You really have no idea what this notation means, do you?
>>>>>>>>
>>>>>>>>> embedded_H is a simulating halt decider that has a full UTM embedded
>>>>>>>>> within it. As soon as it sees that the pure UTM simulation of its
>>>>>>>>> input would never reach the final state of this input it aborts this
>>>>>>>>> simulation and rejects this non-halting input.
>>>>>>>>
>>>>>>>> So you had no business writing those two junk lines, did you? Or do you
>>>>>>>> really think that they are in some way compatible with that last
>>>>>>>> paragraph? Probably neither. I really think you see it much like
>>>>>>>> poetry. Meanings are supposed to be intuited from unusual, often
>>>>>>>> metaphorical, juxtapositions of symbols.
>>>>>>>
>>>>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qy
>>>>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ2⟩ ⊢* H.qn
>>>>>> Still junk.
>>>>>>
>>>>>
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>>>> If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to embedded_H would reach its
>>>>> own final state.
>>>>>
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>>>>> If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to embedded_H would never
>>>>> reach its own final state.
>>>> Still junk. Mixing embedded_H and H. Also H.qy is a final state so
>>>> this is not the hat construction form Linz. Also uses triger word
>>>> "would". What matters is what is the case, not what would be the case.
>>>> But, much like a poem, I can a feeling for what you might mean -- it's
>>>> the same old reject is correct because of what would happen if H (and
>>>> it's embedded copy) where not the TMs that actually are.
>>>> To see why you are clearly wrong, just say what state H ⟨Ĥ⟩ ⟨Ĥ⟩
>>>> transitions to, and what string must be passed to H for H to tell us
>>>> whether Ĥ applied to ⟨Ĥ⟩ halts or not.
>>>
>>> The fact that I do not express myself perfectly does not freaking mean
>>> that the key essence of all my ideas is not exactly correct.
Correction:
>> Absolutely right. The reason the key essence of all your ideas is
>> known to be wrong is because you have, occasionally, been clear.
>
> I addressed this in my other reply to you.
>
> I am only talking about H(P,P) now because if someone imagines that it
> does differently that it does an actual execution trace proves that
> they are incorrect as a matter of objective fact with zero room for
> debate.

That's good because you have been 100% clear about H. It's wrong
because P(P) halts (according to you) and H(P,P) == false (according to
you).

--
Ben.

On 4/12/2022 8:06 AM, Ben wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 4/11/2022 8:02 PM, Ben wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 4/11/2022 6:55 PM, Ben wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 4/10/2022 7:05 PM, Ben wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 4/10/2022 4:18 PM, Ben wrote:
>>>
>>>>>>>>> The truth is not determined by who does or does not agree with
>>>>>>>>> something. But to find the truth of the matter you must first stop
>>>>>>>>> talking literal nonsense. The arguments to H (what you call the
>>>>>>>>> "input") are two pointers. What does simulating two pointers mean?
>>>>>>>>> What you mean, I hope, is simulating calling the first pointer with the
>>>>>>>>> second as it's argument. That simulation, according to you, will halt
>>>>>>>>> (or "reach it's final state" in your flamboyant, sciencey, language).
>>>>>>>>> It will halt because the direct call P(P) halts. Everything here halts
>>>>>>>>> (according to you). That's why H is wrong.
>>>>>>>>
>>>>>>>> You simply are ignoring the actual execution trace that conclusively
>>>>>>>> proves that the simulated input to H cannot possibly reach its final
>>>>>>>> own state.
>>>>>>> The traces that matter are the one of P(P) halting (you made the mistake
>>>>>>> of posting it once), and the one of H(P,P) return false (you posted that
>>>>>>> as well). You a free to retract any of these at any time, but until you
>>>>>>> do, your H is wrong by your own supplied traces.
>>>>>>
>>>>>> It is never the case that the simulated input to H(P,P) ever reaches
>>>>>> its own final state.
>>>>>
>>>>> Waffle. HP(P) halts so (P,P) == false is wrong. You can retract
>>> typo: "so H(P,P) == false is wrong"
>>>>> these facts (since they come from you in the first place). Until
>>>>> then, you've told us that your H is wrong.
>>>>
>>>> It is the case that the simulated input never reaches its [00000970]
>>>> machine address, no waffle there merely an easily verified fact.
>>> You can verify a thousand more irrelevant facts. The facts that matter
>>> are already known: that P(P) halts and that H(P,P) == false. Are you
>>> presenting any verified facts that corrects this mistake? If so, just
>>> say and I'll stop quoting it.
>>
>> The sequence of configurations specified by P(P) intuitively seems
>> like it must be identical to the correct simulation of the input to
>> H(P,P). It turns out that intuition is incorrect.
>
> So which fact are you retracting? That P(P) halts or that H(P,P) ==
> false?
>

As long as the correctly simulated input to H(P,P) cannot possibly reach
the final state of this input then we know that it never halts even if
everyone in the universe disagrees.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 4/12/2022 8:09 AM, Ben wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 4/11/2022 8:17 PM, Ben wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 4/11/2022 6:52 PM, Ben wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 4/10/2022 7:00 PM, Ben wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 4/10/2022 4:41 PM, Ben wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>>>> The above means this:
>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>>>>>>>>> That's funny! You really have no idea what this notation means, do you?
>>>>>>>>>
>>>>>>>>>> embedded_H is a simulating halt decider that has a full UTM embedded
>>>>>>>>>> within it. As soon as it sees that the pure UTM simulation of its
>>>>>>>>>> input would never reach the final state of this input it aborts this
>>>>>>>>>> simulation and rejects this non-halting input.
>>>>>>>>>
>>>>>>>>> So you had no business writing those two junk lines, did you? Or do you
>>>>>>>>> really think that they are in some way compatible with that last
>>>>>>>>> paragraph? Probably neither. I really think you see it much like
>>>>>>>>> poetry. Meanings are supposed to be intuited from unusual, often
>>>>>>>>> metaphorical, juxtapositions of symbols.
>>>>>>>>
>>>>>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qy
>>>>>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ2⟩ ⊢* H.qn
>>>>>>> Still junk.
>>>>>>>
>>>>>>
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>>>>> If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to embedded_H would reach its
>>>>>> own final state.
>>>>>>
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>>>>>> If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to embedded_H would never
>>>>>> reach its own final state.
>>>>> Still junk. Mixing embedded_H and H. Also H.qy is a final state so
>>>>> this is not the hat construction form Linz. Also uses triger word
>>>>> "would". What matters is what is the case, not what would be the case.
>>>>> But, much like a poem, I can a feeling for what you might mean -- it's
>>>>> the same old reject is correct because of what would happen if H (and
>>>>> it's embedded copy) where not the TMs that actually are.
>>>>> To see why you are clearly wrong, just say what state H ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>> transitions to, and what string must be passed to H for H to tell us
>>>>> whether Ĥ applied to ⟨Ĥ⟩ halts or not.
>>>>
>>>> The fact that I do not express myself perfectly does not freaking mean
>>>> that the key essence of all my ideas is not exactly correct.
> Correction:
>>> Absolutely right. The reason the key essence of all your ideas is
>>> known to be wrong is because you have, occasionally, been clear.
>>
>> I addressed this in my other reply to you.
>>
>> I am only talking about H(P,P) now because if someone imagines that it
>> does differently that it does an actual execution trace proves that
>> they are incorrect as a matter of objective fact with zero room for
>> debate.
>
> That's good because you have been 100% clear about H. It's wrong
> because P(P) halts (according to you) and H(P,P) == false (according to
> you).
>

Why do you insist that a halt decider must compute the mapping from
non-inputs: P(P) when you know that it only computes the mapping from
inputs H(P,P) ?

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 2022-04-11 22:34, olcott wrote:
> On 4/11/2022 11:29 PM, André G. Isaak wrote:
>> On 2022-04-11 22:15, olcott wrote:
>>> On 4/11/2022 11:12 PM, André G. Isaak wrote:
>>>> On 2022-04-11 20:59, olcott wrote:
>>>>> On 4/11/2022 9:55 PM, André G. Isaak wrote:
>>>>>> On 2022-04-11 20:32, olcott wrote:
>>>>>>> On 4/11/2022 9:21 PM, André G. Isaak wrote:
>>>>>>>> On 2022-04-11 20:03, olcott wrote:
>>>>>>>>
>>>>>>>>> There is an inherent hole the the logic specified by Linz
>>>>>>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qy
>>>>>>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qn
>>>>>>>>>
>>>>>>>>> The Linz text basically says "magic happens here" ⊢*
>>>>>>>>> at the second wild card state transition shown above:
>>>>>>>>> https://www.liarparadox.org/Linz_Proof.pdf
>>>>>>>>
>>>>>>>> That's *not* what this notation means.
>>>>>>>>
>>>>>>>
>>>>>>> Page 237
>>>>>>> The symbols ⊢* and ⊢+ have the usual meaning of an arbitrary
>>>>>>> number of moves.
>>>>>>
>>>>>> Yes, I am aware of that.
>>>>>>
>>>>>>> Once I hit the first mistake I comment and then ignore the rest.
>>>>>>
>>>>>> There is a big difference between a "mistake" and something which
>>>>>> you simply did not understand.
>>>>>>
>>>>>>> The second ⊢* in Ĥ means an arbitrary number of (unspecified) moves
>>>>>>> Thus ⊢* really is the conventional notion of "magic happens here".
>>>>>>
>>>>>> Clearly, you didn't even read what I wrote.
>>>>>>
>>>>>> The purpose of a specification is to indicate WHAT a TM is
>>>>>> required to do rather than HOW it does that.
>>>>>
>>>>> That is why I am switching back to H(P,P).
>>>>
>>>> But if you don't even know *how* to read a specification
>>>
>>> Which is untrue, yet now we have complete x86 source-code, not merely
>>> ⊢* AKA some-thing-or-other-goes-here.
>>
>> But that is *not* what it means. This specification:
>>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn

The above line is *not* anything I wrote. If you're going to quote me at
least leave the text intact.

> The claim is that Ĥ ⟨Ĥ⟩ gets the wrong answer.

How can that be 'the claim' given that Ĥ is not even claimed to answer
any specific question? You can't be wrong unless there is some question
you claim to be answering.

André

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

On 4/12/2022 3:30 PM, André G. Isaak wrote:
> On 2022-04-11 22:34, olcott wrote:
>> On 4/11/2022 11:29 PM, André G. Isaak wrote:
>>> On 2022-04-11 22:15, olcott wrote:
>>>> On 4/11/2022 11:12 PM, André G. Isaak wrote:
>>>>> On 2022-04-11 20:59, olcott wrote:
>>>>>> On 4/11/2022 9:55 PM, André G. Isaak wrote:
>>>>>>> On 2022-04-11 20:32, olcott wrote:
>>>>>>>> On 4/11/2022 9:21 PM, André G. Isaak wrote:
>>>>>>>>> On 2022-04-11 20:03, olcott wrote:
>>>>>>>>>
>>>>>>>>>> There is an inherent hole the the logic specified by Linz
>>>>>>>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qy
>>>>>>>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qn
>>>>>>>>>>
>>>>>>>>>> The Linz text basically says "magic happens here" ⊢*
>>>>>>>>>> at the second wild card state transition shown above:
>>>>>>>>>> https://www.liarparadox.org/Linz_Proof.pdf
>>>>>>>>>
>>>>>>>>> That's *not* what this notation means.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Page 237
>>>>>>>> The symbols ⊢* and ⊢+ have the usual meaning of an arbitrary
>>>>>>>> number of moves.
>>>>>>>
>>>>>>> Yes, I am aware of that.
>>>>>>>
>>>>>>>> Once I hit the first mistake I comment and then ignore the rest.
>>>>>>>
>>>>>>> There is a big difference between a "mistake" and something which
>>>>>>> you simply did not understand.
>>>>>>>
>>>>>>>> The second ⊢* in Ĥ means an arbitrary number of (unspecified) moves
>>>>>>>> Thus ⊢* really is the conventional notion of "magic happens here".
>>>>>>>
>>>>>>> Clearly, you didn't even read what I wrote.
>>>>>>>
>>>>>>> The purpose of a specification is to indicate WHAT a TM is
>>>>>>> required to do rather than HOW it does that.
>>>>>>
>>>>>> That is why I am switching back to H(P,P).
>>>>>
>>>>> But if you don't even know *how* to read a specification
>>>>
>>>> Which is untrue, yet now we have complete x86 source-code, not
>>>> merely ⊢* AKA some-thing-or-other-goes-here.
>>>
>>> But that is *not* what it means. This specification:
>>>
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>
> The above line is *not* anything I wrote. If you're going to quote me at
> least leave the text intact.
>
>> The claim is that Ĥ ⟨Ĥ⟩ gets the wrong answer.
>
> How can that be 'the claim' given that Ĥ is not even claimed to answer
> any specific question? You can't be wrong unless there is some question
> you claim to be answering.
>
> André
>

The claim is that embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ gets the wrong answer.

I prove that embedded_H correctly maps the actual simulated behavior of
its input: ⟨Ĥ⟩ ⟨Ĥ⟩ to its own reject state.

When the analogous proof of H(P,P) is examined all opinions to the
contrary are conclusively proven to be counter-factual.

The correctly simulated input to H(P,P) would never reach its own final
state.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 2022-04-12 14:47, olcott wrote:
> On 4/12/2022 3:30 PM, André G. Isaak wrote:
>> On 2022-04-11 22:34, olcott wrote:
>>> On 4/11/2022 11:29 PM, André G. Isaak wrote:
>>>> On 2022-04-11 22:15, olcott wrote:
>>>>> On 4/11/2022 11:12 PM, André G. Isaak wrote:
>>>>>> On 2022-04-11 20:59, olcott wrote:
>>>>>>> On 4/11/2022 9:55 PM, André G. Isaak wrote:
>>>>>>>> On 2022-04-11 20:32, olcott wrote:
>>>>>>>>> On 4/11/2022 9:21 PM, André G. Isaak wrote:
>>>>>>>>>> On 2022-04-11 20:03, olcott wrote:
>>>>>>>>>>
>>>>>>>>>>> There is an inherent hole the the logic specified by Linz
>>>>>>>>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qy
>>>>>>>>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qn
>>>>>>>>>>>
>>>>>>>>>>> The Linz text basically says "magic happens here" ⊢*
>>>>>>>>>>> at the second wild card state transition shown above:
>>>>>>>>>>> https://www.liarparadox.org/Linz_Proof.pdf
>>>>>>>>>>
>>>>>>>>>> That's *not* what this notation means.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Page 237
>>>>>>>>> The symbols ⊢* and ⊢+ have the usual meaning of an arbitrary
>>>>>>>>> number of moves.
>>>>>>>>
>>>>>>>> Yes, I am aware of that.
>>>>>>>>
>>>>>>>>> Once I hit the first mistake I comment and then ignore the rest.
>>>>>>>>
>>>>>>>> There is a big difference between a "mistake" and something
>>>>>>>> which you simply did not understand.
>>>>>>>>
>>>>>>>>> The second ⊢* in Ĥ means an arbitrary number of (unspecified)
>>>>>>>>> moves
>>>>>>>>> Thus ⊢* really is the conventional notion of "magic happens here".
>>>>>>>>
>>>>>>>> Clearly, you didn't even read what I wrote.
>>>>>>>>
>>>>>>>> The purpose of a specification is to indicate WHAT a TM is
>>>>>>>> required to do rather than HOW it does that.
>>>>>>>
>>>>>>> That is why I am switching back to H(P,P).
>>>>>>
>>>>>> But if you don't even know *how* to read a specification
>>>>>
>>>>> Which is untrue, yet now we have complete x86 source-code, not
>>>>> merely ⊢* AKA some-thing-or-other-goes-here.
>>>>
>>>> But that is *not* what it means. This specification:
>>>>
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>>
>> The above line is *not* anything I wrote. If you're going to quote me
>> at least leave the text intact.
>>
>>> The claim is that Ĥ ⟨Ĥ⟩ gets the wrong answer.
>>
>> How can that be 'the claim' given that Ĥ is not even claimed to answer
>> any specific question? You can't be wrong unless there is some
>> question you claim to be answering.
>>
>> André
>>
>
> The claim is that embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ gets the wrong answer.

No. The claim is that H ⟨Ĥ⟩ ⟨Ĥ⟩ must get the wrong answer if Ĥ is
derived from H in the manner specified by the proof. What you call
"embedded_H" is not even a Turing Machine; it is simply *part* of Ĥ, and
Ĥ is not a decider so it can neither be right nor wrong.

André

> I prove that embedded_H correctly maps the actual simulated behavior of
> its input: ⟨Ĥ⟩ ⟨Ĥ⟩ to its own reject state.
>
> When the analogous proof of H(P,P) is examined all opinions to the
> contrary are conclusively proven to be counter-factual.
>
> The correctly simulated input to H(P,P) would never reach its own final
> state.

No. The correctly simulated input to H(P, P) *does* reach a final state.
Your simulator aborts the simulation before it gets to that state
because your simulator bases its decision on a faulty pattern.

If you consider the simulation of P(P) at the point where H aborts the
simulation and then continue to *manually* step through it after that
point you will find that it eventually identifies the same pattern in
its input that H based its decision on, and then abort its input and
halt for the exact same reason that H(P, P) halts.

André

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

On 2022-04-11 18:52, olcott wrote:
> On 4/11/2022 7:50 PM, André G. Isaak wrote:
>> On 2022-04-11 18:07, olcott wrote:
>>
>>> It is the case that the simulated input never reaches its [00000970]
>>> machine address, no waffle there merely an easily verified fact.
>>>
>>> _P()
>>> [00000956](01)  55              push ebp
>>> [00000957](02)  8bec            mov ebp,esp
>>> [00000959](03)  8b4508          mov eax,[ebp+08]
>>> [0000095c](01)  50              push eax      // push P
>>> [0000095d](03)  8b4d08          mov ecx,[ebp+08]
>>> [00000960](01)  51              push ecx      // push P
>>> [00000961](05)  e8c0feffff      call 00000826 // H(P,P)
>>>
>>> // The above (as simulated input) keeps repeating until aborted.
>>
>> But the above shows a *direct* call, not a call to a simulator (it has
>> the wrong number of arguments if it is a call to a simulator).
> I will provide more detail for you.

When exactly do you plan on doing this?

André

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

On 4/12/2022 3:58 PM, André G. Isaak wrote:
> On 2022-04-12 14:47, olcott wrote:
>> On 4/12/2022 3:30 PM, André G. Isaak wrote:
>>> On 2022-04-11 22:34, olcott wrote:
>>>> On 4/11/2022 11:29 PM, André G. Isaak wrote:
>>>>> On 2022-04-11 22:15, olcott wrote:
>>>>>> On 4/11/2022 11:12 PM, André G. Isaak wrote:
>>>>>>> On 2022-04-11 20:59, olcott wrote:
>>>>>>>> On 4/11/2022 9:55 PM, André G. Isaak wrote:
>>>>>>>>> On 2022-04-11 20:32, olcott wrote:
>>>>>>>>>> On 4/11/2022 9:21 PM, André G. Isaak wrote:
>>>>>>>>>>> On 2022-04-11 20:03, olcott wrote:
>>>>>>>>>>>
>>>>>>>>>>>> There is an inherent hole the the logic specified by Linz
>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qy
>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qn
>>>>>>>>>>>>
>>>>>>>>>>>> The Linz text basically says "magic happens here" ⊢*
>>>>>>>>>>>> at the second wild card state transition shown above:
>>>>>>>>>>>> https://www.liarparadox.org/Linz_Proof.pdf
>>>>>>>>>>>
>>>>>>>>>>> That's *not* what this notation means.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Page 237
>>>>>>>>>> The symbols ⊢* and ⊢+ have the usual meaning of an arbitrary
>>>>>>>>>> number of moves.
>>>>>>>>>
>>>>>>>>> Yes, I am aware of that.
>>>>>>>>>
>>>>>>>>>> Once I hit the first mistake I comment and then ignore the rest.
>>>>>>>>>
>>>>>>>>> There is a big difference between a "mistake" and something
>>>>>>>>> which you simply did not understand.
>>>>>>>>>
>>>>>>>>>> The second ⊢* in Ĥ means an arbitrary number of (unspecified)
>>>>>>>>>> moves
>>>>>>>>>> Thus ⊢* really is the conventional notion of "magic happens
>>>>>>>>>> here".
>>>>>>>>>
>>>>>>>>> Clearly, you didn't even read what I wrote.
>>>>>>>>>
>>>>>>>>> The purpose of a specification is to indicate WHAT a TM is
>>>>>>>>> required to do rather than HOW it does that.
>>>>>>>>
>>>>>>>> That is why I am switching back to H(P,P).
>>>>>>>
>>>>>>> But if you don't even know *how* to read a specification
>>>>>>
>>>>>> Which is untrue, yet now we have complete x86 source-code, not
>>>>>> merely ⊢* AKA some-thing-or-other-goes-here.
>>>>>
>>>>> But that is *not* what it means. This specification:
>>>>>
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>>>
>>> The above line is *not* anything I wrote. If you're going to quote me
>>> at least leave the text intact.
>>>
>>>> The claim is that Ĥ ⟨Ĥ⟩ gets the wrong answer.
>>>
>>> How can that be 'the claim' given that Ĥ is not even claimed to
>>> answer any specific question? You can't be wrong unless there is some
>>> question you claim to be answering.
>>>
>>> André
>>>
>>
>> The claim is that embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ gets the wrong answer.
>
> No. The claim is that H ⟨Ĥ⟩ ⟨Ĥ⟩ must get the wrong answer if Ĥ is
> derived from H in the manner specified by the proof. What you call
> "embedded_H" is not even a Turing Machine; it is simply *part* of Ĥ, and
> Ĥ is not a decider so it can neither be right nor wrong.
>

It is the case that the input ⟨Ĥ⟩ ⟨Ĥ⟩ to embedded_H never halts
therefore embedded_H is impossibly incorrect.

> André
>
>> I prove that embedded_H correctly maps the actual simulated behavior
>> of its input: ⟨Ĥ⟩ ⟨Ĥ⟩ to its own reject state.
>>
>> When the analogous proof of H(P,P) is examined all opinions to the
>> contrary are conclusively proven to be counter-factual.
>>
>> The correctly simulated input to H(P,P) would never reach its own
>> final state.
>
> No. The correctly simulated input to H(P, P) *does* reach a final state.

That is counter-factual:
The simulated input to H(P,P) cannot possibly reach its own final state
it keeps repeating [00000956] to [00000961] until aborted.

_P()
[00000956](01) 55 push ebp
[00000957](02) 8bec mov ebp,esp
[00000959](03) 8b4508 mov eax,[ebp+08]
[0000095c](01) 50 push eax // push P
[0000095d](03) 8b4d08 mov ecx,[ebp+08]
[00000960](01) 51 push ecx // push P
[00000961](05) e8c0feffff call 00000826 // call H(P,P)

The above keeps repeating until aborted

[00000966](03) 83c408 add esp,+08
[00000969](02) 85c0 test eax,eax
[0000096b](02) 7402 jz 0000096f
[0000096d](02) ebfe jmp 0000096d
[0000096f](01) 5d pop ebp
[00000970](01) c3 ret // final state.
Size in bytes:(0027) [00000970]

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 4/12/22 4:47 PM, olcott wrote:
> On 4/12/2022 3:30 PM, André G. Isaak wrote:
>> On 2022-04-11 22:34, olcott wrote:
>>> On 4/11/2022 11:29 PM, André G. Isaak wrote:
>>>> On 2022-04-11 22:15, olcott wrote:
>>>>> On 4/11/2022 11:12 PM, André G. Isaak wrote:
>>>>>> On 2022-04-11 20:59, olcott wrote:
>>>>>>> On 4/11/2022 9:55 PM, André G. Isaak wrote:
>>>>>>>> On 2022-04-11 20:32, olcott wrote:
>>>>>>>>> On 4/11/2022 9:21 PM, André G. Isaak wrote:
>>>>>>>>>> On 2022-04-11 20:03, olcott wrote:
>>>>>>>>>>
>>>>>>>>>>> There is an inherent hole the the logic specified by Linz
>>>>>>>>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qy
>>>>>>>>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qn
>>>>>>>>>>>
>>>>>>>>>>> The Linz text basically says "magic happens here" ⊢*
>>>>>>>>>>> at the second wild card state transition shown above:
>>>>>>>>>>> https://www.liarparadox.org/Linz_Proof.pdf
>>>>>>>>>>
>>>>>>>>>> That's *not* what this notation means.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Page 237
>>>>>>>>> The symbols ⊢* and ⊢+ have the usual meaning of an arbitrary
>>>>>>>>> number of moves.
>>>>>>>>
>>>>>>>> Yes, I am aware of that.
>>>>>>>>
>>>>>>>>> Once I hit the first mistake I comment and then ignore the rest.
>>>>>>>>
>>>>>>>> There is a big difference between a "mistake" and something
>>>>>>>> which you simply did not understand.
>>>>>>>>
>>>>>>>>> The second ⊢* in Ĥ means an arbitrary number of (unspecified)
>>>>>>>>> moves
>>>>>>>>> Thus ⊢* really is the conventional notion of "magic happens here".
>>>>>>>>
>>>>>>>> Clearly, you didn't even read what I wrote.
>>>>>>>>
>>>>>>>> The purpose of a specification is to indicate WHAT a TM is
>>>>>>>> required to do rather than HOW it does that.
>>>>>>>
>>>>>>> That is why I am switching back to H(P,P).
>>>>>>
>>>>>> But if you don't even know *how* to read a specification
>>>>>
>>>>> Which is untrue, yet now we have complete x86 source-code, not
>>>>> merely ⊢* AKA some-thing-or-other-goes-here.
>>>>
>>>> But that is *not* what it means. This specification:
>>>>
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>>
>> The above line is *not* anything I wrote. If you're going to quote me
>> at least leave the text intact.
>>
>>> The claim is that Ĥ ⟨Ĥ⟩ gets the wrong answer.
>>
>> How can that be 'the claim' given that Ĥ is not even claimed to answer
>> any specific question? You can't be wrong unless there is some
>> question you claim to be answering.
>>
>> André
>>
>
> The claim is that embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ gets the wrong answer.

Then why did you say that H^ got the wrong answer? That's a DIFFERENT
machine.

>
> I prove that embedded_H correctly maps the actual simulated behavior of
> its input: ⟨Ĥ⟩ ⟨Ĥ⟩ to its own reject state.

Nope, you CLAIM that, but it has been PROVEN that it gets it wrong.

All you have proven is that embedded_H correctly answered the POOP question.

>
> When the analogous proof of H(P,P) is examined all opinions to the
> contrary are conclusively proven to be counter-factual.

Nope, it shows that either H isn't a computation, or it gets the wrong
answer.

>
> The correctly simulated input to H(P,P) would never reach its own final
> state.
>

Then NO H(P,P) can EVER answer, since that is where the abort occurs,
that or H isn't actually a Compuation.

Just proves how ignorant you are.

FAIL.

On 4/12/22 5:13 PM, olcott wrote:
> On 4/12/2022 3:58 PM, André G. Isaak wrote:
>> On 2022-04-12 14:47, olcott wrote:
>>> On 4/12/2022 3:30 PM, André G. Isaak wrote:
>>>> On 2022-04-11 22:34, olcott wrote:
>>>>> On 4/11/2022 11:29 PM, André G. Isaak wrote:
>>>>>> On 2022-04-11 22:15, olcott wrote:
>>>>>>> On 4/11/2022 11:12 PM, André G. Isaak wrote:
>>>>>>>> On 2022-04-11 20:59, olcott wrote:
>>>>>>>>> On 4/11/2022 9:55 PM, André G. Isaak wrote:
>>>>>>>>>> On 2022-04-11 20:32, olcott wrote:
>>>>>>>>>>> On 4/11/2022 9:21 PM, André G. Isaak wrote:
>>>>>>>>>>>> On 2022-04-11 20:03, olcott wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> There is an inherent hole the the logic specified by Linz
>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qy
>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qn
>>>>>>>>>>>>>
>>>>>>>>>>>>> The Linz text basically says "magic happens here" ⊢*
>>>>>>>>>>>>> at the second wild card state transition shown above:
>>>>>>>>>>>>> https://www.liarparadox.org/Linz_Proof.pdf
>>>>>>>>>>>>
>>>>>>>>>>>> That's *not* what this notation means.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Page 237
>>>>>>>>>>> The symbols ⊢* and ⊢+ have the usual meaning of an arbitrary
>>>>>>>>>>> number of moves.
>>>>>>>>>>
>>>>>>>>>> Yes, I am aware of that.
>>>>>>>>>>
>>>>>>>>>>> Once I hit the first mistake I comment and then ignore the rest.
>>>>>>>>>>
>>>>>>>>>> There is a big difference between a "mistake" and something
>>>>>>>>>> which you simply did not understand.
>>>>>>>>>>
>>>>>>>>>>> The second ⊢* in Ĥ means an arbitrary number of (unspecified)
>>>>>>>>>>> moves
>>>>>>>>>>> Thus ⊢* really is the conventional notion of "magic happens
>>>>>>>>>>> here".
>>>>>>>>>>
>>>>>>>>>> Clearly, you didn't even read what I wrote.
>>>>>>>>>>
>>>>>>>>>> The purpose of a specification is to indicate WHAT a TM is
>>>>>>>>>> required to do rather than HOW it does that.
>>>>>>>>>
>>>>>>>>> That is why I am switching back to H(P,P).
>>>>>>>>
>>>>>>>> But if you don't even know *how* to read a specification
>>>>>>>
>>>>>>> Which is untrue, yet now we have complete x86 source-code, not
>>>>>>> merely ⊢* AKA some-thing-or-other-goes-here.
>>>>>>
>>>>>> But that is *not* what it means. This specification:
>>>>>>
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>>>>
>>>> The above line is *not* anything I wrote. If you're going to quote
>>>> me at least leave the text intact.
>>>>
>>>>> The claim is that Ĥ ⟨Ĥ⟩ gets the wrong answer.
>>>>
>>>> How can that be 'the claim' given that Ĥ is not even claimed to
>>>> answer any specific question? You can't be wrong unless there is
>>>> some question you claim to be answering.
>>>>
>>>> André
>>>>
>>>
>>> The claim is that embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ gets the wrong answer.
>>
>> No. The claim is that H ⟨Ĥ⟩ ⟨Ĥ⟩ must get the wrong answer if Ĥ is
>> derived from H in the manner specified by the proof. What you call
>> "embedded_H" is not even a Turing Machine; it is simply *part* of Ĥ,
>> and Ĥ is not a decider so it can neither be right nor wrong.
>>
>
> It is the case that the input ⟨Ĥ⟩ ⟨Ĥ⟩ to embedded_H never halts
> therefore embedded_H is impossibly incorrect.
>
>> André
>>
>>> I prove that embedded_H correctly maps the actual simulated behavior
>>> of its input: ⟨Ĥ⟩ ⟨Ĥ⟩ to its own reject state.
>>>
>>> When the analogous proof of H(P,P) is examined all opinions to the
>>> contrary are conclusively proven to be counter-factual.
>>>
>>> The correctly simulated input to H(P,P) would never reach its own
>>> final state.
>>
>> No. The correctly simulated input to H(P, P) *does* reach a final state.
>
> That is counter-factual:
> The simulated input to H(P,P) cannot possibly reach its own final state
> it keeps repeating [00000956] to [00000961] until aborted.
>
> _P()
> [00000956](01)  55              push ebp
> [00000957](02)  8bec            mov ebp,esp
> [00000959](03)  8b4508          mov eax,[ebp+08]
> [0000095c](01)  50              push eax       // push P
> [0000095d](03)  8b4d08          mov ecx,[ebp+08]
> [00000960](01)  51              push ecx       // push P
> [00000961](05)  e8c0feffff      call 00000826  // call H(P,P)
>
> The above keeps repeating until aborted

Then this ISN'T a correct simulatkon of the input, as CORRECT simulation
NEVER abort.

All this proves is that either H is incorrect, as one H answers H(P,P),
but it does so by saying that H doesn't answer H(P,P), or it proves that
H is not actually a computation.

FAIL.

>
> [00000966](03)  83c408          add esp,+08
> [00000969](02)  85c0            test eax,eax
> [0000096b](02)  7402            jz 0000096f
> [0000096d](02)  ebfe            jmp 0000096d
> [0000096f](01)  5d              pop ebp
> [00000970](01)  c3              ret    // final state.
> Size in bytes:(0027) [00000970]
>
>
>

On 4/12/22 11:22 AM, olcott wrote:
> On 4/12/2022 8:09 AM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 4/11/2022 8:17 PM, Ben wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 4/11/2022 6:52 PM, Ben wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 4/10/2022 7:00 PM, Ben wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 4/10/2022 4:41 PM, Ben wrote:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>>>> The above means this:
>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>>>>>>>>>> That's funny!  You really have no idea what this notation
>>>>>>>>>> means, do you?
>>>>>>>>>>
>>>>>>>>>>> embedded_H is a simulating halt decider that has a full UTM
>>>>>>>>>>> embedded
>>>>>>>>>>> within it. As soon as it sees that the pure UTM simulation of
>>>>>>>>>>> its
>>>>>>>>>>> input would never reach the final state of this input it
>>>>>>>>>>> aborts this
>>>>>>>>>>> simulation and rejects this non-halting input.
>>>>>>>>>>
>>>>>>>>>> So you had no business writing those two junk lines, did you?
>>>>>>>>>> Or do you
>>>>>>>>>> really think that they are in some way compatible with that last
>>>>>>>>>> paragraph?  Probably neither.  I really think you see it much
>>>>>>>>>> like
>>>>>>>>>> poetry.  Meanings are supposed to be intuited from unusual, often
>>>>>>>>>> metaphorical, juxtapositions of symbols.
>>>>>>>>>
>>>>>>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qy
>>>>>>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ2⟩ ⊢* H.qn
>>>>>>>> Still junk.
>>>>>>>>
>>>>>>>
>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>>>>>> If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to embedded_H would
>>>>>>> reach its
>>>>>>> own final state.
>>>>>>>
>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>>>>>>> If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to embedded_H would never
>>>>>>> reach its own final state.
>>>>>> Still junk.  Mixing embedded_H and H.  Also H.qy is a final state so
>>>>>> this is not the hat construction form Linz.  Also uses triger word
>>>>>> "would".  What matters is what is the case, not what would be the
>>>>>> case.
>>>>>> But, much like a poem, I can a feeling for what you might mean --
>>>>>> it's
>>>>>> the same old reject is correct because of what would happen if H (and
>>>>>> it's embedded copy) where not the TMs that actually are.
>>>>>> To see why you are clearly wrong, just say what state H ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>> transitions to, and what string must be passed to H for H to tell us
>>>>>> whether Ĥ applied to ⟨Ĥ⟩ halts or not.
>>>>>
>>>>> The fact that I do not express myself perfectly does not freaking mean
>>>>> that the key essence of all my ideas is not exactly correct.
>> Correction:
>>>> Absolutely right.  The reason the key essence of all your ideas is
>>>> known to be wrong is because you have, occasionally, been clear.
>>>
>>> I addressed this in my other reply to you.
>>>
>>> I am only talking about H(P,P) now because if someone imagines that it
>>> does differently that it does an actual execution trace proves that
>>> they are incorrect as a matter of objective fact with zero room for
>>> debate.
>>
>> That's good because you have been 100% clear about H.  It's wrong
>> because P(P) halts (according to you) and H(P,P) == false (according to
>> you).
>>
>
> Why do you insist that a halt decider must compute the mapping from
> non-inputs: P(P) when you know that it only computes the mapping from
> inputs H(P,P) ?
>

Because that ISN'T what is being insisted.

The input is P,P (or <H^> <H^>)

The MAPPING is definied as the behavior of P(P) or H^ applied to <H^>

You don't seem to be able to understand this, probably because you can't
understand what a specification is.

Remember, the DEFINITION of H is:

H applied to <M> w needs to -> Qy if M applied to w halts, and
H applied to <M> w needs to -> Qn if M applied to w never halts.

Thus H <H^> <H^> needs to go to Qy or Qn based on the behavior of H^
applied to <H^>, which you INCORRECT reject as not the requirement, when
it is BY DEFINITION.

You just don't understand the fundamentals. FAIL.

On 4/12/22 11:19 AM, olcott wrote:
> On 4/12/2022 8:06 AM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 4/11/2022 8:02 PM, Ben wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 4/11/2022 6:55 PM, Ben wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 4/10/2022 7:05 PM, Ben wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 4/10/2022 4:18 PM, Ben wrote:
>>>>
>>>>>>>>>> The truth is not determined by who does or does not agree with
>>>>>>>>>> something.  But to find the truth of the matter you must first
>>>>>>>>>> stop
>>>>>>>>>> talking literal nonsense.  The arguments to H (what you call the
>>>>>>>>>> "input") are two pointers.  What does simulating two pointers
>>>>>>>>>> mean?
>>>>>>>>>> What you mean, I hope, is simulating calling the first pointer
>>>>>>>>>> with the
>>>>>>>>>> second as it's argument.  That simulation, according to you,
>>>>>>>>>> will halt
>>>>>>>>>> (or "reach it's final state" in your flamboyant, sciencey,
>>>>>>>>>> language).
>>>>>>>>>> It will halt because the direct call P(P) halts.  Everything
>>>>>>>>>> here halts
>>>>>>>>>> (according to you).  That's why H is wrong.
>>>>>>>>>
>>>>>>>>> You simply are ignoring the actual execution trace that
>>>>>>>>> conclusively
>>>>>>>>> proves that the simulated input to H cannot possibly reach its
>>>>>>>>> final
>>>>>>>>> own state.
>>>>>>>> The traces that matter are the one of P(P) halting (you made the
>>>>>>>> mistake
>>>>>>>> of posting it once), and the one of H(P,P) return false (you
>>>>>>>> posted that
>>>>>>>> as well).  You a free to retract any of these at any time, but
>>>>>>>> until you
>>>>>>>> do, your H is wrong by your own supplied traces.
>>>>>>>
>>>>>>> It is never the case that the simulated input to H(P,P) ever reaches
>>>>>>> its own final state.
>>>>>>
>>>>>> Waffle.  HP(P) halts so (P,P) == false is wrong.  You can retract
>>>> typo: "so H(P,P) == false is wrong"
>>>>>> these facts (since they come from you in the first place).  Until
>>>>>> then, you've told us that your H is wrong.
>>>>>
>>>>> It is the case that the simulated input never reaches its [00000970]
>>>>> machine address, no waffle there merely an easily verified fact.
>>>> You can verify a thousand more irrelevant facts.  The facts that matter
>>>> are already known: that P(P) halts and that H(P,P) == false.  Are you
>>>> presenting any verified facts that corrects this mistake?  If so, just
>>>> say and I'll stop quoting it.
>>>
>>> The sequence of configurations specified by P(P) intuitively seems
>>> like it must be identical to the correct simulation of the input to
>>> H(P,P).  It turns out that intuition is incorrect.
>>
>> So which fact are you retracting?  That P(P) halts or that H(P,P) ==
>> false?
>>
>
> As long as the correctly simulated input to H(P,P) cannot possibly reach
> the final state of this input then we know that it never halts even if
> everyone in the universe disagrees.
>

Except that IT DOES, and you posted the proof previously (when you
called it H_Hat)

On 4/27/21 12:55 AM, olcott wrote:
Message-ID: <Teudndbu59GVBBr9nZ2dnUU7-V2dnZ2d@giganews.com>
> void H_Hat(u32 P)
> {
> u32 Input_Halts = Halts(P, P);
> if (Input_Halts)
> HERE: goto HERE;
> }
>
>
> int main()
> {
> H_Hat((u32)H_Hat);
> }
>
>
> _H_Hat()
> [00000b98](01) 55 push ebp
> [00000b99](02) 8bec mov ebp,esp
>
[00000b9b](01) 51 push ecx
> [00000b9c](03) 8b4508 mov eax,[ebp+08]
> [00000b9f](01) 50 push eax
> [00000ba0](03) 8b4d08 mov ecx,[ebp+08]
> [00000ba3](01) 51 push ecx
> [00000ba4](05) e88ffdffff call 00000938
> [00000ba9](03) 83c408 add esp,+08
> [00000bac](03) 8945fc mov [ebp-04],eax
> [00000baf](04) 837dfc00 cmp dword [ebp-04],+00
> [00000bb3](02) 7402 jz 00000bb7
> [00000bb5](02) ebfe jmp 00000bb5
> [00000bb7](02) 8be5 mov esp,ebp
> [00000bb9](01) 5d pop ebp
> [00000bba](01) c3 ret
> Size in bytes:(0035) [00000bba]
>
> _main()
> [00000bc8](01) 55 push ebp
> [00000bc9](02) 8bec mov ebp,esp
> [00000bcb](05) 68980b0000 push 00000b98
> [00000bd0](05) e8c3ffffff call 00000b98
> [00000bd5](03) 83c404 add esp,+04
> [00000bd8](02) 33c0 xor eax,eax
> [00000bda](01) 5d pop ebp
> [00000bdb](01) c3 ret
> Size in bytes:(0020) [00000bdb]
>
> ===============================
> ...[00000bc8][001015d4][00000000](01) 55 push ebp
> ...[00000bc9][001015d4][00000000](02) 8bec mov ebp,esp
> ...[00000bcb][001015d0][00000b98](05) 68980b0000 push 00000b98
> ...[00000bd0][001015cc][00000bd5](05) e8c3ffffff call 00000b98
> ...[00000b98][001015c8][001015d4](01) 55 push ebp
> ...[00000b99][001015c8][001015d4](02) 8bec mov ebp,esp
> ...[00000b9b][001015c4][00000000](01) 51 push ecx
> ...[00000b9c][001015c4][00000000](03) 8b4508 mov eax,[ebp+08]
> ...[00000b9f][001015c0][00000b98](01) 50 push eax
> ...[00000ba0][001015c0][00000b98](03) 8b4d08 mov ecx,[ebp+08]
> ...[00000ba3][001015bc][00000b98](01) 51 push ecx
> ...[00000ba4][001015b8][00000ba9](05) e88ffdffff call 00000938
> Begin Local Halt Decider Simulation at Machine Address:b98
> ...[00000b98][00211674][00211678](01) 55 push ebp
> ...[00000b99][00211674][00211678](02) 8bec mov ebp,esp
> ...[00000b9b][00211670][00201644](01) 51 push ecx
> ...[00000b9c][00211670][00201644](03) 8b4508 mov eax,[ebp+08]
> ...[00000b9f][0021166c][00000b98](01) 50 push eax
> ...[00000ba0][0021166c][00000b98](03) 8b4d08 mov ecx,[ebp+08]
> ...[00000ba3][00211668][00000b98](01) 51 push ecx
> ...[00000ba4][00211664][00000ba9](05) e88ffdffff call 00000938
> ...[00000b98][0025c09c][0025c0a0](01) 55 push ebp
> ...[00000b99][0025c09c][0025c0a0](02) 8bec mov ebp,esp
> ...[00000b9b][0025c098][0024c06c](01) 51 push ecx
> ...[00000b9c][0025c098][0024c06c](03) 8b4508 mov eax,[ebp+08]
> ...[00000b9f][0025c094][00000b98](01) 50 push eax
> ...[00000ba0][0025c094][00000b98](03) 8b4d08 mov ecx,[ebp+08]
> ...[00000ba3][0025c090][00000b98](01) 51 push ecx
> ...[00000ba4][0025c08c][00000ba9](05) e88ffdffff call 00000938
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped

Above decision was from the call the Halts inside H_Hat, deciding that
H_Hat(H_Hat) seems to be non-halting, it then returns that answer and is
processed below:

> ...[00000ba9][001015c4][00000000](03) 83c408 add esp,+08
> ...[00000bac][001015c4][00000000](03) 8945fc mov [ebp-04],eax
> ...[00000baf][001015c4][00000000](04) 837dfc00 cmp dword [ebp-04],+00
> ...[00000bb3][001015c4][00000000](02) 7402 jz 00000bb7
> ...[00000bb7][001015c8][001015d4](02) 8be5 mov esp,ebp
> ...[00000bb9][001015cc][00000bd5](01) 5d pop ebp
> ...[00000bba][001015d0][00000b98](01) c3 ret
> ...[00000bd5][001015d4][00000000](03) 83c404 add esp,+04
> ...[00000bd8][001015d4][00000000](02) 33c0 xor eax,eax
> ...[00000bda][001015d8][00100000](01) 5d pop ebp
> ...[00000bdb][001015dc][00000098](01) c3 ret

olcott <NoOne@NoWhere.com> writes:

> On 4/12/2022 8:09 AM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 4/11/2022 8:17 PM, Ben wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 4/11/2022 6:52 PM, Ben wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 4/10/2022 7:00 PM, Ben wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 4/10/2022 4:41 PM, Ben wrote:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>>>> The above means this:
>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>>>>>>>>>> That's funny! You really have no idea what this notation means, do you?
>>>>>>>>>>
>>>>>>>>>>> embedded_H is a simulating halt decider that has a full UTM embedded
>>>>>>>>>>> within it. As soon as it sees that the pure UTM simulation of its
>>>>>>>>>>> input would never reach the final state of this input it aborts this
>>>>>>>>>>> simulation and rejects this non-halting input.
>>>>>>>>>>
>>>>>>>>>> So you had no business writing those two junk lines, did you? Or do you
>>>>>>>>>> really think that they are in some way compatible with that last
>>>>>>>>>> paragraph? Probably neither. I really think you see it much like
>>>>>>>>>> poetry. Meanings are supposed to be intuited from unusual, often
>>>>>>>>>> metaphorical, juxtapositions of symbols.
>>>>>>>>>
>>>>>>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qy
>>>>>>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ2⟩ ⊢* H.qn
>>>>>>>> Still junk.
>>>>>>>>
>>>>>>>
>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>>>>>> If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to embedded_H would reach its
>>>>>>> own final state.
>>>>>>>
>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>>>>>>> If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to embedded_H would never
>>>>>>> reach its own final state.
>>>>>> Still junk. Mixing embedded_H and H. Also H.qy is a final state so
>>>>>> this is not the hat construction form Linz. Also uses triger word
>>>>>> "would". What matters is what is the case, not what would be the case.
>>>>>> But, much like a poem, I can a feeling for what you might mean -- it's
>>>>>> the same old reject is correct because of what would happen if H (and
>>>>>> it's embedded copy) where not the TMs that actually are.
>>>>>> To see why you are clearly wrong, just say what state H ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>> transitions to, and what string must be passed to H for H to tell us
>>>>>> whether Ĥ applied to ⟨Ĥ⟩ halts or not.
>>>>>
>>>>> The fact that I do not express myself perfectly does not freaking mean
>>>>> that the key essence of all my ideas is not exactly correct.
>> Correction:
>>>> Absolutely right. The reason the key essence of all your ideas is
>>>> known to be wrong is because you have, occasionally, been clear.
>>>
>>> I addressed this in my other reply to you.
>>>
>>> I am only talking about H(P,P) now because if someone imagines that it
>>> does differently that it does an actual execution trace proves that
>>> they are incorrect as a matter of objective fact with zero room for
>>> debate.
>>
>> That's good because you have been 100% clear about H. It's wrong
>> because P(P) halts (according to you) and H(P,P) == false (according to
>> you).
>
> Why do you insist that a halt decider must compute the mapping from
> non-inputs: P(P) when you know that it only computes the mapping from
> inputs H(P,P) ?

I don't. H takes arguments (what you insist on calling inputs) and maps
them to a result. The correct result is defined by people who know what
the halting problem is -- you don't get to decide. You may never
understand the specification, but you only need to know one fact about
it: mapping the "inputs" P and P to false is wrong.

--
Ben.

olcott <NoOne@NoWhere.com> writes:

> On 4/12/2022 8:06 AM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 4/11/2022 8:02 PM, Ben wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 4/11/2022 6:55 PM, Ben wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 4/10/2022 7:05 PM, Ben wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 4/10/2022 4:18 PM, Ben wrote:
>>>>
>>>>>>>>>> The truth is not determined by who does or does not agree with
>>>>>>>>>> something. But to find the truth of the matter you must first stop
>>>>>>>>>> talking literal nonsense. The arguments to H (what you call the
>>>>>>>>>> "input") are two pointers. What does simulating two pointers mean?
>>>>>>>>>> What you mean, I hope, is simulating calling the first pointer with the
>>>>>>>>>> second as it's argument. That simulation, according to you, will halt
>>>>>>>>>> (or "reach it's final state" in your flamboyant, sciencey, language).
>>>>>>>>>> It will halt because the direct call P(P) halts. Everything here halts
>>>>>>>>>> (according to you). That's why H is wrong.
>>>>>>>>>
>>>>>>>>> You simply are ignoring the actual execution trace that conclusively
>>>>>>>>> proves that the simulated input to H cannot possibly reach its final
>>>>>>>>> own state.
>>>>>>>> The traces that matter are the one of P(P) halting (you made the mistake
>>>>>>>> of posting it once), and the one of H(P,P) return false (you posted that
>>>>>>>> as well). You a free to retract any of these at any time, but until you
>>>>>>>> do, your H is wrong by your own supplied traces.
>>>>>>>
>>>>>>> It is never the case that the simulated input to H(P,P) ever reaches
>>>>>>> its own final state.
>>>>>>
>>>>>> Waffle. HP(P) halts so (P,P) == false is wrong. You can retract
>>>> typo: "so H(P,P) == false is wrong"
>>>>>> these facts (since they come from you in the first place). Until
>>>>>> then, you've told us that your H is wrong.
>>>>>
>>>>> It is the case that the simulated input never reaches its [00000970]
>>>>> machine address, no waffle there merely an easily verified fact.
>>>> You can verify a thousand more irrelevant facts. The facts that matter
>>>> are already known: that P(P) halts and that H(P,P) == false. Are you
>>>> presenting any verified facts that corrects this mistake? If so, just
>>>> say and I'll stop quoting it.
>>>
>>> The sequence of configurations specified by P(P) intuitively seems
>>> like it must be identical to the correct simulation of the input to
>>> H(P,P). It turns out that intuition is incorrect.
>>
>> So which fact are you retracting? That P(P) halts or that H(P,P) ==
>> false?
>
> As long as the correctly simulated input to H(P,P) cannot possibly
> reach the final state of this input then we know that it never halts
> even if everyone in the universe disagrees.

So you plan to keep posting the same sentence in an attempt to take the
focus off the fact that H is obviously wrong? Do you think that will
work? I thought you recently switched to being wrong about Turing
machines because you were getting nowhere with being wrong about your C
code. Oh well, I hope you are having fun (only 18 dogs tonight).

--
Ben.

On 4/12/2022 7:47 PM, Ben wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 4/12/2022 8:09 AM, Ben wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 4/11/2022 8:17 PM, Ben wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 4/11/2022 6:52 PM, Ben wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 4/10/2022 7:00 PM, Ben wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> On 4/10/2022 4:41 PM, Ben wrote:
>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>>>> The above means this:
>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>>>>>>>>>>> That's funny! You really have no idea what this notation means, do you?
>>>>>>>>>>>
>>>>>>>>>>>> embedded_H is a simulating halt decider that has a full UTM embedded
>>>>>>>>>>>> within it. As soon as it sees that the pure UTM simulation of its
>>>>>>>>>>>> input would never reach the final state of this input it aborts this
>>>>>>>>>>>> simulation and rejects this non-halting input.
>>>>>>>>>>>
>>>>>>>>>>> So you had no business writing those two junk lines, did you? Or do you
>>>>>>>>>>> really think that they are in some way compatible with that last
>>>>>>>>>>> paragraph? Probably neither. I really think you see it much like
>>>>>>>>>>> poetry. Meanings are supposed to be intuited from unusual, often
>>>>>>>>>>> metaphorical, juxtapositions of symbols.
>>>>>>>>>>
>>>>>>>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qy
>>>>>>>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ2⟩ ⊢* H.qn
>>>>>>>>> Still junk.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>>>>>>> If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to embedded_H would reach its
>>>>>>>> own final state.
>>>>>>>>
>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>>>>>>>> If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to embedded_H would never
>>>>>>>> reach its own final state.
>>>>>>> Still junk. Mixing embedded_H and H. Also H.qy is a final state so
>>>>>>> this is not the hat construction form Linz. Also uses triger word
>>>>>>> "would". What matters is what is the case, not what would be the case.
>>>>>>> But, much like a poem, I can a feeling for what you might mean -- it's
>>>>>>> the same old reject is correct because of what would happen if H (and
>>>>>>> it's embedded copy) where not the TMs that actually are.
>>>>>>> To see why you are clearly wrong, just say what state H ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>> transitions to, and what string must be passed to H for H to tell us
>>>>>>> whether Ĥ applied to ⟨Ĥ⟩ halts or not.
>>>>>>
>>>>>> The fact that I do not express myself perfectly does not freaking mean
>>>>>> that the key essence of all my ideas is not exactly correct.
>>> Correction:
>>>>> Absolutely right. The reason the key essence of all your ideas is
>>>>> known to be wrong is because you have, occasionally, been clear.
>>>>
>>>> I addressed this in my other reply to you.
>>>>
>>>> I am only talking about H(P,P) now because if someone imagines that it
>>>> does differently that it does an actual execution trace proves that
>>>> they are incorrect as a matter of objective fact with zero room for
>>>> debate.
>>>
>>> That's good because you have been 100% clear about H. It's wrong
>>> because P(P) halts (according to you) and H(P,P) == false (according to
>>> you).
>>
>> Why do you insist that a halt decider must compute the mapping from
>> non-inputs: P(P) when you know that it only computes the mapping from
>> inputs H(P,P) ?
>
> I don't. H takes arguments (what you insist on calling inputs) and maps
> them to a result. The correct result is defined by people who know what
> the halting problem is -- you don't get to decide. You may never
> understand the specification, but you only need to know one fact about
> it: mapping the "inputs" P and P to false is wrong.
>

So in other words you are saying that mere opinions carry more weight
than the following verified fact:

The simulated input to H(P,P) cannot possibly reach its own final state
it keeps repeating [00000956] to [00000961] until aborted.

_P()
[00000956](01) 55 push ebp
[00000957](02) 8bec mov ebp,esp
[00000959](03) 8b4508 mov eax,[ebp+08]
[0000095c](01) 50 push eax // push P
[0000095d](03) 8b4d08 mov ecx,[ebp+08]
[00000960](01) 51 push ecx // push P
[00000961](05) e8c0feffff call 00000826 // call H(P,P)

The above keeps repeating until aborted

[00000966](03) 83c408 add esp,+08
[00000969](02) 85c0 test eax,eax
[0000096b](02) 7402 jz 0000096f
[0000096d](02) ebfe jmp 0000096d
[0000096f](01) 5d pop ebp
[00000970](01) c3 ret // final state.
Size in bytes:(0027) [00000970]

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 4/12/2022 7:49 PM, Ben wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 4/12/2022 8:06 AM, Ben wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 4/11/2022 8:02 PM, Ben wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 4/11/2022 6:55 PM, Ben wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 4/10/2022 7:05 PM, Ben wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> On 4/10/2022 4:18 PM, Ben wrote:
>>>>>
>>>>>>>>>>> The truth is not determined by who does or does not agree with
>>>>>>>>>>> something. But to find the truth of the matter you must first stop
>>>>>>>>>>> talking literal nonsense. The arguments to H (what you call the
>>>>>>>>>>> "input") are two pointers. What does simulating two pointers mean?
>>>>>>>>>>> What you mean, I hope, is simulating calling the first pointer with the
>>>>>>>>>>> second as it's argument. That simulation, according to you, will halt
>>>>>>>>>>> (or "reach it's final state" in your flamboyant, sciencey, language).
>>>>>>>>>>> It will halt because the direct call P(P) halts. Everything here halts
>>>>>>>>>>> (according to you). That's why H is wrong.
>>>>>>>>>>
>>>>>>>>>> You simply are ignoring the actual execution trace that conclusively
>>>>>>>>>> proves that the simulated input to H cannot possibly reach its final
>>>>>>>>>> own state.
>>>>>>>>> The traces that matter are the one of P(P) halting (you made the mistake
>>>>>>>>> of posting it once), and the one of H(P,P) return false (you posted that
>>>>>>>>> as well). You a free to retract any of these at any time, but until you
>>>>>>>>> do, your H is wrong by your own supplied traces.
>>>>>>>>
>>>>>>>> It is never the case that the simulated input to H(P,P) ever reaches
>>>>>>>> its own final state.
>>>>>>>
>>>>>>> Waffle. HP(P) halts so (P,P) == false is wrong. You can retract
>>>>> typo: "so H(P,P) == false is wrong"
>>>>>>> these facts (since they come from you in the first place). Until
>>>>>>> then, you've told us that your H is wrong.
>>>>>>
>>>>>> It is the case that the simulated input never reaches its [00000970]
>>>>>> machine address, no waffle there merely an easily verified fact.
>>>>> You can verify a thousand more irrelevant facts. The facts that matter
>>>>> are already known: that P(P) halts and that H(P,P) == false. Are you
>>>>> presenting any verified facts that corrects this mistake? If so, just
>>>>> say and I'll stop quoting it.
>>>>
>>>> The sequence of configurations specified by P(P) intuitively seems
>>>> like it must be identical to the correct simulation of the input to
>>>> H(P,P). It turns out that intuition is incorrect.
>>>
>>> So which fact are you retracting? That P(P) halts or that H(P,P) ==
>>> false?
>>
>> As long as the correctly simulated input to H(P,P) cannot possibly
>> reach the final state of this input then we know that it never halts
>> even if everyone in the universe disagrees.
>
> So you plan to keep posting the same sentence in an attempt to take the
> focus off the fact that H is obviously wrong?

Then you must mean that a correctly simulated input that would never
reaches its own final state is still a computation that halts.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 4/12/22 9:12 PM, olcott wrote:
> On 4/12/2022 7:47 PM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 4/12/2022 8:09 AM, Ben wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 4/11/2022 8:17 PM, Ben wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 4/11/2022 6:52 PM, Ben wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 4/10/2022 7:00 PM, Ben wrote:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On 4/10/2022 4:41 PM, Ben wrote:
>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>>>> The above means this:
>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>>>>>>>>>>>> That's funny!  You really have no idea what this notation
>>>>>>>>>>>> means, do you?
>>>>>>>>>>>>
>>>>>>>>>>>>> embedded_H is a simulating halt decider that has a full UTM
>>>>>>>>>>>>> embedded
>>>>>>>>>>>>> within it. As soon as it sees that the pure UTM simulation
>>>>>>>>>>>>> of its
>>>>>>>>>>>>> input would never reach the final state of this input it
>>>>>>>>>>>>> aborts this
>>>>>>>>>>>>> simulation and rejects this non-halting input.
>>>>>>>>>>>>
>>>>>>>>>>>> So you had no business writing those two junk lines, did
>>>>>>>>>>>> you?  Or do you
>>>>>>>>>>>> really think that they are in some way compatible with that
>>>>>>>>>>>> last
>>>>>>>>>>>> paragraph?  Probably neither.  I really think you see it
>>>>>>>>>>>> much like
>>>>>>>>>>>> poetry.  Meanings are supposed to be intuited from unusual,
>>>>>>>>>>>> often
>>>>>>>>>>>> metaphorical, juxtapositions of symbols.
>>>>>>>>>>>
>>>>>>>>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qy
>>>>>>>>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ2⟩ ⊢* H.qn
>>>>>>>>>> Still junk.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>>>>>>>> If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to embedded_H would
>>>>>>>>> reach its
>>>>>>>>> own final state.
>>>>>>>>>
>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>>>>>>>>> If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to embedded_H would never
>>>>>>>>> reach its own final state.
>>>>>>>> Still junk.  Mixing embedded_H and H.  Also H.qy is a final
>>>>>>>> state so
>>>>>>>> this is not the hat construction form Linz.  Also uses triger word
>>>>>>>> "would".  What matters is what is the case, not what would be
>>>>>>>> the case.
>>>>>>>> But, much like a poem, I can a feeling for what you might mean
>>>>>>>> -- it's
>>>>>>>> the same old reject is correct because of what would happen if H
>>>>>>>> (and
>>>>>>>> it's embedded copy) where not the TMs that actually are.
>>>>>>>> To see why you are clearly wrong, just say what state H ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>> transitions to, and what string must be passed to H for H to
>>>>>>>> tell us
>>>>>>>> whether Ĥ applied to ⟨Ĥ⟩ halts or not.
>>>>>>>
>>>>>>> The fact that I do not express myself perfectly does not freaking
>>>>>>> mean
>>>>>>> that the key essence of all my ideas is not exactly correct.
>>>> Correction:
>>>>>> Absolutely right.  The reason the key essence of all your ideas is
>>>>>> known to be wrong is because you have, occasionally, been clear.
>>>>>
>>>>> I addressed this in my other reply to you.
>>>>>
>>>>> I am only talking about H(P,P) now because if someone imagines that it
>>>>> does differently that it does an actual execution trace proves that
>>>>> they are incorrect as a matter of objective fact with zero room for
>>>>> debate.
>>>>
>>>> That's good because you have been 100% clear about H.  It's wrong
>>>> because P(P) halts (according to you) and H(P,P) == false (according to
>>>> you).
>>>
>>> Why do you insist that a halt decider must compute the mapping from
>>> non-inputs: P(P) when you know that it only computes the mapping from
>>> inputs H(P,P) ?
>>
>> I don't.  H takes arguments (what you insist on calling inputs) and maps
>> them to a result.  The correct result is defined by people who know what
>> the halting problem is -- you don't get to decide.  You may never
>> understand the specification, but you only need to know one fact about
>> it: mapping the "inputs" P and P to false is wrong.
>>
>
> So in other words you are saying that mere opinions carry more weight
> than the following verified fact:

He isn't stating OPINION, he is stating FACTS.

>
> The simulated input to H(P,P) cannot possibly reach its own final state
> it keeps repeating [00000956] to [00000961] until aborted.
>
> _P()
> [00000956](01)  55              push ebp
> [00000957](02)  8bec            mov ebp,esp
> [00000959](03)  8b4508          mov eax,[ebp+08]
> [0000095c](01)  50              push eax       // push P
> [0000095d](03)  8b4d08          mov ecx,[ebp+08]
> [00000960](01)  51              push ecx       // push P
> [00000961](05)  e8c0feffff      call 00000826  // call H(P,P)
>
> The above keeps repeating until aborted
>
> [00000966](03)  83c408          add esp,+08
> [00000969](02)  85c0            test eax,eax
> [0000096b](02)  7402            jz 0000096f
> [0000096d](02)  ebfe            jmp 0000096d
> [0000096f](01)  5d              pop ebp
> [00000970](01)  c3              ret    // final state.
> Size in bytes:(0027) [00000970]
>

So what fact is that verifying??

Since BY DEFINITION, a correct simulation doesn't abort, all you have
proven is that you don't know what you are talking about!

In fact, this isn't the 'correct simulation' which you have posted (and
I recently reposted) but the simulation done by H.

This show that H can't be a correct decider, as if H does abort this
simulation, the either so does the H that P is calling (and thus P
halts), of your H just fails to meet the requirements of a Computation.

So it just PROVES you are wrong.

On 4/12/22 9:17 PM, olcott wrote:
> On 4/12/2022 7:49 PM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 4/12/2022 8:06 AM, Ben wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 4/11/2022 8:02 PM, Ben wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 4/11/2022 6:55 PM, Ben wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 4/10/2022 7:05 PM, Ben wrote:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On 4/10/2022 4:18 PM, Ben wrote:
>>>>>>
>>>>>>>>>>>> The truth is not determined by who does or does not agree with
>>>>>>>>>>>> something.  But to find the truth of the matter you must
>>>>>>>>>>>> first stop
>>>>>>>>>>>> talking literal nonsense.  The arguments to H (what you call
>>>>>>>>>>>> the
>>>>>>>>>>>> "input") are two pointers.  What does simulating two
>>>>>>>>>>>> pointers mean?
>>>>>>>>>>>> What you mean, I hope, is simulating calling the first
>>>>>>>>>>>> pointer with the
>>>>>>>>>>>> second as it's argument.  That simulation, according to you,
>>>>>>>>>>>> will halt
>>>>>>>>>>>> (or "reach it's final state" in your flamboyant, sciencey,
>>>>>>>>>>>> language).
>>>>>>>>>>>> It will halt because the direct call P(P) halts.  Everything
>>>>>>>>>>>> here halts
>>>>>>>>>>>> (according to you).  That's why H is wrong.
>>>>>>>>>>>
>>>>>>>>>>> You simply are ignoring the actual execution trace that
>>>>>>>>>>> conclusively
>>>>>>>>>>> proves that the simulated input to H cannot possibly reach
>>>>>>>>>>> its final
>>>>>>>>>>> own state.
>>>>>>>>>> The traces that matter are the one of P(P) halting (you made
>>>>>>>>>> the mistake
>>>>>>>>>> of posting it once), and the one of H(P,P) return false (you
>>>>>>>>>> posted that
>>>>>>>>>> as well).  You a free to retract any of these at any time, but
>>>>>>>>>> until you
>>>>>>>>>> do, your H is wrong by your own supplied traces.
>>>>>>>>>
>>>>>>>>> It is never the case that the simulated input to H(P,P) ever
>>>>>>>>> reaches
>>>>>>>>> its own final state.
>>>>>>>>
>>>>>>>> Waffle.  HP(P) halts so (P,P) == false is wrong.  You can retract
>>>>>> typo: "so H(P,P) == false is wrong"
>>>>>>>> these facts (since they come from you in the first place).  Until
>>>>>>>> then, you've told us that your H is wrong.
>>>>>>>
>>>>>>> It is the case that the simulated input never reaches its [00000970]
>>>>>>> machine address, no waffle there merely an easily verified fact.
>>>>>> You can verify a thousand more irrelevant facts.  The facts that
>>>>>> matter
>>>>>> are already known: that P(P) halts and that H(P,P) == false.  Are you
>>>>>> presenting any verified facts that corrects this mistake?  If so,
>>>>>> just
>>>>>> say and I'll stop quoting it.
>>>>>
>>>>> The sequence of configurations specified by P(P) intuitively seems
>>>>> like it must be identical to the correct simulation of the input to
>>>>> H(P,P).  It turns out that intuition is incorrect.
>>>>
>>>> So which fact are you retracting?  That P(P) halts or that H(P,P) ==
>>>> false?
>>>
>>> As long as the correctly simulated input to H(P,P) cannot possibly
>>> reach the final state of this input then we know that it never halts
>>> even if everyone in the universe disagrees.
>>
>> So you plan to keep posting the same sentence in an attempt to take the
>> focus off the fact that H is obviously wrong?
>
> Then you must mean that a correctly simulated input that would never
> reaches its own final state is still a computation that halts.
>

No, but the correct simulation of the input to H(P,P) DOES halt if H
says it doesn't.

This is a PROVED fact, that you ignore, thus H NEVER correctly says that.

The only way for the correct simulation of the input to H(P,P) to not
halt is for H(P,P) to not answer non-halting, so it is impossible for H
to correctly say this input doesn't halt.

That is just like saying you can prove that black is white.

Or basing a prove on the fact that black is white.

FAIL.

olcott <NoOne@NoWhere.com> writes:

> On 4/12/2022 7:47 PM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 4/12/2022 8:09 AM, Ben wrote:
>>>> olcott <NoOne@NoWhere.com> writes:

>>>>> On 4/11/2022 8:17 PM, Ben wrote:
>>>>> I am only talking about H(P,P) now because if someone imagines that it
>>>>> does differently that it does an actual execution trace proves that
>>>>> they are incorrect as a matter of objective fact with zero room for
>>>>> debate.
>>>>
>>>> That's good because you have been 100% clear about H. It's wrong
>>>> because P(P) halts (according to you) and H(P,P) == false (according to
>>>> you).
>>>
>>> Why do you insist that a halt decider must compute the mapping from
>>> non-inputs: P(P) when you know that it only computes the mapping from
>>> inputs H(P,P) ?
>>
>> I don't. H takes arguments (what you insist on calling inputs) and maps
>> them to a result. The correct result is defined by people who know what
>> the halting problem is -- you don't get to decide. You may never
>> understand the specification, but you only need to know one fact about
>> it: mapping the "inputs" P and P to false is wrong.
>
> So in other words you are saying that mere opinions carry more weight
> than the following verified fact:

The facts that (a) H(P,P) == false and (b) P(P) halts are not in dispute
(so far as I know). That H mapping P and P to false is wrong is a
matter of definition. There are no opinions being expressed here at
all.

--
Ben.

On 4/12/2022 8:55 PM, Ben wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 4/12/2022 7:47 PM, Ben wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 4/12/2022 8:09 AM, Ben wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>
>>>>>> On 4/11/2022 8:17 PM, Ben wrote:
>>>>>> I am only talking about H(P,P) now because if someone imagines that it
>>>>>> does differently that it does an actual execution trace proves that
>>>>>> they are incorrect as a matter of objective fact with zero room for
>>>>>> debate.
>>>>>
>>>>> That's good because you have been 100% clear about H. It's wrong
>>>>> because P(P) halts (according to you) and H(P,P) == false (according to
>>>>> you).
>>>>
>>>> Why do you insist that a halt decider must compute the mapping from
>>>> non-inputs: P(P) when you know that it only computes the mapping from
>>>> inputs H(P,P) ?
>>>
>>> I don't. H takes arguments (what you insist on calling inputs) and maps
>>> them to a result. The correct result is defined by people who know what
>>> the halting problem is -- you don't get to decide. You may never
>>> understand the specification, but you only need to know one fact about
>>> it: mapping the "inputs" P and P to false is wrong.
>>
>> So in other words you are saying that mere opinions carry more weight
>> than the following verified fact:
>
> The facts that (a) H(P,P) == false and (b) P(P) halts are not in dispute
> (so far as I know). That H mapping P and P to false is wrong is a
> matter of definition. There are no opinions being expressed here at
> all.
>

So you agree that an input that never halts is a halting computation.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer