On 3/20/22 11:54 AM, olcott wrote:
> On 3/20/2022 10:50 AM, Alan Mackenzie wrote:
>> olcott <NoOne@nowhere.com> wrote:
>>> On 3/20/2022 10:01 AM, Alan Mackenzie wrote:
>>>> olcott <NoOne@nowhere.com> wrote:
>>>>> On 3/20/2022 9:17 AM, olcott wrote:
>>>>>> On 3/20/2022 6:07 AM, Richard Damon wrote:
>>
>>>> [ .... ]
>>
>>>>>> It is not possible that the copy of embedded_H will abort its
>>>>>> simulation
>>>>>> because the simulation is not aborted until the minimum abort
>>>>>> criteria
>>>>>> is met and the outermost embedded_H sees more of the execution trace
>>>>>> than any copy.
>>
>>>>>>> It failed to notice THEIR abort counter counting.
>>
>>>>>>> You forget that ALL copies of a given Turing Machine, given the same
>>>>>>> input, will do the same thing.
>>
>>>>> They are at different levels of recursive invocation thus the
>>>>> outermost
>>>>> one sees the abort criteria first and then aborts all the rest.
>>
>>>> Thus incorrectly aborting them.  They are terminating computations,
>>>> since
>>>> had the outermost level not aborted them, they would have reached a
>>>> terminating state (i.e., when the next level aborted).  So it is
>>>> wrong to
>>>> abort them and declare that they are non-halting.
>>
>>>> Can we not end this fruitless discussion now?  There is no halting
>>>> detector program, and there cannot be one.  We know that.
>>
>>
>>> This is my legacy before I die of cancer.
>>
>>> When-so-ever any simulating halt decider must abort the simulation of
>>> its input to prevent the infinite simulation of the input it always
>>> correctly rejects this input as non-halting.
>>
>> This isn't the situation here.  The purported halt decider DOESN'T need
>> to abort its target, since that target would have terminated of its own
>> accord.
>
> I have been through this dozens of times.
> There is nothing that you can say that is a correct rebuttal.
>
> Unless at least one of the instances of embedded_H aborts its simulation
> the simulation never stops.

Right, but by programming it either WILL or it WON'T. These two cases
each generate a DIFFERENT H^.

If it doesn't, it fails by not answering.

If it does, if fails by giving the wrong answer, as THAT H^ will halt.

>
>> So the purported halt decider falsely categorises its target as
>> non-halting.
>>
>>> Just like with infinite recursion when any of the recursive invocations
>>> is terminated the whole chain stops running. As long as at least one of
>>> these invocations must be aborted then the whole recursive chain was
>>> infinitely recursive.
>>
>> There's no "must" here.  The abortion is unnecessary, since the
>> apparently infinite chain would stop on its own, without the outermost
>> level aborting it.
>>
>>> --
>>> 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/22 10:44 AM, olcott wrote:
> On 3/20/2022 6:07 AM, Richard Damon wrote:
>> On 3/19/22 10:17 PM, olcott wrote:
>>> On 3/19/2022 8:50 PM, Richard Damon wrote:
>>>> On 3/19/22 9:31 PM, olcott wrote:
>>>>> On 3/19/2022 8:25 PM, Richard Damon wrote:
>>>>>> On 3/19/22 9:12 PM, olcott wrote:
>>>>>>> On 3/19/2022 8:04 PM, Richard Damon wrote:
>>>>>>>> On 3/19/22 8:51 PM, olcott wrote:
>>>>>>>>> On 3/19/2022 7:48 PM, Richard Damon wrote:
>>>>>>>>>>
>>>>>>>>>> On 3/19/22 8:24 PM, olcott wrote:
>>>>>>>>>>> On 3/19/2022 7:20 PM, Richard Damon wrote:
>>>>>>>>>>>> On 3/19/22 8:00 PM, olcott wrote:
>>>>>>>>>>>>> On 3/19/2022 6:57 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 3/19/22 7:47 PM, olcott wrote:
>>>>>>>>>>>>>>> Halting problem undecidability and infinitely nested
>>>>>>>>>>>>>>> simulation (V4)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> When a halt decider bases its halt status decision on the
>>>>>>>>>>>>>>> behavior of its simulated input then all of the
>>>>>>>>>>>>>>> conventional halting problem counter example inputs would
>>>>>>>>>>>>>>> be determined to be non-halting.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> A copy of Linz H is embedded at Ĥ.qx as a simulating halt
>>>>>>>>>>>>>>> decider (SHD).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>>>>>>> If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would
>>>>>>>>>>>>>>> reach its final state.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>>>>>> If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would
>>>>>>>>>>>>>>> never reach its final state.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *By these two principles this proof is validated*
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> (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.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The key point that that everyone (including Peter Linz)
>>>>>>>>>>>>>>> has an impossibly difficult time with is that embedded_H
>>>>>>>>>>>>>>> can correctly transition to Ĥ.qn indicting that its input
>>>>>>>>>>>>>>> does not halt.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Everyone (including Peter Linz) incorrectly believes that
>>>>>>>>>>>>>>> this is contradictory.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Everyone assumes the the behavior of the executed Ĥ
>>>>>>>>>>>>>>> applied ⟨Ĥ⟩ must be the same as the input ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>>>>>>>>> simulated by embedded_H or it is wrong.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> We can easily verify that the correct behavior of Ĥ
>>>>>>>>>>>>>>> applied ⟨Ĥ⟩ is not the same as the correct behavior as
>>>>>>>>>>>>>>> the input ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by embedded_H.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> No one ever bothers to do this because of their deep
>>>>>>>>>>>>>>> religious conviction that they must either be the same or
>>>>>>>>>>>>>>> be incorrect.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> https://www.researchgate.net/publication/359349179_Halting_problem_undecidability_and_infinitely_nested_simulation_V4
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Just more of your Fairy Dust Powered Unicorns that do
>>>>>>>>>>>>>> magic to make imppssible things happen.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Just more UNSOUND LOGIC.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> FAIL.
>>>>>>>>>>>>>
>>>>>>>>>>>>> If you paid very close attention as if the salvation of
>>>>>>>>>>>>> your soul depended on the accuracy of your evaluation you
>>>>>>>>>>>>> would see that I have been correct all along.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> No, you logic in NONSENSE, you assert things without any
>>>>>>>>>>>> evidence.
>>>>>>>>>>>>
>>>>>>>>>>> I prove my point and you skip over the proof because you only
>>>>>>>>>>> want to play head games.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Really??
>>>>>>>>>>
>>>>>>>>>> One BIG lile is:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> (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.
>>>>>>>>>>
>>>>>>>>>> Because your SHD can't actually correctly simulate as a UTM
>>>>>>>>>> and abort it simulation at the same time.
>>>>>>>>>>
>>>>>>>>> That is like saying that a car cannot run because it cannot run
>>>>>>>>> and stop running at the same time.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Nope, just shows you still don't understand what a UTM is.
>>>>>>>>
>>>>>>>
>>>>>>> As long as the SHD can correctly simulate enough steps of its
>>>>>>> input to correctly detect an infinite behavior pattern then it
>>>>>>> can correctly reject its input on this basis because that means
>>>>>>> that the simulated input cannot possibly ever reach its own final
>>>>>>> state which conclusively proves that it specifies a non-halting
>>>>>>> sequence of configurations.
>>>>>>>
>>>>>>> People that are not dumber than a box of rocks will understand
>>>>>>> that the above is necessarily correct.
>>>>>>>
>>>>>>
>>>>>> Yes, if it CAN correcly simulate enough states of its input to
>>>>>> correctly detect an infinite behavior.
>>>>>>
>>>>>> The problem is that this is not guaranteed to exist. So you are
>>>>>> just beleiving in Fairy Dust Powered Unicorns to perform their magic.
>>>>>>
>>>>>
>>>>> 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⟩...
>>>>>
>>>>> You acknowledged that the above sequence proves proves infinite
>>>>> behavior. Thus you can I can both see that a transition to Ĥ.qn
>>>>> would be correct.
>>>>>
>>>>
>>>> It is ONLY an infinite sequence if NO embedded_H abort there
>>>> simulations,
>>>
>>> This is the part where the label of BRAIN DEAD MORON applies to you.
>>> As long as embedded_H correctly determines that its simulated input
>>> ⟨Ĥ⟩ ⟨Ĥ⟩ cannot possibly reach its final state embedded_H can
>>> correctly reject this input.
>>>
>>
>> Right, but it hasn't done that, and you seem to be too dumb to
>> understand why. It has (incorrectly) assumed that the copy of
>> embedded_H within all the simulated H^s will NEVER abort their
>> simulations, which they WILL do if we actually ran them, just like
>> this one is going to do.
>>
>> FALSE PREMISE, UNSOUND LOGIG, WRONG ANSWER.
>>
>>
>>> Since we can see that the simulated input to embedded_H cannot
>>> possibly reach its final state after three invocations that means
>>> that if embedded_H transitions to Ĥ.qn after three invocations then
>>> we know it would be correct.
>>>
>>
>> No, because when it does that, it breaks its assumption that the
>> embedded_H in H^s will never abort their simulations. It failed to
>> notice THEIR abort counter counting.
>>
>> You forgert that ALL copies of a given Turing Machine, given the same
>> input, will do the same thing.
>>
>
> 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.
>

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é

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

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.

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

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

On 3/20/22 3:12 PM, 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.

Except that if we look at the behavior of that string with embedded_H
having that pattern in it is that H^ applied to <H^> will halt as does
UTM applied to <H^> <H^> so BY THE DEFINITION OF HALTING, it represents
a HALTING pattern.

This is EXACTLY the case that I showed a 'trace' of a few days ago which
shows how that computation does Halt.

Only by YOU INCORRECT definition of 'Halting' do you get your result.

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

Except that you are again confusing the SIMULATION of the computation
with the actual computation.

If embedded_H applied to <H^> <H^> aborts its simulation at that point
and goes to Qn and the copy of H^ that is using in it Halts, then BY
DEFINITION, <H^> <H^> represents THAT Halting Computation, whether or
not any 'simulator' actually simulates it'

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

Nope, because no infinite simulate actually happens with ANY pure
simulator (aka UTM) which BY DEFINITION NEVER aborts its simulation, the
ALL will terminate after a finite number of cycles.

Peter Olcott wrote:
....
>> Can we not end this fruitless discussion now?  There is no halting
>> detector program, and there cannot be one.  We know that.
>>
>
> This is my legacy before I die of cancer.

The legacy of being known as an abuser and a crank?

Not funny.

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.

Because embedded_H is the master UTM all of these finite strings would
be somewhere on its own tape.

We also know that when a function calls a copy of itself with identical
input that this is infinite recursion.

Therefore we know that Ĥ is applied to ⟨Ĥ⟩ specifies infinite behavior
thus we know that if embedded_H rejected its input it would be correct.

This by itself refutes the Linz conclusion that a contradiction is
necessarily formed. Refuting the conclusion of a proof refutes the proof.

--
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/22 7:50 PM, 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.
>
> Because embedded_H is the master UTM all of these finite strings would
> be somewhere on its own tape.

No, it isn't. First, BY DEFINITION, a UTM will NEVER abort a simulation,
PERIOD.

Second, the top H^ applied to <H^> ISN'T under the control of a simulation.

We are NOT is some crippled system where all Turing Machines are run by
some master UTM. So, FAIL

>
> We also know that when a function calls a copy of itself with identical
> input that this is infinite recursion.

If it was an ACTUAL call (which means no option of aborting), then yes.
But embedded_H doesn't actually 'call' its input, or it would not be
able to 'abort' its simulation.

>
> Therefore we know that Ĥ is applied to ⟨Ĥ⟩ specifies infinite behavior
> thus we know that if embedded_H rejected its input it would be correct.

ONLY in the case above, where embedded_H can't abort the simulation. If
thats you case the embedded_H just fails to be a Decider at all.

>
> This by itself refutes the Linz conclusion that a contradiction is
> necessarily formed. Refuting the conclusion of a proof refutes the proof.
>
>

Nope, something that doesn't decide can't be a counter example for a
Halt Decider being correct.

FAIL.

On 3/20/2022 11:47 AM, Richard Damon wrote:
> On 3/20/22 10:44 AM, olcott wrote:
>> On 3/20/2022 6:07 AM, Richard Damon wrote:
>>> On 3/19/22 10:17 PM, olcott wrote:
>>>> On 3/19/2022 8:50 PM, Richard Damon wrote:
>>>>> On 3/19/22 9:31 PM, olcott wrote:
>>>>>> On 3/19/2022 8:25 PM, Richard Damon wrote:
>>>>>>> On 3/19/22 9:12 PM, olcott wrote:
>>>>>>>> On 3/19/2022 8:04 PM, Richard Damon wrote:
>>>>>>>>> On 3/19/22 8:51 PM, olcott wrote:
>>>>>>>>>> On 3/19/2022 7:48 PM, Richard Damon wrote:
>>>>>>>>>>>
>>>>>>>>>>> On 3/19/22 8:24 PM, olcott wrote:
>>>>>>>>>>>> On 3/19/2022 7:20 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 3/19/22 8:00 PM, olcott wrote:
>>>>>>>>>>>>>> On 3/19/2022 6:57 PM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 3/19/22 7:47 PM, olcott wrote:
>>>>>>>>>>>>>>>> Halting problem undecidability and infinitely nested
>>>>>>>>>>>>>>>> simulation (V4)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> When a halt decider bases its halt status decision on
>>>>>>>>>>>>>>>> the behavior of its simulated input then all of the
>>>>>>>>>>>>>>>> conventional halting problem counter example inputs
>>>>>>>>>>>>>>>> would be determined to be non-halting.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> A copy of Linz H is embedded at Ĥ.qx as a simulating
>>>>>>>>>>>>>>>> halt decider (SHD).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>>>>>>>> If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would
>>>>>>>>>>>>>>>> reach its final state.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>>>>>>> If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would
>>>>>>>>>>>>>>>> never reach its final state.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> *By these two principles this proof is validated*
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> (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.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The key point that that everyone (including Peter Linz)
>>>>>>>>>>>>>>>> has an impossibly difficult time with is that embedded_H
>>>>>>>>>>>>>>>> can correctly transition to Ĥ.qn indicting that its
>>>>>>>>>>>>>>>> input does not halt.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Everyone (including Peter Linz) incorrectly believes
>>>>>>>>>>>>>>>> that this is contradictory.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Everyone assumes the the behavior of the executed Ĥ
>>>>>>>>>>>>>>>> applied ⟨Ĥ⟩ must be the same as the input ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>>>>>>>>>> simulated by embedded_H or it is wrong.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> We can easily verify that the correct behavior of Ĥ
>>>>>>>>>>>>>>>> applied ⟨Ĥ⟩ is not the same as the correct behavior as
>>>>>>>>>>>>>>>> the input ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by embedded_H.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> No one ever bothers to do this because of their deep
>>>>>>>>>>>>>>>> religious conviction that they must either be the same
>>>>>>>>>>>>>>>> or be incorrect.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> https://www.researchgate.net/publication/359349179_Halting_problem_undecidability_and_infinitely_nested_simulation_V4
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Just more of your Fairy Dust Powered Unicorns that do
>>>>>>>>>>>>>>> magic to make imppssible things happen.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Just more UNSOUND LOGIC.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> FAIL.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If you paid very close attention as if the salvation of
>>>>>>>>>>>>>> your soul depended on the accuracy of your evaluation you
>>>>>>>>>>>>>> would see that I have been correct all along.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> No, you logic in NONSENSE, you assert things without any
>>>>>>>>>>>>> evidence.
>>>>>>>>>>>>>
>>>>>>>>>>>> I prove my point and you skip over the proof because you
>>>>>>>>>>>> only want to play head games.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Really??
>>>>>>>>>>>
>>>>>>>>>>> One BIG lile is:
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> (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.
>>>>>>>>>>>
>>>>>>>>>>> Because your SHD can't actually correctly simulate as a UTM
>>>>>>>>>>> and abort it simulation at the same time.
>>>>>>>>>>>
>>>>>>>>>> That is like saying that a car cannot run because it cannot
>>>>>>>>>> run and stop running at the same time.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Nope, just shows you still don't understand what a UTM is.
>>>>>>>>>
>>>>>>>>
>>>>>>>> As long as the SHD can correctly simulate enough steps of its
>>>>>>>> input to correctly detect an infinite behavior pattern then it
>>>>>>>> can correctly reject its input on this basis because that means
>>>>>>>> that the simulated input cannot possibly ever reach its own
>>>>>>>> final state which conclusively proves that it specifies a
>>>>>>>> non-halting sequence of configurations.
>>>>>>>>
>>>>>>>> People that are not dumber than a box of rocks will understand
>>>>>>>> that the above is necessarily correct.
>>>>>>>>
>>>>>>>
>>>>>>> Yes, if it CAN correcly simulate enough states of its input to
>>>>>>> correctly detect an infinite behavior.
>>>>>>>
>>>>>>> The problem is that this is not guaranteed to exist. So you are
>>>>>>> just beleiving in Fairy Dust Powered Unicorns to perform their
>>>>>>> magic.
>>>>>>>
>>>>>>
>>>>>> 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⟩...
>>>>>>
>>>>>> You acknowledged that the above sequence proves proves infinite
>>>>>> behavior. Thus you can I can both see that a transition to Ĥ.qn
>>>>>> would be correct.
>>>>>>
>>>>>
>>>>> It is ONLY an infinite sequence if NO embedded_H abort there
>>>>> simulations,
>>>>
>>>> This is the part where the label of BRAIN DEAD MORON applies to you.
>>>> As long as embedded_H correctly determines that its simulated input
>>>> ⟨Ĥ⟩ ⟨Ĥ⟩ cannot possibly reach its final state embedded_H can
>>>> correctly reject this input.
>>>>
>>>
>>> Right, but it hasn't done that, and you seem to be too dumb to
>>> understand why. It has (incorrectly) assumed that the copy of
>>> embedded_H within all the simulated H^s will NEVER abort their
>>> simulations, which they WILL do if we actually ran them, just like
>>> this one is going to do.
>>>
>>> FALSE PREMISE, UNSOUND LOGIG, WRONG ANSWER.
>>>
>>>
>>>> Since we can see that the simulated input to embedded_H cannot
>>>> possibly reach its final state after three invocations that means
>>>> that if embedded_H transitions to Ĥ.qn after three invocations then
>>>> we know it would be correct.
>>>>
>>>
>>> No, because when it does that, it breaks its assumption that the
>>> embedded_H in H^s will never abort their simulations. It failed to
>>> notice THEIR abort counter counting.
>>>
>>> You forgert that ALL copies of a given Turing Machine, given the same
>>> input, will do the same thing.
>>>
>>
>> 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.
>>
>
> Nope, you still don't understand the the BEHAVIOR represented by the
> input is NOT based on what the partial simulator does, but by what the
> machine represented by the input would actually do, which is the
> equivalent of what an ACTUAL UTM (which will NEVER abort its simulation)
> would do.
>
> The fact that embedded_H never simulated embedded_H0 doesn't mean that
> the behavior of <H^0> <H^1> doesn't include its exectution.
>
> Your refusal to see this is just proof that you just don't understand
> what Computation Theory and Turing Machines are about.
>
> FAIL.

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.

André

> Therefore we know that Ĥ is applied to ⟨Ĥ⟩ specifies infinite behavior
> thus we know that if embedded_H rejected its input it would be correct.
>
> This by itself refutes the Linz conclusion that a contradiction is
> necessarily formed. Refuting the conclusion of a proof refutes the proof.
>
>

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

On 3/20/22 8:59 PM, olcott wrote:
> On 3/20/2022 11:47 AM, Richard Damon wrote:
>> On 3/20/22 10:44 AM, olcott wrote:
>>> On 3/20/2022 6:07 AM, Richard Damon wrote:
>>>> On 3/19/22 10:17 PM, olcott wrote:
>>>>> On 3/19/2022 8:50 PM, Richard Damon wrote:
>>>>>> On 3/19/22 9:31 PM, olcott wrote:
>>>>>>> On 3/19/2022 8:25 PM, Richard Damon wrote:
>>>>>>>> On 3/19/22 9:12 PM, olcott wrote:
>>>>>>>>> On 3/19/2022 8:04 PM, Richard Damon wrote:
>>>>>>>>>> On 3/19/22 8:51 PM, olcott wrote:
>>>>>>>>>>> On 3/19/2022 7:48 PM, Richard Damon wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> On 3/19/22 8:24 PM, olcott wrote:
>>>>>>>>>>>>> On 3/19/2022 7:20 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 3/19/22 8:00 PM, olcott wrote:
>>>>>>>>>>>>>>> On 3/19/2022 6:57 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 3/19/22 7:47 PM, olcott wrote:
>>>>>>>>>>>>>>>>> Halting problem undecidability and infinitely nested
>>>>>>>>>>>>>>>>> simulation (V4)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> When a halt decider bases its halt status decision on
>>>>>>>>>>>>>>>>> the behavior of its simulated input then all of the
>>>>>>>>>>>>>>>>> conventional halting problem counter example inputs
>>>>>>>>>>>>>>>>> would be determined to be non-halting.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> A copy of Linz H is embedded at Ĥ.qx as a simulating
>>>>>>>>>>>>>>>>> halt decider (SHD).
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>>>>>>>>> If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would
>>>>>>>>>>>>>>>>> reach its final state.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>>>>>>>> If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would
>>>>>>>>>>>>>>>>> never reach its final state.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> *By these two principles this proof is validated*
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> (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.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The key point that that everyone (including Peter Linz)
>>>>>>>>>>>>>>>>> has an impossibly difficult time with is that
>>>>>>>>>>>>>>>>> embedded_H can correctly transition to Ĥ.qn indicting
>>>>>>>>>>>>>>>>> that its input does not halt.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Everyone (including Peter Linz) incorrectly believes
>>>>>>>>>>>>>>>>> that this is contradictory.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Everyone assumes the the behavior of the executed Ĥ
>>>>>>>>>>>>>>>>> applied ⟨Ĥ⟩ must be the same as the input ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>>>>>>>>>>> simulated by embedded_H or it is wrong.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> We can easily verify that the correct behavior of Ĥ
>>>>>>>>>>>>>>>>> applied ⟨Ĥ⟩ is not the same as the correct behavior as
>>>>>>>>>>>>>>>>> the input ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by embedded_H.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> No one ever bothers to do this because of their deep
>>>>>>>>>>>>>>>>> religious conviction that they must either be the same
>>>>>>>>>>>>>>>>> or be incorrect.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> https://www.researchgate.net/publication/359349179_Halting_problem_undecidability_and_infinitely_nested_simulation_V4
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Just more of your Fairy Dust Powered Unicorns that do
>>>>>>>>>>>>>>>> magic to make imppssible things happen.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Just more UNSOUND LOGIC.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> FAIL.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If you paid very close attention as if the salvation of
>>>>>>>>>>>>>>> your soul depended on the accuracy of your evaluation you
>>>>>>>>>>>>>>> would see that I have been correct all along.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> No, you logic in NONSENSE, you assert things without any
>>>>>>>>>>>>>> evidence.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> I prove my point and you skip over the proof because you
>>>>>>>>>>>>> only want to play head games.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Really??
>>>>>>>>>>>>
>>>>>>>>>>>> One BIG lile is:
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> (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.
>>>>>>>>>>>>
>>>>>>>>>>>> Because your SHD can't actually correctly simulate as a UTM
>>>>>>>>>>>> and abort it simulation at the same time.
>>>>>>>>>>>>
>>>>>>>>>>> That is like saying that a car cannot run because it cannot
>>>>>>>>>>> run and stop running at the same time.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Nope, just shows you still don't understand what a UTM is.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> As long as the SHD can correctly simulate enough steps of its
>>>>>>>>> input to correctly detect an infinite behavior pattern then it
>>>>>>>>> can correctly reject its input on this basis because that means
>>>>>>>>> that the simulated input cannot possibly ever reach its own
>>>>>>>>> final state which conclusively proves that it specifies a
>>>>>>>>> non-halting sequence of configurations.
>>>>>>>>>
>>>>>>>>> People that are not dumber than a box of rocks will understand
>>>>>>>>> that the above is necessarily correct.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Yes, if it CAN correcly simulate enough states of its input to
>>>>>>>> correctly detect an infinite behavior.
>>>>>>>>
>>>>>>>> The problem is that this is not guaranteed to exist. So you are
>>>>>>>> just beleiving in Fairy Dust Powered Unicorns to perform their
>>>>>>>> magic.
>>>>>>>>
>>>>>>>
>>>>>>> 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⟩...
>>>>>>>
>>>>>>> You acknowledged that the above sequence proves proves infinite
>>>>>>> behavior. Thus you can I can both see that a transition to Ĥ.qn
>>>>>>> would be correct.
>>>>>>>
>>>>>>
>>>>>> It is ONLY an infinite sequence if NO embedded_H abort there
>>>>>> simulations,
>>>>>
>>>>> This is the part where the label of BRAIN DEAD MORON applies to you.
>>>>> As long as embedded_H correctly determines that its simulated input
>>>>> ⟨Ĥ⟩ ⟨Ĥ⟩ cannot possibly reach its final state embedded_H can
>>>>> correctly reject this input.
>>>>>
>>>>
>>>> Right, but it hasn't done that, and you seem to be too dumb to
>>>> understand why. It has (incorrectly) assumed that the copy of
>>>> embedded_H within all the simulated H^s will NEVER abort their
>>>> simulations, which they WILL do if we actually ran them, just like
>>>> this one is going to do.
>>>>
>>>> FALSE PREMISE, UNSOUND LOGIG, WRONG ANSWER.
>>>>
>>>>
>>>>> Since we can see that the simulated input to embedded_H cannot
>>>>> possibly reach its final state after three invocations that means
>>>>> that if embedded_H transitions to Ĥ.qn after three invocations then
>>>>> we know it would be correct.
>>>>>
>>>>
>>>> No, because when it does that, it breaks its assumption that the
>>>> embedded_H in H^s will never abort their simulations. It failed to
>>>> notice THEIR abort counter counting.
>>>>
>>>> You forgert that ALL copies of a given Turing Machine, given the
>>>> same input, will do the same thing.
>>>>
>>>
>>> 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.
>>>
>>
>> Nope, you still don't understand the the BEHAVIOR represented by the
>> input is NOT based on what the partial simulator does, but by what the
>> machine represented by the input would actually do, which is the
>> equivalent of what an ACTUAL UTM (which will NEVER abort its
>> simulation) would do.
>>
>> The fact that embedded_H never simulated embedded_H0 doesn't mean that
>> the behavior of <H^0> <H^1> doesn't include its exectution.
>>
>> Your refusal to see this is just proof that you just don't understand
>> what Computation Theory and Turing Machines are about.
>>
>> FAIL.
>
> By these two principles this proof is validated:
>
> (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.

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.

--
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 8:19 PM, Richard Damon wrote:
> On 3/20/22 8:59 PM, olcott wrote:
>> On 3/20/2022 11:47 AM, Richard Damon wrote:
>>> On 3/20/22 10:44 AM, olcott wrote:
>>>> On 3/20/2022 6:07 AM, Richard Damon wrote:
>>>>> On 3/19/22 10:17 PM, olcott wrote:
>>>>>> On 3/19/2022 8:50 PM, Richard Damon wrote:
>>>>>>> On 3/19/22 9:31 PM, olcott wrote:
>>>>>>>> On 3/19/2022 8:25 PM, Richard Damon wrote:
>>>>>>>>> On 3/19/22 9:12 PM, olcott wrote:
>>>>>>>>>> On 3/19/2022 8:04 PM, Richard Damon wrote:
>>>>>>>>>>> On 3/19/22 8:51 PM, olcott wrote:
>>>>>>>>>>>> On 3/19/2022 7:48 PM, Richard Damon wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 3/19/22 8:24 PM, olcott wrote:
>>>>>>>>>>>>>> On 3/19/2022 7:20 PM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 3/19/22 8:00 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 3/19/2022 6:57 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>> On 3/19/22 7:47 PM, olcott wrote:
>>>>>>>>>>>>>>>>>> Halting problem undecidability and infinitely nested
>>>>>>>>>>>>>>>>>> simulation (V4)
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> When a halt decider bases its halt status decision on
>>>>>>>>>>>>>>>>>> the behavior of its simulated input then all of the
>>>>>>>>>>>>>>>>>> conventional halting problem counter example inputs
>>>>>>>>>>>>>>>>>> would be determined to be non-halting.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> A copy of Linz H is embedded at Ĥ.qx as a simulating
>>>>>>>>>>>>>>>>>> halt decider (SHD).
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>>>>>>>>>> If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would
>>>>>>>>>>>>>>>>>> reach its final state.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>>>>>>>>> If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would
>>>>>>>>>>>>>>>>>> never reach its final state.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> *By these two principles this proof is validated*
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> (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.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The key point that that everyone (including Peter
>>>>>>>>>>>>>>>>>> Linz) has an impossibly difficult time with is that
>>>>>>>>>>>>>>>>>> embedded_H can correctly transition to Ĥ.qn indicting
>>>>>>>>>>>>>>>>>> that its input does not halt.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Everyone (including Peter Linz) incorrectly believes
>>>>>>>>>>>>>>>>>> that this is contradictory.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Everyone assumes the the behavior of the executed Ĥ
>>>>>>>>>>>>>>>>>> applied ⟨Ĥ⟩ must be the same as the input ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>>>>>>>>>>>> simulated by embedded_H or it is wrong.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> We can easily verify that the correct behavior of Ĥ
>>>>>>>>>>>>>>>>>> applied ⟨Ĥ⟩ is not the same as the correct behavior as
>>>>>>>>>>>>>>>>>> the input ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by embedded_H.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> No one ever bothers to do this because of their deep
>>>>>>>>>>>>>>>>>> religious conviction that they must either be the same
>>>>>>>>>>>>>>>>>> or be incorrect.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> https://www.researchgate.net/publication/359349179_Halting_problem_undecidability_and_infinitely_nested_simulation_V4
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Just more of your Fairy Dust Powered Unicorns that do
>>>>>>>>>>>>>>>>> magic to make imppssible things happen.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Just more UNSOUND LOGIC.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> FAIL.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> If you paid very close attention as if the salvation of
>>>>>>>>>>>>>>>> your soul depended on the accuracy of your evaluation
>>>>>>>>>>>>>>>> you would see that I have been correct all along.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> No, you logic in NONSENSE, you assert things without any
>>>>>>>>>>>>>>> evidence.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I prove my point and you skip over the proof because you
>>>>>>>>>>>>>> only want to play head games.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Really??
>>>>>>>>>>>>>
>>>>>>>>>>>>> One BIG lile is:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> (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.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Because your SHD can't actually correctly simulate as a UTM
>>>>>>>>>>>>> and abort it simulation at the same time.
>>>>>>>>>>>>>
>>>>>>>>>>>> That is like saying that a car cannot run because it cannot
>>>>>>>>>>>> run and stop running at the same time.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Nope, just shows you still don't understand what a UTM is.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> As long as the SHD can correctly simulate enough steps of its
>>>>>>>>>> input to correctly detect an infinite behavior pattern then it
>>>>>>>>>> can correctly reject its input on this basis because that
>>>>>>>>>> means that the simulated input cannot possibly ever reach its
>>>>>>>>>> own final state which conclusively proves that it specifies a
>>>>>>>>>> non-halting sequence of configurations.
>>>>>>>>>>
>>>>>>>>>> People that are not dumber than a box of rocks will understand
>>>>>>>>>> that the above is necessarily correct.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Yes, if it CAN correcly simulate enough states of its input to
>>>>>>>>> correctly detect an infinite behavior.
>>>>>>>>>
>>>>>>>>> The problem is that this is not guaranteed to exist. So you are
>>>>>>>>> just beleiving in Fairy Dust Powered Unicorns to perform their
>>>>>>>>> magic.
>>>>>>>>>
>>>>>>>>
>>>>>>>> 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⟩...
>>>>>>>>
>>>>>>>> You acknowledged that the above sequence proves proves infinite
>>>>>>>> behavior. Thus you can I can both see that a transition to Ĥ.qn
>>>>>>>> would be correct.
>>>>>>>>
>>>>>>>
>>>>>>> It is ONLY an infinite sequence if NO embedded_H abort there
>>>>>>> simulations,
>>>>>>
>>>>>> This is the part where the label of BRAIN DEAD MORON applies to you.
>>>>>> As long as embedded_H correctly determines that its simulated
>>>>>> input ⟨Ĥ⟩ ⟨Ĥ⟩ cannot possibly reach its final state embedded_H can
>>>>>> correctly reject this input.
>>>>>>
>>>>>
>>>>> Right, but it hasn't done that, and you seem to be too dumb to
>>>>> understand why. It has (incorrectly) assumed that the copy of
>>>>> embedded_H within all the simulated H^s will NEVER abort their
>>>>> simulations, which they WILL do if we actually ran them, just like
>>>>> this one is going to do.
>>>>>
>>>>> FALSE PREMISE, UNSOUND LOGIG, WRONG ANSWER.
>>>>>
>>>>>
>>>>>> Since we can see that the simulated input to embedded_H cannot
>>>>>> possibly reach its final state after three invocations that means
>>>>>> that if embedded_H transitions to Ĥ.qn after three invocations
>>>>>> then we know it would be correct.
>>>>>>
>>>>>
>>>>> No, because when it does that, it breaks its assumption that the
>>>>> embedded_H in H^s will never abort their simulations. It failed to
>>>>> notice THEIR abort counter counting.
>>>>>
>>>>> You forgert that ALL copies of a given Turing Machine, given the
>>>>> same input, will do the same thing.
>>>>>
>>>>
>>>> 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.
>>>>
>>>
>>> Nope, you still don't understand the the BEHAVIOR represented by the
>>> input is NOT based on what the partial simulator does, but by what
>>> the machine represented by the input would actually do, which is the
>>> equivalent of what an ACTUAL UTM (which will NEVER abort its
>>> simulation) would do.
>>>
>>> The fact that embedded_H never simulated embedded_H0 doesn't mean
>>> that the behavior of <H^0> <H^1> doesn't include its exectution.
>>>
>>> Your refusal to see this is just proof that you just don't understand
>>> what Computation Theory and Turing Machines are about.
>>>
>>> FAIL.
>>
>> By these two principles this proof is validated:
>>
>> (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.
>
> Right, BASED on the Mapping function, which is DEFINED to be based on
> the behavior of the Turing Machine/Input descirbed.

On 3/20/22 9:42 PM, olcott wrote:
> On 3/20/2022 8:19 PM, Richard Damon wrote:
>> On 3/20/22 8:59 PM, olcott wrote:
>>> On 3/20/2022 11:47 AM, Richard Damon wrote:
>>>> On 3/20/22 10:44 AM, olcott wrote:
>>>>> On 3/20/2022 6:07 AM, Richard Damon wrote:
>>>>>> On 3/19/22 10:17 PM, olcott wrote:
>>>>>>> On 3/19/2022 8:50 PM, Richard Damon wrote:
>>>>>>>> On 3/19/22 9:31 PM, olcott wrote:
>>>>>>>>> On 3/19/2022 8:25 PM, Richard Damon wrote:
>>>>>>>>>> On 3/19/22 9:12 PM, olcott wrote:
>>>>>>>>>>> On 3/19/2022 8:04 PM, Richard Damon wrote:
>>>>>>>>>>>> On 3/19/22 8:51 PM, olcott wrote:
>>>>>>>>>>>>> On 3/19/2022 7:48 PM, Richard Damon wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 3/19/22 8:24 PM, olcott wrote:
>>>>>>>>>>>>>>> On 3/19/2022 7:20 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 3/19/22 8:00 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 3/19/2022 6:57 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>> On 3/19/22 7:47 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>> Halting problem undecidability and infinitely nested
>>>>>>>>>>>>>>>>>>> simulation (V4)
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> When a halt decider bases its halt status decision on
>>>>>>>>>>>>>>>>>>> the behavior of its simulated input then all of the
>>>>>>>>>>>>>>>>>>> conventional halting problem counter example inputs
>>>>>>>>>>>>>>>>>>> would be determined to be non-halting.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> A copy of Linz H is embedded at Ĥ.qx as a simulating
>>>>>>>>>>>>>>>>>>> halt decider (SHD).
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>>>>>>>>>>> If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would
>>>>>>>>>>>>>>>>>>> reach its final state.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>>>>>>>>>> If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would
>>>>>>>>>>>>>>>>>>> never reach its final state.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> *By these two principles this proof is validated*
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> (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.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The key point that that everyone (including Peter
>>>>>>>>>>>>>>>>>>> Linz) has an impossibly difficult time with is that
>>>>>>>>>>>>>>>>>>> embedded_H can correctly transition to Ĥ.qn indicting
>>>>>>>>>>>>>>>>>>> that its input does not halt.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Everyone (including Peter Linz) incorrectly believes
>>>>>>>>>>>>>>>>>>> that this is contradictory.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Everyone assumes the the behavior of the executed Ĥ
>>>>>>>>>>>>>>>>>>> applied ⟨Ĥ⟩ must be the same as the input ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>>>>>>>>>>>>> simulated by embedded_H or it is wrong.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> We can easily verify that the correct behavior of Ĥ
>>>>>>>>>>>>>>>>>>> applied ⟨Ĥ⟩ is not the same as the correct behavior
>>>>>>>>>>>>>>>>>>> as the input ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by embedded_H.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> No one ever bothers to do this because of their deep
>>>>>>>>>>>>>>>>>>> religious conviction that they must either be the
>>>>>>>>>>>>>>>>>>> same or be incorrect.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> https://www.researchgate.net/publication/359349179_Halting_problem_undecidability_and_infinitely_nested_simulation_V4
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Just more of your Fairy Dust Powered Unicorns that do
>>>>>>>>>>>>>>>>>> magic to make imppssible things happen.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Just more UNSOUND LOGIC.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> FAIL.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> If you paid very close attention as if the salvation of
>>>>>>>>>>>>>>>>> your soul depended on the accuracy of your evaluation
>>>>>>>>>>>>>>>>> you would see that I have been correct all along.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> No, you logic in NONSENSE, you assert things without any
>>>>>>>>>>>>>>>> evidence.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I prove my point and you skip over the proof because you
>>>>>>>>>>>>>>> only want to play head games.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Really??
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> One BIG lile is:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> (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.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Because your SHD can't actually correctly simulate as a
>>>>>>>>>>>>>> UTM and abort it simulation at the same time.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> That is like saying that a car cannot run because it cannot
>>>>>>>>>>>>> run and stop running at the same time.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Nope, just shows you still don't understand what a UTM is.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> As long as the SHD can correctly simulate enough steps of its
>>>>>>>>>>> input to correctly detect an infinite behavior pattern then
>>>>>>>>>>> it can correctly reject its input on this basis because that
>>>>>>>>>>> means that the simulated input cannot possibly ever reach its
>>>>>>>>>>> own final state which conclusively proves that it specifies a
>>>>>>>>>>> non-halting sequence of configurations.
>>>>>>>>>>>
>>>>>>>>>>> People that are not dumber than a box of rocks will
>>>>>>>>>>> understand that the above is necessarily correct.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Yes, if it CAN correcly simulate enough states of its input to
>>>>>>>>>> correctly detect an infinite behavior.
>>>>>>>>>>
>>>>>>>>>> The problem is that this is not guaranteed to exist. So you
>>>>>>>>>> are just beleiving in Fairy Dust Powered Unicorns to perform
>>>>>>>>>> their magic.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 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⟩...
>>>>>>>>>
>>>>>>>>> You acknowledged that the above sequence proves proves infinite
>>>>>>>>> behavior. Thus you can I can both see that a transition to Ĥ.qn
>>>>>>>>> would be correct.
>>>>>>>>>
>>>>>>>>
>>>>>>>> It is ONLY an infinite sequence if NO embedded_H abort there
>>>>>>>> simulations,
>>>>>>>
>>>>>>> This is the part where the label of BRAIN DEAD MORON applies to you.
>>>>>>> As long as embedded_H correctly determines that its simulated
>>>>>>> input ⟨Ĥ⟩ ⟨Ĥ⟩ cannot possibly reach its final state embedded_H
>>>>>>> can correctly reject this input.
>>>>>>>
>>>>>>
>>>>>> Right, but it hasn't done that, and you seem to be too dumb to
>>>>>> understand why. It has (incorrectly) assumed that the copy of
>>>>>> embedded_H within all the simulated H^s will NEVER abort their
>>>>>> simulations, which they WILL do if we actually ran them, just like
>>>>>> this one is going to do.
>>>>>>
>>>>>> FALSE PREMISE, UNSOUND LOGIG, WRONG ANSWER.
>>>>>>
>>>>>>
>>>>>>> Since we can see that the simulated input to embedded_H cannot
>>>>>>> possibly reach its final state after three invocations that means
>>>>>>> that if embedded_H transitions to Ĥ.qn after three invocations
>>>>>>> then we know it would be correct.
>>>>>>>
>>>>>>
>>>>>> No, because when it does that, it breaks its assumption that the
>>>>>> embedded_H in H^s will never abort their simulations. It failed to
>>>>>> notice THEIR abort counter counting.
>>>>>>
>>>>>> You forgert that ALL copies of a given Turing Machine, given the
>>>>>> same input, will do the same thing.
>>>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>
>>>> Nope, you still don't understand the the BEHAVIOR represented by the
>>>> input is NOT based on what the partial simulator does, but by what
>>>> the machine represented by the input would actually do, which is the
>>>> equivalent of what an ACTUAL UTM (which will NEVER abort its
>>>> simulation) would do.
>>>>
>>>> The fact that embedded_H never simulated embedded_H0 doesn't mean
>>>> that the behavior of <H^0> <H^1> doesn't include its exectution.
>>>>
>>>> Your refusal to see this is just proof that you just don't
>>>> understand what Computation Theory and Turing Machines are about.
>>>>
>>>> FAIL.
>>>
>>> By these two principles this proof is validated:
>>>
>>> (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.
>>
>> Right, BASED on the Mapping function, which is DEFINED to be based on
>> the behavior of the Turing Machine/Input descirbed.
>
> So in other words you are saying the the correct simulation of ⟨Ĥ⟩ ⟨Ĥ⟩
> by embedded_H is incorrect even though it is correct?

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.

Consider a second Turing Machine, PD. PD is a Turing machine which takes
as its input a string and accepts that string if and only if it is a
palindrome.

Now, consider the following:

(1) embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(2) embedded_H ⟨PD⟩ ⟨PD⟩

What string comparison does embedded_H perform which allows it to
determine that (1) is recursive whereas (2) is not?

André

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

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.

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.

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

--
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/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, because the DEFINITION of the Halt Decider is
based on the Machine whose description it was given.

Remember the DEFINITION for H which embedded_H inherets:

H applied to <M> w goes to Qy iff M applied to w Halts, and
H applied to <M> w goes to Qn iff M applied to w Halts.

Since M is H^, and w is <H^> and H^ applied to <H^> Halts, because the
embedded_H in to goes to Qn when applied to <H^> <H^>, this means that
the REQURIED behavior is going to Qy, which it did not do.

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.

You not only failed to answer my question but snipped it entirely. I
have restored it for you:

Consider a second Turing Machine, PD. PD is a Turing machine which takes
as its input a string and accepts that string if and only if it is a
palindrome.

Now, consider the following:

(1) embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(2) embedded_H ⟨PD⟩ ⟨PD⟩

What string comparison does embedded_H perform which allows it to
determine that (1) is recursive whereas (2) is not?

Unless embedded_H has some way of recognizing that Ĥ contains a copy of
embedded_H whereas PD does not, how can it recognize recursion? Which
two strings does it compare to determine this?

I know that you don't actually grasp anything about Turing Machines, but
what you claim to be doing is no less possible than writing the
following C function:

Boolean foo(char* String) {

// return true if String contains the source code of foo as a substring
// and false otherwise

}

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

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,

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.

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

// REPEAT QUESTION

Consider a second Turing Machine, PD. PD is a Turing machine which takes
as its input a string and accepts that string if and only if it is a
palindrome.

Now, consider the following:

(1) embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(2) embedded_H ⟨PD⟩ ⟨PD⟩

What string comparison does embedded_H perform which allows it to
determine that (1) is recursive whereas (2) is not?

Unless embedded_H has some way of recognizing that Ĥ contains a copy of
embedded_H whereas PD does not, how can it recognize recursion? Which
two strings does it compare to determine this?

Note that I moved my question from another thread to this one at your
request. The least you can do is answer it.

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

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