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

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)

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

On 9/29/2021 5:48 PM, Ben Bacarisse wrote:
> olcott <NoOne@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.
>
>> with a single start state.
>
> All TM's have a single start state.
>
>> A simulating halt decider is embedded at Ĥ.qx.
>
> This is not "clarifying" but restricting. Linz uses Ĥ to refer to any
> 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
> 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 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.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
> 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.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

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é
>
>

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 9/30/2021 6:14 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 9/30/2021 11:35 AM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 9/29/2021 9:42 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@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
>>>>>> 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
>>>>> | 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
>>>> and date stamp as I ALWAYS do.
>>>
>>> It's Message-ID: <FL2dnU-wypwbXz_9nZ2dnUU7-d_NnZ2d@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_9nZ2dnUU7-UHNnZ2d@giganews.com>
>
> and again using words this time
>
> H applied to input (Ĥ, Ĥ) transitions to H.qn
> Message-ID: <0cudnXyibs7OuDz9nZ2dnUU7-QfNnZ2d@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_9nZ2dnUU7-RWdnZ2d@giganews.com>
>
> and again using a slightly different notion here
>
> H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
> Message-ID: <2-adncuMeNUVpY78nZ2dnUU7-fPNnZ2d@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: <2aidnV9e3qQaOCDCnZ2dnUU7-c3NnZ2d@giganews.com>
>
> and
>
> "The input to Halts is only finite because..."
> Message-ID: <6eSdnYuLBrIuVFzCnZ2dnUU7-cPNnZ2d@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)

https://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf

Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company. (318-320)

Ĥ.qx(<Ĥ>,<Ĥ>) ⊢* H.qn is correct because the simulation of <Ĥ> applied
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.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

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:
>>>>> 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
>>>>> *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

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 10/1/2021 9:12 AM, Mike Terry wrote:
> 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 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
>>>>> *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
> 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..
>

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
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.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

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
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

On 10/1/2021 11:12 AM, wij wrote:
> 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:
> 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:

(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

>>
>> --
>> Copyright 2021 Pete Olcott
>>
>> "Great spirits have always encountered violent opposition from mediocre
>> minds." Einstein

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

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 [...]
>>> 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. [...]
>>
>>      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 Ĥ.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 10/1/2021 12:17 PM, Richard Damon wrote:
> On 10/1/21 1:04 PM, olcott wrote:
>> 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 [...]
>>>>> 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. [...]
>>>>
>>>>      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 Ĥ.
>>
> 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:
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
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.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 10/1/2021 3:09 PM, Andy Walker wrote:
> 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. [...]
>
>     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
infinitely nested simulation is merely an implementation detail.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

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
Ĥ.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).

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

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:
>>>>>>>>>>> On 10/1/2021 7:08 PM, Ben Bacarisse wrote:
>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 10/1/2021 5:22 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 10/1/2021 3:44 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>>> Oh dear, you've posted about TMs again...
>>>>>>>>>>>>>>>> olcott <NoOne@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.
>>>>>>>>>>>>>> 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
>>>>>>>>>>> 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.
>>>>>>>>>>
>>>>>>>>>> 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.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 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 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.
>>>>>
>>>>> 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
>>>>> 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.
>>>>> 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)
>

On 10/2/2021 3:15 PM, Ben Bacarisse wrote:
> Richard Damon <Richard@Damon-Family.org> writes:
>
>> On 10/2/21 12:34 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>
>>>> M applied to wM means: The TM described by wM applied to w.
> <snip>
>>>> if M applied to wM does not halt
>>>> is translated into
>>>>
>>>> The TM described by wM
>>>
>>> I.e. M
>>>
>>>> applied to wM does not halt
>>>
>>> You got it right this time. I think the w above is just a typo.
>>
>>
>> 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
> 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
>

Ĥ.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.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On Saturday, October 2, 2021 at 4:02:13 PM UTC-5, olcott wrote:
> On 10/2/2021 3:15 PM, Ben Bacarisse wrote:
> > 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>
> >>>> if M applied to wM does not halt
> >>>> is translated into
> >>>>
> >>>> The TM described by wM
> >>>
> >>> I.e. M
> >>>
> >>>> applied to wM does not halt
> >>>
> >>> You got it right this time. I think the w above is just a typo.
> >>
> >>
> >> 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
> > 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
> >
> Ĥ.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.
> --
> Copyright 2021 Pete Olcott
>
> "Great spirits have always encountered violent opposition from mediocre
> minds." Einstein

And a good example of a mediocre mind is Olcott.

On 10/15/2021 10:17 AM, Richard Damon wrote:
>
> On 10/15/21 10:47 AM, olcott wrote:
>> On 10/14/2021 11:29 PM, Richard Damon wrote:
>>> On 10/14/21 8:27 PM, olcott wrote:
>>>
>>>> Linz explicitly specified that H is any TM that gets the right answer.
>>>> He is incorrect that H does not exist.
>>>
>>> So, will you show an ACTUAL Turing Machine that gets the right answer?
>>>
>>> Not just something you claim must be sort of like a Turing Machine
>>> that givs something you hand wave to claim is the right answer.
>>>
>>> This is, of course, impossible, but you will try to make something
>>> that sort of seems to be the right answer, but you will hide the
>>> problems with a bunch of smoke.
>>>
>>>
>>> The key point that you seem to miss is that since H for you case only
>>> needs to get ONE machie right, H could just as easily ignore its
>>> input and give the 'right' answer.
>>>
>>> But Linz has shown that whatever answer H gives, it will be wrong by
>>> the nature of the construction of H^.
>>>
>>
>> Superficial analysis seems to indicate this, yet this is merely
>> superficial analysis. Only categorically exhaustive reasoning can test
>> every possibility that can possibly exist and do this in finite time.
>
> Right, and there are only 4 possible behaviors that H can have.
>
> It can halt in the state qy.
> It can halt in the state qn.
> It can halt in some other state and fail to meet its requirements.
> It can fail to halt in any state and fail to meet its requirements.
>
> What other possibility do you see for H to do.
>
> This IS a Categorically Exhaustive Reasoning.
H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qy
because Ĥ.qx applied to ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to Ĥ.qn

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

On 10/19/2021 11:55 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 10/18/2021 5:59 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 10/17/2021 7:47 PM, Ben Bacarisse wrote:
>>>>> Quotes re-ordered for clarity...
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>> On 10/17/2021 10:03 AM, Ben Bacarisse wrote:
>>>>>>>
>>>>>>> But you agree that
>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊦ Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦ Ĥ.qn
>>>>>>> if (and only if) Ĥ applied to ⟨Ĥ⟩ does not halt.
>>>>>>>
>>>>>>> is (one half of) what Linz means by Ĥ, yes? (I don't expect an
>>>>>>> answer -- I expect you'll just repeat the waffle.)
>>>>>>
>>>>>> No not at all, not in the least little bit
>>>>>
>>>>> OK, so you are not using Ĥ to denote an exemplar of the same class of
>>>>> TMs that Linz does. If you were, you would have to agree that Linz's
>>>>> specification of when Ĥ transitions to qn is the correct one.
>>>>>
>>>>> Oh, and you need to apologise for some very deceptive claims to the
>>>>> contrary.
>>>>
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>> if (and only if) Ĥ applied to ⟨Ĥ⟩ does not halt.
>>
>> https://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf page 319
>>
>> That you do not understand the most basic point that Linz has adapted
>> TM H by prepending states and appending states such that the original
>> H "not" path of H remains in the middle is a necessary prerequisite.
>
> I'll leave it to others to decide which one of use us is lacking basic
> understanding.
>
> Just stop dishonestly removing the key criterion given in Linz, or admit
> that you are not using this notation as Linz does.
>
>> q0 Wm Wm ⊢* y1 qn y2 / The "no" path of TM H
>
> Linz says it better: if M applied to wM does not halt. Your silly
> phrase does not state what it is that H is saying "no" to.
>

Linz is vague about the point in the execution trace that matters.
I am not vague about the point in the execution trace that matters.

As long as the simulating halt decider correctly decides that the
simulation of its input TM description never reaches its final state
whether or not this simulating halt decider aborts the simulation of
this input then this simulating halt decider does correctly decide that
this its input does not halt.

>> q0 Wm Wm ⊢* y1 qn y2 / The "no" path of TM H'
>> q0 Wm ⊢* Ĥq0 Wm Wm ⊢* Ĥ y1 qn y2 // The "no" path of TM Ĥ
>
> Linz says it better: if Ĥ applied to wM does not halt.
>

The only point in the execution trace that matters is where the halt
decider makes its halting decision.

When it is known to be true that the simulated input to Ĥq0 Wm Wm never
reaches its final state whether or not the simulating halt decider
aborts its simulation of this input then we know that the state
transition to qn is correct.

>> This leaves the "no" path of TM H at Linz Ĥq0
>>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
> And Linz says exactly when this transitions sequence occurs: if Ĥ
> applied to ⟨Ĥ⟩ does not halt.
>

If he is referring to something besides the input to the halt decider
then Linz is incorrect.

As long as a simulating halt decider correctly decides that its input
never reaches its own final state then this simulating halt decider is
necessarily correct when it decides that this input never halts.

When we know that we have a black cat then we know that we have a cat.

> The only excuse for dropping what Linz says about these transition
> sequences is to deceive. Stop doing that.
>

Linz is either misleadingly vague or incorrect.
Whether or not a halt decider correctly decides the halt status of its
input only pertains to the halt status of this input and nothing else.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 10/19/2021 8:21 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 10/19/2021 11:55 AM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 10/18/2021 5:59 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 10/17/2021 7:47 PM, Ben Bacarisse wrote:
>>>>>>> Quotes re-ordered for clarity...
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>> On 10/17/2021 10:03 AM, Ben Bacarisse wrote:
>>>>>>>>>
>>>>>>>>> But you agree that
>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊦ Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦ Ĥ.qn
>>>>>>>>> if (and only if) Ĥ applied to ⟨Ĥ⟩ does not halt.
>>>>>>>>>
>>>>>>>>> is (one half of) what Linz means by Ĥ, yes? (I don't expect an
>>>>>>>>> answer -- I expect you'll just repeat the waffle.)
>>>>>>>>
>>>>>>>> No not at all, not in the least little bit
>>>>>>>
>>>>>>> OK, so you are not using Ĥ to denote an exemplar of the same class of
>>>>>>> TMs that Linz does. If you were, you would have to agree that Linz's
>>>>>>> specification of when Ĥ transitions to qn is the correct one.
>>>>>>>
>>>>>>> Oh, and you need to apologise for some very deceptive claims to the
>>>>>>> contrary.
>>>>>>
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>> if (and only if) Ĥ applied to ⟨Ĥ⟩ does not halt.
>>>>
>>>> https://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf page 319
>>>>
>>>> That you do not understand the most basic point that Linz has adapted
>>>> TM H by prepending states and appending states such that the original
>>>> H "not" path of H remains in the middle is a necessary prerequisite.
>>> I'll leave it to others to decide which one of use us is lacking basic
>>> understanding.
>>> Just stop dishonestly removing the key criterion given in Linz, or admit
>>> that you are not using this notation as Linz does.
>>>
>>>> q0 Wm Wm ⊢* y1 qn y2 / The "no" path of TM H
>>> Linz says it better: if M applied to wM does not halt. Your silly
>>> phrase does not state what it is that H is saying "no" to.
>>
>> Linz is vague about the point in the execution trace that matters.
>
> You replacement is useless. Linz's specification is clear. Obviously
> it does not way what you want, but it's not vague.
>
>>>> q0 Wm Wm ⊢* y1 qn y2 / The "no" path of TM H'
>>>> q0 Wm ⊢* Ĥq0 Wm Wm ⊢* Ĥ y1 qn y2 // The "no" path of TM Ĥ
>>>
>>> Linz says it better: if Ĥ applied to wM does not halt.
>>
>> The only point in the execution trace that matters is where the halt
>> decider makes its halting decision.
>
> What matters is that if H is as specified in Linz, the corresponding Ĥ
> behaves as Linz says and you keep removing.
>
>>>> This leaves the "no" path of TM H at Linz Ĥq0
>>>>
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>> And Linz says exactly when this transitions sequence occurs: if Ĥ
>>> applied to ⟨Ĥ⟩ does not halt.
>>
>> If he is referring to something besides the input to the halt decider
>> then Linz is incorrect.
>
> I am happy to explain "if Ĥ applied to wM does not halt" when attached
> to the line you keep leaving it off if you think it would help. What is
> it you don't understand?
>

q0 Wm ⊢* Ĥq0 Wm Wm ⊢* Ĥ y1 qn y2 // The "no" path of TM Ĥ
if M applied to Wm does not halt

Linz cannot be correctly referring to q0 applied to Wm because there is
no halt decider at q0. If he is referring to that then he is wrong.

Linz can only be referring to Ĥq0 Wm Wm the machine of the first
Wm being applied to the machine description of the second Wm.

A simulating halt decider H does correctly decide the halt status of its
input (P,P) if-and-only-if it correctly decides that its simulated input
P never reaches its final state whether or not it aborts the simulation
of this input.

If you can't understand this then you are hopelessly and irreconcilably
lost. Understanding this is a key mandatory prerequisite upon which all
subsequent understanding is based.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 10/20/2021 10:42 AM, André G. Isaak wrote:
> On 2021-10-20 09:25, olcott wrote:
>> On 10/20/2021 10:13 AM, André G. Isaak wrote:
>>> On 2021-10-20 07:57, olcott wrote:
>>>> On 10/19/2021 8:21 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 10/19/2021 11:55 AM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 10/18/2021 5:59 PM, Ben Bacarisse wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> On 10/17/2021 7:47 PM, Ben Bacarisse wrote:
>>>>>>>>>>> Quotes re-ordered for clarity...
>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>> On 10/17/2021 10:03 AM, Ben Bacarisse wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> But you agree that
>>>>>>>>>>>>>         Ĥ.q0 ⟨Ĥ⟩ ⊦ Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦ Ĥ.qn
>>>>>>>>>>>>>         if (and only if) Ĥ applied to ⟨Ĥ⟩ does not halt.
>>>>>>>>>>>>>
>>>>>>>>>>>>> is (one half of) what Linz means by Ĥ, yes?  (I don't
>>>>>>>>>>>>> expect an
>>>>>>>>>>>>> answer -- I expect you'll just repeat the waffle.)
>>>>>>>>>>>>
>>>>>>>>>>>> No not at all, not in the least little bit
>>>>>>>>>>>
>>>>>>>>>>> OK, so you are not using Ĥ to denote an exemplar of the same
>>>>>>>>>>> class of
>>>>>>>>>>> TMs that Linz does.  If you were, you would have to agree
>>>>>>>>>>> that Linz's
>>>>>>>>>>> specification of when Ĥ transitions to qn is the correct one.
>>>>>>>>>>>
>>>>>>>>>>> Oh, and you need to apologise for some very deceptive claims
>>>>>>>>>>> to the
>>>>>>>>>>> contrary.
>>>>>>>>>>
>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>> if (and only if) Ĥ applied to ⟨Ĥ⟩ does not halt.
>>>>>>>>
>>>>>>>> https://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf
>>>>>>>> page 319
>>>>>>>>
>>>>>>>> That you do not understand the most basic point that Linz has
>>>>>>>> adapted
>>>>>>>> TM H by prepending states and appending states such that the
>>>>>>>> original
>>>>>>>> H "not" path of H remains in the middle is a necessary
>>>>>>>> prerequisite.
>>>>>>> I'll leave it to others to decide which one of use us is lacking
>>>>>>> basic
>>>>>>> understanding.
>>>>>>> Just stop dishonestly removing the key criterion given in Linz,
>>>>>>> or admit
>>>>>>> that you are not using this notation as Linz does.
>>>>>>>
>>>>>>>> q0 Wm Wm ⊢* y1 qn y2  / The "no" path of TM H
>>>>>>> Linz says it better: if M applied to wM does not halt.  Your silly
>>>>>>> phrase does not state what it is that H is saying "no" to.
>>>>>>
>>>>>> Linz is vague about the point in the execution trace that matters.
>>>>>
>>>>> You replacement is useless.  Linz's specification is clear.  Obviously
>>>>> it does not way what you want, but it's not vague.
>>>>>
>>>>>>>> q0 Wm Wm ⊢* y1 qn y2  / The "no" path of TM H'
>>>>>>>> q0 Wm ⊢* Ĥq0 Wm Wm ⊢* Ĥ y1 qn y2 // The "no" path of TM Ĥ
>>>>>>>
>>>>>>> Linz says it better: if Ĥ applied to wM does not halt.
>>>>>>
>>>>>> The only point in the execution trace that matters is where the halt
>>>>>> decider makes its halting decision.
>>>>>
>>>>> What matters is that if H is as specified in Linz, the corresponding Ĥ
>>>>> behaves as Linz says and you keep removing.
>>>>>
>>>>>>>> This leaves the "no" path of TM H at Linz Ĥq0
>>>>>>>>
>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>> And Linz says exactly when this transitions sequence occurs: if Ĥ
>>>>>>> applied to ⟨Ĥ⟩ does not halt.
>>>>>>
>>>>>> If he is referring to something besides the input to the halt decider
>>>>>> then Linz is incorrect.
>>>>>
>>>>> I am happy to explain "if Ĥ applied to wM does not halt" when attached
>>>>> to the line you keep leaving it off if you think it would help.
>>>>> What is
>>>>> it you don't understand?
>>>>>
>>>>
>>>> q0 Wm ⊢* Ĥq0 Wm Wm ⊢* Ĥ y1 qn y2 // The "no" path of TM Ĥ
>>>> if M applied to Wm does not halt
>>>>
>>>> Linz cannot be correctly referring to q0 applied to Wm because there
>>>> is no halt decider at q0. If he is referring to that then he is wrong.
>>>
>>> Nor is there a halt decider at Ĥq0. Both q0 and Ĥq0 refer to single
>>> states in the execution of Ĥ. There isn't a halt decider anywhere in Ĥ.
>>>
>>
>> https://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf
>> It is clear that the "no" path of the H halt decider from which Ĥ was
>> constructed begins at Ĥq0 and its input is Wm Wm. Pages 318 and 319
>> prove this.
>
> ??
>
> Ĥ always begins in state q0, so all paths ultimately begin there.
>

That is only the point in the execution trace of Ĥ that copies its input
so that its halt decider at Ĥq0 has its required input pair.

> Since it always passes through state Ĥq0, you can talk about the path
> beginning at Ĥq0 if you want, but that has no bearing on the point being
> made, which is that final state qn is only reached in cases where M
> applied to Wm does not halt.
>
> André
>

As long as the simulating halt decider at Ĥq0 correctly decides that its
simulated input Wm applied to Wm never reaches the final state of this
simulated input (whether or not the simulating halt decider aborts its
simulation of this input) then this simulating halt decider at Ĥq0 is
correct when it transitions to qn.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 10/20/2021 11:46 AM, André G. Isaak wrote:
> On 2021-10-20 09:51, olcott wrote:
>> On 10/20/2021 10:42 AM, André G. Isaak wrote:
>>> On 2021-10-20 09:25, olcott wrote:
>>>> On 10/20/2021 10:13 AM, André G. Isaak wrote:
>>>>> On 2021-10-20 07:57, olcott wrote:
>>>>>> On 10/19/2021 8:21 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 10/19/2021 11:55 AM, Ben Bacarisse wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> On 10/18/2021 5:59 PM, Ben Bacarisse wrote:
>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>> On 10/17/2021 7:47 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>> Quotes re-ordered for clarity...
>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>> On 10/17/2021 10:03 AM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> But you agree that
>>>>>>>>>>>>>>>         Ĥ.q0 ⟨Ĥ⟩ ⊦ Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦ Ĥ.qn
>>>>>>>>>>>>>>>         if (and only if) Ĥ applied to ⟨Ĥ⟩ does not halt.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> is (one half of) what Linz means by Ĥ, yes?  (I don't
>>>>>>>>>>>>>>> expect an
>>>>>>>>>>>>>>> answer -- I expect you'll just repeat the waffle.)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> No not at all, not in the least little bit
>>>>>>>>>>>>>
>>>>>>>>>>>>> OK, so you are not using Ĥ to denote an exemplar of the
>>>>>>>>>>>>> same class of
>>>>>>>>>>>>> TMs that Linz does.  If you were, you would have to agree
>>>>>>>>>>>>> that Linz's
>>>>>>>>>>>>> specification of when Ĥ transitions to qn is the correct one.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Oh, and you need to apologise for some very deceptive
>>>>>>>>>>>>> claims to the
>>>>>>>>>>>>> contrary.
>>>>>>>>>>>>
>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>> if (and only if) Ĥ applied to ⟨Ĥ⟩ does not halt.
>>>>>>>>>>
>>>>>>>>>> https://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf
>>>>>>>>>> page 319
>>>>>>>>>>
>>>>>>>>>> That you do not understand the most basic point that Linz has
>>>>>>>>>> adapted
>>>>>>>>>> TM H by prepending states and appending states such that the
>>>>>>>>>> original
>>>>>>>>>> H "not" path of H remains in the middle is a necessary
>>>>>>>>>> prerequisite.
>>>>>>>>> I'll leave it to others to decide which one of use us is
>>>>>>>>> lacking basic
>>>>>>>>> understanding.
>>>>>>>>> Just stop dishonestly removing the key criterion given in Linz,
>>>>>>>>> or admit
>>>>>>>>> that you are not using this notation as Linz does.
>>>>>>>>>
>>>>>>>>>> q0 Wm Wm ⊢* y1 qn y2  / The "no" path of TM H
>>>>>>>>> Linz says it better: if M applied to wM does not halt.  Your silly
>>>>>>>>> phrase does not state what it is that H is saying "no" to.
>>>>>>>>
>>>>>>>> Linz is vague about the point in the execution trace that matters.
>>>>>>>
>>>>>>> You replacement is useless.  Linz's specification is clear.
>>>>>>> Obviously
>>>>>>> it does not way what you want, but it's not vague.
>>>>>>>
>>>>>>>>>> q0 Wm Wm ⊢* y1 qn y2  / The "no" path of TM H'
>>>>>>>>>> q0 Wm ⊢* Ĥq0 Wm Wm ⊢* Ĥ y1 qn y2 // The "no" path of TM Ĥ
>>>>>>>>>
>>>>>>>>> Linz says it better: if Ĥ applied to wM does not halt.
>>>>>>>>
>>>>>>>> The only point in the execution trace that matters is where the
>>>>>>>> halt
>>>>>>>> decider makes its halting decision.
>>>>>>>
>>>>>>> What matters is that if H is as specified in Linz, the
>>>>>>> corresponding Ĥ
>>>>>>> behaves as Linz says and you keep removing.
>>>>>>>
>>>>>>>>>> This leaves the "no" path of TM H at Linz Ĥq0
>>>>>>>>>>
>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>> And Linz says exactly when this transitions sequence occurs: if Ĥ
>>>>>>>>> applied to ⟨Ĥ⟩ does not halt.
>>>>>>>>
>>>>>>>> If he is referring to something besides the input to the halt
>>>>>>>> decider
>>>>>>>> then Linz is incorrect.
>>>>>>>
>>>>>>> I am happy to explain "if Ĥ applied to wM does not halt" when
>>>>>>> attached
>>>>>>> to the line you keep leaving it off if you think it would help.
>>>>>>> What is
>>>>>>> it you don't understand?
>>>>>>>
>>>>>>
>>>>>> q0 Wm ⊢* Ĥq0 Wm Wm ⊢* Ĥ y1 qn y2 // The "no" path of TM Ĥ
>>>>>> if M applied to Wm does not halt
>>>>>>
>>>>>> Linz cannot be correctly referring to q0 applied to Wm because
>>>>>> there is no halt decider at q0. If he is referring to that then he
>>>>>> is wrong.
>>>>>
>>>>> Nor is there a halt decider at Ĥq0. Both q0 and Ĥq0 refer to single
>>>>> states in the execution of Ĥ. There isn't a halt decider anywhere
>>>>> in Ĥ.
>>>>>
>>>>
>>>> https://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf It is
>>>> clear that the "no" path of the H halt decider from which Ĥ was
>>>> constructed begins at Ĥq0 and its input is Wm Wm. Pages 318 and 319
>>>> prove this.
>>>
>>> ??
>>>
>>> Ĥ always begins in state q0, so all paths ultimately begin there.
>>>
>>
>> That is only the point in the execution trace of Ĥ that copies its input
>
> So what? It's still the starting point of the computation. Ĥ is a Turing
> Machine which takes a *single* input string. The fact that it
> subsequently duplicates that is an integral part of the computation
> performed by Ĥ on a given input.
>
>> so that its halt decider at Ĥq0 has its required input pair.
>
> There IS NO halt decider at Ĥq0. Nor anywhere else in Ĥ.

It "no" path is the H halt decider is at Ĥq0 of Ĥ.

>
>>> Since it always passes through state Ĥq0, you can talk about the path
>>> beginning at Ĥq0 if you want, but that has no bearing on the point
>>> being made, which is that final state qn is only reached in cases
>>> where M applied to Wm does not halt.
>>>
>>> André
>>>
>>
>> As long as the simulating halt decider at Ĥq0 correctly decides that
>> its simulated input Wm applied to Wm never reaches the final state of
>> this simulated input (whether or not the simulating halt decider
>> aborts its simulation of this input) then this simulating halt decider
>> at Ĥq0 is correct when it transitions to qn.
>
> But that's not the criterion given by Linz. He specifies that qn is
> reached if M applied to Wm does not halt.

On 10/20/2021 4:40 PM, André G. Isaak wrote:
> On 2021-10-20 14:34, olcott wrote:
>> On 10/20/2021 3:06 PM, André G. Isaak wrote:
>
>>> But it is *not* guaranteed to halt, so it is not a decider at all.
>>> Not any kind of decider.
>>
>> If I make any thingamajig Whatchamacallit that correctly determines
>> the halt status of the "impossible" halting problem counter-example
>> input then this is very significant.
>
> But again, that's what your *H* is purported to do. It isn't what Ĥ is
> purported to do. I have been commenting on your insistence of calling Ĥ
> (or Ĥq0) a halt decider. It is not one. Linz doesn't describe it as one.
>
> If your going to make grandiose claims about having constructed a
> (partial) halt decider, at least restrict them to your H, not to Ĥ which
> isn't presented by Linz as a decider of anything. It's simply a TM which
> performs some relatively meaningless computation but which plays a role
> in his proof.
>
> André
>

Because H only correctly determines the halt status of ⟨Ĥ⟩ ⟨Ĥ⟩ on the
basis that Ĥq0 correctly detemines the halt status of ⟨Ĥ⟩ ⟨Ĥ⟩ it must be
understood that Ĥq0 correctly determines the halt status of ⟨Ĥ⟩ ⟨Ĥ⟩.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 10/20/2021 8:37 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 10/20/2021 7:00 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 10/19/2021 8:21 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 10/19/2021 11:55 AM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 10/18/2021 5:59 PM, Ben Bacarisse wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> On 10/17/2021 7:47 PM, Ben Bacarisse wrote:
>>>>>>>>>>> Quotes re-ordered for clarity...
>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>> On 10/17/2021 10:03 AM, Ben Bacarisse wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> But you agree that
>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊦ Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦ Ĥ.qn
>>>>>>>>>>>>> if (and only if) Ĥ applied to ⟨Ĥ⟩ does not halt.
>>>>>>>>>>>>>
>>>>>>>>>>>>> is (one half of) what Linz means by Ĥ, yes? (I don't expect an
>>>>>>>>>>>>> answer -- I expect you'll just repeat the waffle.)
>>>>>>>>>>>>
>>>>>>>>>>>> No not at all, not in the least little bit
>>>>>>>>>>>
>>>>>>>>>>> OK, so you are not using Ĥ to denote an exemplar of the same class of
>>>>>>>>>>> TMs that Linz does. If you were, you would have to agree that Linz's
>>>>>>>>>>> specification of when Ĥ transitions to qn is the correct one.
>>>>>>>>>>>
>>>>>>>>>>> Oh, and you need to apologise for some very deceptive claims to the
>>>>>>>>>>> contrary.
>>>>>>>>>>
>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>> if (and only if) Ĥ applied to ⟨Ĥ⟩ does not halt.
>>>>>>>>
>>>>>>>> https://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf page 319
>>>>>>>>
>>>>>>>> That you do not understand the most basic point that Linz has adapted
>>>>>>>> TM H by prepending states and appending states such that the original
>>>>>>>> H "not" path of H remains in the middle is a necessary prerequisite.
>>>>>>> I'll leave it to others to decide which one of use us is lacking basic
>>>>>>> understanding.
>>>>>>> Just stop dishonestly removing the key criterion given in Linz, or admit
>>>>>>> that you are not using this notation as Linz does.
>>>>>>>
>>>>>>>> q0 Wm Wm ⊢* y1 qn y2 / The "no" path of TM H
>>>>>>> Linz says it better: if M applied to wM does not halt. Your silly
>>>>>>> phrase does not state what it is that H is saying "no" to.
>>>>>>
>>>>>> Linz is vague about the point in the execution trace that matters.
>>>>> You replacement is useless. Linz's specification is clear. Obviously
>>>>> it does not way what you want, but it's not vague.
>>>>>
>>>>>>>> q0 Wm Wm ⊢* y1 qn y2 / The "no" path of TM H'
>>>>>>>> q0 Wm ⊢* Ĥq0 Wm Wm ⊢* Ĥ y1 qn y2 // The "no" path of TM Ĥ
>>>>>>>
>>>>>>> Linz says it better: if Ĥ applied to wM does not halt.
>>>>>>
>>>>>> The only point in the execution trace that matters is where the halt
>>>>>> decider makes its halting decision.
>>>>> What matters is that if H is as specified in Linz, the corresponding Ĥ
>>>>> behaves as Linz says and you keep removing.
>>>>>
>>>>>>>> This leaves the "no" path of TM H at Linz Ĥq0
>>>>>>>>
>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>> And Linz says exactly when this transitions sequence occurs: if Ĥ
>>>>>>> applied to ⟨Ĥ⟩ does not halt.
>>>>>>
>>>>>> If he is referring to something besides the input to the halt decider
>>>>>> then Linz is incorrect.
>>>>> I am happy to explain "if Ĥ applied to wM does not halt" when attached
>>>>> to the line you keep leaving it off if you think it would help. What is
>>>>> it you don't understand?
>>>>
>>>> q0 Wm ⊢* Ĥq0 Wm Wm ⊢* Ĥ y1 qn y2 // The "no" path of TM Ĥ
>>>> if M applied to Wm does not halt
>>>>
>>>> Linz cannot be correctly referring to q0 applied to Wm because there
>>>> is no halt decider at q0.
>>> This notation is hopeless in ASCII. Using the notation that has evolved
>>> in these threads (not my preferred one, but I don't want to complicate
>>> matters any more) Linz writes:
>>> Ĥ.q0 <M> ⊢* Ĥ.qx <M> <M> ⊢* y1 Ĥ.qn y2
>>> if M applied to <M> does not halt.
>>> And with these changes in notation you seem to be saying
>>>
>>>> Linz cannot be correctly referring to Ĥ applied to <M> because there
>>>> is no halt decider at q0.
>>> Yes, there is no halt decider at Ĥ.q0, but he is correctly referring to
>>> what Ĥ applied to <M> should do: Ĥ applied to <M> should transition to
>>> Ĥ.qn if (and only if) M (the TM encoded in the string input) applied to
>>> <M> (that exactly same string input) does not halt.
>>> Your next point helps explain how he comes to say this about Ĥ.
>>>
>>>> Linz can only be referring to Ĥ.qx <M> <M> the machine of the first
>>>> <M> being applied to the machine description of the second <M>.
>>>
>>> The annotation dose not specifically refer to what this sub-computation
>>> does. It simply gives the condition under which Ĥ will transition from
>>> Ĥ.q0 to Ĥ.qn.
>>
>> If a simulating halt decider H correctly determines that the
>> simulation of its input <M> applied to <M> never reaches its final
>> state whether or not this simulating halt decider aborts the
>> simulation of this input then this simulating halt decider does
>> correctly decide that this input never halts NO MATTER WHAT ELSE.
>
> This is not what Linz is saying.

Of course this is not what Linz is saying. Linz is still under the
misconception that Ĥ.q0 applied to <Ĥ> <Ĥ> would not correctly
transition to H.qn.

> If I can help with any further
> explanation, I'm happy to have a go but you need to stop repeating what
> you are saying and try to focus on what Linz is saying. Once you get
> what he is saying you will see that you can say anything you like about
> a subclass (those that "simulate") of the empty class of TMs (the halt
> deciders) that Linz is talking about. Atatements about no TMs are
> vacuously true (or irrelevant -- take your pick).
>
>> Anything and everything that is not input to this halt decider is 100%
>> totally irrelevant.
>
> Technically, there is no halt decider in the TM you are talking about,
> but that's a detail and you don't do details. Did you follow what I
> wrote about how the string input to the almost-decider at Ĥ.qx is
> entirely why Linz's annotation is correct? Here it is:
>
>>> But you are correct in that the annotation /derives/ from what we know
>>> about the modified copy of H embedded at Ĥ.qx. We know that
>>> H.q0 <M> s ⊢* y1 H.qn y2
>>> if M applied to s does not halt.
>>> and since the TM at Ĥ.qx is (in this regard at least) exactly like H we
>>> know that
>>> Ĥ.qx <M> <M> ⊢* y1 Ĥ.qn y2
>>> if M applied to <M> does not halt.
>>> Now, because
>>> Ĥ.q0 s ⊢* Ĥ.qx s s
>>> for /any/ string s, we know, specifically, that
>>> Ĥ.q0 <M> ⊢* Ĥ.qx <M> <M> ⊢* y1 Ĥ.qn y2
>>> if M applied to <M> does not halt.
>>> Can you now see where this correctly annotated line comes from? Can I
>>> explain any part of this some other way to make it clearer?
>
> I suspect you simply didn't read it since I am agreeing with you about
> the central role of the Ĥ.qx <M> <M> part in explaining why Linz is
> correct.
>

On 10/21/2021 9:19 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 10/21/2021 4:45 AM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 10/20/2021 8:37 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 10/20/2021 7:00 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>>>>>> q0 Wm ⊢* Ĥq0 Wm Wm ⊢* Ĥ y1 qn y2 // The "no" path of TM Ĥ
>>>>>>>> if M applied to Wm does not halt
>>>>>>>>
>>>>>>>> Linz cannot be correctly referring to q0 applied to Wm because there
>>>>>>>> is no halt decider at q0.
>>>>>>> This notation is hopeless in ASCII. Using the notation that has evolved
>>>>>>> in these threads (not my preferred one, but I don't want to complicate
>>>>>>> matters any more) Linz writes:
>>>>>>> Ĥ.q0 <M> ⊢* Ĥ.qx <M> <M> ⊢* y1 Ĥ.qn y2
>>>>>>> if M applied to <M> does not halt.
>>>>>>> And with these changes in notation you seem to be saying
>>>>>>>
>>>>>>>> Linz cannot be correctly referring to Ĥ applied to <M> because there
>>>>>>>> is no halt decider at q0.
>>>>>>> Yes, there is no halt decider at Ĥ.q0, but he is correctly referring to
>>>>>>> what Ĥ applied to <M> should do: Ĥ applied to <M> should transition to
>>>>>>> Ĥ.qn if (and only if) M (the TM encoded in the string input) applied to
>>>>>>> <M> (that exactly same string input) does not halt.
>>>>>>> Your next point helps explain how he comes to say this about Ĥ.
>>>>>>>
>>>>>>>> Linz can only be referring to Ĥ.qx <M> <M> the machine of the first
>>>>>>>> <M> being applied to the machine description of the second <M>.
>>>>>>>
>>>>>>> The annotation dose not specifically refer to what this sub-computation
>>>>>>> does. It simply gives the condition under which Ĥ will transition from
>>>>>>> Ĥ.q0 to Ĥ.qn.
>>>>>>
>>>>>> If a simulating halt decider H correctly determines that the
>>>>>> simulation of its input <M> applied to <M> never reaches its final
>>>>>> state whether or not this simulating halt decider aborts the
>>>>>> simulation of this input then this simulating halt decider does
>>>>>> correctly decide that this input never halts NO MATTER WHAT ELSE.
>>>>> This is not what Linz is saying.
>>>>
>>>> Of course this is not what Linz is saying.
>>> But until you understand what he is saying, you can't see why you are
>>> wrong.
>>
>> That Linz did not consider a simulating halt decider does not make me
>> wrong.
>
> Quite. You are wrong for the reasons I gave.
>
>> If any of this was wrong someone could point out an actual error:
>>
>> The machine at Ĥq0 transitions to Ĥqn if the simulation of ⟨Ĥ⟩ applied
>> to ⟨Ĥ⟩ would never reach its final state whether or not this
>> simulation is aborted.
>
> The error is that this is a statement about an sub-set of and empty set
> of Turing machines.
>

You are simply making a false assumption. You are beginning with the
premise that Linz is correct then concluding that Linz is correct on the
basis of this premise.

>> Adapted from bottom of page 319 (definition of Ĥ)
>> ⟨Ĥ⟩ indicates the Turing machine description of Ĥ.
>>
>> q0 ⟨Ĥ⟩ ⊢* Ĥq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ∞
>> If the simulated input to Ĥq0 ⟨Ĥ⟩ applied to ⟨Ĥ⟩ halts
>
> This is either the wrong annotation for Linz's Ĥ or a pointless
> re-wording of it.
>
>> q0 ⟨Ĥ⟩ ⊢* Ĥq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥqn
>> If the simulated input to Ĥq0 ⟨Ĥ⟩ applied to ⟨Ĥ⟩ does not halt
>
> And again, this is the wrong annotation for Linz's Ĥ. Linz's Ĥ
> transitions to qn is (and only if) Ĥ applied to ⟨Ĥ⟩ does not halt.
>

No you are wrong.
Ĥq0 ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to Ĥqn when its input never halts.
You can't show that this is incorrect only because it is correct.

> You can't change the specification of what Ĥ does if you want to be
> taken seriously. You have to accept the logical consequences of his
> definitions or define your own class of machines.
>

The halt decider must only correctly decide whether or not its input
halts on its input. As long as this decision is correct then it is
impossible for anything else to show that the halt decider is incorrect.

The halt decider must only correctly decide whether or not its input
halts on its input. As long as this decision is correct then it is
impossible for anything else to show that the halt decider is incorrect.

The halt decider must only correctly decide whether or not its input
halts on its input. As long as this decision is correct then it is
impossible for anything else to show that the halt decider is incorrect.

The halt decider must only correctly decide whether or not its input
halts on its input. As long as this decision is correct then it is
impossible for anything else to show that the halt decider is incorrect.

The halt decider must only correctly decide whether or not its input
halts on its input. As long as this decision is correct then it is
impossible for anything else to show that the halt decider is incorrect.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 10/21/2021 8:33 PM, olcott wrote:

> The halt decider must only correctly decide whether or not its input
> halts on its input. As long as this decision is correct then it is
> impossible for anything else to show that the halt decider is incorrect.
>
> The halt decider must only correctly decide whether or not its input
> halts on its input. As long as this decision is correct then it is
> impossible for anything else to show that the halt decider is incorrect.
>
> The halt decider must only correctly decide whether or not its input
> halts on its input. As long as this decision is correct then it is
> impossible for anything else to show that the halt decider is incorrect.
>
> The halt decider must only correctly decide whether or not its input
> halts on its input. As long as this decision is correct then it is
> impossible for anything else to show that the halt decider is incorrect.
>
> The halt decider must only correctly decide whether or not its input
> halts on its input. As long as this decision is correct then it is
> impossible for anything else to show that the halt decider is incorrect.
<See my recent relevant to this one> N.B. Compulsive repetition such as
the above is strong evidence of fixation in the early, anal stages of
development. Even though it usually occurs in much younger humans, it is
possible (in your case) that either 1) you never passed out of this
stage or 2) you have regressed. Typically compulsions completely inhibit
the mind from processing other information of sensing the environment. I
think your regression has blocked your sanity in addition to your
ability to process simple adult tasks. It's no wonder your logic (not
simply as part of mathematics but as a part of ordinary life) is so
deeply flawed. You can't even engage in simple, pleasant dialogue
without tantrums and endless repetition.

I would suggest that you do some online searches to learn more about
your condition(s). Unfortunately I know better from your behavior here:
you would look something up, your eyes would glaze over since you can
not concentrate, then you would quote things you do not understand and
insist you had novel insights. All the while exhibiting all the signs of
a sick adult mired in the anal retentive stage with no self awareness
what so ever. Get help.
Jeff Barnett