info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Clarification of Linz Ĥ Description
5 views
Skip to first unread message
olcott
Sep 28, 2021, 11:20:35 PM9/28/21
to
The halting theorem counter-examples present infinitely nested
simulation (non-halting) behavior to every simulating halt decider.
-----1-----------2--3----------
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
If the simulation of the 2nd ⟨Ĥ⟩ applied to
the 3rd ⟨Ĥ⟩ at Ĥ.qx reaches its final state.
-----1-----------2--3----------
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
If the simulation of the 2nd ⟨Ĥ⟩ applied to
the 3rd ⟨Ĥ⟩ at Ĥ.qx never reaches its final state.
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
--
Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
simulation (non-halting) behavior to every simulating halt decider.
-----1-----------2--3----------
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
If the simulation of the 2nd ⟨Ĥ⟩ applied to
the 3rd ⟨Ĥ⟩ at Ĥ.qx reaches its final state.
-----1-----------2--3----------
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
If the simulation of the 2nd ⟨Ĥ⟩ applied to
the 3rd ⟨Ĥ⟩ at Ĥ.qx never reaches its final state.
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
--
Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
olcott
Sep 28, 2021, 11:47:52 PM9/28/21
to
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 simulating halt decider is embedded at Ĥ.qx. It has been annotated so
that it only shows Ĥ applied to ⟨Ĥ⟩, converting the variables to constants.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
if the simulated input to Ĥ.qx ⟨Ĥ⟩ applied to ⟨Ĥ⟩ reaches its final
state. (Halts)
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if the simulated input to Ĥ.qx ⟨Ĥ⟩ applied to ⟨Ĥ⟩ never reaches its
final state. (Does not halt)
Turing machine Ĥ, it is now a single machine with a single start state.
A simulating halt decider is embedded at Ĥ.qx. It has been annotated so
that it only shows Ĥ applied to ⟨Ĥ⟩, converting the variables to constants.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
state. (Halts)
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
final state. (Does not halt)
olcott
Sep 29, 2021, 7:19:18 PM9/29/21
to
On 9/29/2021 5:48 PM, Ben Bacarisse wrote:
> TM constructed in a certain way.
> is a sentence that is "not even wrong".
> halt".
>
> You must deny what Linz says because you are not talking about halt
> deciders. You are trying to pretend that Linz was talking about
> deciders for your other problem:
>
> This definition of halting circumvents the pathological self-reference
> error for every simulating halt decider:
>
> An input is decided to be halting only if ...
>
> On that basis:
> Ĥ(<Ĥ>) ⊢* Ĥ.qn
> H(<Ĥ>,<Ĥ>) ⊢* H.qn
>
> You don't get to say what halting is. It is already well-defined. Any
> definition that provides a basis for H rejecting a computation that is
> finite is garbage.
>
1----2-----3-----4--5-----6
When the halt decider at Ĥ.qx is a simulating halt decider the Linz
proof becomes about whether or not the simulation of (4) halts on its
input (5).
(B) The Linz proof is not about whether or not (1) halts on its input (2).
Although it may be over your head because it is very very difficult
to understand (A) and (B) are distinctly different computations that can
have opposite final states without contradiction.
> olcott <No...@NoWhere.com> writes:
>
>> The following simplifies the syntax for the definition of the Linz
>> Turing machine Ĥ, it is now a single machine
>
> It always was.
>
>> The following simplifies the syntax for the definition of the Linz
>> Turing machine Ĥ, it is now a single machine
>
>
>> with a single start state.
>
> All TM's have a single start state.
>> with a single start state.
>
>
>> A simulating halt decider is embedded at Ĥ.qx.
>
> This is not "clarifying" but restricting. Linz uses Ĥ to refer to any
>> A simulating halt decider is embedded at Ĥ.qx.
>
> TM constructed in a certain way.
>
>> It has been annotated so that it only shows Ĥ applied to ⟨Ĥ⟩,
>> converting the variables to constants.
>
> You don't know what at least two of those these words mean. The result
>> It has been annotated so that it only shows Ĥ applied to ⟨Ĥ⟩,
>> converting the variables to constants.
>
> is a sentence that is "not even wrong".
>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>> if the simulated input to Ĥ.qx ⟨Ĥ⟩ applied to ⟨Ĥ⟩ reaches its final
>> state. (Halts)
>
> The correct annotation is the one in Linz: "if Ĥ applied to ⟨Ĥ⟩ halts".
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>> if the simulated input to Ĥ.qx ⟨Ĥ⟩ applied to ⟨Ĥ⟩ reaches its final
>> state. (Halts)
>
>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>> if the simulated input to Ĥ.qx ⟨Ĥ⟩ applied to ⟨Ĥ⟩ never reaches its
>> final state. (Does not halt)
>
> The correct annotation is the one in Linz: "if Ĥ applied to ⟨Ĥ⟩ does not
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>> if the simulated input to Ĥ.qx ⟨Ĥ⟩ applied to ⟨Ĥ⟩ never reaches its
>> final state. (Does not halt)
>
> halt".
>
> You must deny what Linz says because you are not talking about halt
> deciders. You are trying to pretend that Linz was talking about
> deciders for your other problem:
>
> This definition of halting circumvents the pathological self-reference
> error for every simulating halt decider:
>
> An input is decided to be halting only if ...
>
> On that basis:
> Ĥ(<Ĥ>) ⊢* Ĥ.qn
> H(<Ĥ>,<Ĥ>) ⊢* H.qn
>
> You don't get to say what halting is. It is already well-defined. Any
> definition that provides a basis for H rejecting a computation that is
> finite is garbage.
>
1----2-----3-----4--5-----6
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
(A) The Linz proof is about whether or not (4) halts on its input (5).
When the halt decider at Ĥ.qx is a simulating halt decider the Linz
proof becomes about whether or not the simulation of (4) halts on its
input (5).
(B) The Linz proof is not about whether or not (1) halts on its input (2).
Although it may be over your head because it is very very difficult
to understand (A) and (B) are distinctly different computations that can
have opposite final states without contradiction.
olcott
Sep 30, 2021, 7:22:03 PM9/30/21
to
On 9/30/2021 5:55 PM, André G. Isaak wrote:
> On 2021-09-30 16:12, olcott wrote:
>
>> Because of a critique of my work in another forum I have discovered
>> that the halt status that H1(P,P) reports is consistent with the
>> behavior of int main() { P(P); }
>
> But how does this address the Linz proof then? You've derived your P
> from H, not from H1. So all that matter with respect to the Linz proof
> is what *H*(P, P) returns. That some other decider H1, from which P is
> *not* derived, can correctly decide P(P) has no bearing on Linz's claim.
> H1 cannot decide P1(P1) where P1 is derived from H1 in the same way that
> P is derived from H.
>
H(P,P) is correct and H1(P,P) is correct.
> And your proposed 'best of three' test won't work either, since it will
> be possible to derive a BestOfThree_Hat construction from your
> BestOfThree routine which your BestOfThree routine won't be able to decide.
>
> You don't seem to grasp that Linz is *not* claiming that there are
> computations whose halting status cannot be decided.
He is claiming that H does not exist:
The contradiction tells us that our assumption
of the existence of H, and hence the assumption
of the decidability of the halting problem,
must be false. (Linz 1990:320).
https://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf
Not only does the Linz H exist it gets the correct answer and this
answer is consistent with the behavior of Ĥ applied to ⟨Ĥ⟩
Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company. (318-320)
> He is claiming that
> there cannot be a *universal* halt decider because for every purported
> halt decider one can construct a TM which that specific halt decider
> cannot correctly decide.
>
> André
> On 2021-09-30 16:12, olcott wrote:
>
>> Because of a critique of my work in another forum I have discovered
>> that the halt status that H1(P,P) reports is consistent with the
>> behavior of int main() { P(P); }
>
> But how does this address the Linz proof then? You've derived your P
> from H, not from H1. So all that matter with respect to the Linz proof
> is what *H*(P, P) returns. That some other decider H1, from which P is
> *not* derived, can correctly decide P(P) has no bearing on Linz's claim.
> H1 cannot decide P1(P1) where P1 is derived from H1 in the same way that
> P is derived from H.
>
H(P,P) is correct and H1(P,P) is correct.
> And your proposed 'best of three' test won't work either, since it will
> be possible to derive a BestOfThree_Hat construction from your
> BestOfThree routine which your BestOfThree routine won't be able to decide.
>
> You don't seem to grasp that Linz is *not* claiming that there are
> computations whose halting status cannot be decided.
He is claiming that H does not exist:
The contradiction tells us that our assumption
of the existence of H, and hence the assumption
of the decidability of the halting problem,
must be false. (Linz 1990:320).
https://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf
Not only does the Linz H exist it gets the correct answer and this
answer is consistent with the behavior of Ĥ applied to ⟨Ĥ⟩
Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company. (318-320)
> He is claiming that
> there cannot be a *universal* halt decider because for every purported
> halt decider one can construct a TM which that specific halt decider
> cannot correctly decide.
>
> André
olcott
Sep 30, 2021, 7:58:28 PM9/30/21
to
On 9/30/2021 6:14 PM, Ben Bacarisse wrote:
> olcott <No...@NoWhere.com> writes:
>
> olcott <No...@NoWhere.com> writes:
>
>> On 9/30/2021 11:35 AM, Ben Bacarisse wrote:
>>> olcott <No...@NoWhere.com> writes:
>>>
>>>> On 9/29/2021 9:42 PM, Ben Bacarisse wrote:
>>>>> olcott <No...@NoWhere.com> writes:
>>>>>
>
>>>>>> H(<Ĥ>,<Ĥ>) ⊢* H.qy as I just said
>>> olcott <No...@NoWhere.com> writes:
>>>
>>>> On 9/29/2021 9:42 PM, Ben Bacarisse wrote:
>>>>> olcott <No...@NoWhere.com> writes:
>>>>>
>
>>>>>> H(<Ĥ>,<Ĥ>) ⊢* H.qy as I just said
>>>>>> H(<Ĥ>,<Ĥ>) ⊢* H.qy as I just said
>>>>>> H(<Ĥ>,<Ĥ>) ⊢* H.qy as I just said
>>>>>> H(<Ĥ>,<Ĥ>) ⊢* H.qy as I just said
>>>>> But you previously also said that H(<Ĥ>,<Ĥ>) ⊢* H.qn. You can't get mad
>>>>> because people believe what you write!
>>>>> Now I need to know how much of the post where you said that your new
>>>>> basis for halting gives H(<Ĥ>,<Ĥ>) ⊢* H.qn was /also/ wrong. All of it?
>>>>> It formed what appeared to be your entire justification for having
>>>>> "solved" the halting problem. Here is the whole thing:
>>>>> | My current proof simply shows exactly how the exact Peter Linz H would
>>>>> | correctly decide not halting on the exact Peter Linz Ĥ.
>>>>> |
>>>>> | This definition of halting circumvents the pathological self-reference
>>>>> | error for every simulating halt decider:
>>>>> |
>>>>> | An input is decided to be halting only if its simulation never needs
>>>>> | This definition of halting circumvents the pathological self-reference
>>>>> | error for every simulating halt decider:
>>>>> |
>>>>> | to be stopped by any simulating halt decider anywhere in its entire
>>>>> | invocation chain.
>>>>> |
>>>>> | On that basis:
>>>>> | Ĥ(<Ĥ>) ⊢* Ĥ.qn
>>>>> | H(<Ĥ>,<Ĥ>) ⊢* H.qn
>>>>
>>>> It seems a little shady that you don't cut-and-paste it with the time
>>>>> | On that basis:
>>>>> | Ĥ(<Ĥ>) ⊢* Ĥ.qn
>>>>> | H(<Ĥ>,<Ĥ>) ⊢* H.qn
>>>>
>>>> and date stamp as I ALWAYS do.
>>>
>>> It's Message-ID: <FL2dnU-wypwbXz_9...@giganews.com>
>>> Are you accusing me of misquoting you?
>>
>> I am accusing you of not providing proper support for your assertions.
>
> Good. So you do agree that you said it?
>
>> A cut-and-paste of my actual question that includes the time and date
>> stamp is the standard that I established for myself.
>
> I post a message ID if anyone is having trouble finding a post.
>
> You, presumably, knew all along that you have redefined what halting
> means so that H and H^ are no longer like Linz's H and H^. You,
> presumably, knew that with your definition H can reject a halting
> computation. After all, that's what everyone has been objecting to for
> the last few years. You can't have only just noticed that this is what
> people have been telling you.
>
>> If the above is an accurate quote (which has not been properly
>> established) then--->H(<Ĥ>,<Ĥ>) ⊢* H.qn is a typographical error.
>
> This is an appallingly dishonest claim. There is no possibility it is a
> typo. Why would you even try to pretend that it is? You say the same
> thing again in another post
>
> H(<Ĥ>,<Ĥ>) ⊢* H.qn
> Message-ID: <M9Kdnab-FpOgUD_9...@giganews.com>
> H(<Ĥ>,<Ĥ>) ⊢* H.qn
>
> and again using words this time
>
> H applied to input (Ĥ, Ĥ) transitions to H.qn
> Message-ID: <0cudnXyibs7OuDz9...@giganews.com>
>
> and again in words
>
> H(<Ĥ>,<Ĥ>) must abort the simulation of its input ∴ this input <is>
> correctly decided as non-halting.
> Message-ID: <_LednVXB0N9FGT_9...@giganews.com>
>
> and again using a slightly different notion here
>
> H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
> Message-ID: <2-adncuMeNUVpY78...@giganews.com>
>
> And then there is the fact that you've been saying exactly this in other
> ways for months:
>
> "Halts(Confound_Halts, Confound_Halts) returns false."
> Message-ID: <2aidnV9e3qQaOCDC...@giganews.com>
>
> and
>
> "The input to Halts is only finite because..."
> Message-ID: <6eSdnYuLBrIuVFzC...@giganews.com>
>
> And H(H_Hat, H_Hat) == false though H_Hat(H_Hat) halts. Post after post
> explaining why H(H_Hat, H_Hat) == 0 with H_Hat(H_Hat) halting might
> /seem/ wrong but is in fact correct because of how you define halting.
>
> No, it is not a typo. You are lying. You meant what you wrote, and
> people have been addressing what you now pretend is a typo for months.
> The scale of the dishonesty takes my breath away.
>
> I could explain why you are wrong to say
>
>> Ĥ(<Ĥ>) ⊢* Ĥ.qn and H(<Ĥ>,<Ĥ>) ⊢* H.qy
>
> but what's the point? You'll just claim that this was also a typo in a
> few months time. You can keep this up forever if you have no attachment
> to honesty or the truth.
>
You quoted me from five months ago my view has changed.
Here is my view now.
If you want to try to form an actual rebuttal and not just some form of
the strawman error that looks like a rebuttal to gullible fools that are
hardly paying attention you must address the following POINT-BY-POINT.
(A) Ĥ(<Ĥ>) ⊢* Ĥ.qn
(B) Ĥ.qx(<Ĥ>,<Ĥ>) ⊢* H.qn
Your whole basis of rebuttal from the beginning has been that (B) must
be wrong because it disagrees with the actual behavior of (A).
Now that I know that H(<Ĥ>,<Ĥ>) ⊢* H.qy
I have directly contradicted the Linz conclusion.
The contradiction tells us that our assumption
of the existence of H, and hence the assumption
of the decidability of the halting problem, must
be false. (Linz:1990:320)
Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company. (318-320)
to <Ĥ> never reaches any final state whether or not the simulating halt
decider at Ĥ.qx aborts its simulation of this input.
You can dishonestly call this another different halting problem yet you
know damn well it is the original halting problem.
That a computation never reaches its final state when this computation
is allowed to continue unabated is the very conventional definition of
not halting.
I don't know the proper way to say this because the definition of a
computation is restricted to sequence of steps that halts. This makes
non halting computations a contradiction in terms.
olcott
Sep 30, 2021, 9:28:09 PM9/30/21
to
On 9/30/2021 8:07 PM, André G. Isaak wrote:
> On 2021-09-30 18:54, olcott wrote:
>> On 9/30/2021 7:39 PM, André G. Isaak wrote:
>>> On 2021-09-30 18:26, olcott wrote:
>>>> On 9/30/2021 7:18 PM, André G. Isaak wrote:
>>>>> *need* H1? Why bring it up at all?
>>>>>
>>>>
>>>> H(P,P) correctly determines that its input never reaches its final
>>>> state whether or not H aborts the simulation of this input.
>>>>
>>>> H1(P,P) correctly determines that its input reaches its final state.
>>>
>>> They have the *same* input. Therefore they cannot both be correct
>>> unless they give the same answer. You can't have one of them claim
>>> that P(P) never reaches its final state and the other say that P(P)
>>> does reach its final state *and* claim they are both correct.
>>>
>>> That's Trump Logic.
>>>
>>> André
>>>
>>>
>>
>> You have to wait until finish converting functions H1 and H to pure
>> functions. They do derive this result now yet it is possible that this
>> result is an artifact of their requirement of static local data to
>> derive these results.
>>
>> If it works out like preliminary analysis indicates a pair of
>> functions with identical machine code and identical inputs really do
>> have different output because the input to H(P,P) calls H and the
>> input to H1(P,P) calls H (thus does not call H1).
>
> Your statement is entirely incoherent. If H(P, P) and H1(P, P) give
> different results then either:
>
> (A) one is wrong.
>
> or
>
> (B) they are not computing the same function, in which case at most
> *one* of them can actually be deciding the halting function.
>
> You understand that the halting function (which maps computations to
> halting values) is a mathematical object which exists independently of
> any Turing Machine or algorithm and has a fixed mapping from
> computations to {true, false}, right?
>
> André
>
It will continue to be impossible for you to overcome your false
assumptions until you see that:
(a) H1(P,P) correctly reports that its input reaches its final state.
(b) H(P,P) correctly reports that its input NEVER reaches its final
state (whether or not it aborts the simulation of this input).
(c) Both H1 and H are pure functions and have identical machine code.
In computer programming, a pure function is a function that has the
following properties:
(1) The function return values are identical for identical arguments (no
variation with local static variables, non-local variables, mutable
reference arguments or input streams).
(2) The function application has no side effects (no mutation of local
static variables, non-local variables, mutable reference arguments or
input/output streams).
https://en.wikipedia.org/wiki/Pure_function
> On 2021-09-30 18:54, olcott wrote:
>> On 9/30/2021 7:39 PM, André G. Isaak wrote:
>>> On 2021-09-30 18:26, olcott wrote:
>>>> On 9/30/2021 7:18 PM, André G. Isaak wrote:
>>>>> On 2021-09-30 17:21, olcott wrote:
>>>>>> On 9/30/2021 5:55 PM, André G. Isaak wrote:
>>>>>>> On 2021-09-30 16:12, olcott wrote:
>>>>>>>
>>>>>>>> Because of a critique of my work in another forum I have
>>>>>>>> discovered that the halt status that H1(P,P) reports is
>>>>>>>> consistent with the behavior of int main() { P(P); }
>>>>>>>
>>>>>>> But how does this address the Linz proof then? You've derived
>>>>>>> your P from H, not from H1. So all that matter with respect to
>>>>>>> the Linz proof is what *H*(P, P) returns. That some other decider
>>>>>>> H1, from which P is *not* derived, can correctly decide P(P) has
>>>>>>> no bearing on Linz's claim. H1 cannot decide P1(P1) where P1 is
>>>>>>> derived from H1 in the same way that P is derived from H.
>>>>>>>
>>>>>>
>>>>>> H(P,P) is correct and H1(P,P) is correct.
>>>>>
>>>>> So you're saying they both return true? If so, why on earth do you
>>>>>> On 9/30/2021 5:55 PM, André G. Isaak wrote:
>>>>>>> On 2021-09-30 16:12, olcott wrote:
>>>>>>>
>>>>>>>> Because of a critique of my work in another forum I have
>>>>>>>> discovered that the halt status that H1(P,P) reports is
>>>>>>>> consistent with the behavior of int main() { P(P); }
>>>>>>>
>>>>>>> But how does this address the Linz proof then? You've derived
>>>>>>> your P from H, not from H1. So all that matter with respect to
>>>>>>> the Linz proof is what *H*(P, P) returns. That some other decider
>>>>>>> H1, from which P is *not* derived, can correctly decide P(P) has
>>>>>>> no bearing on Linz's claim. H1 cannot decide P1(P1) where P1 is
>>>>>>> derived from H1 in the same way that P is derived from H.
>>>>>>>
>>>>>>
>>>>>> H(P,P) is correct and H1(P,P) is correct.
>>>>>
>>>>> *need* H1? Why bring it up at all?
>>>>>
>>>>
>>>> H(P,P) correctly determines that its input never reaches its final
>>>> state whether or not H aborts the simulation of this input.
>>>>
>>>> H1(P,P) correctly determines that its input reaches its final state.
>>>
>>> They have the *same* input. Therefore they cannot both be correct
>>> unless they give the same answer. You can't have one of them claim
>>> that P(P) never reaches its final state and the other say that P(P)
>>> does reach its final state *and* claim they are both correct.
>>>
>>> That's Trump Logic.
>>>
>>> André
>>>
>>>
>>
>> You have to wait until finish converting functions H1 and H to pure
>> functions. They do derive this result now yet it is possible that this
>> result is an artifact of their requirement of static local data to
>> derive these results.
>>
>> If it works out like preliminary analysis indicates a pair of
>> functions with identical machine code and identical inputs really do
>> have different output because the input to H(P,P) calls H and the
>> input to H1(P,P) calls H (thus does not call H1).
>
> Your statement is entirely incoherent. If H(P, P) and H1(P, P) give
> different results then either:
>
> (A) one is wrong.
>
> or
>
> (B) they are not computing the same function, in which case at most
> *one* of them can actually be deciding the halting function.
>
> You understand that the halting function (which maps computations to
> halting values) is a mathematical object which exists independently of
> any Turing Machine or algorithm and has a fixed mapping from
> computations to {true, false}, right?
>
> André
>
It will continue to be impossible for you to overcome your false
assumptions until you see that:
(a) H1(P,P) correctly reports that its input reaches its final state.
(b) H(P,P) correctly reports that its input NEVER reaches its final
state (whether or not it aborts the simulation of this input).
(c) Both H1 and H are pure functions and have identical machine code.
In computer programming, a pure function is a function that has the
following properties:
(1) The function return values are identical for identical arguments (no
variation with local static variables, non-local variables, mutable
reference arguments or input streams).
(2) The function application has no side effects (no mutation of local
static variables, non-local variables, mutable reference arguments or
input/output streams).
https://en.wikipedia.org/wiki/Pure_function
olcott
Oct 1, 2021, 10:36:24 AM10/1/21
to
On 10/1/2021 9:12 AM, Mike Terry wrote:
> address, and varying its processing according to that address.
>
> (I suggested this was all that was going on a couple of weeks ago, but
> you neither confirmed nor denied that. Almost as though you actually
> don't understand /yourself/ what's going on. (Surely that cannot be...!))
I don't reply to nonsense.
>>
>> If it works out like preliminary analysis indicates a pair of
>> functions with identical machine code and identical inputs really do
>> have different output because the input to H(P,P) calls H and the
>> input to H1(P,P) calls H (thus does not call H1).
>
> Of course an /unrestricted/ x86 program can do that - all it has to do
> is look at its own address and behave differently according to that
> address. (Like your H/H1 routines.) Or cheat with global variables etc..
decider and instead calls another different decider H, then infinitely
nested simulation is not specified for H1(P,P) as it is for H(P,P).
> If you are concerned with saying things of relevance to TMs and Linz's
> proof, you need to limit your C code to doing things that directly
> correspond with what TMs can do.
Yes that was my biggest challenge. I didn't even know the criteria for
that even though Kaz gave me this criteria months ago. After carefully
checking and double checking this criteria seems sufficient:
In computer programming, a pure function is a function that has the
following properties:[1][2]
(1) The function return values are identical for identical arguments (no
variation with local static variables, non-local variables, mutable
reference arguments or input streams).
(2) The function application has no side effects (no mutation of local
static variables, non-local variables, mutable reference arguments or
input/output streams).
https://en.wikipedia.org/wiki/Pure_function
> Otherwise the relationship between
> your computing model and TMs will become distorted and the conclusions
> you want to draw from your program's behaviour to TM behaviour may
> simply not apply.
>
> I know that last paragraph is WAAAAAY over your head (computation
> models? too abstract!) so you will just ignore it. Or perhaps spray
> your "Objection Begone!" Turing-equivalence spray at it, which never
> works for you. :)
>
> Anyway, you need to work out /why/ copying an algorithm can produce
> different behaviour in the copy, and STOP DOING IT!! (Just like you
> seem to have recognised that non-pure functions are to be avoided. I'm
> not sure whether using your own machine code address breaks the "pure
> function" rules per se, but the effect on your efforts is the same so it
> doesn't really matter.)
>
>
> Mike.
My redesign meets all of the above pure function criteria.
It really is the case that a pair of pure functions with identical
machine code will have different behavior on the same input when this
input calls one of these functions in pathological self-reference and
not the other. Identical functions, identical input, differing
relationships between the functions and their input.
> On 01/10/2021 01:54, olcott wrote:
>> On 9/30/2021 7:39 PM, André G. Isaak wrote:
>>> On 2021-09-30 18:26, olcott wrote:
>>>> On 9/30/2021 7:18 PM, André G. Isaak wrote:
>> On 9/30/2021 7:39 PM, André G. Isaak wrote:
>>> On 2021-09-30 18:26, olcott wrote:
>>>>> On 2021-09-30 17:21, olcott wrote:
>>>>>> On 9/30/2021 5:55 PM, André G. Isaak wrote:
>>>>>>> On 2021-09-30 16:12, olcott wrote:
>>>>>>>
>>>>>>>> Because of a critique of my work in another forum I have
>>>>>>>> discovered that the halt status that H1(P,P) reports is
>>>>>>>> consistent with the behavior of int main() { P(P); }
>>>>>>>
>>>>>>> But how does this address the Linz proof then? You've derived
>>>>>>> your P from H, not from H1. So all that matter with respect to
>>>>>>> the Linz proof is what *H*(P, P) returns. That some other decider
>>>>>>> H1, from which P is *not* derived, can correctly decide P(P) has
>>>>>>> no bearing on Linz's claim. H1 cannot decide P1(P1) where P1 is
>>>>>>> derived from H1 in the same way that P is derived from H.
>>>>>>>
>>>>>>
>>>>>> H(P,P) is correct and H1(P,P) is correct.
>>>>>
>>>>>> On 9/30/2021 5:55 PM, André G. Isaak wrote:
>>>>>>> On 2021-09-30 16:12, olcott wrote:
>>>>>>>
>>>>>>>> Because of a critique of my work in another forum I have
>>>>>>>> discovered that the halt status that H1(P,P) reports is
>>>>>>>> consistent with the behavior of int main() { P(P); }
>>>>>>>
>>>>>>> But how does this address the Linz proof then? You've derived
>>>>>>> your P from H, not from H1. So all that matter with respect to
>>>>>>> the Linz proof is what *H*(P, P) returns. That some other decider
>>>>>>> H1, from which P is *not* derived, can correctly decide P(P) has
>>>>>>> no bearing on Linz's claim. H1 cannot decide P1(P1) where P1 is
>>>>>>> derived from H1 in the same way that P is derived from H.
>>>>>>>
>>>>>>
>>>>>> H(P,P) is correct and H1(P,P) is correct.
>>>>>
>>>>> So you're saying they both return true? If so, why on earth do you
>>>>> *need* H1? Why bring it up at all?
>>>>>
>>>>
>>>> H(P,P) correctly determines that its input never reaches its final
>>>> state whether or not H aborts the simulation of this input.
>>>>
>>>> H1(P,P) correctly determines that its input reaches its final state.
>>>
>>> They have the *same* input. Therefore they cannot both be correct
>>> unless they give the same answer. You can't have one of them claim
>>> that P(P) never reaches its final state and the other say that P(P)
>>> does reach its final state *and* claim they are both correct.
>>>
>>> That's Trump Logic.
>>>
>>> André
>>>
>>>
>>
>> You have to wait until finish converting functions H1 and H to pure
>> functions. They do derive this result now yet it is possible that this
>> result is an artifact of their requirement of static local data to
>> derive these results.
>
> Or some other form of cheating such as a function taking its own
>>>>> *need* H1? Why bring it up at all?
>>>>>
>>>>
>>>> H(P,P) correctly determines that its input never reaches its final
>>>> state whether or not H aborts the simulation of this input.
>>>>
>>>> H1(P,P) correctly determines that its input reaches its final state.
>>>
>>> They have the *same* input. Therefore they cannot both be correct
>>> unless they give the same answer. You can't have one of them claim
>>> that P(P) never reaches its final state and the other say that P(P)
>>> does reach its final state *and* claim they are both correct.
>>>
>>> That's Trump Logic.
>>>
>>> André
>>>
>>>
>>
>> You have to wait until finish converting functions H1 and H to pure
>> functions. They do derive this result now yet it is possible that this
>> result is an artifact of their requirement of static local data to
>> derive these results.
>
> address, and varying its processing according to that address.
>
> (I suggested this was all that was going on a couple of weeks ago, but
> you neither confirmed nor denied that. Almost as though you actually
> don't understand /yourself/ what's going on. (Surely that cannot be...!))
I don't reply to nonsense.
>>
>> If it works out like preliminary analysis indicates a pair of
>> functions with identical machine code and identical inputs really do
>> have different output because the input to H(P,P) calls H and the
>> input to H1(P,P) calls H (thus does not call H1).
>
> is look at its own address and behave differently according to that
> address. (Like your H/H1 routines.) Or cheat with global variables etc..
>
The halting theorem counter-examples present infinitely nested
simulation (non-halting) behavior to every simulating halt decider.
When the input P to a simulating halt decider H1 does not call this same
The halting theorem counter-examples present infinitely nested
simulation (non-halting) behavior to every simulating halt decider.
decider and instead calls another different decider H, then infinitely
nested simulation is not specified for H1(P,P) as it is for H(P,P).
> If you are concerned with saying things of relevance to TMs and Linz's
> proof, you need to limit your C code to doing things that directly
> correspond with what TMs can do.
Yes that was my biggest challenge. I didn't even know the criteria for
that even though Kaz gave me this criteria months ago. After carefully
checking and double checking this criteria seems sufficient:
In computer programming, a pure function is a function that has the
(1) The function return values are identical for identical arguments (no
variation with local static variables, non-local variables, mutable
reference arguments or input streams).
(2) The function application has no side effects (no mutation of local
static variables, non-local variables, mutable reference arguments or
input/output streams).
https://en.wikipedia.org/wiki/Pure_function
> your computing model and TMs will become distorted and the conclusions
> you want to draw from your program's behaviour to TM behaviour may
> simply not apply.
>
> I know that last paragraph is WAAAAAY over your head (computation
> models? too abstract!) so you will just ignore it. Or perhaps spray
> your "Objection Begone!" Turing-equivalence spray at it, which never
> works for you. :)
>
> Anyway, you need to work out /why/ copying an algorithm can produce
> different behaviour in the copy, and STOP DOING IT!! (Just like you
> seem to have recognised that non-pure functions are to be avoided. I'm
> not sure whether using your own machine code address breaks the "pure
> function" rules per se, but the effect on your efforts is the same so it
> doesn't really matter.)
>
>
> Mike.
My redesign meets all of the above pure function criteria.
It really is the case that a pair of pure functions with identical
machine code will have different behavior on the same input when this
input calls one of these functions in pathological self-reference and
not the other. Identical functions, identical input, differing
relationships between the functions and their input.
Jeff Barnett
Oct 1, 2021, 12:45:20 PM10/1/21
to
On 10/1/2021 8:36 AM, olcott wrote:
>
> I don't reply to nonsense.
>
You do very frequently. You have written messages "in reply to" your own
>
> I don't reply to nonsense.
>
messages more than any other (sub)human alive to day or in the past for
that matter. Your nonsense and repetitive behavior reminds me of a
neurotic chimpanzee at our local zoo. It hurts to watch. The Guinness
Book of World Records is holding a place for you in this regards as well
as several other categories. Be proud son/daughter; be proud.
--
Jeff Barnett
olcott
Oct 1, 2021, 12:46:20 PM10/1/21
to
On 10/1/2021 11:12 AM, wij wrote:
> GUR https://groups.google.com/g/comp.theory/c/_tbCYyMox9M
>
> Your proof is essentially several lines of "C" program, nothing to do with
> TM or the traditional Halting Problem.
>
> The key basis of your refutation is a refutation to your own conception that
> no one care. You were denying some part of yourself, not the HP.
>
> I find the key essence is that your relevant knowledge is very weak, you read
> text books but not doing exercises.
> Do exercises in the text books of C,Assembly or Computation theory you read.
> That would take much lesser time than 7 years (rumor sayed that you have been
> working on that several lines of C codes for probably more than 7 years!).
It may superficially seem that way.
This is the essence of the basis of my refutation:
The halting theorem counter-examples present infinitely nested
simulation (non-halting) behavior to every simulating halt decider.
I created the x86utm operating system so that every single detail of
theory of computation problems can be analyzed at the much higher level
of abstraction of the C/x86 languages. Without this much higher level
abstraction key elements of the HP proof are essentially validated by
hand-waving.
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
A key element that had taken me by complete surprise is that some things
that are C/x86 computable are not TM computable. I had previously
thought that the Church-Turing thesis confirmed that any and all things
that any physically existing computer can do a TM can compute.
https://en.wikipedia.org/wiki/Computable_function#Characteristics_of_computable_functions
It seems that no aspect of the definition of [computable function]
requires it to be a [pure function], none-the-less most expert opinion
seems to indicate that this requirement exists. I am on the verge of
reproducing my work such that the simulating partial halt deciders H1
and H are pure functions and take finite string parameters. To conform
my C/x86 code to the Linz Ĥ template P will copy its input.
In computer programming, a pure function is a function that has the
following properties:
> On Wednesday, 29 September 2021 at 11:20:35 UTC+8, olcott wrote:
>> The halting theorem counter-examples present infinitely nested
>> simulation (non-halting) behavior to every simulating halt decider.
>>
>> -----1-----------2--3----------
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>
>> If the simulation of the 2nd ⟨Ĥ⟩ applied to
>> the 3rd ⟨Ĥ⟩ at Ĥ.qx reaches its final state.
>>
>>
>> -----1-----------2--3----------
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>
>> If the simulation of the 2nd ⟨Ĥ⟩ applied to
>> the 3rd ⟨Ĥ⟩ at Ĥ.qx never reaches its final state.
>>
>>
>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>
> Apparently, you are trying to solve an undecidable problem:
>> The halting theorem counter-examples present infinitely nested
>> simulation (non-halting) behavior to every simulating halt decider.
>>
>> -----1-----------2--3----------
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>
>> If the simulation of the 2nd ⟨Ĥ⟩ applied to
>> the 3rd ⟨Ĥ⟩ at Ĥ.qx reaches its final state.
>>
>>
>> -----1-----------2--3----------
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>
>> If the simulation of the 2nd ⟨Ĥ⟩ applied to
>> the 3rd ⟨Ĥ⟩ at Ĥ.qx never reaches its final state.
>>
>>
>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>
> GUR https://groups.google.com/g/comp.theory/c/_tbCYyMox9M
>
> Your proof is essentially several lines of "C" program, nothing to do with
> TM or the traditional Halting Problem.
>
> The key basis of your refutation is a refutation to your own conception that
> no one care. You were denying some part of yourself, not the HP.
>
> I find the key essence is that your relevant knowledge is very weak, you read
> text books but not doing exercises.
> Do exercises in the text books of C,Assembly or Computation theory you read.
> That would take much lesser time than 7 years (rumor sayed that you have been
> working on that several lines of C codes for probably more than 7 years!).
It may superficially seem that way.
This is the essence of the basis of my refutation:
The halting theorem counter-examples present infinitely nested
simulation (non-halting) behavior to every simulating halt decider.
theory of computation problems can be analyzed at the much higher level
of abstraction of the C/x86 languages. Without this much higher level
abstraction key elements of the HP proof are essentially validated by
hand-waving.
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
A key element that had taken me by complete surprise is that some things
that are C/x86 computable are not TM computable. I had previously
thought that the Church-Turing thesis confirmed that any and all things
that any physically existing computer can do a TM can compute.
https://en.wikipedia.org/wiki/Computable_function#Characteristics_of_computable_functions
It seems that no aspect of the definition of [computable function]
requires it to be a [pure function], none-the-less most expert opinion
seems to indicate that this requirement exists. I am on the verge of
reproducing my work such that the simulating partial halt deciders H1
and H are pure functions and take finite string parameters. To conform
my C/x86 code to the Linz Ĥ template P will copy its input.
In computer programming, a pure function is a function that has the
following properties:
(1) The function return values are identical for identical arguments (no
variation with local static variables, non-local variables, mutable
reference arguments or input streams).
(2) The function application has no side effects (no mutation of local
static variables, non-local variables, mutable reference arguments or
input/output streams).
https://en.wikipedia.org/wiki/Pure_function
>>
variation with local static variables, non-local variables, mutable
reference arguments or input streams).
(2) The function application has no side effects (no mutation of local
static variables, non-local variables, mutable reference arguments or
input/output streams).
https://en.wikipedia.org/wiki/Pure_function
>>
olcott
Oct 1, 2021, 1:04:52 PM10/1/21
to
On 10/1/2021 11:55 AM, Jeff Barnett wrote:
> On 10/1/2021 10:27 AM, Andy Walker wrote:
>> On 01/10/2021 15:12, Mike Terry wrote [to PO, of course]:
>>> Of course an /unrestricted/ x86 program can do that [...]
>>
>> I think it is misleading to talk about what TMs can do as
>> thought they are interestingly different from what x86 programs or
>> any real computer can do. An x86 computer /is/ a FSM with extra
>> storage; in other words, a TM. We tend to write rather simple
>> TMs to illustrate points, but there is no reason why it should
>> not have 2^N states, where N is rather large [the number of bits
>> in your computer]. "Taking the address of a function" is not
>> "difficult" with a TM, just rather tedious.
>>
>> There is no reason why someone [I'm not volunteering!]
>> should not write a C compiler the target of which is recognisably
>> a TM. It's just going to be rather complicated. [Probably easier,
>> AAMOF, to write a microcode as a TM, and describe real computers
>> in terms of that microcode. In the 1930s, that would have seemed
>> like magic, but it is how many/most modern computers work.]
>>
>> That's why I think people are barking up the wrong tree
>> when complaining that PO writes C code that is "not a function".
>> It doesn't matter. It just means that the "hat" construction
>> is more complicated than PO claims, inc all the states [etc] of
>> the FSM, inc "hidden" variables. The real errors lie elsewhere.
> I think what people are trying to say and may be saying badly is that
> the set of things that can influence an execution must all be considered
> part of that execution. Trivial but important. Said another way apropos
> to the current conversation is that when you propose something to play
> the role of the Linz H, the definition of that something must include
> everything that influences its execution. PO doesn't do that. 'It' also
> keeps the piece he calls H from being function- or computation-like. One
> of the "rules" of software reasoning is that one must carefully delimit
> the boundaries of what one is talking about. This basic guideline has
> been ignored into oblivion.
It is very difficult to confirm that a [computable function]
https://en.wikipedia.org/wiki/Computable_function#Characteristics_of_computable_functions
Must be a [pure function]
https://en.wikipedia.org/wiki/Pure_function
When no official source say this.
None-the-less my partial halt deciders {H1, H} are being transformed
into [pure functions] that take finite string inputs. Also my C/x86
equivalent P of the Linz Ĥ will copy its input so that it more closely
conforms to the Linz Ĥ.
> On 10/1/2021 10:27 AM, Andy Walker wrote:
>> On 01/10/2021 15:12, Mike Terry wrote [to PO, of course]:
>>> Of course an /unrestricted/ x86 program can do that [...]
>>> If you are concerned with saying things of relevance to TMs and
>>> Linz's proof, you need to limit your C code to doing things that
>>> directly correspond with what TMs can do. [...]
>>> Linz's proof, you need to limit your C code to doing things that
>>
>> I think it is misleading to talk about what TMs can do as
>> thought they are interestingly different from what x86 programs or
>> any real computer can do. An x86 computer /is/ a FSM with extra
>> storage; in other words, a TM. We tend to write rather simple
>> TMs to illustrate points, but there is no reason why it should
>> not have 2^N states, where N is rather large [the number of bits
>> in your computer]. "Taking the address of a function" is not
>> "difficult" with a TM, just rather tedious.
>>
>> There is no reason why someone [I'm not volunteering!]
>> should not write a C compiler the target of which is recognisably
>> a TM. It's just going to be rather complicated. [Probably easier,
>> AAMOF, to write a microcode as a TM, and describe real computers
>> in terms of that microcode. In the 1930s, that would have seemed
>> like magic, but it is how many/most modern computers work.]
>>
>> That's why I think people are barking up the wrong tree
>> when complaining that PO writes C code that is "not a function".
>> It doesn't matter. It just means that the "hat" construction
>> is more complicated than PO claims, inc all the states [etc] of
>> the FSM, inc "hidden" variables. The real errors lie elsewhere.
> I think what people are trying to say and may be saying badly is that
> the set of things that can influence an execution must all be considered
> part of that execution. Trivial but important. Said another way apropos
> to the current conversation is that when you propose something to play
> the role of the Linz H, the definition of that something must include
> everything that influences its execution. PO doesn't do that. 'It' also
> keeps the piece he calls H from being function- or computation-like. One
> of the "rules" of software reasoning is that one must carefully delimit
> the boundaries of what one is talking about. This basic guideline has
> been ignored into oblivion.
It is very difficult to confirm that a [computable function]
https://en.wikipedia.org/wiki/Computable_function#Characteristics_of_computable_functions
Must be a [pure function]
https://en.wikipedia.org/wiki/Pure_function
When no official source say this.
None-the-less my partial halt deciders {H1, H} are being transformed
into [pure functions] that take finite string inputs. Also my C/x86
equivalent P of the Linz Ĥ will copy its input so that it more closely
conforms to the Linz Ĥ.
olcott
Oct 1, 2021, 1:30:22 PM10/1/21
to
On 10/1/2021 12:17 PM, Richard Damon wrote:
> Because they are different concepts and don't actually map directly into
> each other.
>
> A Computatble Function will tend to naturally be a Pure Function, but it
> is possible to make a Computable Function out of limited forms of
> non-Pure Functions (for example, caching of results to avoid recomputing
> already computed results).
>
> It is also possible of a Pure Function to not be a Computatble Function
> if the pure function depends in some way on the address that it is being
> run from. The concept of Pure Functions deal with a single instance of
> it always mapping input to output, while a Computable Function deals
> with a UNIVERSAL mapping of input to output of ALL copies of it.
>
> Pure Functions are inplementations in physical hardware.
>
> Computable Functions are mathematical abstractions.
>
Some of the stuff that you say is well reasoned and can be confirmed.
Some of it is pure bullshit, simply talking out of your ass.
The key pure bullshit item was either you or André that simply rejected
the whole idea of a simulating halt decider out-of-hand.
This is the key basis of my whole proof:
of infinitely nested simulation is merely an implementation detail.
As long as a simulating halt decider can determine this by one means or
another, then the conventional halting theorem proofs have been refuted.
> each other.
>
> A Computatble Function will tend to naturally be a Pure Function, but it
> is possible to make a Computable Function out of limited forms of
> non-Pure Functions (for example, caching of results to avoid recomputing
> already computed results).
>
> It is also possible of a Pure Function to not be a Computatble Function
> if the pure function depends in some way on the address that it is being
> run from. The concept of Pure Functions deal with a single instance of
> it always mapping input to output, while a Computable Function deals
> with a UNIVERSAL mapping of input to output of ALL copies of it.
>
> Pure Functions are inplementations in physical hardware.
>
> Computable Functions are mathematical abstractions.
>
Some of the stuff that you say is well reasoned and can be confirmed.
Some of it is pure bullshit, simply talking out of your ass.
The key pure bullshit item was either you or André that simply rejected
the whole idea of a simulating halt decider out-of-hand.
This is the key basis of my whole proof:
The halting theorem counter-examples present infinitely nested
simulation (non-halting) behavior to every simulating halt decider.
How a simulating halt decider determines that its input is an instance
simulation (non-halting) behavior to every simulating halt decider.
of infinitely nested simulation is merely an implementation detail.
As long as a simulating halt decider can determine this by one means or
another, then the conventional halting theorem proofs have been refuted.
olcott
Oct 1, 2021, 4:23:53 PM10/1/21
to
On 10/1/2021 3:09 PM, Andy Walker wrote:
> On 01/10/2021 17:55, Jeff Barnett wrote:
> [I wrote:]
>
> Absolutely. IOW, the "hat" construction is still possible,
> but is not the simplistic version that PO presents.
>
> [FTAOD, although I was replying to one of your posts, my
> article wasn't "aimed" at you, but at the whole way this "debate"
> has been going. It's too easy to get sucked in to PO's way of
> "thinking".]
>
The whole basis of my rebuttal of the halting problem proofs:
The halting theorem counter-examples present infinitely nested
simulation (non-halting) behavior to every simulating halt decider.
How the simulating halt decider detects that an input is presenting
> On 01/10/2021 17:55, Jeff Barnett wrote:
> [I wrote:]
>>> That's why I think people are barking up the wrong tree
>>> when complaining that PO writes C code that is "not a function".
>>> It doesn't matter. It just means that the "hat" construction
>>> is more complicated than PO claims, inc all the states [etc] of
>>> the FSM, inc "hidden" variables. The real errors lie elsewhere.
>> I think what people are trying to say and may be saying badly is that
>> the set of things that can influence an execution must all be
>> considered part of that execution. Trivial but important. [...]
>>> when complaining that PO writes C code that is "not a function".
>>> It doesn't matter. It just means that the "hat" construction
>>> is more complicated than PO claims, inc all the states [etc] of
>>> the FSM, inc "hidden" variables. The real errors lie elsewhere.
>> I think what people are trying to say and may be saying badly is that
>> the set of things that can influence an execution must all be
>
> Absolutely. IOW, the "hat" construction is still possible,
> but is not the simplistic version that PO presents.
>
> [FTAOD, although I was replying to one of your posts, my
> article wasn't "aimed" at you, but at the whole way this "debate"
> has been going. It's too easy to get sucked in to PO's way of
> "thinking".]
>
The whole basis of my rebuttal of the halting problem proofs:
The halting theorem counter-examples present infinitely nested
simulation (non-halting) behavior to every simulating halt decider.
infinitely nested simulation is merely an implementation detail.
olcott
Oct 2, 2021, 12:23:13 PM10/2/21
to
On 10/2/2021 10:58 AM, André G. Isaak wrote:
> On 2021-10-02 09:31, olcott wrote:
>
>> The problem is that when Linz refers to wM he calls it M.
>>
>> The input to H will be the description (encoded in some form) of M,
>> say wM, as well as the input w.
>>
>> There is no M in H, yet he refers to an M in H
>> q0 wM w ⊢* qn
>> if M applied to w does not halt.
>>
>> To correct this error
>> if the TM described by wM applied to w does not halt.
>
> How on earth is this an "error"?
>
> wM means the description of M.
>
> "the TM described by wM" and "M" mean exactly the same thing. What need
> is there for adding this extra verbiage?
>
> André
>
>
-----1----2-----3-----4--5-----6
that the Linz notation refers to (1) halting on (2) and not (4) halting
on (5).
> On 2021-10-02 09:31, olcott wrote:
>
>> The problem is that when Linz refers to wM he calls it M.
>>
>> The input to H will be the description (encoded in some form) of M,
>> say wM, as well as the input w.
>>
>> There is no M in H, yet he refers to an M in H
>> q0 wM w ⊢* qn
>> if M applied to w does not halt.
>>
>> To correct this error
>> if the TM described by wM applied to w does not halt.
>
> How on earth is this an "error"?
>
> wM means the description of M.
>
> "the TM described by wM" and "M" mean exactly the same thing. What need
> is there for adding this extra verbiage?
>
> André
>
>
-----1----2-----3-----4--5-----6
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
We need the extra verbiage only because Ben and Richard falsely believe
that the Linz notation refers to (1) halting on (2) and not (4) halting
on (5).
olcott
Oct 2, 2021, 2:08:55 PM10/2/21
to
On 10/2/2021 12:50 PM, Richard Damon wrote:
> On 10/2/21 1:32 PM, olcott wrote:
>> On 10/2/2021 12:04 PM, Richard Damon wrote:
>>> On 10/2/21 12:39 PM, olcott wrote:
>>>> On 10/2/2021 11:02 AM, Richard Damon wrote:
>>>>> On 10/2/21 11:29 AM, olcott wrote:
>>>>>> On 10/2/2021 10:08 AM, Richard Damon wrote:
>>>>>>> On 10/2/21 10:26 AM, olcott wrote:
>>>>>>>> On 10/2/2021 9:16 AM, olcott wrote:
>>>>>>>>> On 10/2/2021 5:54 AM, Richard Damon wrote:
>>>>>>>>>>
>>>>>>>>>> On 10/2/21 12:10 AM, olcott wrote:
>>>>>>>>>>>>>>>> Oh dear, you've posted about TMs again...
>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ---1----2-----3-----4--5-----6
>>>>>>>>>>>>>>>> if) Ĥ
>>>>>>>>>>>>>> Linz is not wrong about how he himself specifies the behaviour
>>>>>>>>>>>>>> of Ĥ.
>>>>>>>>>>>>>> It's his specification. You /could/ reject that
>>>>>>>>>>>>>> specification,
>>>>>>>>>>>>>> but in
>>>>>>>>>>>>>> fact you insist that you only ever use Ĥ to refer to Linz's Ĥ.
>>>>>>>>>>>>>> You dishonestly leave off a key part of his specification
>>>>>>>>>>>>>> because
>>>>>>>>>>>>>> you
>>>>>>>>>>>>>> don't want to keep seeing the problem.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Ĥ.qx(⟨Ĥ⟩, ⟨Ĥ⟩) the simulation of the input to Ĥ.qx never
>>>>>>>>>>>>>>> reaches
>>>>>>>>>>>>>>> its
>>>>>>>>>>>>>>> final state whether or not Ĥ.qx aborts this simulation
>>>>>>>>>>>>>>> therefore
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> transition of Ĥ.qx to Ĥ.qn is correct.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> What is correct is determined by the annotation you keep
>>>>>>>>>>>>>> dishonestly
>>>>>>>>>>>>>> omitting. Ĥ(⟨Ĥ⟩) transitions to Ĥ.qn if (and only if) Ĥ(⟨Ĥ⟩)
>>>>>>>>>>>>>> does not
>>>>>>>>>>>>>> halt.
>>>>>>>>>>>>>
>>>>>>>>>>>>> That is flatly false.
>>>>>>>>>>>>
>>>>>>>>>>>> No, it's right there in Linz. It's dishonest to remove the key
>>>>>>>>>>>> thing
>>>>>>>>>>>> about the line you keep writing, but I know you have to
>>>>>>>>>>>> remove it.
>>>>>>>>>>>> There is no other way for you to avoid Linz's conclusion.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Beginning with the Linz H
>>>>>>>>>>> template
>>>>>>>>>>> so we have to go back to these words to see what M applied to wM
>>>>>>>>>>> means:
>>>>>>>>>>
>>>>>>>>>> NO. Maybe you don't understand what a 'Formal Parameter' is. Let
>>>>>>>>>> us go
>>>>>>>>>>
>>>>>>>>>> So M is the Turing Machine previous mentioned in the
>>>>>>>>>> description of
>>>>>>>>>> what
>>>>>>>>>> the Halting Problem's Question was:
>>>>>>>>>>
>>>>>>>>>>> Simply stated, the problem is: given the description of a Turing
>>>>>>>>>>> machine M and an input w, does M, when started in the initial
>>>>>>>>>>> configuration qow, perform a computation that eventually halts?
>>>>>>>>>>
>>>>>>>>>> So M is NOT an 'undefined term that we need to figure out what it
>>>>>>>>>> means', that is a lie.
>>>>>>>>>>
>>>>>>>>>> M is the machine that the decider is supposed to decider, it is in
>>>>>>>>>> Software Engineering terms, a Formal Parameter to the Halting
>>>>>>>>>> Decider.
>>>>>>>>>>
>>>>>>>>>> Just like when we write the definition of H(P,I) as a function
>>>>>>>>>> definition, the P and I are the names of the Formal Parameters,
>>>>>>>>>> that
>>>>>>>>>> when we later call H(H_hat, H_hat) get filled in by the values
>>>>>>>>>> from
>>>>>>>>>> the
>>>>>>>>>> calling site.
>>>>>>>>>>
>>>>>>>>>> Is that why you suddenly changed the name of the machine to be
>>>>>>>>>> decided,
>>>>>>>>>> because having the formal parameter named P and the passed
>>>>>>>>>> parameter
>>>>>>>>>> named H_hat was too confusing for you?
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Right, the question is about the behavior of the ACTUAL Turing
>>>>>>>>>> Machine
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Now onto the Linz Ĥ
>>>>>>>>>>> ---1---2--------3---4---5-------6
>>>>>>>>>>> q0 wM ⊢* qx wM wM ⊢* qn
>>>>>>>>>>>
>>>>>>>>>>> if M applied to wM does not halt
>>>>>>>>>>> is translated into
>>>>>>>>>>>
>>>>>>>>>>> The TM described by wM applied to wM does not halt
>>>>>>>>>>> is translated into
>>>>>>>>>>>
>>>>>>>>>>> The TM described by ⟨Ĥ⟩ applied to ⟨Ĥ⟩ does not halt
>>>>>>>>>>>
>>>>>>>>>>> ----1----2-----3-----4--5-----6
>>>>>>>>>>> The TM described by ⟨Ĥ⟩ applied to ⟨Ĥ⟩
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Right, so the question is does the TM which is described by <H^>
>>>>>>>>>> applied
>>>>>>>>>> to <H^> Halt, and that is exactly your (1) applied to (2) which
>>>>>>>>>> you
>>>>>>>>>> show
>>>>>>>>>
>>>>>>>>> The TM described by ⟨Ĥ⟩ applied to ⟨Ĥ⟩ does not halt
>>>>>>>>> (1) is not a TM description, proving that you are wrong.
>>>>>>>>>
>>>>>>>>
>>>>>>>> There is only one place where the TM described by ⟨Ĥ⟩ is applied to
>>>>>>>> ⟨Ĥ⟩
>>>>>>>> and that is (4) and (5).
>>>>>>>>
>>>>>>>
>>>>>>> Is the problem honestly that you don't understand what Linz is
>>>>>>> saying?
>>>>>>> What is meant by a representation.
>>>>>
>>>>> That is clear.
>>>>>
>>>>
>>>> Yes, agreed.
>>>>> and needs to decide what it will do.
>>>>>
>>>>
>>>> Yes, agreed.
>>>>
>>>>>>
>>>>>> To correct this error
>>>>>
>>>>> There is no error here (except by you)
>>>>> The question is, does M w halt or not?
>>>>>
>>>>
>>>> Yes, agreed.
>>>>
>>>>>
>>>>>>
>>>>>> There is no M in Ĥ, yet he refers to an M in Ĥ
>>>>>
>>>>> Wrong.
>>>>>
>>>>> M is the formal parameter, H^ is the actual parameter.
>>>>>
>>>>
>>>> M cannot be any parameter at all, TMa are not allowed to be parameters,
>>>> only TM descriptions are allowed to be parmeters.
>>>
>>> Maybe I went above your head again. Yes, at the implementation level, H
>>> needs to be given a representation. so it gets wM, but at the abstract
>>> description of what it is being asked to do, it is being asked to decide
>>> what Turing Machine M applied to input w will do. That make M a Formal
>>> Parameter to the problem.
>>>
>>>>
>>>>> so, H taking Formal Parameters wM and w, is 'called' by the actual
>>>>> parameters <H^> and <H^>
>>>>>
>>>>
>>>> Yes, agreed.
>>>>
>>>>> Just like when we define H as H(P,I) and call it as H(H_hat, H_hat).
>>>>>
>>>>>> q0 wM ⊢* qx wM wM ⊢* qn
>>>>>> if M applied to wM does not halt
>>>>>>
>>>>>> To correct this error
>>>>>> if the TM described by wM applied to wM does not halt.
>>>>>
>>>>> Right the TM described by wM is M which, is applied to w.
>>>>
>>>> There is another one of your terrible careless mistakes.
>>>> There is no w in Ĥ.
>>>
>>> Neither is there a wM, so you are being inconsistent.
>>
>> ----------1------------2---3----------
>>>>>> q0 wM ⊢* qx wM wM ⊢* qn
>>
>> It is stupid mistakes like saying that there is no wM at (1) (2) and (3)
>> that cause me to not even glance at anything you say for several days.
>>
>>
>
> Yes, H^ *ITSELF* does not have a w, but does have a wM, but the
> definition of H still has a w as a formal parameter, as that is the
> definition of H.
>
> When we look at what is supposed to happen at qx (which you are actually
> WRONG about Linz getting wrong here)
>
Linz (like everyone else) has the error of omission not the error of
commission.
Linz (and everyone else) simply fails to notice that the conventional
halting theorem template presents infinitely nested simulation to every
simulating halt decider.
You and Ben have been dodging this by pretending that the halt decider
is at (1) on input (2) and not at (3) on inputs (4) and (5).
----1----2-----3-----4--5-----6
> Linz state here is H^q0 not q0 so he gives it a unique name, there are
> NOT two q0. (If we want to be pedantic).
>
> So, at H^'s H^q0 which is essentially a copy of H's q0, we have as the
> input tape wM wM which if we look at the definition of H, we see that H
> applied to wM w is supposed to predict what the machine M applied to w
> will do. Appling these formal parameters we gets:
>
> H's wM corresponds to H^'s wM
> H's w corresponds to H^'s wM
>
> Thus the sub-machine at H^q0 (aka PO-qx) is supposed to answer what the
> machine M, which is the machine described by H^s input wm would do when
> applied to the input wM to H^.
>
> The next step in the proof, he applies this H^ machine to decide on H^,
> by creating a w^ as the value for wM (so w^ is the description of H^)
> and this means that H given w^ w^ needs to decide what H^ applied to w^
> will do, which is the starting Computation of H^'s q0 being applied to w^.
>
> From your claims, H^'s qx applied to w^ W^ will go to H^'s qn saying
> that it is non-halting, (and thus that is exactly what H's q0 applied to
> w^ w^ will say, since they are the same machine description with the
> same inputs) but H^'s q0 applied to w^ will thus also end up in H^'s qn
> which is a halting state.
>
> Thus H says non-halting, but the actual machine is Halting.
> On 10/2/21 1:32 PM, olcott wrote:
>> On 10/2/2021 12:04 PM, Richard Damon wrote:
>>> On 10/2/21 12:39 PM, olcott wrote:
>>>> On 10/2/2021 11:02 AM, Richard Damon wrote:
>>>>> On 10/2/21 11:29 AM, olcott wrote:
>>>>>> On 10/2/2021 10:08 AM, Richard Damon wrote:
>>>>>>> On 10/2/21 10:26 AM, olcott wrote:
>>>>>>>> On 10/2/2021 9:16 AM, olcott wrote:
>>>>>>>>> On 10/2/2021 5:54 AM, Richard Damon wrote:
>>>>>>>>>>
>>>>>>>>>> On 10/2/21 12:10 AM, olcott wrote:
>>>>>>>>>>> On 10/1/2021 7:08 PM, Ben Bacarisse wrote:
>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 10/1/2021 5:22 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 10/1/2021 3:44 PM, Ben Bacarisse wrote:
>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 10/1/2021 5:22 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Oh dear, you've posted about TMs again...
>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ---1----2-----3-----4--5-----6
>>>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>>>>>>> And the correct annotation for this line is "if (and only
>>>>>>>>>>>>>>>> if) Ĥ
>>>>>>>>>>>>>>>> applied
>>>>>>>>>>>>>>>> to ⟨Ĥ⟩ does not halt".
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Flat out totally incorrect.
>>>>>>>>>>>>>>>> to ⟨Ĥ⟩ does not halt".
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Linz is not wrong about how he himself specifies the behaviour
>>>>>>>>>>>>>> of Ĥ.
>>>>>>>>>>>>>> It's his specification. You /could/ reject that
>>>>>>>>>>>>>> specification,
>>>>>>>>>>>>>> but in
>>>>>>>>>>>>>> fact you insist that you only ever use Ĥ to refer to Linz's Ĥ.
>>>>>>>>>>>>>> You dishonestly leave off a key part of his specification
>>>>>>>>>>>>>> because
>>>>>>>>>>>>>> you
>>>>>>>>>>>>>> don't want to keep seeing the problem.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Ĥ.qx(⟨Ĥ⟩, ⟨Ĥ⟩) the simulation of the input to Ĥ.qx never
>>>>>>>>>>>>>>> reaches
>>>>>>>>>>>>>>> its
>>>>>>>>>>>>>>> final state whether or not Ĥ.qx aborts this simulation
>>>>>>>>>>>>>>> therefore
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> transition of Ĥ.qx to Ĥ.qn is correct.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> What is correct is determined by the annotation you keep
>>>>>>>>>>>>>> dishonestly
>>>>>>>>>>>>>> omitting. Ĥ(⟨Ĥ⟩) transitions to Ĥ.qn if (and only if) Ĥ(⟨Ĥ⟩)
>>>>>>>>>>>>>> does not
>>>>>>>>>>>>>> halt.
>>>>>>>>>>>>>
>>>>>>>>>>>>> That is flatly false.
>>>>>>>>>>>>
>>>>>>>>>>>> No, it's right there in Linz. It's dishonest to remove the key
>>>>>>>>>>>> thing
>>>>>>>>>>>> about the line you keep writing, but I know you have to
>>>>>>>>>>>> remove it.
>>>>>>>>>>>> There is no other way for you to avoid Linz's conclusion.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Beginning with the Linz H
>>>>>>>>>>> q0 wM w ⊢* qn
>>>>>>>>>>> if M applied to w does not halt.
>>>>>>>>>>>
>>>>>>>>>>> When Linz refers to M applied to wM there is no M in the Linz
>>>>>>>>>>> if M applied to w does not halt.
>>>>>>>>>>>
>>>>>>>>>>> template
>>>>>>>>>>> so we have to go back to these words to see what M applied to wM
>>>>>>>>>>> means:
>>>>>>>>>>
>>>>>>>>>> NO. Maybe you don't understand what a 'Formal Parameter' is. Let
>>>>>>>>>> us go
>>>>>>>>>> back to what Linz said:
>>>>>>>>>>
>>>>>>>>>>> The input to H will be the description (encoded in some form)
>>>>>>>>>>> of M,
>>>>>>>>>>> say WM, as well as the input w.
>>>>>>>>>>
>>>>>>>>>>> The input to H will be the description (encoded in some form)
>>>>>>>>>>> of M,
>>>>>>>>>>
>>>>>>>>>> So M is the Turing Machine previous mentioned in the
>>>>>>>>>> description of
>>>>>>>>>> what
>>>>>>>>>> the Halting Problem's Question was:
>>>>>>>>>>
>>>>>>>>>>> Simply stated, the problem is: given the description of a Turing
>>>>>>>>>>> machine M and an input w, does M, when started in the initial
>>>>>>>>>>> configuration qow, perform a computation that eventually halts?
>>>>>>>>>>
>>>>>>>>>> So M is NOT an 'undefined term that we need to figure out what it
>>>>>>>>>> means', that is a lie.
>>>>>>>>>>
>>>>>>>>>> M is the machine that the decider is supposed to decider, it is in
>>>>>>>>>> Software Engineering terms, a Formal Parameter to the Halting
>>>>>>>>>> Decider.
>>>>>>>>>>
>>>>>>>>>> Just like when we write the definition of H(P,I) as a function
>>>>>>>>>> definition, the P and I are the names of the Formal Parameters,
>>>>>>>>>> that
>>>>>>>>>> when we later call H(H_hat, H_hat) get filled in by the values
>>>>>>>>>> from
>>>>>>>>>> the
>>>>>>>>>> calling site.
>>>>>>>>>>
>>>>>>>>>> Is that why you suddenly changed the name of the machine to be
>>>>>>>>>> decided,
>>>>>>>>>> because having the formal parameter named P and the passed
>>>>>>>>>> parameter
>>>>>>>>>> named H_hat was too confusing for you?
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The input to H will be the description (encoded in some form) of
>>>>>>>>>>> M, say
>>>>>>>>>>> wM, as well as the input w.
>>>>>>>>>>>
>>>>>>>>>>> M applied to wM means: The TM described by wM applied to w.
>>>>>>>>>>>
>>>>>>>>>>> The input to H will be the description (encoded in some form) of
>>>>>>>>>>> M, say
>>>>>>>>>>> wM, as well as the input w.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Right, the question is about the behavior of the ACTUAL Turing
>>>>>>>>>> Machine
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Now onto the Linz Ĥ
>>>>>>>>>>> ---1---2--------3---4---5-------6
>>>>>>>>>>> q0 wM ⊢* qx wM wM ⊢* qn
>>>>>>>>>>>
>>>>>>>>>>> if M applied to wM does not halt
>>>>>>>>>>> is translated into
>>>>>>>>>>>
>>>>>>>>>>> The TM described by wM applied to wM does not halt
>>>>>>>>>>> is translated into
>>>>>>>>>>>
>>>>>>>>>>> The TM described by ⟨Ĥ⟩ applied to ⟨Ĥ⟩ does not halt
>>>>>>>>>>>
>>>>>>>>>>> ----1----2-----3-----4--5-----6
>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>>
>>>>>>>>>>> There is only one place in the above where this exists:
>>>>>>>>>>>
>>>>>>>>>>> The TM described by ⟨Ĥ⟩ applied to ⟨Ĥ⟩
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Right, so the question is does the TM which is described by <H^>
>>>>>>>>>> applied
>>>>>>>>>> to <H^> Halt, and that is exactly your (1) applied to (2) which
>>>>>>>>>> you
>>>>>>>>>> show
>>>>>>>>>
>>>>>>>>> The TM described by ⟨Ĥ⟩ applied to ⟨Ĥ⟩ does not halt
>>>>>>>>> (1) is not a TM description, proving that you are wrong.
>>>>>>>>>
>>>>>>>>
>>>>>>>> There is only one place where the TM described by ⟨Ĥ⟩ is applied to
>>>>>>>> ⟨Ĥ⟩
>>>>>>>> and that is (4) and (5).
>>>>>>>>
>>>>>>>
>>>>>>> Is the problem honestly that you don't understand what Linz is
>>>>>>> saying?
>>>>>>> What is meant by a representation.
>>>>>>>
>>>>>>
>>>>>> The problem is that when Linz refers to wM he calls it M.
>>>>>
>>>>> No, he doesn't.
>>>>>>
>>>>>> The problem is that when Linz refers to wM he calls it M.
>>>>>
>>>>>
>>>>>>
>>>>>> The input to H will be the description (encoded in some form) of M,
>>>>>> say
>>>>>> wM, as well as the input w.
>>>>>
>>>>> Read it again. M is the Turing Machine. wM is the description of M.
>>>>>>
>>>>>> The input to H will be the description (encoded in some form) of M,
>>>>>> say
>>>>>> wM, as well as the input w.
>>>>>
>>>>>
>>>>> That is clear.
>>>>>
>>>>
>>>> Yes, agreed.
>>>>
>>>>>>
>>>>>> There is no M in H, yet he refers to an M in H
>>>>>> q0 wM w ⊢* qn
>>>>>> if M applied to w does not halt.
>>>>>
>>>>> H is given the input wM w, the representation of M w
>>>>>>
>>>>>> There is no M in H, yet he refers to an M in H
>>>>>> q0 wM w ⊢* qn
>>>>>> if M applied to w does not halt.
>>>>>
>>>>> and needs to decide what it will do.
>>>>>
>>>>
>>>> Yes, agreed.
>>>>
>>>>>>
>>>>>> To correct this error
>>>>>
>>>>> There is no error here (except by you)
>>>>>
>>>>>> if the TM described by wM applied to w does not halt.
>>>>>
>>>>> Right, the TM described by wm is M.
>>>>>> if the TM described by wM applied to w does not halt.
>>>>>
>>>>> The question is, does M w halt or not?
>>>>>
>>>>
>>>> Yes, agreed.
>>>>
>>>>>
>>>>>>
>>>>>> There is no M in Ĥ, yet he refers to an M in Ĥ
>>>>>
>>>>> Wrong.
>>>>>
>>>>> M is the formal parameter, H^ is the actual parameter.
>>>>>
>>>>
>>>> M cannot be any parameter at all, TMa are not allowed to be parameters,
>>>> only TM descriptions are allowed to be parmeters.
>>>
>>> Maybe I went above your head again. Yes, at the implementation level, H
>>> needs to be given a representation. so it gets wM, but at the abstract
>>> description of what it is being asked to do, it is being asked to decide
>>> what Turing Machine M applied to input w will do. That make M a Formal
>>> Parameter to the problem.
>>>
>>>>
>>>>> so, H taking Formal Parameters wM and w, is 'called' by the actual
>>>>> parameters <H^> and <H^>
>>>>>
>>>>
>>>> Yes, agreed.
>>>>
>>>>> Just like when we define H as H(P,I) and call it as H(H_hat, H_hat).
>>>>>
>>>>>> q0 wM ⊢* qx wM wM ⊢* qn
>>>>>> if M applied to wM does not halt
>>>>>>
>>>>>> To correct this error
>>>>>> if the TM described by wM applied to wM does not halt.
>>>>>
>>>>> Right the TM described by wM is M which, is applied to w.
>>>>
>>>> There is another one of your terrible careless mistakes.
>>>> There is no w in Ĥ.
>>>
>>> Neither is there a wM, so you are being inconsistent.
>>
>> ----------1------------2---3----------
>>>>>> q0 wM ⊢* qx wM wM ⊢* qn
>>
>> It is stupid mistakes like saying that there is no wM at (1) (2) and (3)
>> that cause me to not even glance at anything you say for several days.
>>
>>
>
> Yes, H^ *ITSELF* does not have a w, but does have a wM, but the
> definition of H still has a w as a formal parameter, as that is the
> definition of H.
>
> When we look at what is supposed to happen at qx (which you are actually
> WRONG about Linz getting wrong here)
>
Linz (like everyone else) has the error of omission not the error of
commission.
Linz (and everyone else) simply fails to notice that the conventional
halting theorem template presents infinitely nested simulation to every
simulating halt decider.
You and Ben have been dodging this by pretending that the halt decider
is at (1) on input (2) and not at (3) on inputs (4) and (5).
----1----2-----3-----4--5-----6
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
Because the simulated input to Ĥ.qx(⟨Ĥ⟩, ⟨Ĥ⟩) never reaches any final
state whether or not the simulating halt decider at Ĥ.qx aborts its
simulation of this input we know that Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct.
> Linz state here is H^q0 not q0 so he gives it a unique name, there are
> NOT two q0. (If we want to be pedantic).
>
> So, at H^'s H^q0 which is essentially a copy of H's q0, we have as the
> input tape wM wM which if we look at the definition of H, we see that H
> applied to wM w is supposed to predict what the machine M applied to w
> will do. Appling these formal parameters we gets:
>
> H's wM corresponds to H^'s wM
> H's w corresponds to H^'s wM
>
> Thus the sub-machine at H^q0 (aka PO-qx) is supposed to answer what the
> machine M, which is the machine described by H^s input wm would do when
> applied to the input wM to H^.
>
> The next step in the proof, he applies this H^ machine to decide on H^,
> by creating a w^ as the value for wM (so w^ is the description of H^)
> and this means that H given w^ w^ needs to decide what H^ applied to w^
> will do, which is the starting Computation of H^'s q0 being applied to w^.
>
> From your claims, H^'s qx applied to w^ W^ will go to H^'s qn saying
> that it is non-halting, (and thus that is exactly what H's q0 applied to
> w^ w^ will say, since they are the same machine description with the
> same inputs) but H^'s q0 applied to w^ will thus also end up in H^'s qn
> which is a halting state.
>
> Thus H says non-halting, but the actual machine is Halting.
olcott
Oct 2, 2021, 5:02:13 PM10/2/21
to
On 10/2/2021 3:15 PM, Ben Bacarisse wrote:
> Richard Damon <Ric...@Damon-Family.org> writes:
>>
>>
>> The q0 wM w ⊢* qn
>>
>> is the specification of H, not H^.
>>
>> H is applied to wM w as an input.
>
> Yes, but that's not what I'm talking about. (And when I say he got it
> right I juts mean it's not technically wrong. It's still a silly way to
> put it.)
>
> I'm talking about this line:
> is peculiar so goodness knows what he meant.
>
w is the arbitrary finite string that H deals with.
wM is the TM description finite string that Ĥ deals with.
> But later on he does not use the same "translation", just a pointless
> renaming of M as "[t]he TM described by wM":
The fact that Ĥ halts on input ⟨Ĥ⟩
does not contradict the fact that the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ never halts.
This is apparently too difficult for you to understand.
It is very very difficult and cannot be understood until after every
single detail of the actual complete computation has been studied.
No one ever does this. The x86utm C/x86 version is as close as anyone
has ever come to studying every single detail of the essential algorithm.
Most people simply dismiss it as impossible on the basis that they
falsely believe it is a contradiction.
> Richard Damon <Ric...@Damon-Family.org> writes:
>
>> On 10/2/21 12:34 PM, Ben Bacarisse wrote:
>>> olcott <No...@NoWhere.com> writes:
>
>>>> M applied to wM means: The TM described by wM applied to w.
> <snip>
>> On 10/2/21 12:34 PM, Ben Bacarisse wrote:
>>> olcott <No...@NoWhere.com> writes:
>
>>>> M applied to wM means: The TM described by wM applied to w.
>>>> if M applied to wM does not halt
>>>> is translated into
>>>>
>>>> The TM described by wM
>>>
>>> I.e. M
>>>> is translated into
>>>>
>>>> The TM described by wM
>>>
>>>
>>>> applied to wM does not halt
>>>
>>> You got it right this time. I think the w above is just a typo.
>>>> applied to wM does not halt
>>>
>>
>>
>> The q0 wM w ⊢* qn
>>
>> is the specification of H, not H^.
>>
>> H is applied to wM w as an input.
>
> Yes, but that's not what I'm talking about. (And when I say he got it
> right I juts mean it's not technically wrong. It's still a silly way to
> put it.)
>
> I'm talking about this line:
>
> ||| M applied to wM means: The TM described by wM applied to w.
>
> I don't think he intended to write that lone w, but the whole digression
> ||| M applied to wM means: The TM described by wM applied to w.
>
> is peculiar so goodness knows what he meant.
>
w is the arbitrary finite string that H deals with.
wM is the TM description finite string that Ĥ deals with.
> But later on he does not use the same "translation", just a pointless
> renaming of M as "[t]he TM described by wM":
>
> ||| if M applied to wM does not halt
> ||| is translated into
> |||
> ||| The TM described by wM applied to wM does not halt
>
> ||| if M applied to wM does not halt
> ||| is translated into
> |||
> ||| The TM described by wM applied to wM does not halt
>
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
Transitioning to Ĥ.qn is based on this decision: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
The fact that Ĥ halts on input ⟨Ĥ⟩
does not contradict the fact that the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ never halts.
This is apparently too difficult for you to understand.
It is very very difficult and cannot be understood until after every
single detail of the actual complete computation has been studied.
No one ever does this. The x86utm C/x86 version is as close as anyone
has ever come to studying every single detail of the essential algorithm.
Most people simply dismiss it as impossible on the basis that they
falsely believe it is a contradiction.
Message has been deleted
0 new messages