On 3/20/22 10:18 PM, olcott wrote:
> On 3/20/2022 9:13 PM, Richard Damon wrote:
>> On 3/20/22 10:05 PM, olcott wrote:
>>> On 3/20/2022 8:53 PM, André G. Isaak wrote:
>>>> On 2022-03-20 19:39, olcott wrote:
>>>>> On 3/20/2022 8:09 PM, André G. Isaak wrote:
>>>>>> On 2022-03-20 17:50, olcott wrote:
>>>>>>> On 3/20/2022 2:25 PM, André G. Isaak wrote:
>>>>>>>> On 2022-03-20 13:12, olcott wrote:
>>>>>>>>> On 3/20/2022 1:59 PM, André G. Isaak wrote:
>>>>>>>>>> I'm reposting the following question in this thread at
>>>>>>>>>> Olcott's insistence even though it doesn't belong here. The
>>>>>>>>>> original message can be seen in its proper context here:
>>>>>>>>>> <t164qe$59o$2@dont-email.me>
>>>>>>>>>>
>>>>>>>>>> On 2022-03-19 20:47, olcott wrote:
>>>>>>>>>>  > On 3/19/2022 9:38 PM, André G. Isaak wrote:
>>>>>>>>>>
>>>>>>>>>>  > I changed to a different thread that does not have the lame
>>>>>>>>>> main
>>>>>>>>>>  > thread name of Comic.
>>>>>>>>>>  >
>>>>>>>>>>  >> A Turing Machine has no access to *any* information apart
>>>>>>>>>> from what
>>>>>>>>>>  >> is present on its tape. Ĥ (of which your embedded_H is a
>>>>>>>>>> part) starts
>>>>>>>>>>  >> with only a *single* string on its tape.
>>>>>>>>>>  >>
>>>>>>>>>>  >> With what, exactly, do you plan on comparing this string
>>>>>>>>>> in making
>>>>>>>>>>  >> your 'halt status decision'?
>>>>>>>>>>
>>>>>>>>>> You didn't actually answer the above question. What exactly do
>>>>>>>>>> you plan on comparing the input to?
>>>>>>>>>>
>>>>>>>>>> André
>>>>>>>>>
>>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>>>>    Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then embedded_H simulates
>>>>>>>>> ⟨Ĥ0⟩ ⟨Ĥ1⟩
>>>>>>>>>
>>>>>>>>> Then these steps would keep repeating:
>>>>>>>>>    Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H0 simulates
>>>>>>>>> ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>>>>>>>>    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H1 simulates
>>>>>>>>> ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>>>>>>>>    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H2 simulates
>>>>>>>>> ⟨Ĥ3⟩ ⟨Ĥ4⟩...
>>>>>>>>>
>>>>>>>>> Technically the abort criteria exists when embedded_H0 would
>>>>>>>>> simulate ⟨Ĥ1⟩ ⟨Ĥ2⟩. It is at this point that embedded_H would
>>>>>>>>> otherwise simulate an exact copy of itself with an exact copy
>>>>>>>>> of its inputs.
>>>>>>>>>
>>>>>>>>> If embedded_H aborts the simulation of embedded_H0 before
>>>>>>>>> embedded_H0 is invoked then not even the first copy does the
>>>>>>>>> same thing as embedded_H and there are no copies besides this
>>>>>>>>> first one.
>>>>>>>>>
>>>>>>>>> That the infinitely nested simulation criteria is definitively
>>>>>>>>> met conclusively proves that embedded_H can reject its input
>>>>>>>>> without forming the contradiction that Linz claims is formed.
>>>>>>>>
>>>>>>>>
>>>>>>>> How does any of the above even remotely address the question I
>>>>>>>> asked?
>>>>>>>>
>>>>>>>> You claimed "strcmp()" played an important role in your halting
>>>>>>>> decision. (Your exact words were "When strcmp is used as the key
>>>>>>>> element of a halt status decision then this changes the behavior
>>>>>>>> H relative to embedded_H for the same input")
>>>>>>>>
>>>>>>>> Putting aside the fact that strcmp() is a C function which has
>>>>>>>> nothing to do with Turing machines, string comparison requires
>>>>>>>> *two* strings to compare. Ĥ takes a *single* string as its input
>>>>>>>> so there is only one string on the tape. What do you plan on
>>>>>>>> comparing this string with?
>>>>>>>>
>>>>>>>> André
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>>    Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then embedded_H simulates ⟨Ĥ0⟩
>>>>>>> ⟨Ĥ1⟩
>>>>>>>
>>>>>>> Then these steps would keep repeating:
>>>>>>>    Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H0 simulates
>>>>>>> ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>>>>>>    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H1 simulates
>>>>>>> ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>>>>>>    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H2 simulates
>>>>>>> ⟨Ĥ3⟩ ⟨Ĥ4⟩...
>>>>>>>
>>>>>>> Because we can tell that all the copies of ⟨Ĥ⟩ are identical to
>>>>>>> each other we know that their finite string comparisons would be
>>>>>>> identical.
>>>>>>
>>>>>> You're acting very ELIZA-like here. Instead of answering the
>>>>>> question you are simply repeating earlier material.
>>>>>>
>>>>>> The question I asked was *which* strings are being compared?
>>>>>>
>>>>>>> Because embedded_H is the master UTM all of these finite strings
>>>>>>> would be somewhere on its own tape.
>>>>>>
>>>>>> embedded_H isn't a UTM at all, let alone a 'master UTM'. It is a
>>>>>> modified version of a simulating halt decider.
>>>>>>
>>>>>> The top-level embedded_H has an input consisting of two identical
>>>>>> copies of a single string which may or may not be ⟨Ĥ⟩. Please
>>>>>> explain which two strings the top-level embedded_H compares and
>>>>>> where it gets these strings from.
>>>>>>
>>>>>>> We also know that when a function calls a copy of itself with
>>>>>>> identical input that this is infinite recursion.
>>>>>>
>>>>>> But embedded_H has no way of knowing whether the input it is
>>>>>> emulating contains a copy of itself or not, therefore it has no
>>>>>> way of recognizing recursion.
>>>>>
>>>>> All of these details are moot at this point in the dialogue.
>>>>
>>>> No, they are not moot. They are crucial details since you claim that
>>>> 'string comparison' is what makes it possible for your embedded_H to
>>>> recognize infinitely-recursive patterns'.
>>>>
>>>>> As long as we ourselves can tell that ⟨Ĥ⟩ ⟨Ĥ⟩ specifies infinitely
>>>>> nested simulation to embedded_H then it is necessarily correct for
>>>>> embedded_H to transition to Ĥ.qn even if it does this on the basis
>>>>> of a wild guess.
>>>>
>>>> You claim this is infinitely recursive. Purely for sake of argument,
>>>> I'll assume this is true. You can recognize this recursion only
>>>> because you have a piece of information that embedded_H does not.
>>>> You are aware that the string you have given it is a description of
>>>> Ĥ which contains embedded_H. Your embedded_H, however, has
>>>> absolutely no way of knowing this fact.
>>>>
>>>
>>> This means that embedded_H can correctly reject its input even if it
>>> does so by wild guess.
>>>
>>> If embedded_H does correctly reject its input by wild guess this
>>> refutes the Linz proof that concludes that rejecting its input
>>> derives a necessary contradiction.
>>>
>>>
>>
>> Except that if embedded_H rejects <H^> <H^> then the H^ that it was
>> embedded into sees that rejection and HALTS, thus embedded_H was
>> incorrect to reject it,
>
> We are back to these two (necessarily correct) foundational principles:
>
> (1) A halt decider (because it is a decider) must report on the behavior
> specified by its finite string input. A decider computes the mapping
> from its input finite strings to an accept or reject state.
>
> (2) The behavior specified by this input is the actual behavior of this
> input when it is correctly simulated by its simulating halt decider
> (SHD) that contains a full UTM.
>

On 3/20/22 10:10 PM, olcott wrote:
> On 3/20/2022 8:54 PM, Richard Damon wrote:
>> On 3/20/22 9:39 PM, olcott wrote:
>>> On 3/20/2022 8:09 PM, André G. Isaak wrote:
>>>> On 2022-03-20 17:50, olcott wrote:
>>>>> On 3/20/2022 2:25 PM, André G. Isaak wrote:
>>>>>> On 2022-03-20 13:12, olcott wrote:
>>>>>>> On 3/20/2022 1:59 PM, André G. Isaak wrote:
>>>>>>>> I'm reposting the following question in this thread at Olcott's
>>>>>>>> insistence even though it doesn't belong here. The original
>>>>>>>> message can be seen in its proper context here:
>>>>>>>> <t164qe$59o$2@dont-email.me>
>>>>>>>>
>>>>>>>> On 2022-03-19 20:47, olcott wrote:
>>>>>>>>  > On 3/19/2022 9:38 PM, André G. Isaak wrote:
>>>>>>>>
>>>>>>>>  > I changed to a different thread that does not have the lame main
>>>>>>>>  > thread name of Comic.
>>>>>>>>  >
>>>>>>>>  >> A Turing Machine has no access to *any* information apart
>>>>>>>> from what
>>>>>>>>  >> is present on its tape. Ĥ (of which your embedded_H is a
>>>>>>>> part) starts
>>>>>>>>  >> with only a *single* string on its tape.
>>>>>>>>  >>
>>>>>>>>  >> With what, exactly, do you plan on comparing this string in
>>>>>>>> making
>>>>>>>>  >> your 'halt status decision'?
>>>>>>>>
>>>>>>>> You didn't actually answer the above question. What exactly do
>>>>>>>> you plan on comparing the input to?
>>>>>>>>
>>>>>>>> André
>>>>>>>
>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>>    Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then embedded_H simulates ⟨Ĥ0⟩
>>>>>>> ⟨Ĥ1⟩
>>>>>>>
>>>>>>> Then these steps would keep repeating:
>>>>>>>    Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H0 simulates
>>>>>>> ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>>>>>>    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H1 simulates
>>>>>>> ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>>>>>>    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H2 simulates
>>>>>>> ⟨Ĥ3⟩ ⟨Ĥ4⟩...
>>>>>>>
>>>>>>> Technically the abort criteria exists when embedded_H0 would
>>>>>>> simulate ⟨Ĥ1⟩ ⟨Ĥ2⟩. It is at this point that embedded_H would
>>>>>>> otherwise simulate an exact copy of itself with an exact copy of
>>>>>>> its inputs.
>>>>>>>
>>>>>>> If embedded_H aborts the simulation of embedded_H0 before
>>>>>>> embedded_H0 is invoked then not even the first copy does the same
>>>>>>> thing as embedded_H and there are no copies besides this first one.
>>>>>>>
>>>>>>> That the infinitely nested simulation criteria is definitively
>>>>>>> met conclusively proves that embedded_H can reject its input
>>>>>>> without forming the contradiction that Linz claims is formed.
>>>>>>
>>>>>>
>>>>>> How does any of the above even remotely address the question I asked?
>>>>>>
>>>>>> You claimed "strcmp()" played an important role in your halting
>>>>>> decision. (Your exact words were "When strcmp is used as the key
>>>>>> element of a halt status decision then this changes the behavior H
>>>>>> relative to embedded_H for the same input")
>>>>>>
>>>>>> Putting aside the fact that strcmp() is a C function which has
>>>>>> nothing to do with Turing machines, string comparison requires
>>>>>> *two* strings to compare. Ĥ takes a *single* string as its input
>>>>>> so there is only one string on the tape. What do you plan on
>>>>>> comparing this string with?
>>>>>>
>>>>>> André
>>>>>>
>>>>>
>>>>>
>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>    Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then embedded_H simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩
>>>>>
>>>>> Then these steps would keep repeating:
>>>>>    Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H0 simulates ⟨Ĥ1⟩
>>>>> ⟨Ĥ2⟩
>>>>>    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H1 simulates ⟨Ĥ2⟩
>>>>> ⟨Ĥ3⟩
>>>>>    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H2 simulates ⟨Ĥ3⟩
>>>>> ⟨Ĥ4⟩...
>>>>>
>>>>> Because we can tell that all the copies of ⟨Ĥ⟩ are identical to
>>>>> each other we know that their finite string comparisons would be
>>>>> identical.
>>>>
>>>> You're acting very ELIZA-like here. Instead of answering the
>>>> question you are simply repeating earlier material.
>>>>
>>>> The question I asked was *which* strings are being compared?
>>>>
>>>>> Because embedded_H is the master UTM all of these finite strings
>>>>> would be somewhere on its own tape.
>>>>
>>>> embedded_H isn't a UTM at all, let alone a 'master UTM'. It is a
>>>> modified version of a simulating halt decider.
>>>>
>>>> The top-level embedded_H has an input consisting of two identical
>>>> copies of a single string which may or may not be ⟨Ĥ⟩. Please
>>>> explain which two strings the top-level embedded_H compares and
>>>> where it gets these strings from.
>>>>
>>>>> We also know that when a function calls a copy of itself with
>>>>> identical input that this is infinite recursion.
>>>>
>>>> But embedded_H has no way of knowing whether the input it is
>>>> emulating contains a copy of itself or not, therefore it has no way
>>>> of recognizing recursion.
>>>
>>> All of these details are moot at this point in the dialogue.
>>>
>>> As long as we ourselves can tell that ⟨Ĥ⟩ ⟨Ĥ⟩ specifies infinitely
>>> nested simulation to embedded_H then it is necessarily correct for
>>> embedded_H to transition to Ĥ.qn even if it does this on the basis of
>>> a wild guess.
>>>
>>>
>>
>> Backing off because that avenue didn't work?
>>
>> The problem is that <H^> <H^> only specifies infinitely nested
>> simulation for tha case where H/embedded_H NEVER abort their
>> simulation, and in that case they don't give an answer so fail to be
>> Deciders.
>>
>> FAIL.
>
> I keep telling you that as long as we can tell that the correct
> simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H can never reach its final state then
> embedded_H can correctly reject this input
>
> even if it does this on the basis of a wild guess.
>

Except that the simulation that shows this is only correct when
embedded_H never aborts its simmulation.

If it aborts it, and goes to Qn, then the correct simulation shows it to
halt.

I don't care how it gets the answer, It can even be a machine that just
calls ALL inputs non-halting.

By the design of H^, it will be WRONG, because H^ uses its copy to KNOW
the answer that H will give and then does the opposite.

Until you can show how to make that copy behave differently then the H
answering, and still having followed the construction rules, you are wrong.

To do that, you need to show some ACTUAL TURING MACHINE that can have
two copies of it give different answer when given the exact same input;l

Until you can prove that impossibility, all you 'proof' is just a big
fat LIE.

FAIL.

André G. Isaak <agisaak@gm.invalid> writes:

> On 2022-03-20 19:39, olcott wrote:

>> All of these details are moot at this point in the dialogue.
>
> No, they are not moot. They are crucial details since you claim that
> 'string comparison' is what makes it possible for your embedded_H to
> recognize infinitely-recursive patterns'.

Just an aside: I think the claim was much stronger than that. The
"string compare" is what makes his PO-machines magic. It's what makes
embedded_H behave differently to H, something that identical TMs can't
do.

--
Ben.

On 3/20/2022 9:51 PM, Richard Damon wrote:
> On 3/20/22 10:18 PM, olcott wrote:
>> On 3/20/2022 9:13 PM, Richard Damon wrote:
>>> On 3/20/22 10:05 PM, olcott wrote:
>>>> On 3/20/2022 8:53 PM, André G. Isaak wrote:
>>>>> On 2022-03-20 19:39, olcott wrote:
>>>>>> On 3/20/2022 8:09 PM, André G. Isaak wrote:
>>>>>>> On 2022-03-20 17:50, olcott wrote:
>>>>>>>> On 3/20/2022 2:25 PM, André G. Isaak wrote:
>>>>>>>>> On 2022-03-20 13:12, olcott wrote:
>>>>>>>>>> On 3/20/2022 1:59 PM, André G. Isaak wrote:
>>>>>>>>>>> I'm reposting the following question in this thread at
>>>>>>>>>>> Olcott's insistence even though it doesn't belong here. The
>>>>>>>>>>> original message can be seen in its proper context here:
>>>>>>>>>>> <t164qe$59o$2@dont-email.me>
>>>>>>>>>>>
>>>>>>>>>>> On 2022-03-19 20:47, olcott wrote:
>>>>>>>>>>>  > On 3/19/2022 9:38 PM, André G. Isaak wrote:
>>>>>>>>>>>
>>>>>>>>>>>  > I changed to a different thread that does not have the
>>>>>>>>>>> lame main
>>>>>>>>>>>  > thread name of Comic.
>>>>>>>>>>>  >
>>>>>>>>>>>  >> A Turing Machine has no access to *any* information apart
>>>>>>>>>>> from what
>>>>>>>>>>>  >> is present on its tape. Ĥ (of which your embedded_H is a
>>>>>>>>>>> part) starts
>>>>>>>>>>>  >> with only a *single* string on its tape.
>>>>>>>>>>>  >>
>>>>>>>>>>>  >> With what, exactly, do you plan on comparing this string
>>>>>>>>>>> in making
>>>>>>>>>>>  >> your 'halt status decision'?
>>>>>>>>>>>
>>>>>>>>>>> You didn't actually answer the above question. What exactly
>>>>>>>>>>> do you plan on comparing the input to?
>>>>>>>>>>>
>>>>>>>>>>> André
>>>>>>>>>>
>>>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>>>>>    Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then embedded_H simulates
>>>>>>>>>> ⟨Ĥ0⟩ ⟨Ĥ1⟩
>>>>>>>>>>
>>>>>>>>>> Then these steps would keep repeating:
>>>>>>>>>>    Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H0 simulates
>>>>>>>>>> ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>>>>>>>>>    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H1 simulates
>>>>>>>>>> ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>>>>>>>>>    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H2 simulates
>>>>>>>>>> ⟨Ĥ3⟩ ⟨Ĥ4⟩...
>>>>>>>>>>
>>>>>>>>>> Technically the abort criteria exists when embedded_H0 would
>>>>>>>>>> simulate ⟨Ĥ1⟩ ⟨Ĥ2⟩. It is at this point that embedded_H would
>>>>>>>>>> otherwise simulate an exact copy of itself with an exact copy
>>>>>>>>>> of its inputs.
>>>>>>>>>>
>>>>>>>>>> If embedded_H aborts the simulation of embedded_H0 before
>>>>>>>>>> embedded_H0 is invoked then not even the first copy does the
>>>>>>>>>> same thing as embedded_H and there are no copies besides this
>>>>>>>>>> first one.
>>>>>>>>>>
>>>>>>>>>> That the infinitely nested simulation criteria is definitively
>>>>>>>>>> met conclusively proves that embedded_H can reject its input
>>>>>>>>>> without forming the contradiction that Linz claims is formed.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> How does any of the above even remotely address the question I
>>>>>>>>> asked?
>>>>>>>>>
>>>>>>>>> You claimed "strcmp()" played an important role in your halting
>>>>>>>>> decision. (Your exact words were "When strcmp is used as the
>>>>>>>>> key element of a halt status decision then this changes the
>>>>>>>>> behavior H relative to embedded_H for the same input")
>>>>>>>>>
>>>>>>>>> Putting aside the fact that strcmp() is a C function which has
>>>>>>>>> nothing to do with Turing machines, string comparison requires
>>>>>>>>> *two* strings to compare. Ĥ takes a *single* string as its
>>>>>>>>> input so there is only one string on the tape. What do you plan
>>>>>>>>> on comparing this string with?
>>>>>>>>>
>>>>>>>>> André
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>>>    Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then embedded_H simulates
>>>>>>>> ⟨Ĥ0⟩ ⟨Ĥ1⟩
>>>>>>>>
>>>>>>>> Then these steps would keep repeating:
>>>>>>>>    Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H0 simulates
>>>>>>>> ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>>>>>>>    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H1 simulates
>>>>>>>> ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>>>>>>>    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H2 simulates
>>>>>>>> ⟨Ĥ3⟩ ⟨Ĥ4⟩...
>>>>>>>>
>>>>>>>> Because we can tell that all the copies of ⟨Ĥ⟩ are identical to
>>>>>>>> each other we know that their finite string comparisons would be
>>>>>>>> identical.
>>>>>>>
>>>>>>> You're acting very ELIZA-like here. Instead of answering the
>>>>>>> question you are simply repeating earlier material.
>>>>>>>
>>>>>>> The question I asked was *which* strings are being compared?
>>>>>>>
>>>>>>>> Because embedded_H is the master UTM all of these finite strings
>>>>>>>> would be somewhere on its own tape.
>>>>>>>
>>>>>>> embedded_H isn't a UTM at all, let alone a 'master UTM'. It is a
>>>>>>> modified version of a simulating halt decider.
>>>>>>>
>>>>>>> The top-level embedded_H has an input consisting of two identical
>>>>>>> copies of a single string which may or may not be ⟨Ĥ⟩. Please
>>>>>>> explain which two strings the top-level embedded_H compares and
>>>>>>> where it gets these strings from.
>>>>>>>
>>>>>>>> We also know that when a function calls a copy of itself with
>>>>>>>> identical input that this is infinite recursion.
>>>>>>>
>>>>>>> But embedded_H has no way of knowing whether the input it is
>>>>>>> emulating contains a copy of itself or not, therefore it has no
>>>>>>> way of recognizing recursion.
>>>>>>
>>>>>> All of these details are moot at this point in the dialogue.
>>>>>
>>>>> No, they are not moot. They are crucial details since you claim
>>>>> that 'string comparison' is what makes it possible for your
>>>>> embedded_H to recognize infinitely-recursive patterns'.
>>>>>
>>>>>> As long as we ourselves can tell that ⟨Ĥ⟩ ⟨Ĥ⟩ specifies infinitely
>>>>>> nested simulation to embedded_H then it is necessarily correct for
>>>>>> embedded_H to transition to Ĥ.qn even if it does this on the basis
>>>>>> of a wild guess.
>>>>>
>>>>> You claim this is infinitely recursive. Purely for sake of
>>>>> argument, I'll assume this is true. You can recognize this
>>>>> recursion only because you have a piece of information that
>>>>> embedded_H does not. You are aware that the string you have given
>>>>> it is a description of Ĥ which contains embedded_H. Your
>>>>> embedded_H, however, has absolutely no way of knowing this fact.
>>>>>
>>>>
>>>> This means that embedded_H can correctly reject its input even if it
>>>> does so by wild guess.
>>>>
>>>> If embedded_H does correctly reject its input by wild guess this
>>>> refutes the Linz proof that concludes that rejecting its input
>>>> derives a necessary contradiction.
>>>>
>>>>
>>>
>>> Except that if embedded_H rejects <H^> <H^> then the H^ that it was
>>> embedded into sees that rejection and HALTS, thus embedded_H was
>>> incorrect to reject it,
>>
>> We are back to these two (necessarily correct) foundational principles:
>>
>> (1) A halt decider (because it is a decider) must report on the
>> behavior specified by its finite string input. A decider computes the
>> mapping from its input finite strings to an accept or reject state.
>>
>> (2) The behavior specified by this input is the actual behavior of
>> this input when it is correctly simulated by its simulating halt
>> decider (SHD) that contains a full UTM.
>>
>
> 'Impossible correct' because they are impossible to BE correct.
>

On 3/20/2022 9:56 PM, Richard Damon wrote:
> On 3/20/22 10:10 PM, olcott wrote:
>> On 3/20/2022 8:54 PM, Richard Damon wrote:
>>> On 3/20/22 9:39 PM, olcott wrote:
>>>> On 3/20/2022 8:09 PM, André G. Isaak wrote:
>>>>> On 2022-03-20 17:50, olcott wrote:
>>>>>> On 3/20/2022 2:25 PM, André G. Isaak wrote:
>>>>>>> On 2022-03-20 13:12, olcott wrote:
>>>>>>>> On 3/20/2022 1:59 PM, André G. Isaak wrote:
>>>>>>>>> I'm reposting the following question in this thread at Olcott's
>>>>>>>>> insistence even though it doesn't belong here. The original
>>>>>>>>> message can be seen in its proper context here:
>>>>>>>>> <t164qe$59o$2@dont-email.me>
>>>>>>>>>
>>>>>>>>> On 2022-03-19 20:47, olcott wrote:
>>>>>>>>>  > On 3/19/2022 9:38 PM, André G. Isaak wrote:
>>>>>>>>>
>>>>>>>>>  > I changed to a different thread that does not have the lame
>>>>>>>>> main
>>>>>>>>>  > thread name of Comic.
>>>>>>>>>  >
>>>>>>>>>  >> A Turing Machine has no access to *any* information apart
>>>>>>>>> from what
>>>>>>>>>  >> is present on its tape. Ĥ (of which your embedded_H is a
>>>>>>>>> part) starts
>>>>>>>>>  >> with only a *single* string on its tape.
>>>>>>>>>  >>
>>>>>>>>>  >> With what, exactly, do you plan on comparing this string in
>>>>>>>>> making
>>>>>>>>>  >> your 'halt status decision'?
>>>>>>>>>
>>>>>>>>> You didn't actually answer the above question. What exactly do
>>>>>>>>> you plan on comparing the input to?
>>>>>>>>>
>>>>>>>>> André
>>>>>>>>
>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>>>    Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then embedded_H simulates
>>>>>>>> ⟨Ĥ0⟩ ⟨Ĥ1⟩
>>>>>>>>
>>>>>>>> Then these steps would keep repeating:
>>>>>>>>    Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H0 simulates
>>>>>>>> ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>>>>>>>    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H1 simulates
>>>>>>>> ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>>>>>>>    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H2 simulates
>>>>>>>> ⟨Ĥ3⟩ ⟨Ĥ4⟩...
>>>>>>>>
>>>>>>>> Technically the abort criteria exists when embedded_H0 would
>>>>>>>> simulate ⟨Ĥ1⟩ ⟨Ĥ2⟩. It is at this point that embedded_H would
>>>>>>>> otherwise simulate an exact copy of itself with an exact copy of
>>>>>>>> its inputs.
>>>>>>>>
>>>>>>>> If embedded_H aborts the simulation of embedded_H0 before
>>>>>>>> embedded_H0 is invoked then not even the first copy does the
>>>>>>>> same thing as embedded_H and there are no copies besides this
>>>>>>>> first one.
>>>>>>>>
>>>>>>>> That the infinitely nested simulation criteria is definitively
>>>>>>>> met conclusively proves that embedded_H can reject its input
>>>>>>>> without forming the contradiction that Linz claims is formed.
>>>>>>>
>>>>>>>
>>>>>>> How does any of the above even remotely address the question I
>>>>>>> asked?
>>>>>>>
>>>>>>> You claimed "strcmp()" played an important role in your halting
>>>>>>> decision. (Your exact words were "When strcmp is used as the key
>>>>>>> element of a halt status decision then this changes the behavior
>>>>>>> H relative to embedded_H for the same input")
>>>>>>>
>>>>>>> Putting aside the fact that strcmp() is a C function which has
>>>>>>> nothing to do with Turing machines, string comparison requires
>>>>>>> *two* strings to compare. Ĥ takes a *single* string as its input
>>>>>>> so there is only one string on the tape. What do you plan on
>>>>>>> comparing this string with?
>>>>>>>
>>>>>>> André
>>>>>>>
>>>>>>
>>>>>>
>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>    Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then embedded_H simulates ⟨Ĥ0⟩
>>>>>> ⟨Ĥ1⟩
>>>>>>
>>>>>> Then these steps would keep repeating:
>>>>>>    Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H0 simulates
>>>>>> ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>>>>>    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H1 simulates
>>>>>> ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>>>>>    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H2 simulates
>>>>>> ⟨Ĥ3⟩ ⟨Ĥ4⟩...
>>>>>>
>>>>>> Because we can tell that all the copies of ⟨Ĥ⟩ are identical to
>>>>>> each other we know that their finite string comparisons would be
>>>>>> identical.
>>>>>
>>>>> You're acting very ELIZA-like here. Instead of answering the
>>>>> question you are simply repeating earlier material.
>>>>>
>>>>> The question I asked was *which* strings are being compared?
>>>>>
>>>>>> Because embedded_H is the master UTM all of these finite strings
>>>>>> would be somewhere on its own tape.
>>>>>
>>>>> embedded_H isn't a UTM at all, let alone a 'master UTM'. It is a
>>>>> modified version of a simulating halt decider.
>>>>>
>>>>> The top-level embedded_H has an input consisting of two identical
>>>>> copies of a single string which may or may not be ⟨Ĥ⟩. Please
>>>>> explain which two strings the top-level embedded_H compares and
>>>>> where it gets these strings from.
>>>>>
>>>>>> We also know that when a function calls a copy of itself with
>>>>>> identical input that this is infinite recursion.
>>>>>
>>>>> But embedded_H has no way of knowing whether the input it is
>>>>> emulating contains a copy of itself or not, therefore it has no way
>>>>> of recognizing recursion.
>>>>
>>>> All of these details are moot at this point in the dialogue.
>>>>
>>>> As long as we ourselves can tell that ⟨Ĥ⟩ ⟨Ĥ⟩ specifies infinitely
>>>> nested simulation to embedded_H then it is necessarily correct for
>>>> embedded_H to transition to Ĥ.qn even if it does this on the basis
>>>> of a wild guess.
>>>>
>>>>
>>>
>>> Backing off because that avenue didn't work?
>>>
>>> The problem is that <H^> <H^> only specifies infinitely nested
>>> simulation for tha case where H/embedded_H NEVER abort their
>>> simulation, and in that case they don't give an answer so fail to be
>>> Deciders.
>>>
>>> FAIL.
>>
>> I keep telling you that as long as we can tell that the correct
>> simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H can never reach its final state
>> then embedded_H can correctly reject this input
>>
>> even if it does this on the basis of a wild guess.
>>
>
> Except that the simulation that shows this is only correct when
> embedded_H never aborts its simmulation.
>

You are simply too stupid or dishonest on this point.

--
Copyright 2021 Pete Olcott

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

olcott <NoOne@NoWhere.com> writes:

> On 3/19/2022 11:08 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 3/19/2022 7:29 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> A copy of Linz H ...
>>>>
>>>> Linz is talking about Turing machines but you are not. Your magic
>>>> PO-machines have the property that "exact copies" (your words) can
>>>> behave differently when applied (your word) to the same input.
>>>> To address Linz's proof you need to be talking about TMs, not magic
>>>> PO-machines.
>>>
>>> (1) H and Ĥ aren't exact copies strcmp() proves that they differ by
>>> the appended states. H and Ĥ use strcmp() as part of the decision
>>> criteria.
>> No one ever said they were. You, however, did say that H and embedded_H
>> are exact copies:
>
> embedded_H is an exact copy of H in the it has the same state
> transitions. Its Turing machine description has the infinite loop
> state appended to the end, this a string comparison of the machine
> descriptions will not match.

Garbage. If you now want to be seen as talking about Turing machines,
then if

Ĥ.qx <Ĥ> <Ĥ> ⊦* Ĥ.qn then H <Ĥ> <Ĥ> ⊦* H.qn

and if

Ĥ.qx <Ĥ> <Ĥ> ⊦* Ĥ.qy ⊦* oo then H <Ĥ> <Ĥ> ⊦* H.qy

In both cases there is a contradiction. You saw this, and have been
pretending that H and embedded_H can behave differently. Now you want
to walk back that absurd point of view, but then you have to deal with
the contradiction.

>> "Linz [...] requires that Ĥ.qx is an exact copy of H."
>> "Ĥ includes an exact copy of H embedded at its state Ĥ.qx"
>> "Ĥ.qx <is> an exact copy of H"
>>
>>> (2) I made all of this moot months ago by only focusing on the copy of
>>> H that is embedded within Ĥ, so when people bring up H I must tell
>>> this this is off topic.
>> The mistake does not go away because you refuse to talk about it. You
>> have made your ploy very clear. Here you are saying it quite
>> explicitly:
>
> It is not longer in any part of my proof, so it is moot.

Don't be silly. An absurd claim does not become moot because you won't
talk about it. Unless you say you were wrong we must assume that you
are still talking about magic PO-machines. Were you wrong? Is

>> "Ĥ.qx maps ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qn
>> corresponds to
>> H maps ⟨Ĥ⟩ ⟨Ĥ⟩ to H.qy"

actually not possible? Were you wrong to say that

>> "The behavior of H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ is different than the behavior
>> of embedded_H applied to ⟨Ĥ⟩ ⟨Ĥ⟩"

If you won't admit to being wrong, I am free use these facts about your
magic machines to disprove what you now want to say! I can counter
anything you say by pointing out that your machines don't behave like
Turing machines.

--
Ben.

On 2022-03-20 21:04, Ben Bacarisse wrote:
> André G. Isaak <agisaak@gm.invalid> writes:
>
>> On 2022-03-20 19:39, olcott wrote:
>
>>> All of these details are moot at this point in the dialogue.
>>
>> No, they are not moot. They are crucial details since you claim that
>> 'string comparison' is what makes it possible for your embedded_H to
>> recognize infinitely-recursive patterns'.
>
> Just an aside: I think the claim was much stronger than that. The
> "string compare" is what makes his PO-machines magic. It's what makes
> embedded_H behave differently to H, something that identical TMs can't
> do.

That actually was going to be my next question for PO: How does this
'strcmp()' lead to different behaviours for the same machine with the
same input.

Sadly, since he won't even tell me which strings are being compared, I
doubt he will be willing to explain how this comparison allows for
miracles either.

André

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

On 3/20/2022 9:56 PM, Richard Damon wrote:
> On 3/20/22 10:10 PM, olcott wrote:
>> On 3/20/2022 8:54 PM, Richard Damon wrote:
>>> On 3/20/22 9:39 PM, olcott wrote:
>>>> On 3/20/2022 8:09 PM, André G. Isaak wrote:
>>>>> On 2022-03-20 17:50, olcott wrote:
>>>>>> On 3/20/2022 2:25 PM, André G. Isaak wrote:
>>>>>>> On 2022-03-20 13:12, olcott wrote:
>>>>>>>> On 3/20/2022 1:59 PM, André G. Isaak wrote:
>>>>>>>>> I'm reposting the following question in this thread at Olcott's
>>>>>>>>> insistence even though it doesn't belong here. The original
>>>>>>>>> message can be seen in its proper context here:
>>>>>>>>> <t164qe$59o$2@dont-email.me>
>>>>>>>>>
>>>>>>>>> On 2022-03-19 20:47, olcott wrote:
>>>>>>>>>  > On 3/19/2022 9:38 PM, André G. Isaak wrote:
>>>>>>>>>
>>>>>>>>>  > I changed to a different thread that does not have the lame
>>>>>>>>> main
>>>>>>>>>  > thread name of Comic.
>>>>>>>>>  >
>>>>>>>>>  >> A Turing Machine has no access to *any* information apart
>>>>>>>>> from what
>>>>>>>>>  >> is present on its tape. Ĥ (of which your embedded_H is a
>>>>>>>>> part) starts
>>>>>>>>>  >> with only a *single* string on its tape.
>>>>>>>>>  >>
>>>>>>>>>  >> With what, exactly, do you plan on comparing this string in
>>>>>>>>> making
>>>>>>>>>  >> your 'halt status decision'?
>>>>>>>>>
>>>>>>>>> You didn't actually answer the above question. What exactly do
>>>>>>>>> you plan on comparing the input to?
>>>>>>>>>
>>>>>>>>> André
>>>>>>>>
>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>>>    Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then embedded_H simulates
>>>>>>>> ⟨Ĥ0⟩ ⟨Ĥ1⟩
>>>>>>>>
>>>>>>>> Then these steps would keep repeating:
>>>>>>>>    Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H0 simulates
>>>>>>>> ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>>>>>>>    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H1 simulates
>>>>>>>> ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>>>>>>>    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H2 simulates
>>>>>>>> ⟨Ĥ3⟩ ⟨Ĥ4⟩...
>>>>>>>>
>>>>>>>> Technically the abort criteria exists when embedded_H0 would
>>>>>>>> simulate ⟨Ĥ1⟩ ⟨Ĥ2⟩. It is at this point that embedded_H would
>>>>>>>> otherwise simulate an exact copy of itself with an exact copy of
>>>>>>>> its inputs.
>>>>>>>>
>>>>>>>> If embedded_H aborts the simulation of embedded_H0 before
>>>>>>>> embedded_H0 is invoked then not even the first copy does the
>>>>>>>> same thing as embedded_H and there are no copies besides this
>>>>>>>> first one.
>>>>>>>>
>>>>>>>> That the infinitely nested simulation criteria is definitively
>>>>>>>> met conclusively proves that embedded_H can reject its input
>>>>>>>> without forming the contradiction that Linz claims is formed.
>>>>>>>
>>>>>>>
>>>>>>> How does any of the above even remotely address the question I
>>>>>>> asked?
>>>>>>>
>>>>>>> You claimed "strcmp()" played an important role in your halting
>>>>>>> decision. (Your exact words were "When strcmp is used as the key
>>>>>>> element of a halt status decision then this changes the behavior
>>>>>>> H relative to embedded_H for the same input")
>>>>>>>
>>>>>>> Putting aside the fact that strcmp() is a C function which has
>>>>>>> nothing to do with Turing machines, string comparison requires
>>>>>>> *two* strings to compare. Ĥ takes a *single* string as its input
>>>>>>> so there is only one string on the tape. What do you plan on
>>>>>>> comparing this string with?
>>>>>>>
>>>>>>> André
>>>>>>>
>>>>>>
>>>>>>
>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>    Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then embedded_H simulates ⟨Ĥ0⟩
>>>>>> ⟨Ĥ1⟩
>>>>>>
>>>>>> Then these steps would keep repeating:
>>>>>>    Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H0 simulates
>>>>>> ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>>>>>    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H1 simulates
>>>>>> ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>>>>>    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H2 simulates
>>>>>> ⟨Ĥ3⟩ ⟨Ĥ4⟩...
>>>>>>
>>>>>> Because we can tell that all the copies of ⟨Ĥ⟩ are identical to
>>>>>> each other we know that their finite string comparisons would be
>>>>>> identical.
>>>>>
>>>>> You're acting very ELIZA-like here. Instead of answering the
>>>>> question you are simply repeating earlier material.
>>>>>
>>>>> The question I asked was *which* strings are being compared?
>>>>>
>>>>>> Because embedded_H is the master UTM all of these finite strings
>>>>>> would be somewhere on its own tape.
>>>>>
>>>>> embedded_H isn't a UTM at all, let alone a 'master UTM'. It is a
>>>>> modified version of a simulating halt decider.
>>>>>
>>>>> The top-level embedded_H has an input consisting of two identical
>>>>> copies of a single string which may or may not be ⟨Ĥ⟩. Please
>>>>> explain which two strings the top-level embedded_H compares and
>>>>> where it gets these strings from.
>>>>>
>>>>>> We also know that when a function calls a copy of itself with
>>>>>> identical input that this is infinite recursion.
>>>>>
>>>>> But embedded_H has no way of knowing whether the input it is
>>>>> emulating contains a copy of itself or not, therefore it has no way
>>>>> of recognizing recursion.
>>>>
>>>> All of these details are moot at this point in the dialogue.
>>>>
>>>> As long as we ourselves can tell that ⟨Ĥ⟩ ⟨Ĥ⟩ specifies infinitely
>>>> nested simulation to embedded_H then it is necessarily correct for
>>>> embedded_H to transition to Ĥ.qn even if it does this on the basis
>>>> of a wild guess.
>>>>
>>>>
>>>
>>> Backing off because that avenue didn't work?
>>>
>>> The problem is that <H^> <H^> only specifies infinitely nested
>>> simulation for tha case where H/embedded_H NEVER abort their
>>> simulation, and in that case they don't give an answer so fail to be
>>> Deciders.
>>>
>>> FAIL.
>>
>> I keep telling you that as long as we can tell that the correct
>> simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H can never reach its final state
>> then embedded_H can correctly reject this input
>>
>> even if it does this on the basis of a wild guess.
>>
>
> Except that the simulation that shows this is only correct when
> embedded_H never aborts its simmulation.
>
THAT YOU ALREADY KNOW THIS PROVES THAT YOU ARE A LIAR:
That a simulated Turing machine description cannot possibly reach its
own final state whether or not its simulation has been aborted
conclusively proves that it specifies a non-halting sequence of
configurations.

On 3/20/22 11:12 PM, olcott wrote:
> On 3/20/2022 9:51 PM, Richard Damon wrote:
>> On 3/20/22 10:18 PM, olcott wrote:
>>> On 3/20/2022 9:13 PM, Richard Damon wrote:
>>>> On 3/20/22 10:05 PM, olcott wrote:
>>>>> On 3/20/2022 8:53 PM, André G. Isaak wrote:
>>>>>> On 2022-03-20 19:39, olcott wrote:
>>>>>>> On 3/20/2022 8:09 PM, André G. Isaak wrote:
>>>>>>>> On 2022-03-20 17:50, olcott wrote:
>>>>>>>>> On 3/20/2022 2:25 PM, André G. Isaak wrote:
>>>>>>>>>> On 2022-03-20 13:12, olcott wrote:
>>>>>>>>>>> On 3/20/2022 1:59 PM, André G. Isaak wrote:
>>>>>>>>>>>> I'm reposting the following question in this thread at
>>>>>>>>>>>> Olcott's insistence even though it doesn't belong here. The
>>>>>>>>>>>> original message can be seen in its proper context here:
>>>>>>>>>>>> <t164qe$59o$2@dont-email.me>
>>>>>>>>>>>>
>>>>>>>>>>>> On 2022-03-19 20:47, olcott wrote:
>>>>>>>>>>>>  > On 3/19/2022 9:38 PM, André G. Isaak wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>  > I changed to a different thread that does not have the
>>>>>>>>>>>> lame main
>>>>>>>>>>>>  > thread name of Comic.
>>>>>>>>>>>>  >
>>>>>>>>>>>>  >> A Turing Machine has no access to *any* information
>>>>>>>>>>>> apart from what
>>>>>>>>>>>>  >> is present on its tape. Ĥ (of which your embedded_H is a
>>>>>>>>>>>> part) starts
>>>>>>>>>>>>  >> with only a *single* string on its tape.
>>>>>>>>>>>>  >>
>>>>>>>>>>>>  >> With what, exactly, do you plan on comparing this string
>>>>>>>>>>>> in making
>>>>>>>>>>>>  >> your 'halt status decision'?
>>>>>>>>>>>>
>>>>>>>>>>>> You didn't actually answer the above question. What exactly
>>>>>>>>>>>> do you plan on comparing the input to?
>>>>>>>>>>>>
>>>>>>>>>>>> André
>>>>>>>>>>>
>>>>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>>>>>>    Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then embedded_H simulates
>>>>>>>>>>> ⟨Ĥ0⟩ ⟨Ĥ1⟩
>>>>>>>>>>>
>>>>>>>>>>> Then these steps would keep repeating:
>>>>>>>>>>>    Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H0
>>>>>>>>>>> simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>>>>>>>>>>    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H1
>>>>>>>>>>> simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>>>>>>>>>>    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H2
>>>>>>>>>>> simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩...
>>>>>>>>>>>
>>>>>>>>>>> Technically the abort criteria exists when embedded_H0 would
>>>>>>>>>>> simulate ⟨Ĥ1⟩ ⟨Ĥ2⟩. It is at this point that embedded_H would
>>>>>>>>>>> otherwise simulate an exact copy of itself with an exact copy
>>>>>>>>>>> of its inputs.
>>>>>>>>>>>
>>>>>>>>>>> If embedded_H aborts the simulation of embedded_H0 before
>>>>>>>>>>> embedded_H0 is invoked then not even the first copy does the
>>>>>>>>>>> same thing as embedded_H and there are no copies besides this
>>>>>>>>>>> first one.
>>>>>>>>>>>
>>>>>>>>>>> That the infinitely nested simulation criteria is
>>>>>>>>>>> definitively met conclusively proves that embedded_H can
>>>>>>>>>>> reject its input without forming the contradiction that Linz
>>>>>>>>>>> claims is formed.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> How does any of the above even remotely address the question I
>>>>>>>>>> asked?
>>>>>>>>>>
>>>>>>>>>> You claimed "strcmp()" played an important role in your
>>>>>>>>>> halting decision. (Your exact words were "When strcmp is used
>>>>>>>>>> as the key element of a halt status decision then this changes
>>>>>>>>>> the behavior H relative to embedded_H for the same input")
>>>>>>>>>>
>>>>>>>>>> Putting aside the fact that strcmp() is a C function which has
>>>>>>>>>> nothing to do with Turing machines, string comparison requires
>>>>>>>>>> *two* strings to compare. Ĥ takes a *single* string as its
>>>>>>>>>> input so there is only one string on the tape. What do you
>>>>>>>>>> plan on comparing this string with?
>>>>>>>>>>
>>>>>>>>>> André
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>>>>    Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then embedded_H simulates
>>>>>>>>> ⟨Ĥ0⟩ ⟨Ĥ1⟩
>>>>>>>>>
>>>>>>>>> Then these steps would keep repeating:
>>>>>>>>>    Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H0 simulates
>>>>>>>>> ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>>>>>>>>    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H1 simulates
>>>>>>>>> ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>>>>>>>>    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H2 simulates
>>>>>>>>> ⟨Ĥ3⟩ ⟨Ĥ4⟩...
>>>>>>>>>
>>>>>>>>> Because we can tell that all the copies of ⟨Ĥ⟩ are identical to
>>>>>>>>> each other we know that their finite string comparisons would
>>>>>>>>> be identical.
>>>>>>>>
>>>>>>>> You're acting very ELIZA-like here. Instead of answering the
>>>>>>>> question you are simply repeating earlier material.
>>>>>>>>
>>>>>>>> The question I asked was *which* strings are being compared?
>>>>>>>>
>>>>>>>>> Because embedded_H is the master UTM all of these finite
>>>>>>>>> strings would be somewhere on its own tape.
>>>>>>>>
>>>>>>>> embedded_H isn't a UTM at all, let alone a 'master UTM'. It is a
>>>>>>>> modified version of a simulating halt decider.
>>>>>>>>
>>>>>>>> The top-level embedded_H has an input consisting of two
>>>>>>>> identical copies of a single string which may or may not be ⟨Ĥ⟩.
>>>>>>>> Please explain which two strings the top-level embedded_H
>>>>>>>> compares and where it gets these strings from.
>>>>>>>>
>>>>>>>>> We also know that when a function calls a copy of itself with
>>>>>>>>> identical input that this is infinite recursion.
>>>>>>>>
>>>>>>>> But embedded_H has no way of knowing whether the input it is
>>>>>>>> emulating contains a copy of itself or not, therefore it has no
>>>>>>>> way of recognizing recursion.
>>>>>>>
>>>>>>> All of these details are moot at this point in the dialogue.
>>>>>>
>>>>>> No, they are not moot. They are crucial details since you claim
>>>>>> that 'string comparison' is what makes it possible for your
>>>>>> embedded_H to recognize infinitely-recursive patterns'.
>>>>>>
>>>>>>> As long as we ourselves can tell that ⟨Ĥ⟩ ⟨Ĥ⟩ specifies
>>>>>>> infinitely nested simulation to embedded_H then it is necessarily
>>>>>>> correct for embedded_H to transition to Ĥ.qn even if it does this
>>>>>>> on the basis of a wild guess.
>>>>>>
>>>>>> You claim this is infinitely recursive. Purely for sake of
>>>>>> argument, I'll assume this is true. You can recognize this
>>>>>> recursion only because you have a piece of information that
>>>>>> embedded_H does not. You are aware that the string you have given
>>>>>> it is a description of Ĥ which contains embedded_H. Your
>>>>>> embedded_H, however, has absolutely no way of knowing this fact.
>>>>>>
>>>>>
>>>>> This means that embedded_H can correctly reject its input even if
>>>>> it does so by wild guess.
>>>>>
>>>>> If embedded_H does correctly reject its input by wild guess this
>>>>> refutes the Linz proof that concludes that rejecting its input
>>>>> derives a necessary contradiction.
>>>>>
>>>>>
>>>>
>>>> Except that if embedded_H rejects <H^> <H^> then the H^ that it was
>>>> embedded into sees that rejection and HALTS, thus embedded_H was
>>>> incorrect to reject it,
>>>
>>> We are back to these two (necessarily correct) foundational principles:
>>>
>>> (1) A halt decider (because it is a decider) must report on the
>>> behavior specified by its finite string input. A decider computes the
>>> mapping from its input finite strings to an accept or reject state.
>>>
>>> (2) The behavior specified by this input is the actual behavior of
>>> this input when it is correctly simulated by its simulating halt
>>> decider (SHD) that contains a full UTM.
>>>
>>
>> 'Impossible correct' because they are impossible to BE correct.
>>
>
> A SHD that simulates its Turing machine description input using its
> fully functional UTM necessarily does this correctly by definition.
>

On 3/20/22 11:40 PM, olcott wrote:
> On 3/20/2022 9:56 PM, Richard Damon wrote:
>> On 3/20/22 10:10 PM, olcott wrote:
>>> On 3/20/2022 8:54 PM, Richard Damon wrote:
>>>> On 3/20/22 9:39 PM, olcott wrote:
>>>>> On 3/20/2022 8:09 PM, André G. Isaak wrote:
>>>>>> On 2022-03-20 17:50, olcott wrote:
>>>>>>> On 3/20/2022 2:25 PM, André G. Isaak wrote:
>>>>>>>> On 2022-03-20 13:12, olcott wrote:
>>>>>>>>> On 3/20/2022 1:59 PM, André G. Isaak wrote:
>>>>>>>>>> I'm reposting the following question in this thread at
>>>>>>>>>> Olcott's insistence even though it doesn't belong here. The
>>>>>>>>>> original message can be seen in its proper context here:
>>>>>>>>>> <t164qe$59o$2@dont-email.me>
>>>>>>>>>>
>>>>>>>>>> On 2022-03-19 20:47, olcott wrote:
>>>>>>>>>>  > On 3/19/2022 9:38 PM, André G. Isaak wrote:
>>>>>>>>>>
>>>>>>>>>>  > I changed to a different thread that does not have the lame
>>>>>>>>>> main
>>>>>>>>>>  > thread name of Comic.
>>>>>>>>>>  >
>>>>>>>>>>  >> A Turing Machine has no access to *any* information apart
>>>>>>>>>> from what
>>>>>>>>>>  >> is present on its tape. Ĥ (of which your embedded_H is a
>>>>>>>>>> part) starts
>>>>>>>>>>  >> with only a *single* string on its tape.
>>>>>>>>>>  >>
>>>>>>>>>>  >> With what, exactly, do you plan on comparing this string
>>>>>>>>>> in making
>>>>>>>>>>  >> your 'halt status decision'?
>>>>>>>>>>
>>>>>>>>>> You didn't actually answer the above question. What exactly do
>>>>>>>>>> you plan on comparing the input to?
>>>>>>>>>>
>>>>>>>>>> André
>>>>>>>>>
>>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>>>>    Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then embedded_H simulates
>>>>>>>>> ⟨Ĥ0⟩ ⟨Ĥ1⟩
>>>>>>>>>
>>>>>>>>> Then these steps would keep repeating:
>>>>>>>>>    Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H0 simulates
>>>>>>>>> ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>>>>>>>>    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H1 simulates
>>>>>>>>> ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>>>>>>>>    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H2 simulates
>>>>>>>>> ⟨Ĥ3⟩ ⟨Ĥ4⟩...
>>>>>>>>>
>>>>>>>>> Technically the abort criteria exists when embedded_H0 would
>>>>>>>>> simulate ⟨Ĥ1⟩ ⟨Ĥ2⟩. It is at this point that embedded_H would
>>>>>>>>> otherwise simulate an exact copy of itself with an exact copy
>>>>>>>>> of its inputs.
>>>>>>>>>
>>>>>>>>> If embedded_H aborts the simulation of embedded_H0 before
>>>>>>>>> embedded_H0 is invoked then not even the first copy does the
>>>>>>>>> same thing as embedded_H and there are no copies besides this
>>>>>>>>> first one.
>>>>>>>>>
>>>>>>>>> That the infinitely nested simulation criteria is definitively
>>>>>>>>> met conclusively proves that embedded_H can reject its input
>>>>>>>>> without forming the contradiction that Linz claims is formed.
>>>>>>>>
>>>>>>>>
>>>>>>>> How does any of the above even remotely address the question I
>>>>>>>> asked?
>>>>>>>>
>>>>>>>> You claimed "strcmp()" played an important role in your halting
>>>>>>>> decision. (Your exact words were "When strcmp is used as the key
>>>>>>>> element of a halt status decision then this changes the behavior
>>>>>>>> H relative to embedded_H for the same input")
>>>>>>>>
>>>>>>>> Putting aside the fact that strcmp() is a C function which has
>>>>>>>> nothing to do with Turing machines, string comparison requires
>>>>>>>> *two* strings to compare. Ĥ takes a *single* string as its input
>>>>>>>> so there is only one string on the tape. What do you plan on
>>>>>>>> comparing this string with?
>>>>>>>>
>>>>>>>> André
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>>    Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then embedded_H simulates ⟨Ĥ0⟩
>>>>>>> ⟨Ĥ1⟩
>>>>>>>
>>>>>>> Then these steps would keep repeating:
>>>>>>>    Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H0 simulates
>>>>>>> ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>>>>>>    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H1 simulates
>>>>>>> ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>>>>>>    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H2 simulates
>>>>>>> ⟨Ĥ3⟩ ⟨Ĥ4⟩...
>>>>>>>
>>>>>>> Because we can tell that all the copies of ⟨Ĥ⟩ are identical to
>>>>>>> each other we know that their finite string comparisons would be
>>>>>>> identical.
>>>>>>
>>>>>> You're acting very ELIZA-like here. Instead of answering the
>>>>>> question you are simply repeating earlier material.
>>>>>>
>>>>>> The question I asked was *which* strings are being compared?
>>>>>>
>>>>>>> Because embedded_H is the master UTM all of these finite strings
>>>>>>> would be somewhere on its own tape.
>>>>>>
>>>>>> embedded_H isn't a UTM at all, let alone a 'master UTM'. It is a
>>>>>> modified version of a simulating halt decider.
>>>>>>
>>>>>> The top-level embedded_H has an input consisting of two identical
>>>>>> copies of a single string which may or may not be ⟨Ĥ⟩. Please
>>>>>> explain which two strings the top-level embedded_H compares and
>>>>>> where it gets these strings from.
>>>>>>
>>>>>>> We also know that when a function calls a copy of itself with
>>>>>>> identical input that this is infinite recursion.
>>>>>>
>>>>>> But embedded_H has no way of knowing whether the input it is
>>>>>> emulating contains a copy of itself or not, therefore it has no
>>>>>> way of recognizing recursion.
>>>>>
>>>>> All of these details are moot at this point in the dialogue.
>>>>>
>>>>> As long as we ourselves can tell that ⟨Ĥ⟩ ⟨Ĥ⟩ specifies infinitely
>>>>> nested simulation to embedded_H then it is necessarily correct for
>>>>> embedded_H to transition to Ĥ.qn even if it does this on the basis
>>>>> of a wild guess.
>>>>>
>>>>>
>>>>
>>>> Backing off because that avenue didn't work?
>>>>
>>>> The problem is that <H^> <H^> only specifies infinitely nested
>>>> simulation for tha case where H/embedded_H NEVER abort their
>>>> simulation, and in that case they don't give an answer so fail to be
>>>> Deciders.
>>>>
>>>> FAIL.
>>>
>>> I keep telling you that as long as we can tell that the correct
>>> simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H can never reach its final state
>>> then embedded_H can correctly reject this input
>>>
>>> even if it does this on the basis of a wild guess.
>>>
>>
>> Except that the simulation that shows this is only correct when
>> embedded_H never aborts its simmulation.
>>
> THAT YOU ALREADY KNOW THIS PROVES THAT YOU ARE A LIAR:
> That a simulated Turing machine description cannot possibly reach its
> own final state whether or not its simulation has been aborted
> conclusively proves that it specifies a non-halting sequence of
> configurations.
>

On 3/21/2022 6:15 AM, Richard Damon wrote:
> On 3/20/22 11:40 PM, olcott wrote:
>> On 3/20/2022 9:56 PM, Richard Damon wrote:
>>> On 3/20/22 10:10 PM, olcott wrote:
>>>> On 3/20/2022 8:54 PM, Richard Damon wrote:
>>>>> On 3/20/22 9:39 PM, olcott wrote:
>>>>>> On 3/20/2022 8:09 PM, André G. Isaak wrote:
>>>>>>> On 2022-03-20 17:50, olcott wrote:
>>>>>>>> On 3/20/2022 2:25 PM, André G. Isaak wrote:
>>>>>>>>> On 2022-03-20 13:12, olcott wrote:
>>>>>>>>>> On 3/20/2022 1:59 PM, André G. Isaak wrote:
>>>>>>>>>>> I'm reposting the following question in this thread at
>>>>>>>>>>> Olcott's insistence even though it doesn't belong here. The
>>>>>>>>>>> original message can be seen in its proper context here:
>>>>>>>>>>> <t164qe$59o$2@dont-email.me>
>>>>>>>>>>>
>>>>>>>>>>> On 2022-03-19 20:47, olcott wrote:
>>>>>>>>>>>  > On 3/19/2022 9:38 PM, André G. Isaak wrote:
>>>>>>>>>>>
>>>>>>>>>>>  > I changed to a different thread that does not have the
>>>>>>>>>>> lame main
>>>>>>>>>>>  > thread name of Comic.
>>>>>>>>>>>  >
>>>>>>>>>>>  >> A Turing Machine has no access to *any* information apart
>>>>>>>>>>> from what
>>>>>>>>>>>  >> is present on its tape. Ĥ (of which your embedded_H is a
>>>>>>>>>>> part) starts
>>>>>>>>>>>  >> with only a *single* string on its tape.
>>>>>>>>>>>  >>
>>>>>>>>>>>  >> With what, exactly, do you plan on comparing this string
>>>>>>>>>>> in making
>>>>>>>>>>>  >> your 'halt status decision'?
>>>>>>>>>>>
>>>>>>>>>>> You didn't actually answer the above question. What exactly
>>>>>>>>>>> do you plan on comparing the input to?
>>>>>>>>>>>
>>>>>>>>>>> André
>>>>>>>>>>
>>>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>>>>>    Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then embedded_H simulates
>>>>>>>>>> ⟨Ĥ0⟩ ⟨Ĥ1⟩
>>>>>>>>>>
>>>>>>>>>> Then these steps would keep repeating:
>>>>>>>>>>    Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H0 simulates
>>>>>>>>>> ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>>>>>>>>>    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H1 simulates
>>>>>>>>>> ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>>>>>>>>>    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H2 simulates
>>>>>>>>>> ⟨Ĥ3⟩ ⟨Ĥ4⟩...
>>>>>>>>>>
>>>>>>>>>> Technically the abort criteria exists when embedded_H0 would
>>>>>>>>>> simulate ⟨Ĥ1⟩ ⟨Ĥ2⟩. It is at this point that embedded_H would
>>>>>>>>>> otherwise simulate an exact copy of itself with an exact copy
>>>>>>>>>> of its inputs.
>>>>>>>>>>
>>>>>>>>>> If embedded_H aborts the simulation of embedded_H0 before
>>>>>>>>>> embedded_H0 is invoked then not even the first copy does the
>>>>>>>>>> same thing as embedded_H and there are no copies besides this
>>>>>>>>>> first one.
>>>>>>>>>>
>>>>>>>>>> That the infinitely nested simulation criteria is definitively
>>>>>>>>>> met conclusively proves that embedded_H can reject its input
>>>>>>>>>> without forming the contradiction that Linz claims is formed.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> How does any of the above even remotely address the question I
>>>>>>>>> asked?
>>>>>>>>>
>>>>>>>>> You claimed "strcmp()" played an important role in your halting
>>>>>>>>> decision. (Your exact words were "When strcmp is used as the
>>>>>>>>> key element of a halt status decision then this changes the
>>>>>>>>> behavior H relative to embedded_H for the same input")
>>>>>>>>>
>>>>>>>>> Putting aside the fact that strcmp() is a C function which has
>>>>>>>>> nothing to do with Turing machines, string comparison requires
>>>>>>>>> *two* strings to compare. Ĥ takes a *single* string as its
>>>>>>>>> input so there is only one string on the tape. What do you plan
>>>>>>>>> on comparing this string with?
>>>>>>>>>
>>>>>>>>> André
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>>>    Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then embedded_H simulates
>>>>>>>> ⟨Ĥ0⟩ ⟨Ĥ1⟩
>>>>>>>>
>>>>>>>> Then these steps would keep repeating:
>>>>>>>>    Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H0 simulates
>>>>>>>> ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>>>>>>>    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H1 simulates
>>>>>>>> ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>>>>>>>    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H2 simulates
>>>>>>>> ⟨Ĥ3⟩ ⟨Ĥ4⟩...
>>>>>>>>
>>>>>>>> Because we can tell that all the copies of ⟨Ĥ⟩ are identical to
>>>>>>>> each other we know that their finite string comparisons would be
>>>>>>>> identical.
>>>>>>>
>>>>>>> You're acting very ELIZA-like here. Instead of answering the
>>>>>>> question you are simply repeating earlier material.
>>>>>>>
>>>>>>> The question I asked was *which* strings are being compared?
>>>>>>>
>>>>>>>> Because embedded_H is the master UTM all of these finite strings
>>>>>>>> would be somewhere on its own tape.
>>>>>>>
>>>>>>> embedded_H isn't a UTM at all, let alone a 'master UTM'. It is a
>>>>>>> modified version of a simulating halt decider.
>>>>>>>
>>>>>>> The top-level embedded_H has an input consisting of two identical
>>>>>>> copies of a single string which may or may not be ⟨Ĥ⟩. Please
>>>>>>> explain which two strings the top-level embedded_H compares and
>>>>>>> where it gets these strings from.
>>>>>>>
>>>>>>>> We also know that when a function calls a copy of itself with
>>>>>>>> identical input that this is infinite recursion.
>>>>>>>
>>>>>>> But embedded_H has no way of knowing whether the input it is
>>>>>>> emulating contains a copy of itself or not, therefore it has no
>>>>>>> way of recognizing recursion.
>>>>>>
>>>>>> All of these details are moot at this point in the dialogue.
>>>>>>
>>>>>> As long as we ourselves can tell that ⟨Ĥ⟩ ⟨Ĥ⟩ specifies infinitely
>>>>>> nested simulation to embedded_H then it is necessarily correct for
>>>>>> embedded_H to transition to Ĥ.qn even if it does this on the basis
>>>>>> of a wild guess.
>>>>>>
>>>>>>
>>>>>
>>>>> Backing off because that avenue didn't work?
>>>>>
>>>>> The problem is that <H^> <H^> only specifies infinitely nested
>>>>> simulation for tha case where H/embedded_H NEVER abort their
>>>>> simulation, and in that case they don't give an answer so fail to
>>>>> be Deciders.
>>>>>
>>>>> FAIL.
>>>>
>>>> I keep telling you that as long as we can tell that the correct
>>>> simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H can never reach its final state
>>>> then embedded_H can correctly reject this input
>>>>
>>>> even if it does this on the basis of a wild guess.
>>>>
>>>
>>> Except that the simulation that shows this is only correct when
>>> embedded_H never aborts its simmulation.
>>>
>> THAT YOU ALREADY KNOW THIS PROVES THAT YOU ARE A LIAR:
>> That a simulated Turing machine description cannot possibly reach its
>> own final state whether or not its simulation has been aborted
>> conclusively proves that it specifies a non-halting sequence of
>> configurations.
>>
>
> But YOUR statement is a LIE, and you should know it, or you are just an
> idiot.
>
> The definition of HALTING is based on the ACTUAL machine, and in this
> case it is easy to show that H^ applied to <H^> will Halt if
> H/embedded_H applied to <H^> <H^> goes to Qn, so it can't be right.

On 3/21/2022 7:57 AM, olcott wrote:
> On 3/21/2022 6:15 AM, Richard Damon wrote:
>> On 3/20/22 11:40 PM, olcott wrote:
>>> On 3/20/2022 9:56 PM, Richard Damon wrote:
>>>> On 3/20/22 10:10 PM, olcott wrote:
>>>>> On 3/20/2022 8:54 PM, Richard Damon wrote:
>>>>>> On 3/20/22 9:39 PM, olcott wrote:
>>>>>>> On 3/20/2022 8:09 PM, André G. Isaak wrote:
>>>>>>>> On 2022-03-20 17:50, olcott wrote:
>>>>>>>>> On 3/20/2022 2:25 PM, André G. Isaak wrote:
>>>>>>>>>> On 2022-03-20 13:12, olcott wrote:
>>>>>>>>>>> On 3/20/2022 1:59 PM, André G. Isaak wrote:
>>>>>>>>>>>> I'm reposting the following question in this thread at
>>>>>>>>>>>> Olcott's insistence even though it doesn't belong here. The
>>>>>>>>>>>> original message can be seen in its proper context here:
>>>>>>>>>>>> <t164qe$59o$2@dont-email.me>
>>>>>>>>>>>>
>>>>>>>>>>>> On 2022-03-19 20:47, olcott wrote:
>>>>>>>>>>>>  > On 3/19/2022 9:38 PM, André G. Isaak wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>  > I changed to a different thread that does not have the
>>>>>>>>>>>> lame main
>>>>>>>>>>>>  > thread name of Comic.
>>>>>>>>>>>>  >
>>>>>>>>>>>>  >> A Turing Machine has no access to *any* information
>>>>>>>>>>>> apart from what
>>>>>>>>>>>>  >> is present on its tape. Ĥ (of which your embedded_H is a
>>>>>>>>>>>> part) starts
>>>>>>>>>>>>  >> with only a *single* string on its tape.
>>>>>>>>>>>>  >>
>>>>>>>>>>>>  >> With what, exactly, do you plan on comparing this string
>>>>>>>>>>>> in making
>>>>>>>>>>>>  >> your 'halt status decision'?
>>>>>>>>>>>>
>>>>>>>>>>>> You didn't actually answer the above question. What exactly
>>>>>>>>>>>> do you plan on comparing the input to?
>>>>>>>>>>>>
>>>>>>>>>>>> André
>>>>>>>>>>>
>>>>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>>>>>>    Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then embedded_H simulates
>>>>>>>>>>> ⟨Ĥ0⟩ ⟨Ĥ1⟩
>>>>>>>>>>>
>>>>>>>>>>> Then these steps would keep repeating:
>>>>>>>>>>>    Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H0
>>>>>>>>>>> simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>>>>>>>>>>    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H1
>>>>>>>>>>> simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>>>>>>>>>>    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H2
>>>>>>>>>>> simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩...
>>>>>>>>>>>
>>>>>>>>>>> Technically the abort criteria exists when embedded_H0 would
>>>>>>>>>>> simulate ⟨Ĥ1⟩ ⟨Ĥ2⟩. It is at this point that embedded_H would
>>>>>>>>>>> otherwise simulate an exact copy of itself with an exact copy
>>>>>>>>>>> of its inputs.
>>>>>>>>>>>
>>>>>>>>>>> If embedded_H aborts the simulation of embedded_H0 before
>>>>>>>>>>> embedded_H0 is invoked then not even the first copy does the
>>>>>>>>>>> same thing as embedded_H and there are no copies besides this
>>>>>>>>>>> first one.
>>>>>>>>>>>
>>>>>>>>>>> That the infinitely nested simulation criteria is
>>>>>>>>>>> definitively met conclusively proves that embedded_H can
>>>>>>>>>>> reject its input without forming the contradiction that Linz
>>>>>>>>>>> claims is formed.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> How does any of the above even remotely address the question I
>>>>>>>>>> asked?
>>>>>>>>>>
>>>>>>>>>> You claimed "strcmp()" played an important role in your
>>>>>>>>>> halting decision. (Your exact words were "When strcmp is used
>>>>>>>>>> as the key element of a halt status decision then this changes
>>>>>>>>>> the behavior H relative to embedded_H for the same input")
>>>>>>>>>>
>>>>>>>>>> Putting aside the fact that strcmp() is a C function which has
>>>>>>>>>> nothing to do with Turing machines, string comparison requires
>>>>>>>>>> *two* strings to compare. Ĥ takes a *single* string as its
>>>>>>>>>> input so there is only one string on the tape. What do you
>>>>>>>>>> plan on comparing this string with?
>>>>>>>>>>
>>>>>>>>>> André
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>>>>    Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then embedded_H simulates
>>>>>>>>> ⟨Ĥ0⟩ ⟨Ĥ1⟩
>>>>>>>>>
>>>>>>>>> Then these steps would keep repeating:
>>>>>>>>>    Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H0 simulates
>>>>>>>>> ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>>>>>>>>    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H1 simulates
>>>>>>>>> ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>>>>>>>>    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H2 simulates
>>>>>>>>> ⟨Ĥ3⟩ ⟨Ĥ4⟩...
>>>>>>>>>
>>>>>>>>> Because we can tell that all the copies of ⟨Ĥ⟩ are identical to
>>>>>>>>> each other we know that their finite string comparisons would
>>>>>>>>> be identical.
>>>>>>>>
>>>>>>>> You're acting very ELIZA-like here. Instead of answering the
>>>>>>>> question you are simply repeating earlier material.
>>>>>>>>
>>>>>>>> The question I asked was *which* strings are being compared?
>>>>>>>>
>>>>>>>>> Because embedded_H is the master UTM all of these finite
>>>>>>>>> strings would be somewhere on its own tape.
>>>>>>>>
>>>>>>>> embedded_H isn't a UTM at all, let alone a 'master UTM'. It is a
>>>>>>>> modified version of a simulating halt decider.
>>>>>>>>
>>>>>>>> The top-level embedded_H has an input consisting of two
>>>>>>>> identical copies of a single string which may or may not be ⟨Ĥ⟩.
>>>>>>>> Please explain which two strings the top-level embedded_H
>>>>>>>> compares and where it gets these strings from.
>>>>>>>>
>>>>>>>>> We also know that when a function calls a copy of itself with
>>>>>>>>> identical input that this is infinite recursion.
>>>>>>>>
>>>>>>>> But embedded_H has no way of knowing whether the input it is
>>>>>>>> emulating contains a copy of itself or not, therefore it has no
>>>>>>>> way of recognizing recursion.
>>>>>>>
>>>>>>> All of these details are moot at this point in the dialogue.
>>>>>>>
>>>>>>> As long as we ourselves can tell that ⟨Ĥ⟩ ⟨Ĥ⟩ specifies
>>>>>>> infinitely nested simulation to embedded_H then it is necessarily
>>>>>>> correct for embedded_H to transition to Ĥ.qn even if it does this
>>>>>>> on the basis of a wild guess.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Backing off because that avenue didn't work?
>>>>>>
>>>>>> The problem is that <H^> <H^> only specifies infinitely nested
>>>>>> simulation for tha case where H/embedded_H NEVER abort their
>>>>>> simulation, and in that case they don't give an answer so fail to
>>>>>> be Deciders.
>>>>>>
>>>>>> FAIL.
>>>>>
>>>>> I keep telling you that as long as we can tell that the correct
>>>>> simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H can never reach its final state
>>>>> then embedded_H can correctly reject this input
>>>>>
>>>>> even if it does this on the basis of a wild guess.
>>>>>
>>>>
>>>> Except that the simulation that shows this is only correct when
>>>> embedded_H never aborts its simmulation.
>>>>
>>> THAT YOU ALREADY KNOW THIS PROVES THAT YOU ARE A LIAR:
>>> That a simulated Turing machine description cannot possibly reach its
>>> own final state whether or not its simulation has been aborted
>>> conclusively proves that it specifies a non-halting sequence of
>>> configurations.
>>>
>>
>> But YOUR statement is a LIE, and you should know it, or you are just
>> an idiot.
>>
>> The definition of HALTING is based on the ACTUAL machine, and in this
>> case it is easy to show that H^ applied to <H^> will Halt if
>> H/embedded_H applied to <H^> <H^> goes to Qn, so it can't be right.
>
> You know that the simulation of the Turing machine description by a UTM
> is computationally equivalent to the direct execution of the underlying
> machine so you lie again. WHY LIE ?

Peter Olcott wrote:
> [snip bs]

There is a picture of you, Peter, floating around:

https://imgflip.com/i/69g4jd

On 3/20/2022 9:30 PM, André G. Isaak wrote:
> On 2022-03-20 20:21, olcott wrote:
>> On 3/20/2022 9:15 PM, André G. Isaak wrote:
>>> On 2022-03-20 20:05, olcott wrote:
>>>
>>>> This means that embedded_H can correctly reject its input even if it
>>>> does so by wild guess.
>>>
>>> If a wild guess happens to be 'correct' that doesn't constitute a
>>> valid algorithm.
>>>
>>
>> It does constitute a correct halt decision that refutes Linz.
>>
>>> You not only failed to answer my question but snipped it entirely. I
>>> have restored it for you:
>>>
>>
>> Unless we have mutual agreement step-by-step you have not proven that
>> you are willing to have an honest dialogue.
>
> You are the one who claimed that your embedded_H can recognize a pattern
> of infinite recursion.
>
> You are the one who claimed it did this by string comparison.
>
> If you're not willing to actually defend your claims, how on earth can
> we reach mutual agreement? And how does refusing to answer questions
> constitute 'honest dialogue' on your part?
>
> Unless and until you can answer the following, I reject both of the
> above claims.
>

Whether or not it is even possible for embedded_H to recognize the
infinitely nested simulation

because we can see that embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ does derive infinitely nested
simulation

then we can know that a transition to Ĥ.qn by embedded_H is necessarily
correct even if it does this entirely on the basis of a wild guess.

This by itself refutes the Linz conclusion that a transition to Ĥ.qn
derives a necessary contradiction.

You are only interested in finding fault and whenever I make a key point
you change the subject because you are only interested in finding fault.

I just proved that I correctly refuted Linz. I will not tolerate
skipping over this point to a different subject.

--
Copyright 2021 Pete Olcott

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

On 3/20/2022 9:30 PM, André G. Isaak wrote:
> On 2022-03-20 20:21, olcott wrote:
>> On 3/20/2022 9:15 PM, André G. Isaak wrote:
>>> On 2022-03-20 20:05, olcott wrote:
>>>
>>>> This means that embedded_H can correctly reject its input even if it
>>>> does so by wild guess.
>>>
>>> If a wild guess happens to be 'correct' that doesn't constitute a
>>> valid algorithm.
>>>
>>
>> It does constitute a correct halt decision that refutes Linz.
>>
>>> You not only failed to answer my question but snipped it entirely. I
>>> have restored it for you:
>>>
>>
>> Unless we have mutual agreement step-by-step you have not proven that
>> you are willing to have an honest dialogue.
>
> You are the one who claimed that your embedded_H can recognize a pattern
> of infinite recursion.
>
> You are the one who claimed it did this by string comparison.
>
> If you're not willing to actually defend your claims, how on earth can
> we reach mutual agreement? And how does refusing to answer questions
> constitute 'honest dialogue' on your part?
>
> Unless and until you can answer the following, I reject both of the
> above claims.
None-the-less

Whether or not it is even possible for embedded_H to recognize the
infinitely nested simulation

because we can see that embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ does derive infinitely nested
simulation

then we can know that a transition to Ĥ.qn by embedded_H is necessarily
correct even if it does this entirely on the basis of a wild guess.

This by itself refutes the Linz conclusion that a transition to Ĥ.qn
derives a necessary contradiction.

You are only interested in finding fault and whenever I make a key point
you change the subject because you are only interested in finding fault.

I just proved that I correctly refuted Linz. I will not tolerate
skipping over this point to a different subject.

--
Copyright 2021 Pete Olcott

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

On 3/21/22 2:45 PM, olcott wrote:
> On 3/20/2022 9:30 PM, André G. Isaak wrote:
>> On 2022-03-20 20:21, olcott wrote:
>>> On 3/20/2022 9:15 PM, André G. Isaak wrote:
>>>> On 2022-03-20 20:05, olcott wrote:
>>>>
>>>>> This means that embedded_H can correctly reject its input even if
>>>>> it does so by wild guess.
>>>>
>>>> If a wild guess happens to be 'correct' that doesn't constitute a
>>>> valid algorithm.
>>>>
>>>
>>> It does constitute a correct halt decision that refutes Linz.
>>>
>>>> You not only failed to answer my question but snipped it entirely. I
>>>> have restored it for you:
>>>>
>>>
>>> Unless we have mutual agreement step-by-step you have not proven that
>>> you are willing to have an honest dialogue.
>>
>> You are the one who claimed that your embedded_H can recognize a
>> pattern of infinite recursion.
>>
>> You are the one who claimed it did this by string comparison.
>>
>> If you're not willing to actually defend your claims, how on earth can
>> we reach mutual agreement? And how does refusing to answer questions
>> constitute 'honest dialogue' on your part?
>>
>> Unless and until you can answer the following, I reject both of the
>> above claims.
>>
>
> Whether or not it is even possible for embedded_H to recognize the
> infinitely nested simulation
>
> because we can see that embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ does derive infinitely nested
> simulation

BUT only if embedded_N never aborts.

>
> then we can know that a transition to Ĥ.qn by embedded_H is necessarily
> correct even if it does this entirely on the basis of a wild guess.
>

No, because THEN we violated the conditions we detected the infinitely
nested simulation to exist in. In fact, it is easy to see that if
embedded_H DOES abort its simulation, the H^ will Halt.

> This by itself refutes the Linz conclusion that a transition to Ĥ.qn
> derives a necessary contradiction.

Nope just proves you are lousy at logic.

>
> You are only interested in finding fault and whenever I make a key point
> you change the subject because you are only interested in finding fault.

We are SUPPOSED to find fault when there is ERROR.

>
> I just proved that I correctly refuted Linz. I will not tolerate
> skipping over this point to a different subject.
>

Nope, you proved you are an idiot that doesn't understand how logic
works or is interested in finding out what is actually True.

On 3/21/22 4:49 PM, olcott wrote:
> On 3/20/2022 9:30 PM, André G. Isaak wrote:
>> On 2022-03-20 20:21, olcott wrote:
>>> On 3/20/2022 9:15 PM, André G. Isaak wrote:
>>>> On 2022-03-20 20:05, olcott wrote:
>>>>
>>>>> This means that embedded_H can correctly reject its input even if
>>>>> it does so by wild guess.
>>>>
>>>> If a wild guess happens to be 'correct' that doesn't constitute a
>>>> valid algorithm.
>>>>
>>>
>>> It does constitute a correct halt decision that refutes Linz.
>>>
>>>> You not only failed to answer my question but snipped it entirely. I
>>>> have restored it for you:
>>>>
>>>
>>> Unless we have mutual agreement step-by-step you have not proven that
>>> you are willing to have an honest dialogue.
>>
>> You are the one who claimed that your embedded_H can recognize a
>> pattern of infinite recursion.
>>
>> You are the one who claimed it did this by string comparison.
>>
>> If you're not willing to actually defend your claims, how on earth can
>> we reach mutual agreement? And how does refusing to answer questions
>> constitute 'honest dialogue' on your part?
>>
>> Unless and until you can answer the following, I reject both of the
>> above claims.
> None-the-less
>
> Whether or not it is even possible for embedded_H to recognize the
> infinitely nested simulation
>
> because we can see that embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ does derive infinitely nested
> simulation
>
> then we can know that a transition to Ĥ.qn by embedded_H is necessarily
> correct even if it does this entirely on the basis of a wild guess.
>
> This by itself refutes the Linz conclusion that a transition to Ĥ.qn
> derives a necessary contradiction.
>
> You are only interested in finding fault and whenever I make a key point
> you change the subject because you are only interested in finding fault.
>
> I just proved that I correctly refuted Linz. I will not tolerate
> skipping over this point to a different subject.
>

Repeating it doesn't make it any more True, You are stil wrong.

The infinite simulation loop only occurs IF embedded_H never aborts its
simulation, and thus it fails by not answering.

If it aborts, and goes to Qn, then H^ applied to <H^> Halts, so it is wrong.

Thus you have proved nothing but your own stupidity.

We find fault where there IS fault. Maybe if you tried to find an actaul
error in one of the rebuttals, that you can point to a ACTUAL rule that
is violated (not one of your 'made up' 'self-evident' rules) then people
might treat you better.

On 3/21/22 8:57 AM, olcott wrote:
> On 3/21/2022 6:15 AM, Richard Damon wrote:
>> On 3/20/22 11:40 PM, olcott wrote:
>>> On 3/20/2022 9:56 PM, Richard Damon wrote:
>>>> On 3/20/22 10:10 PM, olcott wrote:
>>>>> On 3/20/2022 8:54 PM, Richard Damon wrote:
>>>>>> On 3/20/22 9:39 PM, olcott wrote:
>>>>>>> On 3/20/2022 8:09 PM, André G. Isaak wrote:
>>>>>>>> On 2022-03-20 17:50, olcott wrote:
>>>>>>>>> On 3/20/2022 2:25 PM, André G. Isaak wrote:
>>>>>>>>>> On 2022-03-20 13:12, olcott wrote:
>>>>>>>>>>> On 3/20/2022 1:59 PM, André G. Isaak wrote:
>>>>>>>>>>>> I'm reposting the following question in this thread at
>>>>>>>>>>>> Olcott's insistence even though it doesn't belong here. The
>>>>>>>>>>>> original message can be seen in its proper context here:
>>>>>>>>>>>> <t164qe$59o$2@dont-email.me>
>>>>>>>>>>>>
>>>>>>>>>>>> On 2022-03-19 20:47, olcott wrote:
>>>>>>>>>>>>  > On 3/19/2022 9:38 PM, André G. Isaak wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>  > I changed to a different thread that does not have the
>>>>>>>>>>>> lame main
>>>>>>>>>>>>  > thread name of Comic.
>>>>>>>>>>>>  >
>>>>>>>>>>>>  >> A Turing Machine has no access to *any* information
>>>>>>>>>>>> apart from what
>>>>>>>>>>>>  >> is present on its tape. Ĥ (of which your embedded_H is a
>>>>>>>>>>>> part) starts
>>>>>>>>>>>>  >> with only a *single* string on its tape.
>>>>>>>>>>>>  >>
>>>>>>>>>>>>  >> With what, exactly, do you plan on comparing this string
>>>>>>>>>>>> in making
>>>>>>>>>>>>  >> your 'halt status decision'?
>>>>>>>>>>>>
>>>>>>>>>>>> You didn't actually answer the above question. What exactly
>>>>>>>>>>>> do you plan on comparing the input to?
>>>>>>>>>>>>
>>>>>>>>>>>> André
>>>>>>>>>>>
>>>>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>>>>>>    Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then embedded_H simulates
>>>>>>>>>>> ⟨Ĥ0⟩ ⟨Ĥ1⟩
>>>>>>>>>>>
>>>>>>>>>>> Then these steps would keep repeating:
>>>>>>>>>>>    Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H0
>>>>>>>>>>> simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>>>>>>>>>>    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H1
>>>>>>>>>>> simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>>>>>>>>>>    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H2
>>>>>>>>>>> simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩...
>>>>>>>>>>>
>>>>>>>>>>> Technically the abort criteria exists when embedded_H0 would
>>>>>>>>>>> simulate ⟨Ĥ1⟩ ⟨Ĥ2⟩. It is at this point that embedded_H would
>>>>>>>>>>> otherwise simulate an exact copy of itself with an exact copy
>>>>>>>>>>> of its inputs.
>>>>>>>>>>>
>>>>>>>>>>> If embedded_H aborts the simulation of embedded_H0 before
>>>>>>>>>>> embedded_H0 is invoked then not even the first copy does the
>>>>>>>>>>> same thing as embedded_H and there are no copies besides this
>>>>>>>>>>> first one.
>>>>>>>>>>>
>>>>>>>>>>> That the infinitely nested simulation criteria is
>>>>>>>>>>> definitively met conclusively proves that embedded_H can
>>>>>>>>>>> reject its input without forming the contradiction that Linz
>>>>>>>>>>> claims is formed.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> How does any of the above even remotely address the question I
>>>>>>>>>> asked?
>>>>>>>>>>
>>>>>>>>>> You claimed "strcmp()" played an important role in your
>>>>>>>>>> halting decision. (Your exact words were "When strcmp is used
>>>>>>>>>> as the key element of a halt status decision then this changes
>>>>>>>>>> the behavior H relative to embedded_H for the same input")
>>>>>>>>>>
>>>>>>>>>> Putting aside the fact that strcmp() is a C function which has
>>>>>>>>>> nothing to do with Turing machines, string comparison requires
>>>>>>>>>> *two* strings to compare. Ĥ takes a *single* string as its
>>>>>>>>>> input so there is only one string on the tape. What do you
>>>>>>>>>> plan on comparing this string with?
>>>>>>>>>>
>>>>>>>>>> André
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>>>>    Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then embedded_H simulates
>>>>>>>>> ⟨Ĥ0⟩ ⟨Ĥ1⟩
>>>>>>>>>
>>>>>>>>> Then these steps would keep repeating:
>>>>>>>>>    Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H0 simulates
>>>>>>>>> ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>>>>>>>>    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H1 simulates
>>>>>>>>> ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>>>>>>>>    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H2 simulates
>>>>>>>>> ⟨Ĥ3⟩ ⟨Ĥ4⟩...
>>>>>>>>>
>>>>>>>>> Because we can tell that all the copies of ⟨Ĥ⟩ are identical to
>>>>>>>>> each other we know that their finite string comparisons would
>>>>>>>>> be identical.
>>>>>>>>
>>>>>>>> You're acting very ELIZA-like here. Instead of answering the
>>>>>>>> question you are simply repeating earlier material.
>>>>>>>>
>>>>>>>> The question I asked was *which* strings are being compared?
>>>>>>>>
>>>>>>>>> Because embedded_H is the master UTM all of these finite
>>>>>>>>> strings would be somewhere on its own tape.
>>>>>>>>
>>>>>>>> embedded_H isn't a UTM at all, let alone a 'master UTM'. It is a
>>>>>>>> modified version of a simulating halt decider.
>>>>>>>>
>>>>>>>> The top-level embedded_H has an input consisting of two
>>>>>>>> identical copies of a single string which may or may not be ⟨Ĥ⟩.
>>>>>>>> Please explain which two strings the top-level embedded_H
>>>>>>>> compares and where it gets these strings from.
>>>>>>>>
>>>>>>>>> We also know that when a function calls a copy of itself with
>>>>>>>>> identical input that this is infinite recursion.
>>>>>>>>
>>>>>>>> But embedded_H has no way of knowing whether the input it is
>>>>>>>> emulating contains a copy of itself or not, therefore it has no
>>>>>>>> way of recognizing recursion.
>>>>>>>
>>>>>>> All of these details are moot at this point in the dialogue.
>>>>>>>
>>>>>>> As long as we ourselves can tell that ⟨Ĥ⟩ ⟨Ĥ⟩ specifies
>>>>>>> infinitely nested simulation to embedded_H then it is necessarily
>>>>>>> correct for embedded_H to transition to Ĥ.qn even if it does this
>>>>>>> on the basis of a wild guess.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Backing off because that avenue didn't work?
>>>>>>
>>>>>> The problem is that <H^> <H^> only specifies infinitely nested
>>>>>> simulation for tha case where H/embedded_H NEVER abort their
>>>>>> simulation, and in that case they don't give an answer so fail to
>>>>>> be Deciders.
>>>>>>
>>>>>> FAIL.
>>>>>
>>>>> I keep telling you that as long as we can tell that the correct
>>>>> simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H can never reach its final state
>>>>> then embedded_H can correctly reject this input
>>>>>
>>>>> even if it does this on the basis of a wild guess.
>>>>>
>>>>
>>>> Except that the simulation that shows this is only correct when
>>>> embedded_H never aborts its simmulation.
>>>>
>>> THAT YOU ALREADY KNOW THIS PROVES THAT YOU ARE A LIAR:
>>> That a simulated Turing machine description cannot possibly reach its
>>> own final state whether or not its simulation has been aborted
>>> conclusively proves that it specifies a non-halting sequence of
>>> configurations.
>>>
>>
>> But YOUR statement is a LIE, and you should know it, or you are just
>> an idiot.
>>
>> The definition of HALTING is based on the ACTUAL machine, and in this
>> case it is easy to show that H^ applied to <H^> will Halt if
>> H/embedded_H applied to <H^> <H^> goes to Qn, so it can't be right.
>
> You know that the simulation of the Turing machine description by a UTM
> is computationally equivalent to the direct execution of the underlying
> machine so you lie again. WHY LIE ?
>

On 3/21/22 9:42 AM, olcott wrote:
> On 3/21/2022 7:57 AM, olcott wrote:
>> On 3/21/2022 6:15 AM, Richard Damon wrote:
>>> On 3/20/22 11:40 PM, olcott wrote:
>>>> On 3/20/2022 9:56 PM, Richard Damon wrote:
>>>>> On 3/20/22 10:10 PM, olcott wrote:
>>>>>> On 3/20/2022 8:54 PM, Richard Damon wrote:
>>>>>>> On 3/20/22 9:39 PM, olcott wrote:
>>>>>>>> On 3/20/2022 8:09 PM, André G. Isaak wrote:
>>>>>>>>> On 2022-03-20 17:50, olcott wrote:
>>>>>>>>>> On 3/20/2022 2:25 PM, André G. Isaak wrote:
>>>>>>>>>>> On 2022-03-20 13:12, olcott wrote:
>>>>>>>>>>>> On 3/20/2022 1:59 PM, André G. Isaak wrote:
>>>>>>>>>>>>> I'm reposting the following question in this thread at
>>>>>>>>>>>>> Olcott's insistence even though it doesn't belong here. The
>>>>>>>>>>>>> original message can be seen in its proper context here:
>>>>>>>>>>>>> <t164qe$59o$2@dont-email.me>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 2022-03-19 20:47, olcott wrote:
>>>>>>>>>>>>>  > On 3/19/2022 9:38 PM, André G. Isaak wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>  > I changed to a different thread that does not have the
>>>>>>>>>>>>> lame main
>>>>>>>>>>>>>  > thread name of Comic.
>>>>>>>>>>>>>  >
>>>>>>>>>>>>>  >> A Turing Machine has no access to *any* information
>>>>>>>>>>>>> apart from what
>>>>>>>>>>>>>  >> is present on its tape. Ĥ (of which your embedded_H is
>>>>>>>>>>>>> a part) starts
>>>>>>>>>>>>>  >> with only a *single* string on its tape.
>>>>>>>>>>>>>  >>
>>>>>>>>>>>>>  >> With what, exactly, do you plan on comparing this
>>>>>>>>>>>>> string in making
>>>>>>>>>>>>>  >> your 'halt status decision'?
>>>>>>>>>>>>>
>>>>>>>>>>>>> You didn't actually answer the above question. What exactly
>>>>>>>>>>>>> do you plan on comparing the input to?
>>>>>>>>>>>>>
>>>>>>>>>>>>> André
>>>>>>>>>>>>
>>>>>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>>>>>>>    Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then embedded_H simulates
>>>>>>>>>>>> ⟨Ĥ0⟩ ⟨Ĥ1⟩
>>>>>>>>>>>>
>>>>>>>>>>>> Then these steps would keep repeating:
>>>>>>>>>>>>    Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H0
>>>>>>>>>>>> simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>>>>>>>>>>>    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H1
>>>>>>>>>>>> simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>>>>>>>>>>>    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H2
>>>>>>>>>>>> simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩...
>>>>>>>>>>>>
>>>>>>>>>>>> Technically the abort criteria exists when embedded_H0 would
>>>>>>>>>>>> simulate ⟨Ĥ1⟩ ⟨Ĥ2⟩. It is at this point that embedded_H
>>>>>>>>>>>> would otherwise simulate an exact copy of itself with an
>>>>>>>>>>>> exact copy of its inputs.
>>>>>>>>>>>>
>>>>>>>>>>>> If embedded_H aborts the simulation of embedded_H0 before
>>>>>>>>>>>> embedded_H0 is invoked then not even the first copy does the
>>>>>>>>>>>> same thing as embedded_H and there are no copies besides
>>>>>>>>>>>> this first one.
>>>>>>>>>>>>
>>>>>>>>>>>> That the infinitely nested simulation criteria is
>>>>>>>>>>>> definitively met conclusively proves that embedded_H can
>>>>>>>>>>>> reject its input without forming the contradiction that Linz
>>>>>>>>>>>> claims is formed.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> How does any of the above even remotely address the question
>>>>>>>>>>> I asked?
>>>>>>>>>>>
>>>>>>>>>>> You claimed "strcmp()" played an important role in your
>>>>>>>>>>> halting decision. (Your exact words were "When strcmp is used
>>>>>>>>>>> as the key element of a halt status decision then this
>>>>>>>>>>> changes the behavior H relative to embedded_H for the same
>>>>>>>>>>> input")
>>>>>>>>>>>
>>>>>>>>>>> Putting aside the fact that strcmp() is a C function which
>>>>>>>>>>> has nothing to do with Turing machines, string comparison
>>>>>>>>>>> requires *two* strings to compare. Ĥ takes a *single* string
>>>>>>>>>>> as its input so there is only one string on the tape. What do
>>>>>>>>>>> you plan on comparing this string with?
>>>>>>>>>>>
>>>>>>>>>>> André
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>>>>>    Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then embedded_H simulates
>>>>>>>>>> ⟨Ĥ0⟩ ⟨Ĥ1⟩
>>>>>>>>>>
>>>>>>>>>> Then these steps would keep repeating:
>>>>>>>>>>    Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H0 simulates
>>>>>>>>>> ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>>>>>>>>>    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H1 simulates
>>>>>>>>>> ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>>>>>>>>>    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H2 simulates
>>>>>>>>>> ⟨Ĥ3⟩ ⟨Ĥ4⟩...
>>>>>>>>>>
>>>>>>>>>> Because we can tell that all the copies of ⟨Ĥ⟩ are identical
>>>>>>>>>> to each other we know that their finite string comparisons
>>>>>>>>>> would be identical.
>>>>>>>>>
>>>>>>>>> You're acting very ELIZA-like here. Instead of answering the
>>>>>>>>> question you are simply repeating earlier material.
>>>>>>>>>
>>>>>>>>> The question I asked was *which* strings are being compared?
>>>>>>>>>
>>>>>>>>>> Because embedded_H is the master UTM all of these finite
>>>>>>>>>> strings would be somewhere on its own tape.
>>>>>>>>>
>>>>>>>>> embedded_H isn't a UTM at all, let alone a 'master UTM'. It is
>>>>>>>>> a modified version of a simulating halt decider.
>>>>>>>>>
>>>>>>>>> The top-level embedded_H has an input consisting of two
>>>>>>>>> identical copies of a single string which may or may not be
>>>>>>>>> ⟨Ĥ⟩. Please explain which two strings the top-level embedded_H
>>>>>>>>> compares and where it gets these strings from.
>>>>>>>>>
>>>>>>>>>> We also know that when a function calls a copy of itself with
>>>>>>>>>> identical input that this is infinite recursion.
>>>>>>>>>
>>>>>>>>> But embedded_H has no way of knowing whether the input it is
>>>>>>>>> emulating contains a copy of itself or not, therefore it has no
>>>>>>>>> way of recognizing recursion.
>>>>>>>>
>>>>>>>> All of these details are moot at this point in the dialogue.
>>>>>>>>
>>>>>>>> As long as we ourselves can tell that ⟨Ĥ⟩ ⟨Ĥ⟩ specifies
>>>>>>>> infinitely nested simulation to embedded_H then it is
>>>>>>>> necessarily correct for embedded_H to transition to Ĥ.qn even if
>>>>>>>> it does this on the basis of a wild guess.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> Backing off because that avenue didn't work?
>>>>>>>
>>>>>>> The problem is that <H^> <H^> only specifies infinitely nested
>>>>>>> simulation for tha case where H/embedded_H NEVER abort their
>>>>>>> simulation, and in that case they don't give an answer so fail to
>>>>>>> be Deciders.
>>>>>>>
>>>>>>> FAIL.
>>>>>>
>>>>>> I keep telling you that as long as we can tell that the correct
>>>>>> simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H can never reach its final
>>>>>> state then embedded_H can correctly reject this input
>>>>>>
>>>>>> even if it does this on the basis of a wild guess.
>>>>>>
>>>>>
>>>>> Except that the simulation that shows this is only correct when
>>>>> embedded_H never aborts its simmulation.
>>>>>
>>>> THAT YOU ALREADY KNOW THIS PROVES THAT YOU ARE A LIAR:
>>>> That a simulated Turing machine description cannot possibly reach
>>>> its own final state whether or not its simulation has been aborted
>>>> conclusively proves that it specifies a non-halting sequence of
>>>> configurations.
>>>>
>>>
>>> But YOUR statement is a LIE, and you should know it, or you are just
>>> an idiot.
>>>
>>> The definition of HALTING is based on the ACTUAL machine, and in this
>>> case it is easy to show that H^ applied to <H^> will Halt if
>>> H/embedded_H applied to <H^> <H^> goes to Qn, so it can't be right.
>>
>> You know that the simulation of the Turing machine description by a
>> UTM is computationally equivalent to the direct execution of the
>> underlying machine so you lie again. WHY LIE ?
>
> When Ĥ is applied to ⟨Ĥ⟩
>   Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then embedded_H simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩
>
> Then these steps would keep repeating:
>   Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H0 simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
>   Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H1 simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
>   Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H2 simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩...
>
> That a simulated Turing machine description cannot possibly reach its
> own final state whether or not its simulation has been aborted
> conclusively proves that it specifies a non-halting sequence of
> configurations.
>

On 3/21/2022 4:36 PM, Richard Damon wrote:
> On 3/21/22 2:45 PM, olcott wrote:
>> On 3/20/2022 9:30 PM, André G. Isaak wrote:
>>> On 2022-03-20 20:21, olcott wrote:
>>>> On 3/20/2022 9:15 PM, André G. Isaak wrote:
>>>>> On 2022-03-20 20:05, olcott wrote:
>>>>>
>>>>>> This means that embedded_H can correctly reject its input even if
>>>>>> it does so by wild guess.
>>>>>
>>>>> If a wild guess happens to be 'correct' that doesn't constitute a
>>>>> valid algorithm.
>>>>>
>>>>
>>>> It does constitute a correct halt decision that refutes Linz.
>>>>
>>>>> You not only failed to answer my question but snipped it entirely.
>>>>> I have restored it for you:
>>>>>
>>>>
>>>> Unless we have mutual agreement step-by-step you have not proven
>>>> that you are willing to have an honest dialogue.
>>>
>>> You are the one who claimed that your embedded_H can recognize a
>>> pattern of infinite recursion.
>>>
>>> You are the one who claimed it did this by string comparison.
>>>
>>> If you're not willing to actually defend your claims, how on earth
>>> can we reach mutual agreement? And how does refusing to answer
>>> questions constitute 'honest dialogue' on your part?
>>>
>>> Unless and until you can answer the following, I reject both of the
>>> above claims.
>>>
>>
>> Whether or not it is even possible for embedded_H to recognize the
>> infinitely nested simulation
>>
>> because we can see that embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ does derive infinitely
>> nested simulation
>
> BUT only if embedded_N never aborts.

The simulated input meets the Linz definition of non halting whether or
not its simulation is aborted.

--
Copyright 2021 Pete Olcott

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

On 3/21/2022 4:44 PM, Richard Damon wrote:
> On 3/21/22 8:57 AM, olcott wrote:
>> On 3/21/2022 6:15 AM, Richard Damon wrote:
>>> On 3/20/22 11:40 PM, olcott wrote:
>>>> On 3/20/2022 9:56 PM, Richard Damon wrote:
>>>>> On 3/20/22 10:10 PM, olcott wrote:
>>>>>> On 3/20/2022 8:54 PM, Richard Damon wrote:
>>>>>>> On 3/20/22 9:39 PM, olcott wrote:
>>>>>>>> On 3/20/2022 8:09 PM, André G. Isaak wrote:
>>>>>>>>> On 2022-03-20 17:50, olcott wrote:
>>>>>>>>>> On 3/20/2022 2:25 PM, André G. Isaak wrote:
>>>>>>>>>>> On 2022-03-20 13:12, olcott wrote:
>>>>>>>>>>>> On 3/20/2022 1:59 PM, André G. Isaak wrote:
>>>>>>>>>>>>> I'm reposting the following question in this thread at
>>>>>>>>>>>>> Olcott's insistence even though it doesn't belong here. The
>>>>>>>>>>>>> original message can be seen in its proper context here:
>>>>>>>>>>>>> <t164qe$59o$2@dont-email.me>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 2022-03-19 20:47, olcott wrote:
>>>>>>>>>>>>>  > On 3/19/2022 9:38 PM, André G. Isaak wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>  > I changed to a different thread that does not have the
>>>>>>>>>>>>> lame main
>>>>>>>>>>>>>  > thread name of Comic.
>>>>>>>>>>>>>  >
>>>>>>>>>>>>>  >> A Turing Machine has no access to *any* information
>>>>>>>>>>>>> apart from what
>>>>>>>>>>>>>  >> is present on its tape. Ĥ (of which your embedded_H is
>>>>>>>>>>>>> a part) starts
>>>>>>>>>>>>>  >> with only a *single* string on its tape.
>>>>>>>>>>>>>  >>
>>>>>>>>>>>>>  >> With what, exactly, do you plan on comparing this
>>>>>>>>>>>>> string in making
>>>>>>>>>>>>>  >> your 'halt status decision'?
>>>>>>>>>>>>>
>>>>>>>>>>>>> You didn't actually answer the above question. What exactly
>>>>>>>>>>>>> do you plan on comparing the input to?
>>>>>>>>>>>>>
>>>>>>>>>>>>> André
>>>>>>>>>>>>
>>>>>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>>>>>>>    Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then embedded_H simulates
>>>>>>>>>>>> ⟨Ĥ0⟩ ⟨Ĥ1⟩
>>>>>>>>>>>>
>>>>>>>>>>>> Then these steps would keep repeating:
>>>>>>>>>>>>    Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H0
>>>>>>>>>>>> simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>>>>>>>>>>>    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H1
>>>>>>>>>>>> simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>>>>>>>>>>>    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H2
>>>>>>>>>>>> simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩...
>>>>>>>>>>>>
>>>>>>>>>>>> Technically the abort criteria exists when embedded_H0 would
>>>>>>>>>>>> simulate ⟨Ĥ1⟩ ⟨Ĥ2⟩. It is at this point that embedded_H
>>>>>>>>>>>> would otherwise simulate an exact copy of itself with an
>>>>>>>>>>>> exact copy of its inputs.
>>>>>>>>>>>>
>>>>>>>>>>>> If embedded_H aborts the simulation of embedded_H0 before
>>>>>>>>>>>> embedded_H0 is invoked then not even the first copy does the
>>>>>>>>>>>> same thing as embedded_H and there are no copies besides
>>>>>>>>>>>> this first one.
>>>>>>>>>>>>
>>>>>>>>>>>> That the infinitely nested simulation criteria is
>>>>>>>>>>>> definitively met conclusively proves that embedded_H can
>>>>>>>>>>>> reject its input without forming the contradiction that Linz
>>>>>>>>>>>> claims is formed.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> How does any of the above even remotely address the question
>>>>>>>>>>> I asked?
>>>>>>>>>>>
>>>>>>>>>>> You claimed "strcmp()" played an important role in your
>>>>>>>>>>> halting decision. (Your exact words were "When strcmp is used
>>>>>>>>>>> as the key element of a halt status decision then this
>>>>>>>>>>> changes the behavior H relative to embedded_H for the same
>>>>>>>>>>> input")
>>>>>>>>>>>
>>>>>>>>>>> Putting aside the fact that strcmp() is a C function which
>>>>>>>>>>> has nothing to do with Turing machines, string comparison
>>>>>>>>>>> requires *two* strings to compare. Ĥ takes a *single* string
>>>>>>>>>>> as its input so there is only one string on the tape. What do
>>>>>>>>>>> you plan on comparing this string with?
>>>>>>>>>>>
>>>>>>>>>>> André
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>>>>>    Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then embedded_H simulates
>>>>>>>>>> ⟨Ĥ0⟩ ⟨Ĥ1⟩
>>>>>>>>>>
>>>>>>>>>> Then these steps would keep repeating:
>>>>>>>>>>    Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H0 simulates
>>>>>>>>>> ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>>>>>>>>>    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H1 simulates
>>>>>>>>>> ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>>>>>>>>>    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H2 simulates
>>>>>>>>>> ⟨Ĥ3⟩ ⟨Ĥ4⟩...
>>>>>>>>>>
>>>>>>>>>> Because we can tell that all the copies of ⟨Ĥ⟩ are identical
>>>>>>>>>> to each other we know that their finite string comparisons
>>>>>>>>>> would be identical.
>>>>>>>>>
>>>>>>>>> You're acting very ELIZA-like here. Instead of answering the
>>>>>>>>> question you are simply repeating earlier material.
>>>>>>>>>
>>>>>>>>> The question I asked was *which* strings are being compared?
>>>>>>>>>
>>>>>>>>>> Because embedded_H is the master UTM all of these finite
>>>>>>>>>> strings would be somewhere on its own tape.
>>>>>>>>>
>>>>>>>>> embedded_H isn't a UTM at all, let alone a 'master UTM'. It is
>>>>>>>>> a modified version of a simulating halt decider.
>>>>>>>>>
>>>>>>>>> The top-level embedded_H has an input consisting of two
>>>>>>>>> identical copies of a single string which may or may not be
>>>>>>>>> ⟨Ĥ⟩. Please explain which two strings the top-level embedded_H
>>>>>>>>> compares and where it gets these strings from.
>>>>>>>>>
>>>>>>>>>> We also know that when a function calls a copy of itself with
>>>>>>>>>> identical input that this is infinite recursion.
>>>>>>>>>
>>>>>>>>> But embedded_H has no way of knowing whether the input it is
>>>>>>>>> emulating contains a copy of itself or not, therefore it has no
>>>>>>>>> way of recognizing recursion.
>>>>>>>>
>>>>>>>> All of these details are moot at this point in the dialogue.
>>>>>>>>
>>>>>>>> As long as we ourselves can tell that ⟨Ĥ⟩ ⟨Ĥ⟩ specifies
>>>>>>>> infinitely nested simulation to embedded_H then it is
>>>>>>>> necessarily correct for embedded_H to transition to Ĥ.qn even if
>>>>>>>> it does this on the basis of a wild guess.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> Backing off because that avenue didn't work?
>>>>>>>
>>>>>>> The problem is that <H^> <H^> only specifies infinitely nested
>>>>>>> simulation for tha case where H/embedded_H NEVER abort their
>>>>>>> simulation, and in that case they don't give an answer so fail to
>>>>>>> be Deciders.
>>>>>>>
>>>>>>> FAIL.
>>>>>>
>>>>>> I keep telling you that as long as we can tell that the correct
>>>>>> simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H can never reach its final
>>>>>> state then embedded_H can correctly reject this input
>>>>>>
>>>>>> even if it does this on the basis of a wild guess.
>>>>>>
>>>>>
>>>>> Except that the simulation that shows this is only correct when
>>>>> embedded_H never aborts its simmulation.
>>>>>
>>>> THAT YOU ALREADY KNOW THIS PROVES THAT YOU ARE A LIAR:
>>>> That a simulated Turing machine description cannot possibly reach
>>>> its own final state whether or not its simulation has been aborted
>>>> conclusively proves that it specifies a non-halting sequence of
>>>> configurations.
>>>>
>>>
>>> But YOUR statement is a LIE, and you should know it, or you are just
>>> an idiot.
>>>
>>> The definition of HALTING is based on the ACTUAL machine, and in this
>>> case it is easy to show that H^ applied to <H^> will Halt if
>>> H/embedded_H applied to <H^> <H^> goes to Qn, so it can't be right.
>>
>> You know that the simulation of the Turing machine description by a
>> UTM is computationally equivalent to the direct execution of the
>> underlying machine so you lie again. WHY LIE ?
>>
>
> When did I deny that? Note that if the simulation DOESN'T match the
> direct exection, that is PROOF the simulator isn't a UTM.

On 3/21/22 7:13 PM, olcott wrote:
> On 3/21/2022 4:36 PM, Richard Damon wrote:
>> On 3/21/22 2:45 PM, olcott wrote:
>>> On 3/20/2022 9:30 PM, André G. Isaak wrote:
>>>> On 2022-03-20 20:21, olcott wrote:
>>>>> On 3/20/2022 9:15 PM, André G. Isaak wrote:
>>>>>> On 2022-03-20 20:05, olcott wrote:
>>>>>>
>>>>>>> This means that embedded_H can correctly reject its input even if
>>>>>>> it does so by wild guess.
>>>>>>
>>>>>> If a wild guess happens to be 'correct' that doesn't constitute a
>>>>>> valid algorithm.
>>>>>>
>>>>>
>>>>> It does constitute a correct halt decision that refutes Linz.
>>>>>
>>>>>> You not only failed to answer my question but snipped it entirely.
>>>>>> I have restored it for you:
>>>>>>
>>>>>
>>>>> Unless we have mutual agreement step-by-step you have not proven
>>>>> that you are willing to have an honest dialogue.
>>>>
>>>> You are the one who claimed that your embedded_H can recognize a
>>>> pattern of infinite recursion.
>>>>
>>>> You are the one who claimed it did this by string comparison.
>>>>
>>>> If you're not willing to actually defend your claims, how on earth
>>>> can we reach mutual agreement? And how does refusing to answer
>>>> questions constitute 'honest dialogue' on your part?
>>>>
>>>> Unless and until you can answer the following, I reject both of the
>>>> above claims.
>>>>
>>>
>>> Whether or not it is even possible for embedded_H to recognize the
>>> infinitely nested simulation
>>>
>>> because we can see that embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ does derive infinitely
>>> nested simulation
>>
>> BUT only if embedded_N never aborts.
>
> The simulated input meets the Linz definition of non halting whether or
> not its simulation is aborted.
>

Nope, since Linz's definition only directly applies to Turing Machines,
not simulation. You can get to UTM simulations, because they behave, BY
DEFINITION the same as the machine. Since your simulation doesn't match
the actual machine behavior, it doesn't count.

If you don'y understand the domain a definition applies to, you don't
understand it.

FAIL.

On 3/21/22 7:16 PM, olcott wrote:
> On 3/21/2022 4:44 PM, Richard Damon wrote:
>> On 3/21/22 8:57 AM, olcott wrote:
>>> On 3/21/2022 6:15 AM, Richard Damon wrote:
>>>> On 3/20/22 11:40 PM, olcott wrote:
>>>>> On 3/20/2022 9:56 PM, Richard Damon wrote:
>>>>>> On 3/20/22 10:10 PM, olcott wrote:
>>>>>>> On 3/20/2022 8:54 PM, Richard Damon wrote:
>>>>>>>> On 3/20/22 9:39 PM, olcott wrote:
>>>>>>>>> On 3/20/2022 8:09 PM, André G. Isaak wrote:
>>>>>>>>>> On 2022-03-20 17:50, olcott wrote:
>>>>>>>>>>> On 3/20/2022 2:25 PM, André G. Isaak wrote:
>>>>>>>>>>>> On 2022-03-20 13:12, olcott wrote:
>>>>>>>>>>>>> On 3/20/2022 1:59 PM, André G. Isaak wrote:
>>>>>>>>>>>>>> I'm reposting the following question in this thread at
>>>>>>>>>>>>>> Olcott's insistence even though it doesn't belong here.
>>>>>>>>>>>>>> The original message can be seen in its proper context
>>>>>>>>>>>>>> here: <t164qe$59o$2@dont-email.me>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 2022-03-19 20:47, olcott wrote:
>>>>>>>>>>>>>>  > On 3/19/2022 9:38 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>  > I changed to a different thread that does not have the
>>>>>>>>>>>>>> lame main
>>>>>>>>>>>>>>  > thread name of Comic.
>>>>>>>>>>>>>>  >
>>>>>>>>>>>>>>  >> A Turing Machine has no access to *any* information
>>>>>>>>>>>>>> apart from what
>>>>>>>>>>>>>>  >> is present on its tape. Ĥ (of which your embedded_H is
>>>>>>>>>>>>>> a part) starts
>>>>>>>>>>>>>>  >> with only a *single* string on its tape.
>>>>>>>>>>>>>>  >>
>>>>>>>>>>>>>>  >> With what, exactly, do you plan on comparing this
>>>>>>>>>>>>>> string in making
>>>>>>>>>>>>>>  >> your 'halt status decision'?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You didn't actually answer the above question. What
>>>>>>>>>>>>>> exactly do you plan on comparing the input to?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> André
>>>>>>>>>>>>>
>>>>>>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>>>>>>>>    Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then embedded_H
>>>>>>>>>>>>> simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩
>>>>>>>>>>>>>
>>>>>>>>>>>>> Then these steps would keep repeating:
>>>>>>>>>>>>>    Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H0
>>>>>>>>>>>>> simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>>>>>>>>>>>>    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H1
>>>>>>>>>>>>> simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>>>>>>>>>>>>    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H2
>>>>>>>>>>>>> simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩...
>>>>>>>>>>>>>
>>>>>>>>>>>>> Technically the abort criteria exists when embedded_H0
>>>>>>>>>>>>> would simulate ⟨Ĥ1⟩ ⟨Ĥ2⟩. It is at this point that
>>>>>>>>>>>>> embedded_H would otherwise simulate an exact copy of itself
>>>>>>>>>>>>> with an exact copy of its inputs.
>>>>>>>>>>>>>
>>>>>>>>>>>>> If embedded_H aborts the simulation of embedded_H0 before
>>>>>>>>>>>>> embedded_H0 is invoked then not even the first copy does
>>>>>>>>>>>>> the same thing as embedded_H and there are no copies
>>>>>>>>>>>>> besides this first one.
>>>>>>>>>>>>>
>>>>>>>>>>>>> That the infinitely nested simulation criteria is
>>>>>>>>>>>>> definitively met conclusively proves that embedded_H can
>>>>>>>>>>>>> reject its input without forming the contradiction that
>>>>>>>>>>>>> Linz claims is formed.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> How does any of the above even remotely address the question
>>>>>>>>>>>> I asked?
>>>>>>>>>>>>
>>>>>>>>>>>> You claimed "strcmp()" played an important role in your
>>>>>>>>>>>> halting decision. (Your exact words were "When strcmp is
>>>>>>>>>>>> used as the key element of a halt status decision then this
>>>>>>>>>>>> changes the behavior H relative to embedded_H for the same
>>>>>>>>>>>> input")
>>>>>>>>>>>>
>>>>>>>>>>>> Putting aside the fact that strcmp() is a C function which
>>>>>>>>>>>> has nothing to do with Turing machines, string comparison
>>>>>>>>>>>> requires *two* strings to compare. Ĥ takes a *single* string
>>>>>>>>>>>> as its input so there is only one string on the tape. What
>>>>>>>>>>>> do you plan on comparing this string with?
>>>>>>>>>>>>
>>>>>>>>>>>> André
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>>>>>>    Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then embedded_H simulates
>>>>>>>>>>> ⟨Ĥ0⟩ ⟨Ĥ1⟩
>>>>>>>>>>>
>>>>>>>>>>> Then these steps would keep repeating:
>>>>>>>>>>>    Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H0
>>>>>>>>>>> simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>>>>>>>>>>    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H1
>>>>>>>>>>> simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>>>>>>>>>>    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H2
>>>>>>>>>>> simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩...
>>>>>>>>>>>
>>>>>>>>>>> Because we can tell that all the copies of ⟨Ĥ⟩ are identical
>>>>>>>>>>> to each other we know that their finite string comparisons
>>>>>>>>>>> would be identical.
>>>>>>>>>>
>>>>>>>>>> You're acting very ELIZA-like here. Instead of answering the
>>>>>>>>>> question you are simply repeating earlier material.
>>>>>>>>>>
>>>>>>>>>> The question I asked was *which* strings are being compared?
>>>>>>>>>>
>>>>>>>>>>> Because embedded_H is the master UTM all of these finite
>>>>>>>>>>> strings would be somewhere on its own tape.
>>>>>>>>>>
>>>>>>>>>> embedded_H isn't a UTM at all, let alone a 'master UTM'. It is
>>>>>>>>>> a modified version of a simulating halt decider.
>>>>>>>>>>
>>>>>>>>>> The top-level embedded_H has an input consisting of two
>>>>>>>>>> identical copies of a single string which may or may not be
>>>>>>>>>> ⟨Ĥ⟩. Please explain which two strings the top-level embedded_H
>>>>>>>>>> compares and where it gets these strings from.
>>>>>>>>>>
>>>>>>>>>>> We also know that when a function calls a copy of itself with
>>>>>>>>>>> identical input that this is infinite recursion.
>>>>>>>>>>
>>>>>>>>>> But embedded_H has no way of knowing whether the input it is
>>>>>>>>>> emulating contains a copy of itself or not, therefore it has
>>>>>>>>>> no way of recognizing recursion.
>>>>>>>>>
>>>>>>>>> All of these details are moot at this point in the dialogue.
>>>>>>>>>
>>>>>>>>> As long as we ourselves can tell that ⟨Ĥ⟩ ⟨Ĥ⟩ specifies
>>>>>>>>> infinitely nested simulation to embedded_H then it is
>>>>>>>>> necessarily correct for embedded_H to transition to Ĥ.qn even
>>>>>>>>> if it does this on the basis of a wild guess.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> Backing off because that avenue didn't work?
>>>>>>>>
>>>>>>>> The problem is that <H^> <H^> only specifies infinitely nested
>>>>>>>> simulation for tha case where H/embedded_H NEVER abort their
>>>>>>>> simulation, and in that case they don't give an answer so fail
>>>>>>>> to be Deciders.
>>>>>>>>
>>>>>>>> FAIL.
>>>>>>>
>>>>>>> I keep telling you that as long as we can tell that the correct
>>>>>>> simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H can never reach its final
>>>>>>> state then embedded_H can correctly reject this input
>>>>>>>
>>>>>>> even if it does this on the basis of a wild guess.
>>>>>>>
>>>>>>
>>>>>> Except that the simulation that shows this is only correct when
>>>>>> embedded_H never aborts its simmulation.
>>>>>>
>>>>> THAT YOU ALREADY KNOW THIS PROVES THAT YOU ARE A LIAR:
>>>>> That a simulated Turing machine description cannot possibly reach
>>>>> its own final state whether or not its simulation has been aborted
>>>>> conclusively proves that it specifies a non-halting sequence of
>>>>> configurations.
>>>>>
>>>>
>>>> But YOUR statement is a LIE, and you should know it, or you are just
>>>> an idiot.
>>>>
>>>> The definition of HALTING is based on the ACTUAL machine, and in
>>>> this case it is easy to show that H^ applied to <H^> will Halt if
>>>> H/embedded_H applied to <H^> <H^> goes to Qn, so it can't be right.
>>>
>>> You know that the simulation of the Turing machine description by a
>>> UTM is computationally equivalent to the direct execution of the
>>> underlying machine so you lie again. WHY LIE ?
>>>
>>
>> When did I deny that? Note that if the simulation DOESN'T match the
>> direct exection, that is PROOF the simulator isn't a UTM.
>
> We can see what the correct simulation would do.
> You disagree that it does what it actually does.
>

On 3/20/2022 2:25 PM, André G. Isaak wrote:
> On 2022-03-20 13:12, olcott wrote:
>> On 3/20/2022 1:59 PM, André G. Isaak wrote:
>>> I'm reposting the following question in this thread at Olcott's
>>> insistence even though it doesn't belong here. The original message
>>> can be seen in its proper context here: <t164qe$59o$2@dont-email.me>
>>>
>>> On 2022-03-19 20:47, olcott wrote:
>>>  > On 3/19/2022 9:38 PM, André G. Isaak wrote:
>>>
>>>  > I changed to a different thread that does not have the lame main
>>>  > thread name of Comic.
>>>  >
>>>  >> A Turing Machine has no access to *any* information apart from what
>>>  >> is present on its tape. Ĥ (of which your embedded_H is a part)
>>> starts
>>>  >> with only a *single* string on its tape.
>>>  >>
>>>  >> With what, exactly, do you plan on comparing this string in making
>>>  >> your 'halt status decision'?
>>>
>>> You didn't actually answer the above question. What exactly do you
>>> plan on comparing the input to?
>>>
>>> André
>>
>> When Ĥ is applied to ⟨Ĥ⟩
>>    Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then embedded_H simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩
>>
>> Then these steps would keep repeating:
>>    Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H0 simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H1 simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H2 simulates ⟨Ĥ3⟩
>> ⟨Ĥ4⟩...
>>
>> Technically the abort criteria exists when embedded_H0 would simulate
>> ⟨Ĥ1⟩ ⟨Ĥ2⟩. It is at this point that embedded_H would otherwise
>> simulate an exact copy of itself with an exact copy of its inputs.
>>
>> If embedded_H aborts the simulation of embedded_H0 before embedded_H0
>> is invoked then not even the first copy does the same thing as
>> embedded_H and there are no copies besides this first one.
>>
>> That the infinitely nested simulation criteria is definitively met
>> conclusively proves that embedded_H can reject its input without
>> forming the contradiction that Linz claims is formed.
>
>
> How does any of the above even remotely address the question I asked?
>
> You claimed "strcmp()" played an important role in your halting
> decision. (Your exact words were "When strcmp is used as the key element
> of a halt status decision then this changes the behavior H relative to
> embedded_H for the same input")
>
> Putting aside the fact that strcmp() is a C function which has nothing
> to do with Turing machines, string comparison requires *two* strings to
> compare. Ĥ takes a *single* string as its input so there is only one
> string on the tape. What do you plan on comparing this string with?
>
> André
>

When Ĥ is applied to ⟨Ĥ⟩
Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then embedded_H simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩

Then these steps would keep repeating:
Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H0 simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H1 simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H2 simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩...

We can see that an identical finite string of embedded_H continues to be
simulated with identical finite string inputs. **

This tells us that Ĥ applied to ⟨Ĥ⟩ does specify infinitely nested
simulation to the original directly executed embedded_H.

This is all that we need to refute the Linz conclusion that a that a
transition to Ĥ.qn necessarily results in a contradiction.

To prove that the input to embedded_H is decidable we need to know the
algorithm that embedded_H would use. All that this algorithm must do is
recognize the same pattern that we can see. That we can see this pattern
proves that recognizing this pattern is not categorically impossible.

I could not show the details of recognizing this pattern using actual
Turing machines because it is enormously too tedious. Even the details
of calculating the digits of PI would be far too cumbersome for hardly
anyone to understand when these details are actual Turing machine state
transitions.

The rational approach would be to specify the algorithm in some higher
level abstraction such as a RASP machine and then map this higher level
abstraction to a Turing machine description.

** A finite string comparison can also see that these finite string are
identical. All of these finite strings are somewhere on the tape of the
UTM that is a part of the original executed not simulated embedded_H,
thus available to this embedded_H.

THE KEY POINT IS THAT THE LINZ CONCLUSION (THAT A TRANSITION TO Ĥ.QN
DERIVES A CONTRADICTION) IS REFUTED BY WHAT WE ALREADY KNOW.

TO PROVE THAT THE HALTING PROBLEM COUNTER-EXAMPLE INPUTS ARE DECIDABLE
REQUIRES KNOWING THE ALGORITHM BASIS.

--
Copyright 2021 Pete Olcott

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

On Wednesday, 23 March 2022 at 00:57:47 UTC+8, olcott wrote:
> On 3/20/2022 2:25 PM, André G. Isaak wrote:
> > On 2022-03-20 13:12, olcott wrote:
> >> On 3/20/2022 1:59 PM, André G. Isaak wrote:
> >>> I'm reposting the following question in this thread at Olcott's
> >>> insistence even though it doesn't belong here. The original message
> >>> can be seen in its proper context here: <t164qe$59o$2...@dont-email.me>
> >>>
> >>> On 2022-03-19 20:47, olcott wrote:
> >>> > On 3/19/2022 9:38 PM, André G. Isaak wrote:
> >>>
> >>> > I changed to a different thread that does not have the lame main
> >>> > thread name of Comic.
> >>> >
> >>> >> A Turing Machine has no access to *any* information apart from what
> >>> >> is present on its tape. Ĥ (of which your embedded_H is a part)
> >>> starts
> >>> >> with only a *single* string on its tape.
> >>> >>
> >>> >> With what, exactly, do you plan on comparing this string in making
> >>> >> your 'halt status decision'?
> >>>
> >>> You didn't actually answer the above question. What exactly do you
> >>> plan on comparing the input to?
> >>>
> >>> André
> >>
> >> When Ĥ is applied to ⟨Ĥ⟩
> >> Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then embedded_H simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩
> >>
> >> Then these steps would keep repeating:
> >> Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H0 simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
> >> Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H1 simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
> >> Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H2 simulates ⟨Ĥ3⟩
> >> ⟨Ĥ4⟩...
> >>
> >> Technically the abort criteria exists when embedded_H0 would simulate
> >> ⟨Ĥ1⟩ ⟨Ĥ2⟩. It is at this point that embedded_H would otherwise
> >> simulate an exact copy of itself with an exact copy of its inputs.
> >>
> >> If embedded_H aborts the simulation of embedded_H0 before embedded_H0
> >> is invoked then not even the first copy does the same thing as
> >> embedded_H and there are no copies besides this first one.
> >>
> >> That the infinitely nested simulation criteria is definitively met
> >> conclusively proves that embedded_H can reject its input without
> >> forming the contradiction that Linz claims is formed.
> >
> >
> > How does any of the above even remotely address the question I asked?
> >
> > You claimed "strcmp()" played an important role in your halting
> > decision. (Your exact words were "When strcmp is used as the key element
> > of a halt status decision then this changes the behavior H relative to
> > embedded_H for the same input")
> >
> > Putting aside the fact that strcmp() is a C function which has nothing
> > to do with Turing machines, string comparison requires *two* strings to
> > compare. Ĥ takes a *single* string as its input so there is only one
> > string on the tape. What do you plan on comparing this string with?
> >
> > André
> >
>
> When Ĥ is applied to ⟨Ĥ⟩
> Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then embedded_H simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩
>
> Then these steps would keep repeating:
> Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H0 simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
> Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H1 simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
> Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H2 simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩...
> We can see that an identical finite string of embedded_H continues to be
> simulated with identical finite string inputs. **
>
> This tells us that Ĥ applied to ⟨Ĥ⟩ does specify infinitely nested
> simulation to the original directly executed embedded_H.
>
> This is all that we need to refute the Linz conclusion that a that a
> transition to Ĥ.qn necessarily results in a contradiction.
>
>
>
>
> To prove that the input to embedded_H is decidable we need to know the
> algorithm that embedded_H would use. All that this algorithm must do is
> recognize the same pattern that we can see. That we can see this pattern
> proves that recognizing this pattern is not categorically impossible.
>
> I could not show the details of recognizing this pattern using actual
> Turing machines because it is enormously too tedious. Even the details
> of calculating the digits of PI would be far too cumbersome for hardly
> anyone to understand when these details are actual Turing machine state
> transitions.

It doesn't matter what programming language you use, you just do not have a real
H and P but talk that you have.

> The rational approach would be to specify the algorithm in some higher
> level abstraction such as a RASP machine and then map this higher level
> abstraction to a Turing machine description.
>
>
>
> ** A finite string comparison can also see that these finite string are
> identical. All of these finite strings are somewhere on the tape of the
> UTM that is a part of the original executed not simulated embedded_H,
> thus available to this embedded_H.
>
> THE KEY POINT IS THAT THE LINZ CONCLUSION (THAT A TRANSITION TO Ĥ.QN
> DERIVES A CONTRADICTION) IS REFUTED BY WHAT WE ALREADY KNOW.
>
> TO PROVE THAT THE HALTING PROBLEM COUNTER-EXAMPLE INPUTS ARE DECIDABLE
> REQUIRES KNOWING THE ALGORITHM BASIS.
> --
> Copyright 2021 Pete Olcott
>
> Talent hits a target no one else can hit;
> Genius hits a target no one else can see.
> Arthur Schopenhauer

H is a deterministic system (https://en.wikipedia.org/wiki/Deterministic_system)
No H can correctly decide (halt at y or n state) the test case P:

void P() {
if H(P) { for(;;) {}; }
}

1. You don't have such H.
Where is the claimed H these years? (just talks)
2. You don't even have a correct implement of the P above, neither.
Your version is wrong. the "H(P)" in P is difficult to implement. (no one think you can do it right)