On 3/16/2022 10:02 PM, Richard Damon wrote:
>
> On 3/16/22 10:04 PM, olcott wrote:
>> On 3/16/2022 8:54 PM, Richard Damon wrote:
>>> On 3/16/22 9:16 PM, olcott wrote:
>>>> On 3/16/2022 8:08 PM, Richard Damon wrote:
>>>>> On 3/16/22 8:51 PM, olcott wrote:
>>>>>> On 3/16/2022 7:47 PM, Richard Damon wrote:
>>>>>>> On 3/16/22 7:32 PM, olcott wrote:
>>>>>>>> On 3/16/2022 6:22 PM, Richard Damon wrote:
>>>>>>>>> On 3/16/22 6:56 PM, olcott wrote:
>>>>>>>>>> On 3/16/2022 5:41 PM, Richard Damon wrote:
>>>>>>>>>>> On 3/16/22 3:10 PM, olcott wrote:
>>>>>>>>>>>> On 3/16/2022 12:37 PM, Mike Terry wrote:
>>>>>>>>>>>>> On 16/03/2022 17:20, olcott wrote:
>>>>>>>>>>>>>> On 3/16/2022 12:04 PM, Mike Terry wrote:
>>>>>>>>>>>>>>> On 16/03/2022 14:15, olcott wrote:
>>>>>>>>>>>>>>>> On 3/16/2022 2:21 AM, Jeff Barnett wrote:
>>>>>>>>>>>>>>>>> On 3/15/2022 4:02 PM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 3/15/2022 4:48 PM, Jeff Barnett wrote:
>>>>>>>>>>>>>>>>>>> On 3/15/2022 1:44 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 3/15/2022 1:58 PM, Jeff Barnett wrote:
>>>>>>>>>>>>>>>>>>>>> On 3/15/2022 10:11 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>> On 3/15/2022 10:44 AM, Malcolm McLean wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>     <MAJOR SNIP>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> So how would you describe a compiler which is
>>>>>>>>>>>>>>>>>>>>>>> "bootstrapped", i.e. fed its own
>>>>>>>>>>>>>>>>>>>>>>> source code?
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> A compiler that is fed its own source-code is not
>>>>>>>>>>>>>>>>>>>>>> the same because the compiler does not execute
>>>>>>>>>>>>>>>>>>>>>> this source-code.
>>>>>>>>>>>>>>>>>>>>> This is one of your best Peter. Along the way
>>>>>>>>>>>>>>>>>>>>> you've had 100s of messages that have said that
>>>>>>>>>>>>>>>>>>>>> simulation as a basis for a Halting Problem
>>>>>>>>>>>>>>>>>>>>> solution is hopeless. Of course you pay no
>>>>>>>>>>>>>>>>>>>>> attention because it's unlikely you understood what
>>>>>>>>>>>>>>>>>>>>> you were being told. So here you are looping back
>>>>>>>>>>>>>>>>>>>>> over years of the same bone headed approach.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Let's start with a few basics:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Nothing executes source code; even an interpreter
>>>>>>>>>>>>>>>>>>>>> ingests it first.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> A compiler the compiles its own source-code is
>>>>>>>>>>>>>>>>>>>> nothing at all like executing this source code.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> You really do have rocks in your head. Think for at
>>>>>>>>>>>>>>>>>>> least 2 seconds before responding and getting it all
>>>>>>>>>>>>>>>>>>> wrong. The mistakes you are making with the above
>>>>>>>>>>>>>>>>>>> statement are so basic that I hardly know where to
>>>>>>>>>>>>>>>>>>> start. As I've been told many times it's harder to
>>>>>>>>>>>>>>>>>>> teach Kindergarten than grad students. And in this
>>>>>>>>>>>>>>>>>>> instance, with you, we have a sixty year old crawling
>>>>>>>>>>>>>>>>>>> around in diapers.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> An interpreter that interprets source code can be
>>>>>>>>>>>>>>>>>>>> reasonably construed as running this source code.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Perhaps. The issue is it really doesn't know that it
>>>>>>>>>>>>>>>>>>> is it's own source code, does it? And, in fact,
>>>>>>>>>>>>>>>>>>> neither it nor any observer is aware of any vicious
>>>>>>>>>>>>>>>>>>> self reference. Only a dunce would worry about it.
>>>>>>>>>>>>>>>>>>> You do worry don't you?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> In other words you are saying that no one is bright
>>>>>>>>>>>>>>>>>> enough to be able to detect what is essentially
>>>>>>>>>>>>>>>>>> infinite recursion.
>>>>>>>>>>>>>>>>> You soiled your diapers again. I said nothing of the
>>>>>>>>>>>>>>>>> sort. I will say it now though, nobody is intelligent
>>>>>>>>>>>>>>>>> enough to systematically (by algorithm) spot infinite
>>>>>>>>>>>>>>>>> recursion. God can't do it either. It's not
>>>>>>>>>>>>>>>>> theoretically possible. Only an ignorant nitwit would
>>>>>>>>>>>>>>>>> not know that and prattle on for years about it.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I already have a group of many experts that concur that
>>>>>>>>>>>>>>>> infinite recursion can be detected and the criterion
>>>>>>>>>>>>>>>> measure by which it is correctly detected.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'm afraid that you lack the intellect to understand
>>>>>>>>>>>>>>> exactly what other people are saying on technical issues.
>>>>>>>>>>>>>>> How many times have you quoted me (and others here) as
>>>>>>>>>>>>>>> supporting something you've claimed, whereas it turns out
>>>>>>>>>>>>>>> you had just misunderstood some remark that had been
>>>>>>>>>>>>>>> made? [Answer: lots of times!]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You also have a habit of going elsewhere, and "tricking"
>>>>>>>>>>>>>>> the people there into "agreeing" with some claim you've
>>>>>>>>>>>>>>> made here by not properly explaining the full context of
>>>>>>>>>>>>>>> your claim. Then you come back here selectively quoting
>>>>>>>>>>>>>>> some "expert" to suggest he is supporting you. [Like when
>>>>>>>>>>>>>>> you went to the x86 group and showed them your "trace"
>>>>>>>>>>>>>>> asking them if they could see what's going on, and got
>>>>>>>>>>>>>>> one of them to say "it's looping...".  You failed to
>>>>>>>>>>>>>>> mention the trace was not the "processor trace" they
>>>>>>>>>>>>>>> would naturally expect, and that there was simulation
>>>>>>>>>>>>>>> involved, and that your trace was in fact some kind of
>>>>>>>>>>>>>>> "merged simulation trace", and that you were using this
>>>>>>>>>>>>>>> trace to disprove the Halting Problem theorem.]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It's been pointed out to you many times that algorithms
>>>>>>>>>>>>>>> exhist that can identify /some/ infinite loops/recursions
>>>>>>>>>>>>>>> as such, but no algorithm detects ALL non-halting behaviour.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> And specifically, your test (looking for more than one
>>>>>>>>>>>>>>> call to a particular address etc.) is /unsound/ when you
>>>>>>>>>>>>>>> try to use it on your "merged simulation" trace.  No
>>>>>>>>>>>>>>> expert would say otherwise if they had been given the
>>>>>>>>>>>>>>> full context, so probably you've just tricked someone
>>>>>>>>>>>>>>> again...
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Mike.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> None-the-less is is self-evident that the input presented
>>>>>>>>>>>>>> to the copy of the Linz H embedded at Ĥ.qx does specify
>>>>>>>>>>>>>> infinitely nested simulation to simulating halt decider
>>>>>>>>>>>>>> embedded_H thus proving that a transition to Ĥ.qn by
>>>>>>>>>>>>>> embedded_H would be correct.
>>>>>>>>>>>>>
>>>>>>>>>>>>> You mean self-evident TO YOU.  To people who have an
>>>>>>>>>>>>> understanding of TMs it is simply wrong or meaningless
>>>>>>>>>>>>> (depending on how tolerant people are of your wishy-washy
>>>>>>>>>>>>> phrasing).
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Mike.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> They simply dogmatically state that the believe that I am
>>>>>>>>>>>> wrong about this yet cannot point to the specific error
>>>>>>>>>>>> because there is none:
>>>>>>>>>>>>
>>>>>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>>>>>>>    Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates
>>>>>>>>>>>> ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>>>>>>>>>>>
>>>>>>>>>>>> Then these steps would keep repeating:
>>>>>>>>>>>>    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H
>>>>>>>>>>>> simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>>>>>>>>>>>    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H
>>>>>>>>>>>> simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
>>>>>>>>>>>>    Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H
>>>>>>>>>>>> simulates ⟨Ĥ4⟩ ⟨Ĥ5⟩...
>>>>>>>>>>>>
>>>>>>>>>>>> The above repeating pattern shows that the correctly
>>>>>>>>>>>> simulated input to embedded_H would never reach its final
>>>>>>>>>>>> state of ⟨Ĥ⟩.qn conclusively proving that this simulated
>>>>>>>>>>>> input never halts. This enables embedded_H to abort its
>>>>>>>>>>>> simulation and correctly transition to Ĥ.qn.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The error has been pointed out to you many times, but you
>>>>>>>>>>> seem either too dumb or too dishonest to see/admit the error.
>>>>>>>>>>>
>>>>>>>>>> You cannot show that the simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to embedded_H
>>>>>>>>>> can possibly ever reach its own final state ⟨Ĥ⟩.qn in any
>>>>>>>>>> finite number of simulated steps YOU FREAKING BRAIN DEAD MORON!
>>>>>>>>>>
>>>>>>>>>> Ĥ.qn is not the final state of any simulated input:
>>>>>>>>>> YOU FREAKING BRAIN DEAD MORON!
>>>>>>>>>>
>>>>>>>>>> Ĥ.qn is only the final state of the simulating halt decider
>>>>>>>>>> YOU FREAKING BRAIN DEAD MORON!
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> But I CAN and HAVE proven that the CORRECT simulation of <H^>
>>>>>>>>> <H^> by an ACTUAL UTM does reach that state.
>>>>>>>> Not at all because you are a BRAIN DEAD MORON you are simply TOO
>>>>>>>> DAMNED STUPID to know the difference between when the simulated
>>>>>>>> input reaches the final state of this simulated input and when
>>>>>>>> the directly executed halt decider reaches its own final state.
>>>>>>>>
>>>>>>>
>>>>>>> If the simulation doesn't match the actual exectution, then it
>>>>>>> isn't a correct simulation.
>>>>>>
>>>>>> It is a verifiable fact that the pure simulation of the input to
>>>>>> embedded_H would never halt in any finite number of steps of
>>>>>> simulation.
>>>>>>
>>>>>> Quit being a "Putin says he is rescuing Ukraine" liar.
>>>>>>
>>>>>>
>>>>>
>>>>> Another Fallicy, you like them don't you. Doesn't help your
>>>>> arguement one bit, and just shows you have nothing to stand on.
>>>>>
>>>>> It is only 'verifiable' that the pure simulation does this if H is
>>>>> JUST a pure simulator and never aborts.
>>>>>
>>>>
>>>> Whether embedded_H aborts its simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ or not the
>>>> simulated input cannot reach its own final state of ⟨Ĥ⟩.qn.
>>>>
>>>> The simulated input has a final state: ⟨Ĥ⟩.qn and the halt decider
>>>> has an entirely different final state: Ĥ.qn these are not the same.
>>>>
>>>>
>>>>
>>>>
>>>> Whether embedded_H aborts its simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ or not the
>>>> simulated input cannot reach its own final state of ⟨Ĥ⟩.qn.
>>>>
>>>> The simulated input has a final state: ⟨Ĥ⟩.qn and the halt decider
>>>> has an entirely different final state: Ĥ.qn these are not the same.
>>>>
>>>>
>>>>
>>>> Whether embedded_H aborts its simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ or not the
>>>> simulated input cannot reach its own final state of ⟨Ĥ⟩.qn.
>>>>
>>>> The simulated input has a final state: ⟨Ĥ⟩.qn and the halt decider
>>>> has an entirely different final state: Ĥ.qn these are not the same.
>>>>
>>>>
>>>>
>>>> Whether embedded_H aborts its simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ or not the
>>>> simulated input cannot reach its own final state of ⟨Ĥ⟩.qn.
>>>>
>>>> The simulated input has a final state: ⟨Ĥ⟩.qn and the halt decider
>>>> has an entirely different final state: Ĥ.qn these are not the same.
>>>>
>>>>
>>>>
>>>> Whether embedded_H aborts its simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ or not the
>>>> simulated input cannot reach its own final state of ⟨Ĥ⟩.qn.
>>>>
>>>> The simulated input has a final state: ⟨Ĥ⟩.qn and the halt decider
>>>> has an entirely different final state: Ĥ.qn these are not the same.
>>>>
>>>>
>>>>
>>>> Whether embedded_H aborts its simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ or not the
>>>> simulated input cannot reach its own final state of ⟨Ĥ⟩.qn.
>>>>
>>>> The simulated input has a final state: ⟨Ĥ⟩.qn and the halt decider
>>>> has an entirely different final state: Ĥ.qn these are not the same.
>>>>
>>>>
>>>>
>>>> Whether embedded_H aborts its simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ or not the
>>>> simulated input cannot reach its own final state of ⟨Ĥ⟩.qn.
>>>>
>>>> The simulated input has a final state: ⟨Ĥ⟩.qn and the halt decider
>>>> has an entirely different final state: Ĥ.qn these are not the same.
>>>>
>>>>
>>>>
>>>> Whether embedded_H aborts its simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ or not the
>>>> simulated input cannot reach its own final state of ⟨Ĥ⟩.qn.
>>>>
>>>> The simulated input has a final state: ⟨Ĥ⟩.qn and the halt decider
>>>> has an entirely different final state: Ĥ.qn these are not the same.
>>>>
>>>>
>>>>
>>>> Whether embedded_H aborts its simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ or not the
>>>> simulated input cannot reach its own final state of ⟨Ĥ⟩.qn.
>>>>
>>>> The simulated input has a final state: ⟨Ĥ⟩.qn and the halt decider
>>>> has an entirely different final state: Ĥ.qn these are not the same.
>>>>
>>>>
>>>
>>> Already disproven and you are just showing you are ignorant of how
>>> Turing Machines work,
>>>
>>> Because, in FACT, unless you are LYING about building H^ correctly,
>>> the final state of H^, H^.Qn IS the exact same state as the H.Qn
>>
>> So you are saying that embedded_H is simulating its actual self and is
>> never ever being directly executed?
>>
>> It is not the exact one-and-the-same state. It is a copy of an
>> equivalent state in an entirely different process.
>>
>
> There is an actual 'self' of embedded_H that is embedded in the H^
> machine, and this sub-machine is given the input <H^> <H^> to decide on,
> by simulating if that is its pleasure.
>
> So in part YES, embedded_H is simulation a representaiton of itself. (it
> is a category error to say it is simulation its actual self, or even a
> copy of itself).
>
> There also MUST be a Turing Machine H, which is the origial decider that
> is claimed to be correct, as an actual independent machine, and the
> behavior of the embedded copy of it must behave exactly like this
> independent copy or you didn't build H^ correctly.
>
> This actual machine H has terminal state H.Qy and H.Qn (or possibly just
> named Qy and Qn), and when we embedded a copy of that machine H into H^,
> then the states H.Qy and H.Qn become the exact equivalent states H^.Qy
> and H^.Qn, and if H applied to <M> w goes to H.Qn then the embedded copy
> you are calling goes to its equivalenet state to H.Qn which IS H^.Qn
>
> Unless you are going to claim that identical copies of a Turing Machine
> given exactly the same input can behave differently, they are
> effectively the identical state. Unless you want to say that the 2 that
> you get from 1+1 is different than the 2 you get from 5-3, you are going
> to run into problems claiming they are different.
>
> If you DO want to claim that identical copies of a Turing Machine given
> exactly the same input can do something different, please provide an
> ACTAUL example, or STFU.
>
> Until you do, then it is an established fact that if H <M> <M> goes to
> state H.Qn, then it is a fact that the H^ that has a copy of that H in
> it goes to H^.Qn and halts when applied to the input <M>, so H^ applied
> to <H^> will halt if H applied to <H^> <H^> goes to H.Qn claiming that
> input represents a non-halting computation, but that computation is
> EXACTLY H^ applied to <H^> which we just showed halted.

On 2022-03-17 08:06, olcott wrote:

> This is the key part where you err.
> Ĥ applied to ⟨Ĥ⟩ differs from embedded_H applied to ⟨Ĥ⟩ ⟨Ĥ⟩.

Yes, those are two entirely different computations. And Ĥ applied to ⟨Ĥ⟩
is the computation which H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ is required to answer about.

> Ĥ applied to ⟨Ĥ⟩ reaches its final state only when embedded_H applied to
> ⟨Ĥ⟩ ⟨Ĥ⟩ aborts its simulation.

Yes, Ĥ applied to ⟨Ĥ⟩ reaches its final state which means that it halts.
It doesn't matter *why* it reaches it's final state. If it does, the
correct answer for H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ to give is HALTS.

> This falls under the general principle that when-so-ever the simulation
> of any input to a simulating halt decider must be aborted to prevent its
> infinite simulation this input is correctly rejected as non-halting.

That's not recognized general principle.

André

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

On 3/17/2022 9:36 AM, André G. Isaak wrote:
> On 2022-03-17 08:06, olcott wrote:
>
>> This is the key part where you err.
>> Ĥ applied to ⟨Ĥ⟩ differs from embedded_H applied to ⟨Ĥ⟩ ⟨Ĥ⟩.
>
> Yes, those are two entirely different computations. And Ĥ applied to ⟨Ĥ⟩
> is the computation which H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ is required to answer about.
>
>> Ĥ applied to ⟨Ĥ⟩ reaches its final state only when embedded_H applied
>> to ⟨Ĥ⟩ ⟨Ĥ⟩ aborts its simulation.
>
> Yes, Ĥ applied to ⟨Ĥ⟩ reaches its final state which means that it halts.
> It doesn't matter *why* it reaches it's final state. If it does, the
> correct answer for H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ to give is HALTS.
>
>> This falls under the general principle that when-so-ever the
>> simulation of any input to a simulating halt decider must be aborted
>> to prevent its infinite simulation this input is correctly rejected as
>> non-halting.
>
> That's not recognized general principle.
>

Not yet. It is self-evidently correct though.

> André
>

--
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/17/22 10:06 AM, olcott wrote:
> On 3/16/2022 10:02 PM, Richard Damon wrote:
>>
>> On 3/16/22 10:04 PM, olcott wrote:
>>> On 3/16/2022 8:54 PM, Richard Damon wrote:
>>>> On 3/16/22 9:16 PM, olcott wrote:
>>>>> On 3/16/2022 8:08 PM, Richard Damon wrote:
>>>>>> On 3/16/22 8:51 PM, olcott wrote:
>>>>>>> On 3/16/2022 7:47 PM, Richard Damon wrote:
>>>>>>>> On 3/16/22 7:32 PM, olcott wrote:
>>>>>>>>> On 3/16/2022 6:22 PM, Richard Damon wrote:
>>>>>>>>>> On 3/16/22 6:56 PM, olcott wrote:
>>>>>>>>>>> On 3/16/2022 5:41 PM, Richard Damon wrote:
>>>>>>>>>>>> On 3/16/22 3:10 PM, olcott wrote:
>>>>>>>>>>>>> On 3/16/2022 12:37 PM, Mike Terry wrote:
>>>>>>>>>>>>>> On 16/03/2022 17:20, olcott wrote:
>>>>>>>>>>>>>>> On 3/16/2022 12:04 PM, Mike Terry wrote:
>>>>>>>>>>>>>>>> On 16/03/2022 14:15, olcott wrote:
>>>>>>>>>>>>>>>>> On 3/16/2022 2:21 AM, Jeff Barnett wrote:
>>>>>>>>>>>>>>>>>> On 3/15/2022 4:02 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 3/15/2022 4:48 PM, Jeff Barnett wrote:
>>>>>>>>>>>>>>>>>>>> On 3/15/2022 1:44 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>> On 3/15/2022 1:58 PM, Jeff Barnett wrote:
>>>>>>>>>>>>>>>>>>>>>> On 3/15/2022 10:11 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 3/15/2022 10:44 AM, Malcolm McLean wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>     <MAJOR SNIP>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> So how would you describe a compiler which is
>>>>>>>>>>>>>>>>>>>>>>>> "bootstrapped", i.e. fed its own
>>>>>>>>>>>>>>>>>>>>>>>> source code?
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> A compiler that is fed its own source-code is not
>>>>>>>>>>>>>>>>>>>>>>> the same because the compiler does not execute
>>>>>>>>>>>>>>>>>>>>>>> this source-code.
>>>>>>>>>>>>>>>>>>>>>> This is one of your best Peter. Along the way
>>>>>>>>>>>>>>>>>>>>>> you've had 100s of messages that have said that
>>>>>>>>>>>>>>>>>>>>>> simulation as a basis for a Halting Problem
>>>>>>>>>>>>>>>>>>>>>> solution is hopeless. Of course you pay no
>>>>>>>>>>>>>>>>>>>>>> attention because it's unlikely you understood
>>>>>>>>>>>>>>>>>>>>>> what you were being told. So here you are looping
>>>>>>>>>>>>>>>>>>>>>> back over years of the same bone headed approach.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Let's start with a few basics:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Nothing executes source code; even an interpreter
>>>>>>>>>>>>>>>>>>>>>> ingests it first.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> A compiler the compiles its own source-code is
>>>>>>>>>>>>>>>>>>>>> nothing at all like executing this source code.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> You really do have rocks in your head. Think for at
>>>>>>>>>>>>>>>>>>>> least 2 seconds before responding and getting it all
>>>>>>>>>>>>>>>>>>>> wrong. The mistakes you are making with the above
>>>>>>>>>>>>>>>>>>>> statement are so basic that I hardly know where to
>>>>>>>>>>>>>>>>>>>> start. As I've been told many times it's harder to
>>>>>>>>>>>>>>>>>>>> teach Kindergarten than grad students. And in this
>>>>>>>>>>>>>>>>>>>> instance, with you, we have a sixty year old
>>>>>>>>>>>>>>>>>>>> crawling around in diapers.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> An interpreter that interprets source code can be
>>>>>>>>>>>>>>>>>>>>> reasonably construed as running this source code.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Perhaps. The issue is it really doesn't know that it
>>>>>>>>>>>>>>>>>>>> is it's own source code, does it? And, in fact,
>>>>>>>>>>>>>>>>>>>> neither it nor any observer is aware of any vicious
>>>>>>>>>>>>>>>>>>>> self reference. Only a dunce would worry about it.
>>>>>>>>>>>>>>>>>>>> You do worry don't you?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> In other words you are saying that no one is bright
>>>>>>>>>>>>>>>>>>> enough to be able to detect what is essentially
>>>>>>>>>>>>>>>>>>> infinite recursion.
>>>>>>>>>>>>>>>>>> You soiled your diapers again. I said nothing of the
>>>>>>>>>>>>>>>>>> sort. I will say it now though, nobody is intelligent
>>>>>>>>>>>>>>>>>> enough to systematically (by algorithm) spot infinite
>>>>>>>>>>>>>>>>>> recursion. God can't do it either. It's not
>>>>>>>>>>>>>>>>>> theoretically possible. Only an ignorant nitwit would
>>>>>>>>>>>>>>>>>> not know that and prattle on for years about it.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I already have a group of many experts that concur that
>>>>>>>>>>>>>>>>> infinite recursion can be detected and the criterion
>>>>>>>>>>>>>>>>> measure by which it is correctly detected.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I'm afraid that you lack the intellect to understand
>>>>>>>>>>>>>>>> exactly what other people are saying on technical
>>>>>>>>>>>>>>>> issues. How many times have you quoted me (and others
>>>>>>>>>>>>>>>> here) as supporting something you've claimed, whereas it
>>>>>>>>>>>>>>>> turns out you had just misunderstood some remark that
>>>>>>>>>>>>>>>> had been made? [Answer: lots of times!]
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> You also have a habit of going elsewhere, and "tricking"
>>>>>>>>>>>>>>>> the people there into "agreeing" with some claim you've
>>>>>>>>>>>>>>>> made here by not properly explaining the full context of
>>>>>>>>>>>>>>>> your claim. Then you come back here selectively quoting
>>>>>>>>>>>>>>>> some "expert" to suggest he is supporting you. [Like
>>>>>>>>>>>>>>>> when you went to the x86 group and showed them your
>>>>>>>>>>>>>>>> "trace" asking them if they could see what's going on,
>>>>>>>>>>>>>>>> and got one of them to say "it's looping...".  You
>>>>>>>>>>>>>>>> failed to mention the trace was not the "processor
>>>>>>>>>>>>>>>> trace" they would naturally expect, and that there was
>>>>>>>>>>>>>>>> simulation involved, and that your trace was in fact
>>>>>>>>>>>>>>>> some kind of "merged simulation trace", and that you
>>>>>>>>>>>>>>>> were using this trace to disprove the Halting Problem
>>>>>>>>>>>>>>>> theorem.]
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> It's been pointed out to you many times that algorithms
>>>>>>>>>>>>>>>> exhist that can identify /some/ infinite
>>>>>>>>>>>>>>>> loops/recursions as such, but no algorithm detects ALL
>>>>>>>>>>>>>>>> non-halting behaviour.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> And specifically, your test (looking for more than one
>>>>>>>>>>>>>>>> call to a particular address etc.) is /unsound/ when you
>>>>>>>>>>>>>>>> try to use it on your "merged simulation" trace.  No
>>>>>>>>>>>>>>>> expert would say otherwise if they had been given the
>>>>>>>>>>>>>>>> full context, so probably you've just tricked someone
>>>>>>>>>>>>>>>> again...
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Mike.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> None-the-less is is self-evident that the input presented
>>>>>>>>>>>>>>> to the copy of the Linz H embedded at Ĥ.qx does specify
>>>>>>>>>>>>>>> infinitely nested simulation to simulating halt decider
>>>>>>>>>>>>>>> embedded_H thus proving that a transition to Ĥ.qn by
>>>>>>>>>>>>>>> embedded_H would be correct.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You mean self-evident TO YOU.  To people who have an
>>>>>>>>>>>>>> understanding of TMs it is simply wrong or meaningless
>>>>>>>>>>>>>> (depending on how tolerant people are of your wishy-washy
>>>>>>>>>>>>>> phrasing).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Mike.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> They simply dogmatically state that the believe that I am
>>>>>>>>>>>>> wrong about this yet cannot point to the specific error
>>>>>>>>>>>>> because there is none:
>>>>>>>>>>>>>
>>>>>>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>>>>>>>>    Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H
>>>>>>>>>>>>> simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>>>>>>>>>>>>
>>>>>>>>>>>>> Then these steps would keep repeating:
>>>>>>>>>>>>>    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H
>>>>>>>>>>>>> simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>>>>>>>>>>>>    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H
>>>>>>>>>>>>> simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
>>>>>>>>>>>>>    Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H
>>>>>>>>>>>>> simulates ⟨Ĥ4⟩ ⟨Ĥ5⟩...
>>>>>>>>>>>>>
>>>>>>>>>>>>> The above repeating pattern shows that the correctly
>>>>>>>>>>>>> simulated input to embedded_H would never reach its final
>>>>>>>>>>>>> state of ⟨Ĥ⟩.qn conclusively proving that this simulated
>>>>>>>>>>>>> input never halts. This enables embedded_H to abort its
>>>>>>>>>>>>> simulation and correctly transition to Ĥ.qn.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> The error has been pointed out to you many times, but you
>>>>>>>>>>>> seem either too dumb or too dishonest to see/admit the error.
>>>>>>>>>>>>
>>>>>>>>>>> You cannot show that the simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to
>>>>>>>>>>> embedded_H can possibly ever reach its own final state ⟨Ĥ⟩.qn
>>>>>>>>>>> in any finite number of simulated steps YOU FREAKING BRAIN
>>>>>>>>>>> DEAD MORON!
>>>>>>>>>>>
>>>>>>>>>>> Ĥ.qn is not the final state of any simulated input:
>>>>>>>>>>> YOU FREAKING BRAIN DEAD MORON!
>>>>>>>>>>>
>>>>>>>>>>> Ĥ.qn is only the final state of the simulating halt decider
>>>>>>>>>>> YOU FREAKING BRAIN DEAD MORON!
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> But I CAN and HAVE proven that the CORRECT simulation of <H^>
>>>>>>>>>> <H^> by an ACTUAL UTM does reach that state.
>>>>>>>>> Not at all because you are a BRAIN DEAD MORON you are simply
>>>>>>>>> TOO DAMNED STUPID to know the difference between when the
>>>>>>>>> simulated input reaches the final state of this simulated input
>>>>>>>>> and when the directly executed halt decider reaches its own
>>>>>>>>> final state.
>>>>>>>>>
>>>>>>>>
>>>>>>>> If the simulation doesn't match the actual exectution, then it
>>>>>>>> isn't a correct simulation.
>>>>>>>
>>>>>>> It is a verifiable fact that the pure simulation of the input to
>>>>>>> embedded_H would never halt in any finite number of steps of
>>>>>>> simulation.
>>>>>>>
>>>>>>> Quit being a "Putin says he is rescuing Ukraine" liar.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Another Fallicy, you like them don't you. Doesn't help your
>>>>>> arguement one bit, and just shows you have nothing to stand on.
>>>>>>
>>>>>> It is only 'verifiable' that the pure simulation does this if H is
>>>>>> JUST a pure simulator and never aborts.
>>>>>>
>>>>>
>>>>> Whether embedded_H aborts its simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ or not the
>>>>> simulated input cannot reach its own final state of ⟨Ĥ⟩.qn.
>>>>>
>>>>> The simulated input has a final state: ⟨Ĥ⟩.qn and the halt decider
>>>>> has an entirely different final state: Ĥ.qn these are not the same.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Whether embedded_H aborts its simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ or not the
>>>>> simulated input cannot reach its own final state of ⟨Ĥ⟩.qn.
>>>>>
>>>>> The simulated input has a final state: ⟨Ĥ⟩.qn and the halt decider
>>>>> has an entirely different final state: Ĥ.qn these are not the same.
>>>>>
>>>>>
>>>>>
>>>>> Whether embedded_H aborts its simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ or not the
>>>>> simulated input cannot reach its own final state of ⟨Ĥ⟩.qn.
>>>>>
>>>>> The simulated input has a final state: ⟨Ĥ⟩.qn and the halt decider
>>>>> has an entirely different final state: Ĥ.qn these are not the same.
>>>>>
>>>>>
>>>>>
>>>>> Whether embedded_H aborts its simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ or not the
>>>>> simulated input cannot reach its own final state of ⟨Ĥ⟩.qn.
>>>>>
>>>>> The simulated input has a final state: ⟨Ĥ⟩.qn and the halt decider
>>>>> has an entirely different final state: Ĥ.qn these are not the same.
>>>>>
>>>>>
>>>>>
>>>>> Whether embedded_H aborts its simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ or not the
>>>>> simulated input cannot reach its own final state of ⟨Ĥ⟩.qn.
>>>>>
>>>>> The simulated input has a final state: ⟨Ĥ⟩.qn and the halt decider
>>>>> has an entirely different final state: Ĥ.qn these are not the same.
>>>>>
>>>>>
>>>>>
>>>>> Whether embedded_H aborts its simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ or not the
>>>>> simulated input cannot reach its own final state of ⟨Ĥ⟩.qn.
>>>>>
>>>>> The simulated input has a final state: ⟨Ĥ⟩.qn and the halt decider
>>>>> has an entirely different final state: Ĥ.qn these are not the same.
>>>>>
>>>>>
>>>>>
>>>>> Whether embedded_H aborts its simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ or not the
>>>>> simulated input cannot reach its own final state of ⟨Ĥ⟩.qn.
>>>>>
>>>>> The simulated input has a final state: ⟨Ĥ⟩.qn and the halt decider
>>>>> has an entirely different final state: Ĥ.qn these are not the same.
>>>>>
>>>>>
>>>>>
>>>>> Whether embedded_H aborts its simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ or not the
>>>>> simulated input cannot reach its own final state of ⟨Ĥ⟩.qn.
>>>>>
>>>>> The simulated input has a final state: ⟨Ĥ⟩.qn and the halt decider
>>>>> has an entirely different final state: Ĥ.qn these are not the same.
>>>>>
>>>>>
>>>>>
>>>>> Whether embedded_H aborts its simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ or not the
>>>>> simulated input cannot reach its own final state of ⟨Ĥ⟩.qn.
>>>>>
>>>>> The simulated input has a final state: ⟨Ĥ⟩.qn and the halt decider
>>>>> has an entirely different final state: Ĥ.qn these are not the same.
>>>>>
>>>>>
>>>>
>>>> Already disproven and you are just showing you are ignorant of how
>>>> Turing Machines work,
>>>>
>>>> Because, in FACT, unless you are LYING about building H^ correctly,
>>>> the final state of H^, H^.Qn IS the exact same state as the H.Qn
>>>
>>> So you are saying that embedded_H is simulating its actual self and
>>> is never ever being directly executed?
>>>
>>> It is not the exact one-and-the-same state. It is a copy of an
>>> equivalent state in an entirely different process.
>>>
>>
>> There is an actual 'self' of embedded_H that is embedded in the H^
>> machine, and this sub-machine is given the input <H^> <H^> to decide
>> on, by simulating if that is its pleasure.
>>
>> So in part YES, embedded_H is simulation a representaiton of itself.
>> (it is a category error to say it is simulation its actual self, or
>> even a copy of itself).
>>
>> There also MUST be a Turing Machine H, which is the origial decider
>> that is claimed to be correct, as an actual independent machine, and
>> the behavior of the embedded copy of it must behave exactly like this
>> independent copy or you didn't build H^ correctly.
>>
>> This actual machine H has terminal state H.Qy and H.Qn (or possibly
>> just named Qy and Qn), and when we embedded a copy of that machine H
>> into H^, then the states H.Qy and H.Qn become the exact equivalent
>> states H^.Qy and H^.Qn, and if H applied to <M> w goes to H.Qn then
>> the embedded copy you are calling goes to its equivalenet state to
>> H.Qn which IS H^.Qn
>>
>> Unless you are going to claim that identical copies of a Turing
>> Machine given exactly the same input can behave differently, they are
>> effectively the identical state. Unless you want to say that the 2
>> that you get from 1+1 is different than the 2 you get from 5-3, you
>> are going to run into problems claiming they are different.
>>
>> If you DO want to claim that identical copies of a Turing Machine
>> given exactly the same input can do something different, please
>> provide an ACTAUL example, or STFU.
>>
>> Until you do, then it is an established fact that if H <M> <M> goes to
>> state H.Qn, then it is a fact that the H^ that has a copy of that H in
>> it goes to H^.Qn and halts when applied to the input <M>, so H^
>> applied to <H^> will halt if H applied to <H^> <H^> goes to H.Qn
>> claiming that input represents a non-halting computation, but that
>> computation is EXACTLY H^ applied to <H^> which we just showed halted.
>
> This is the key part where you err.
> Ĥ applied to ⟨Ĥ⟩ differs from embedded_H applied to ⟨Ĥ⟩ ⟨Ĥ⟩.

On 3/17/22 11:02 AM, olcott wrote:
> On 3/17/2022 9:36 AM, André G. Isaak wrote:
>> On 2022-03-17 08:06, olcott wrote:
>>
>>> This is the key part where you err.
>>> Ĥ applied to ⟨Ĥ⟩ differs from embedded_H applied to ⟨Ĥ⟩ ⟨Ĥ⟩.
>>
>> Yes, those are two entirely different computations. And Ĥ applied to
>> ⟨Ĥ⟩ is the computation which H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ is required to
>> answer about.
>>
>>> Ĥ applied to ⟨Ĥ⟩ reaches its final state only when embedded_H applied
>>> to ⟨Ĥ⟩ ⟨Ĥ⟩ aborts its simulation.
>>
>> Yes, Ĥ applied to ⟨Ĥ⟩ reaches its final state which means that it
>> halts. It doesn't matter *why* it reaches it's final state. If it
>> does, the correct answer for H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ to give is HALTS.
>>
>>> This falls under the general principle that when-so-ever the
>>> simulation of any input to a simulating halt decider must be aborted
>>> to prevent its infinite simulation this input is correctly rejected
>>> as non-halting.
>>
>> That's not recognized general principle.
>>
>
> Not yet. It is self-evidently correct though.
>

Except it is prove FALSE by H^ applied to <H^>, and the ACTUAL
definition of Halting.

Anyone who thinks a FALSE statement is self-evidently CORRECT, has just
proved that they don't actually understand what is true.

>> André
>>
>
>

On 3/17/2022 2:30 PM, Richard Damon wrote:
>
> On 3/17/22 10:06 AM, olcott wrote:
>> On 3/16/2022 10:02 PM, Richard Damon wrote:
>>>
>>> On 3/16/22 10:04 PM, olcott wrote:
>>>> On 3/16/2022 8:54 PM, Richard Damon wrote:
>>>>> On 3/16/22 9:16 PM, olcott wrote:
>>>>>> On 3/16/2022 8:08 PM, Richard Damon wrote:
>>>>>>> On 3/16/22 8:51 PM, olcott wrote:
>>>>>>>> On 3/16/2022 7:47 PM, Richard Damon wrote:
>>>>>>>>> On 3/16/22 7:32 PM, olcott wrote:
>>>>>>>>>> On 3/16/2022 6:22 PM, Richard Damon wrote:
>>>>>>>>>>> On 3/16/22 6:56 PM, olcott wrote:
>>>>>>>>>>>> On 3/16/2022 5:41 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 3/16/22 3:10 PM, olcott wrote:
>>>>>>>>>>>>>> On 3/16/2022 12:37 PM, Mike Terry wrote:
>>>>>>>>>>>>>>> On 16/03/2022 17:20, olcott wrote:
>>>>>>>>>>>>>>>> On 3/16/2022 12:04 PM, Mike Terry wrote:
>>>>>>>>>>>>>>>>> On 16/03/2022 14:15, olcott wrote:
>>>>>>>>>>>>>>>>>> On 3/16/2022 2:21 AM, Jeff Barnett wrote:
>>>>>>>>>>>>>>>>>>> On 3/15/2022 4:02 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 3/15/2022 4:48 PM, Jeff Barnett wrote:
>>>>>>>>>>>>>>>>>>>>> On 3/15/2022 1:44 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>> On 3/15/2022 1:58 PM, Jeff Barnett wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 3/15/2022 10:11 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 3/15/2022 10:44 AM, Malcolm McLean wrote:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>     <MAJOR SNIP>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> So how would you describe a compiler which is
>>>>>>>>>>>>>>>>>>>>>>>>> "bootstrapped", i.e. fed its own
>>>>>>>>>>>>>>>>>>>>>>>>> source code?
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> A compiler that is fed its own source-code is
>>>>>>>>>>>>>>>>>>>>>>>> not the same because the compiler does not
>>>>>>>>>>>>>>>>>>>>>>>> execute this source-code.
>>>>>>>>>>>>>>>>>>>>>>> This is one of your best Peter. Along the way
>>>>>>>>>>>>>>>>>>>>>>> you've had 100s of messages that have said that
>>>>>>>>>>>>>>>>>>>>>>> simulation as a basis for a Halting Problem
>>>>>>>>>>>>>>>>>>>>>>> solution is hopeless. Of course you pay no
>>>>>>>>>>>>>>>>>>>>>>> attention because it's unlikely you understood
>>>>>>>>>>>>>>>>>>>>>>> what you were being told. So here you are looping
>>>>>>>>>>>>>>>>>>>>>>> back over years of the same bone headed approach.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Let's start with a few basics:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Nothing executes source code; even an interpreter
>>>>>>>>>>>>>>>>>>>>>>> ingests it first.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> A compiler the compiles its own source-code is
>>>>>>>>>>>>>>>>>>>>>> nothing at all like executing this source code.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> You really do have rocks in your head. Think for at
>>>>>>>>>>>>>>>>>>>>> least 2 seconds before responding and getting it
>>>>>>>>>>>>>>>>>>>>> all wrong. The mistakes you are making with the
>>>>>>>>>>>>>>>>>>>>> above statement are so basic that I hardly know
>>>>>>>>>>>>>>>>>>>>> where to start. As I've been told many times it's
>>>>>>>>>>>>>>>>>>>>> harder to teach Kindergarten than grad students.
>>>>>>>>>>>>>>>>>>>>> And in this instance, with you, we have a sixty
>>>>>>>>>>>>>>>>>>>>> year old crawling around in diapers.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> An interpreter that interprets source code can be
>>>>>>>>>>>>>>>>>>>>>> reasonably construed as running this source code.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Perhaps. The issue is it really doesn't know that
>>>>>>>>>>>>>>>>>>>>> it is it's own source code, does it? And, in fact,
>>>>>>>>>>>>>>>>>>>>> neither it nor any observer is aware of any vicious
>>>>>>>>>>>>>>>>>>>>> self reference. Only a dunce would worry about it.
>>>>>>>>>>>>>>>>>>>>> You do worry don't you?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> In other words you are saying that no one is bright
>>>>>>>>>>>>>>>>>>>> enough to be able to detect what is essentially
>>>>>>>>>>>>>>>>>>>> infinite recursion.
>>>>>>>>>>>>>>>>>>> You soiled your diapers again. I said nothing of the
>>>>>>>>>>>>>>>>>>> sort. I will say it now though, nobody is intelligent
>>>>>>>>>>>>>>>>>>> enough to systematically (by algorithm) spot infinite
>>>>>>>>>>>>>>>>>>> recursion. God can't do it either. It's not
>>>>>>>>>>>>>>>>>>> theoretically possible. Only an ignorant nitwit would
>>>>>>>>>>>>>>>>>>> not know that and prattle on for years about it.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I already have a group of many experts that concur
>>>>>>>>>>>>>>>>>> that infinite recursion can be detected and the
>>>>>>>>>>>>>>>>>> criterion measure by which it is correctly detected.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I'm afraid that you lack the intellect to understand
>>>>>>>>>>>>>>>>> exactly what other people are saying on technical
>>>>>>>>>>>>>>>>> issues. How many times have you quoted me (and others
>>>>>>>>>>>>>>>>> here) as supporting something you've claimed, whereas
>>>>>>>>>>>>>>>>> it turns out you had just misunderstood some remark
>>>>>>>>>>>>>>>>> that had been made? [Answer: lots of times!]
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> You also have a habit of going elsewhere, and
>>>>>>>>>>>>>>>>> "tricking" the people there into "agreeing" with some
>>>>>>>>>>>>>>>>> claim you've made here by not properly explaining the
>>>>>>>>>>>>>>>>> full context of your claim. Then you come back here
>>>>>>>>>>>>>>>>> selectively quoting some "expert" to suggest he is
>>>>>>>>>>>>>>>>> supporting you. [Like when you went to the x86 group
>>>>>>>>>>>>>>>>> and showed them your "trace" asking them if they could
>>>>>>>>>>>>>>>>> see what's going on, and got one of them to say "it's
>>>>>>>>>>>>>>>>> looping...".  You failed to mention the trace was not
>>>>>>>>>>>>>>>>> the "processor trace" they would naturally expect, and
>>>>>>>>>>>>>>>>> that there was simulation involved, and that your trace
>>>>>>>>>>>>>>>>> was in fact some kind of "merged simulation trace", and
>>>>>>>>>>>>>>>>> that you were using this trace to disprove the Halting
>>>>>>>>>>>>>>>>> Problem theorem.]
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> It's been pointed out to you many times that algorithms
>>>>>>>>>>>>>>>>> exhist that can identify /some/ infinite
>>>>>>>>>>>>>>>>> loops/recursions as such, but no algorithm detects ALL
>>>>>>>>>>>>>>>>> non-halting behaviour.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> And specifically, your test (looking for more than one
>>>>>>>>>>>>>>>>> call to a particular address etc.) is /unsound/ when
>>>>>>>>>>>>>>>>> you try to use it on your "merged simulation" trace.
>>>>>>>>>>>>>>>>> No expert would say otherwise if they had been given
>>>>>>>>>>>>>>>>> the full context, so probably you've just tricked
>>>>>>>>>>>>>>>>> someone again...
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Mike.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> None-the-less is is self-evident that the input
>>>>>>>>>>>>>>>> presented to the copy of the Linz H embedded at Ĥ.qx
>>>>>>>>>>>>>>>> does specify infinitely nested simulation to simulating
>>>>>>>>>>>>>>>> halt decider embedded_H thus proving that a transition
>>>>>>>>>>>>>>>> to Ĥ.qn by embedded_H would be correct.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You mean self-evident TO YOU.  To people who have an
>>>>>>>>>>>>>>> understanding of TMs it is simply wrong or meaningless
>>>>>>>>>>>>>>> (depending on how tolerant people are of your wishy-washy
>>>>>>>>>>>>>>> phrasing).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Mike.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> They simply dogmatically state that the believe that I am
>>>>>>>>>>>>>> wrong about this yet cannot point to the specific error
>>>>>>>>>>>>>> because there is none:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>>>>>>>>>    Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H
>>>>>>>>>>>>>> simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Then these steps would keep repeating:
>>>>>>>>>>>>>>    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H
>>>>>>>>>>>>>> simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>>>>>>>>>>>>>    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H
>>>>>>>>>>>>>> simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
>>>>>>>>>>>>>>    Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H
>>>>>>>>>>>>>> simulates ⟨Ĥ4⟩ ⟨Ĥ5⟩...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The above repeating pattern shows that the correctly
>>>>>>>>>>>>>> simulated input to embedded_H would never reach its final
>>>>>>>>>>>>>> state of ⟨Ĥ⟩.qn conclusively proving that this simulated
>>>>>>>>>>>>>> input never halts. This enables embedded_H to abort its
>>>>>>>>>>>>>> simulation and correctly transition to Ĥ.qn.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> The error has been pointed out to you many times, but you
>>>>>>>>>>>>> seem either too dumb or too dishonest to see/admit the error.
>>>>>>>>>>>>>
>>>>>>>>>>>> You cannot show that the simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to
>>>>>>>>>>>> embedded_H can possibly ever reach its own final state
>>>>>>>>>>>> ⟨Ĥ⟩.qn in any finite number of simulated steps YOU FREAKING
>>>>>>>>>>>> BRAIN DEAD MORON!
>>>>>>>>>>>>
>>>>>>>>>>>> Ĥ.qn is not the final state of any simulated input:
>>>>>>>>>>>> YOU FREAKING BRAIN DEAD MORON!
>>>>>>>>>>>>
>>>>>>>>>>>> Ĥ.qn is only the final state of the simulating halt decider
>>>>>>>>>>>> YOU FREAKING BRAIN DEAD MORON!
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> But I CAN and HAVE proven that the CORRECT simulation of <H^>
>>>>>>>>>>> <H^> by an ACTUAL UTM does reach that state.
>>>>>>>>>> Not at all because you are a BRAIN DEAD MORON you are simply
>>>>>>>>>> TOO DAMNED STUPID to know the difference between when the
>>>>>>>>>> simulated input reaches the final state of this simulated
>>>>>>>>>> input and when the directly executed halt decider reaches its
>>>>>>>>>> own final state.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> If the simulation doesn't match the actual exectution, then it
>>>>>>>>> isn't a correct simulation.
>>>>>>>>
>>>>>>>> It is a verifiable fact that the pure simulation of the input to
>>>>>>>> embedded_H would never halt in any finite number of steps of
>>>>>>>> simulation.
>>>>>>>>
>>>>>>>> Quit being a "Putin says he is rescuing Ukraine" liar.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> Another Fallicy, you like them don't you. Doesn't help your
>>>>>>> arguement one bit, and just shows you have nothing to stand on.
>>>>>>>
>>>>>>> It is only 'verifiable' that the pure simulation does this if H
>>>>>>> is JUST a pure simulator and never aborts.
>>>>>>>
>>>>>>
>>>>>> Whether embedded_H aborts its simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ or not the
>>>>>> simulated input cannot reach its own final state of ⟨Ĥ⟩.qn.
>>>>>>
>>>>>> The simulated input has a final state: ⟨Ĥ⟩.qn and the halt decider
>>>>>> has an entirely different final state: Ĥ.qn these are not the same.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Whether embedded_H aborts its simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ or not the
>>>>>> simulated input cannot reach its own final state of ⟨Ĥ⟩.qn.
>>>>>>
>>>>>> The simulated input has a final state: ⟨Ĥ⟩.qn and the halt decider
>>>>>> has an entirely different final state: Ĥ.qn these are not the same.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Whether embedded_H aborts its simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ or not the
>>>>>> simulated input cannot reach its own final state of ⟨Ĥ⟩.qn.
>>>>>>
>>>>>> The simulated input has a final state: ⟨Ĥ⟩.qn and the halt decider
>>>>>> has an entirely different final state: Ĥ.qn these are not the same.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Whether embedded_H aborts its simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ or not the
>>>>>> simulated input cannot reach its own final state of ⟨Ĥ⟩.qn.
>>>>>>
>>>>>> The simulated input has a final state: ⟨Ĥ⟩.qn and the halt decider
>>>>>> has an entirely different final state: Ĥ.qn these are not the same.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Whether embedded_H aborts its simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ or not the
>>>>>> simulated input cannot reach its own final state of ⟨Ĥ⟩.qn.
>>>>>>
>>>>>> The simulated input has a final state: ⟨Ĥ⟩.qn and the halt decider
>>>>>> has an entirely different final state: Ĥ.qn these are not the same.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Whether embedded_H aborts its simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ or not the
>>>>>> simulated input cannot reach its own final state of ⟨Ĥ⟩.qn.
>>>>>>
>>>>>> The simulated input has a final state: ⟨Ĥ⟩.qn and the halt decider
>>>>>> has an entirely different final state: Ĥ.qn these are not the same.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Whether embedded_H aborts its simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ or not the
>>>>>> simulated input cannot reach its own final state of ⟨Ĥ⟩.qn.
>>>>>>
>>>>>> The simulated input has a final state: ⟨Ĥ⟩.qn and the halt decider
>>>>>> has an entirely different final state: Ĥ.qn these are not the same.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Whether embedded_H aborts its simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ or not the
>>>>>> simulated input cannot reach its own final state of ⟨Ĥ⟩.qn.
>>>>>>
>>>>>> The simulated input has a final state: ⟨Ĥ⟩.qn and the halt decider
>>>>>> has an entirely different final state: Ĥ.qn these are not the same.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Whether embedded_H aborts its simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ or not the
>>>>>> simulated input cannot reach its own final state of ⟨Ĥ⟩.qn.
>>>>>>
>>>>>> The simulated input has a final state: ⟨Ĥ⟩.qn and the halt decider
>>>>>> has an entirely different final state: Ĥ.qn these are not the same.
>>>>>>
>>>>>>
>>>>>
>>>>> Already disproven and you are just showing you are ignorant of how
>>>>> Turing Machines work,
>>>>>
>>>>> Because, in FACT, unless you are LYING about building H^ correctly,
>>>>> the final state of H^, H^.Qn IS the exact same state as the H.Qn
>>>>
>>>> So you are saying that embedded_H is simulating its actual self and
>>>> is never ever being directly executed?
>>>>
>>>> It is not the exact one-and-the-same state. It is a copy of an
>>>> equivalent state in an entirely different process.
>>>>
>>>
>>> There is an actual 'self' of embedded_H that is embedded in the H^
>>> machine, and this sub-machine is given the input <H^> <H^> to decide
>>> on, by simulating if that is its pleasure.
>>>
>>> So in part YES, embedded_H is simulation a representaiton of itself.
>>> (it is a category error to say it is simulation its actual self, or
>>> even a copy of itself).
>>>
>>> There also MUST be a Turing Machine H, which is the origial decider
>>> that is claimed to be correct, as an actual independent machine, and
>>> the behavior of the embedded copy of it must behave exactly like this
>>> independent copy or you didn't build H^ correctly.
>>>
>>> This actual machine H has terminal state H.Qy and H.Qn (or possibly
>>> just named Qy and Qn), and when we embedded a copy of that machine H
>>> into H^, then the states H.Qy and H.Qn become the exact equivalent
>>> states H^.Qy and H^.Qn, and if H applied to <M> w goes to H.Qn then
>>> the embedded copy you are calling goes to its equivalenet state to
>>> H.Qn which IS H^.Qn
>>>
>>> Unless you are going to claim that identical copies of a Turing
>>> Machine given exactly the same input can behave differently, they are
>>> effectively the identical state. Unless you want to say that the 2
>>> that you get from 1+1 is different than the 2 you get from 5-3, you
>>> are going to run into problems claiming they are different.
>>>
>>> If you DO want to claim that identical copies of a Turing Machine
>>> given exactly the same input can do something different, please
>>> provide an ACTAUL example, or STFU.
>>>
>>> Until you do, then it is an established fact that if H <M> <M> goes
>>> to state H.Qn, then it is a fact that the H^ that has a copy of that
>>> H in it goes to H^.Qn and halts when applied to the input <M>, so H^
>>> applied to <H^> will halt if H applied to <H^> <H^> goes to H.Qn
>>> claiming that input represents a non-halting computation, but that
>>> computation is EXACTLY H^ applied to <H^> which we just showed halted.
>>
>> This is the key part where you err.
>> Ĥ applied to ⟨Ĥ⟩ differs from embedded_H applied to ⟨Ĥ⟩ ⟨Ĥ⟩.
>
> Right, but the CORRECT answer for embedded_H appilied to <H^> <H^>
> depends on the behavior of H^ applied to <H^>. If H^ applied to <H^>
> eventually halts, then the ONLY correct answer for ANY halt decider
> applied to <H^> <H^> must be Halting (Qy).
>
> The problem you run into is H^ only halts if the halt decider it is
> built on goes to Qn, so THAT hatl decider can never be correct for the
> H^ built on it.
>
>>
>> Ĥ applied to ⟨Ĥ⟩ reaches its final state only when embedded_H applied
>> to ⟨Ĥ⟩ ⟨Ĥ⟩ aborts its simulation.
>
> Right, but it DOES reach its final state, so embedded_H, to be correct,
> must take that into account. it doesn't, so it gives the WRONG answer.
>

On 3/17/22 4:00 PM, olcott wrote:
> On 3/17/2022 2:30 PM, Richard Damon wrote:
>>
>> On 3/17/22 10:06 AM, olcott wrote:
>>> On 3/16/2022 10:02 PM, Richard Damon wrote:
>>> Ĥ applied to ⟨Ĥ⟩ reaches its final state only when embedded_H applied
>>> to ⟨Ĥ⟩ ⟨Ĥ⟩ aborts its simulation.
>>
>> Right, but it DOES reach its final state, so embedded_H, to be
>> correct, must take that into account. it doesn't, so it gives the
>> WRONG answer.
>>
>
> No BRAIN DEAD MORON the simulated ⟨Ĥ⟩ never reaches its own final state.
>

The CORRECT Simulation shows that it does.

H's simulation only doesn't reach that final state because H aborted it
simulation.

Once H aborts its simulation, the fact that it never reached a final
state doesn't matter, because only the CORRECT simulation matters,
because only the correct simulation matches the behavior of the
computation described.

On 3/17/2022 3:36 PM, Richard Damon wrote:
>
> On 3/17/22 4:00 PM, olcott wrote:
>> On 3/17/2022 2:30 PM, Richard Damon wrote:
>>>
>>> On 3/17/22 10:06 AM, olcott wrote:
>>>> On 3/16/2022 10:02 PM, Richard Damon wrote:
>>>> Ĥ applied to ⟨Ĥ⟩ reaches its final state only when embedded_H
>>>> applied to ⟨Ĥ⟩ ⟨Ĥ⟩ aborts its simulation.
>>>
>>> Right, but it DOES reach its final state, so embedded_H, to be
>>> correct, must take that into account. it doesn't, so it gives the
>>> WRONG answer.
>>>
>>
>> No BRAIN DEAD MORON the simulated ⟨Ĥ⟩ never reaches its own final state.
>>
>
> The CORRECT Simulation shows that it does.
>
> H's simulation only doesn't reach that final state because H aborted it
> simulation.
>

We are not talking about the simulation reaching the final state of the
simulation BRAIN DEAD MORON we are talking about the simulated input
reaching its own final state.

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

Then these steps would keep repeating:
Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩ ⟨Ĥ5⟩...

The simulated input never reaches its own final state whether or not
embedded_H aborts this simulation.

--
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/17/22 5:30 PM, olcott wrote:
> On 3/17/2022 3:36 PM, Richard Damon wrote:
>>
>> On 3/17/22 4:00 PM, olcott wrote:
>>> On 3/17/2022 2:30 PM, Richard Damon wrote:
>>>>
>>>> On 3/17/22 10:06 AM, olcott wrote:
>>>>> On 3/16/2022 10:02 PM, Richard Damon wrote:
>>>>> Ĥ applied to ⟨Ĥ⟩ reaches its final state only when embedded_H
>>>>> applied to ⟨Ĥ⟩ ⟨Ĥ⟩ aborts its simulation.
>>>>
>>>> Right, but it DOES reach its final state, so embedded_H, to be
>>>> correct, must take that into account. it doesn't, so it gives the
>>>> WRONG answer.
>>>>
>>>
>>> No BRAIN DEAD MORON the simulated ⟨Ĥ⟩ never reaches its own final state.
>>>
>>
>> The CORRECT Simulation shows that it does.
>>
>> H's simulation only doesn't reach that final state because H aborted
>> it simulation.
>>
>
> We are not talking about the simulation reaching the final state of the
> simulation BRAIN DEAD MORON we are talking about the simulated input
> reaching its own final state.
>
> When Ĥ is applied to ⟨Ĥ⟩
>   Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
>
> Then these steps would keep repeating:
>   Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
>   Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
>   Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩ ⟨Ĥ5⟩...
>
> The simulated input never reaches its own final state whether or not
> embedded_H aborts this simulation.
>

No, because if embedded_H aborts its simulation, then the trace must be:

When H^ is applied <H^>
H^0 copies its input <H^1> to <H^2> then H0 simulates <H^1> <H^2>
H^1 copies its input <H^2> to <H^3> then H1 simulates <H^2> <H^3>
H^2 copies its input <H^3> to <H^4> then H2 simulates <H^3> <H^4>
.... n levels (to when H0 aborts
H0 goes to H0.Qn and H^0 HALTS.

I.E. if embedded_H will only simulate a finite number of iterations, and
them abort its simulation, there is NO infinite simulation that happens.

FAIL.

Remember, the question is NOT "Can H simulate its input to a final
state?", it is "Does the computation the input represents Halt?" (or
reach a final state) or equivalently, would the input to H if simulated
by a UTM reach a final state/Halt. (Which isn't replace copies of H by a
UTM).

The "Can H simulate its input to a final state?" is just your POOP.

On 3/17/2022 5:30 PM, Richard Damon wrote:
>
> On 3/17/22 5:30 PM, olcott wrote:
>> On 3/17/2022 3:36 PM, Richard Damon wrote:
>>>
>>> On 3/17/22 4:00 PM, olcott wrote:
>>>> On 3/17/2022 2:30 PM, Richard Damon wrote:
>>>>>
>>>>> On 3/17/22 10:06 AM, olcott wrote:
>>>>>> On 3/16/2022 10:02 PM, Richard Damon wrote:
>>>>>> Ĥ applied to ⟨Ĥ⟩ reaches its final state only when embedded_H
>>>>>> applied to ⟨Ĥ⟩ ⟨Ĥ⟩ aborts its simulation.
>>>>>
>>>>> Right, but it DOES reach its final state, so embedded_H, to be
>>>>> correct, must take that into account. it doesn't, so it gives the
>>>>> WRONG answer.
>>>>>
>>>>
>>>> No BRAIN DEAD MORON the simulated ⟨Ĥ⟩ never reaches its own final
>>>> state.
>>>>
>>>
>>> The CORRECT Simulation shows that it does.
>>>
>>> H's simulation only doesn't reach that final state because H aborted
>>> it simulation.
>>>
>>
>> We are not talking about the simulation reaching the final state of
>> the simulation BRAIN DEAD MORON we are talking about the simulated
>> input reaching its own final state.
>>
>> When Ĥ is applied to ⟨Ĥ⟩
>>    Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>
>> Then these steps would keep repeating:
>>    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
>>    Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩
>> ⟨Ĥ5⟩...
>>
>> The simulated input never reaches its own final state whether or not
>> embedded_H aborts this simulation.
>>
>
> No, because if embedded_H aborts its simulation, then the trace must be:
>
> When H^ is applied <H^>
> H^0 copies its input <H^1> to <H^2> then H0 simulates <H^1> <H^2>
> H^1 copies its input <H^2> to <H^3> then H1 simulates <H^2> <H^3>
> H^2 copies its input <H^3> to <H^4> then H2 simulates <H^3> <H^4>
> ... n levels (to when H0 aborts
> H0 goes to H0.Qn and H^0 HALTS.
>

Incorrect notation.

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⟩

When the original executing (not simulated) embedded_H sees the
infinitely repeating pattern then it aborts its simulation killing every
simulation in the whole process tree.

> I.E. if embedded_H will only simulate a finite number of iterations, and
> them abort its simulation, there is NO infinite simulation that happens.

No BRAIN DEAD MORON the question is:
Can the simulated ⟨Ĥ⟩ possibly ever reach its own final state?
(a) embedded_H does not abort its simulation: NO
(b) embedded_H aborts its simulation: NO

It is all covered by the self-evidently correct general principle:

When-so-ever the simulation of any input to a simulating halt decider
must be aborted to prevent its infinite simulation this input is
correctly rejected as non-halting.

--
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/17/22 8:20 PM, olcott wrote:
> On 3/17/2022 5:30 PM, Richard Damon wrote:
>>
>> On 3/17/22 5:30 PM, olcott wrote:
>>> On 3/17/2022 3:36 PM, Richard Damon wrote:
>>>>
>>>> On 3/17/22 4:00 PM, olcott wrote:
>>>>> On 3/17/2022 2:30 PM, Richard Damon wrote:
>>>>>>
>>>>>> On 3/17/22 10:06 AM, olcott wrote:
>>>>>>> On 3/16/2022 10:02 PM, Richard Damon wrote:
>>>>>>> Ĥ applied to ⟨Ĥ⟩ reaches its final state only when embedded_H
>>>>>>> applied to ⟨Ĥ⟩ ⟨Ĥ⟩ aborts its simulation.
>>>>>>
>>>>>> Right, but it DOES reach its final state, so embedded_H, to be
>>>>>> correct, must take that into account. it doesn't, so it gives the
>>>>>> WRONG answer.
>>>>>>
>>>>>
>>>>> No BRAIN DEAD MORON the simulated ⟨Ĥ⟩ never reaches its own final
>>>>> state.
>>>>>
>>>>
>>>> The CORRECT Simulation shows that it does.
>>>>
>>>> H's simulation only doesn't reach that final state because H aborted
>>>> it simulation.
>>>>
>>>
>>> We are not talking about the simulation reaching the final state of
>>> the simulation BRAIN DEAD MORON we are talking about the simulated
>>> input reaching its own final state.
>>>
>>> When Ĥ is applied to ⟨Ĥ⟩
>>>    Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>>
>>> Then these steps would keep repeating:
>>>    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>>    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
>>>    Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩
>>> ⟨Ĥ5⟩...
>>>
>>> The simulated input never reaches its own final state whether or not
>>> embedded_H aborts this simulation.
>>>
>>
>> No, because if embedded_H aborts its simulation, then the trace must be:
>>
>> When H^ is applied <H^>
>> H^0 copies its input <H^1> to <H^2> then H0 simulates <H^1> <H^2>
>> H^1 copies its input <H^2> to <H^3> then H1 simulates <H^2> <H^3>
>> H^2 copies its input <H^3> to <H^4> then H2 simulates <H^3> <H^4>
>> ... n levels (to when H0 aborts
>> H0 goes to H0.Qn and H^0 HALTS.
>>
>
> Incorrect notation.
>
> 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⟩
>
> When the original executing (not simulated) embedded_H sees the
> infinitely repeating pattern then it aborts its simulation killing every
> simulation in the whole process tree.

LEAVING THE ORIGINAL H^ running!!!!

That is the one that reaches its final state.

>
>
>> I.E. if embedded_H will only simulate a finite number of iterations,
>> and them abort its simulation, there is NO infinite simulation that
>> happens.
>
> No BRAIN DEAD MORON the question is:
> Can the simulated ⟨Ĥ⟩ possibly ever reach its own final state?
> (a) embedded_H does not abort its simulation: NO
> (b) embedded_H aborts its simulation: NO

(b) YES, beause the 'simulation' in question is by a REAL UTM, not by
embeeded_H that only played one on TV.

You are getting back to talking about your POOP gain.

>
> It is all covered by the self-evidently correct general principle:
>
> When-so-ever the simulation of any input to a simulating halt decider
> must be aborted to prevent its infinite simulation this input is
> correctly rejected as non-halting.
>

WHICH IS A FALSE STATEMENT.

PROVEN.

JUST SHOWS YOU ARE NOT TALKING ABOUT HALTING.

And that you have no concept of what is TRUTH.

DEFINITION OF HALTING for a computation, if the ACTUAL TURING MACHINE
doing the computation reachs a final state in finite time.

Your 'self-evidently correct general principle' doesn't meet this
requirement in some cases, so it can NOT be 'correct'.

Something that isn't always correct, is in ERROR.

FAIL.

On 3/17/2022 7:26 PM, Richard Damon wrote:
> On 3/17/22 8:20 PM, olcott wrote:
>> On 3/17/2022 5:30 PM, Richard Damon wrote:
>>>
>>> On 3/17/22 5:30 PM, olcott wrote:
>>>> On 3/17/2022 3:36 PM, Richard Damon wrote:
>>>>>
>>>>> On 3/17/22 4:00 PM, olcott wrote:
>>>>>> On 3/17/2022 2:30 PM, Richard Damon wrote:
>>>>>>>
>>>>>>> On 3/17/22 10:06 AM, olcott wrote:
>>>>>>>> On 3/16/2022 10:02 PM, Richard Damon wrote:
>>>>>>>> Ĥ applied to ⟨Ĥ⟩ reaches its final state only when embedded_H
>>>>>>>> applied to ⟨Ĥ⟩ ⟨Ĥ⟩ aborts its simulation.
>>>>>>>
>>>>>>> Right, but it DOES reach its final state, so embedded_H, to be
>>>>>>> correct, must take that into account. it doesn't, so it gives the
>>>>>>> WRONG answer.
>>>>>>>
>>>>>>
>>>>>> No BRAIN DEAD MORON the simulated ⟨Ĥ⟩ never reaches its own final
>>>>>> state.
>>>>>>
>>>>>
>>>>> The CORRECT Simulation shows that it does.
>>>>>
>>>>> H's simulation only doesn't reach that final state because H
>>>>> aborted it simulation.
>>>>>
>>>>
>>>> We are not talking about the simulation reaching the final state of
>>>> the simulation BRAIN DEAD MORON we are talking about the simulated
>>>> input reaching its own final state.
>>>>
>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>    Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>>>
>>>> Then these steps would keep repeating:
>>>>    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>>>    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
>>>>    Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩
>>>> ⟨Ĥ5⟩...
>>>>
>>>> The simulated input never reaches its own final state whether or not
>>>> embedded_H aborts this simulation.
>>>>
>>>
>>> No, because if embedded_H aborts its simulation, then the trace must be:
>>>
>>> When H^ is applied <H^>
>>> H^0 copies its input <H^1> to <H^2> then H0 simulates <H^1> <H^2>
>>> H^1 copies its input <H^2> to <H^3> then H1 simulates <H^2> <H^3>
>>> H^2 copies its input <H^3> to <H^4> then H2 simulates <H^3> <H^4>
>>> ... n levels (to when H0 aborts
>>> H0 goes to H0.Qn and H^0 HALTS.
>>>
>>
>> Incorrect notation.
>>
>> 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⟩
>>
>> When the original executing (not simulated) embedded_H sees the
>> infinitely repeating pattern then it aborts its simulation killing
>> every simulation in the whole process tree.
>
> LEAVING THE ORIGINAL H^ running!!!!
>
> That is the one that reaches its final state.
>

The original Ĥ is the same computation as embedded_H and as I have said
dozens of times no halt decider ever computes the halt status of its
actual self. Halt deciders only compute the halt status of their inputs.

--
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/17/22 8:37 PM, olcott wrote:
> On 3/17/2022 7:26 PM, Richard Damon wrote:
>> On 3/17/22 8:20 PM, olcott wrote:
>>> On 3/17/2022 5:30 PM, Richard Damon wrote:
>>>>
>>>> On 3/17/22 5:30 PM, olcott wrote:
>>>>> On 3/17/2022 3:36 PM, Richard Damon wrote:
>>>>>>
>>>>>> On 3/17/22 4:00 PM, olcott wrote:
>>>>>>> On 3/17/2022 2:30 PM, Richard Damon wrote:
>>>>>>>>
>>>>>>>> On 3/17/22 10:06 AM, olcott wrote:
>>>>>>>>> On 3/16/2022 10:02 PM, Richard Damon wrote:
>>>>>>>>> Ĥ applied to ⟨Ĥ⟩ reaches its final state only when embedded_H
>>>>>>>>> applied to ⟨Ĥ⟩ ⟨Ĥ⟩ aborts its simulation.
>>>>>>>>
>>>>>>>> Right, but it DOES reach its final state, so embedded_H, to be
>>>>>>>> correct, must take that into account. it doesn't, so it gives
>>>>>>>> the WRONG answer.
>>>>>>>>
>>>>>>>
>>>>>>> No BRAIN DEAD MORON the simulated ⟨Ĥ⟩ never reaches its own final
>>>>>>> state.
>>>>>>>
>>>>>>
>>>>>> The CORRECT Simulation shows that it does.
>>>>>>
>>>>>> H's simulation only doesn't reach that final state because H
>>>>>> aborted it simulation.
>>>>>>
>>>>>
>>>>> We are not talking about the simulation reaching the final state of
>>>>> the simulation BRAIN DEAD MORON we are talking about the simulated
>>>>> input reaching its own final state.
>>>>>
>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>    Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>>>>
>>>>> Then these steps would keep repeating:
>>>>>    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩
>>>>> ⟨Ĥ3⟩
>>>>>    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩
>>>>> ⟨Ĥ4⟩
>>>>>    Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩
>>>>> ⟨Ĥ5⟩...
>>>>>
>>>>> The simulated input never reaches its own final state whether or
>>>>> not embedded_H aborts this simulation.
>>>>>
>>>>
>>>> No, because if embedded_H aborts its simulation, then the trace must
>>>> be:
>>>>
>>>> When H^ is applied <H^>
>>>> H^0 copies its input <H^1> to <H^2> then H0 simulates <H^1> <H^2>
>>>> H^1 copies its input <H^2> to <H^3> then H1 simulates <H^2> <H^3>
>>>> H^2 copies its input <H^3> to <H^4> then H2 simulates <H^3> <H^4>
>>>> ... n levels (to when H0 aborts
>>>> H0 goes to H0.Qn and H^0 HALTS.
>>>>
>>>
>>> Incorrect notation.
>>>
>>> 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⟩
>>>
>>> When the original executing (not simulated) embedded_H sees the
>>> infinitely repeating pattern then it aborts its simulation killing
>>> every simulation in the whole process tree.
>>
>> LEAVING THE ORIGINAL H^ running!!!!
>>
>> That is the one that reaches its final state.
>>
>
> The original Ĥ is the same computation as embedded_H and as I have said
> dozens of times no halt decider ever computes the halt status of its
> actual self. Halt deciders only compute the halt status of their inputs.
>
>

Why not? and how can you tell? Remember ALL copies of a given Turing
Machine when given the exact same input behave exzctly the same. That is
a FUNDAMENTAL property of them.

IF you want to dispute that, show an actual counter example, REAL Turing
Machine and input.

Remember the DEFINITION of the correct Halt decider is that:

H applied to <M> w needs to go to H.Qy if M applied to w Halts and to
H.Qn if M applied to w never halts.

There is NO exception in that about if M contains a copy of H, none.

With M = H^, <M> = <H^> and w = <H^> this is EXACTLY the case we have here.

THe only answer is that you are LYING.

Either about the rule or that you are even working on the Halting Problem.

FFFFF A IIIII L
F A A I L
F A A I L
FFFF AAAAA I L
F A A I L
F A A I L
F A A IIIII LLLLL

On 3/17/2022 7:48 PM, Richard Damon wrote:
> On 3/17/22 8:37 PM, olcott wrote:
>> On 3/17/2022 7:26 PM, Richard Damon wrote:
>>> On 3/17/22 8:20 PM, olcott wrote:
>>>> On 3/17/2022 5:30 PM, Richard Damon wrote:
>>>>>
>>>>> On 3/17/22 5:30 PM, olcott wrote:
>>>>>> On 3/17/2022 3:36 PM, Richard Damon wrote:
>>>>>>>
>>>>>>> On 3/17/22 4:00 PM, olcott wrote:
>>>>>>>> On 3/17/2022 2:30 PM, Richard Damon wrote:
>>>>>>>>>
>>>>>>>>> On 3/17/22 10:06 AM, olcott wrote:
>>>>>>>>>> On 3/16/2022 10:02 PM, Richard Damon wrote:
>>>>>>>>>> Ĥ applied to ⟨Ĥ⟩ reaches its final state only when embedded_H
>>>>>>>>>> applied to ⟨Ĥ⟩ ⟨Ĥ⟩ aborts its simulation.
>>>>>>>>>
>>>>>>>>> Right, but it DOES reach its final state, so embedded_H, to be
>>>>>>>>> correct, must take that into account. it doesn't, so it gives
>>>>>>>>> the WRONG answer.
>>>>>>>>>
>>>>>>>>
>>>>>>>> No BRAIN DEAD MORON the simulated ⟨Ĥ⟩ never reaches its own
>>>>>>>> final state.
>>>>>>>>
>>>>>>>
>>>>>>> The CORRECT Simulation shows that it does.
>>>>>>>
>>>>>>> H's simulation only doesn't reach that final state because H
>>>>>>> aborted it simulation.
>>>>>>>
>>>>>>
>>>>>> We are not talking about the simulation reaching the final state
>>>>>> of the simulation BRAIN DEAD MORON we are talking about the
>>>>>> simulated input reaching its own final state.
>>>>>>
>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>    Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩
>>>>>> ⟨Ĥ2⟩
>>>>>>
>>>>>> Then these steps would keep repeating:
>>>>>>    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩
>>>>>> ⟨Ĥ3⟩
>>>>>>    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩
>>>>>> ⟨Ĥ4⟩
>>>>>>    Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩
>>>>>> ⟨Ĥ5⟩...
>>>>>>
>>>>>> The simulated input never reaches its own final state whether or
>>>>>> not embedded_H aborts this simulation.
>>>>>>
>>>>>
>>>>> No, because if embedded_H aborts its simulation, then the trace
>>>>> must be:
>>>>>
>>>>> When H^ is applied <H^>
>>>>> H^0 copies its input <H^1> to <H^2> then H0 simulates <H^1> <H^2>
>>>>> H^1 copies its input <H^2> to <H^3> then H1 simulates <H^2> <H^3>
>>>>> H^2 copies its input <H^3> to <H^4> then H2 simulates <H^3> <H^4>
>>>>> ... n levels (to when H0 aborts
>>>>> H0 goes to H0.Qn and H^0 HALTS.
>>>>>
>>>>
>>>> Incorrect notation.
>>>>
>>>> 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⟩
>>>>
>>>> When the original executing (not simulated) embedded_H sees the
>>>> infinitely repeating pattern then it aborts its simulation killing
>>>> every simulation in the whole process tree.
>>>
>>> LEAVING THE ORIGINAL H^ running!!!!
>>>
>>> That is the one that reaches its final state.
>>>
>>
>> The original Ĥ is the same computation as embedded_H and as I have
>> said dozens of times no halt decider ever computes the halt status of
>> its actual self. Halt deciders only compute the halt status of their
>> inputs.
>>
>>
>
> Why not? and how can you tell?

Deciders only compute the mapping from their input to their own accept
or reject state. I have proven that the simulated input to embedded_H
cannot possibly reach its own final state and you are simply too
freaking stupid to see this.

--
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/17/22 8:53 PM, olcott wrote:
> On 3/17/2022 7:48 PM, Richard Damon wrote:
>> On 3/17/22 8:37 PM, olcott wrote:
>>> On 3/17/2022 7:26 PM, Richard Damon wrote:
>>>> On 3/17/22 8:20 PM, olcott wrote:
>>>>> On 3/17/2022 5:30 PM, Richard Damon wrote:
>>>>>>
>>>>>> On 3/17/22 5:30 PM, olcott wrote:
>>>>>>> On 3/17/2022 3:36 PM, Richard Damon wrote:
>>>>>>>>
>>>>>>>> On 3/17/22 4:00 PM, olcott wrote:
>>>>>>>>> On 3/17/2022 2:30 PM, Richard Damon wrote:
>>>>>>>>>>
>>>>>>>>>> On 3/17/22 10:06 AM, olcott wrote:
>>>>>>>>>>> On 3/16/2022 10:02 PM, Richard Damon wrote:
>>>>>>>>>>> Ĥ applied to ⟨Ĥ⟩ reaches its final state only when embedded_H
>>>>>>>>>>> applied to ⟨Ĥ⟩ ⟨Ĥ⟩ aborts its simulation.
>>>>>>>>>>
>>>>>>>>>> Right, but it DOES reach its final state, so embedded_H, to be
>>>>>>>>>> correct, must take that into account. it doesn't, so it gives
>>>>>>>>>> the WRONG answer.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> No BRAIN DEAD MORON the simulated ⟨Ĥ⟩ never reaches its own
>>>>>>>>> final state.
>>>>>>>>>
>>>>>>>>
>>>>>>>> The CORRECT Simulation shows that it does.
>>>>>>>>
>>>>>>>> H's simulation only doesn't reach that final state because H
>>>>>>>> aborted it simulation.
>>>>>>>>
>>>>>>>
>>>>>>> We are not talking about the simulation reaching the final state
>>>>>>> of the simulation BRAIN DEAD MORON we are talking about the
>>>>>>> simulated input reaching its own final state.
>>>>>>>
>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>>    Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩
>>>>>>> ⟨Ĥ2⟩
>>>>>>>
>>>>>>> Then these steps would keep repeating:
>>>>>>>    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates
>>>>>>> ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>>>>>>    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates
>>>>>>> ⟨Ĥ3⟩ ⟨Ĥ4⟩
>>>>>>>    Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates
>>>>>>> ⟨Ĥ4⟩ ⟨Ĥ5⟩...
>>>>>>>
>>>>>>> The simulated input never reaches its own final state whether or
>>>>>>> not embedded_H aborts this simulation.
>>>>>>>
>>>>>>
>>>>>> No, because if embedded_H aborts its simulation, then the trace
>>>>>> must be:
>>>>>>
>>>>>> When H^ is applied <H^>
>>>>>> H^0 copies its input <H^1> to <H^2> then H0 simulates <H^1> <H^2>
>>>>>> H^1 copies its input <H^2> to <H^3> then H1 simulates <H^2> <H^3>
>>>>>> H^2 copies its input <H^3> to <H^4> then H2 simulates <H^3> <H^4>
>>>>>> ... n levels (to when H0 aborts
>>>>>> H0 goes to H0.Qn and H^0 HALTS.
>>>>>>
>>>>>
>>>>> Incorrect notation.
>>>>>
>>>>> 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⟩
>>>>>
>>>>> When the original executing (not simulated) embedded_H sees the
>>>>> infinitely repeating pattern then it aborts its simulation killing
>>>>> every simulation in the whole process tree.
>>>>
>>>> LEAVING THE ORIGINAL H^ running!!!!
>>>>
>>>> That is the one that reaches its final state.
>>>>
>>>
>>> The original Ĥ is the same computation as embedded_H and as I have
>>> said dozens of times no halt decider ever computes the halt status of
>>> its actual self. Halt deciders only compute the halt status of their
>>> inputs.
>>>
>>>
>>
>> Why not? and how can you tell?
>
> Deciders only compute the mapping from their input to their own accept
> or reject state.

Which has NOTHING to do with whether on not that mapping depends on the
machine that the decider is part of.

> I have proven that the simulated input to embedded_H
> cannot possibly reach its own final state and you are simply too
> freaking stupid to see this.
>

The fact the PARTIAL simulation done by the Halt Decider doesn't reach a
Halting state is NOT proof that the machine does not halt.

Only showing the ACTUAL machine or a REAL UTM (which by definition never
aborts its simulation) simulation of the input never reaches a final
state is actually proof.

Remember the DEFINITION of the mapping that H is supposed to answer:

H applied to <M> w must go to H.Qy iff M applied to w Halts, and
H applied to <M> w must go to H.Qn iff M applied to w will never halt.

NO mention of a partial simulation by H. NO exception for M containing a
copy of H within it.

FAIL.

This is simple proof that you are just lying and making up stuff, and
have no respect for what Truth actually means.

On 3/17/2022 8:09 PM, Richard Damon wrote:
>
> On 3/17/22 8:53 PM, olcott wrote:
>> On 3/17/2022 7:48 PM, Richard Damon wrote:
>>> On 3/17/22 8:37 PM, olcott wrote:
>>>> On 3/17/2022 7:26 PM, Richard Damon wrote:
>>>>> On 3/17/22 8:20 PM, olcott wrote:
>>>>>> On 3/17/2022 5:30 PM, Richard Damon wrote:
>>>>>>>
>>>>>>> On 3/17/22 5:30 PM, olcott wrote:
>>>>>>>> On 3/17/2022 3:36 PM, Richard Damon wrote:
>>>>>>>>>
>>>>>>>>> On 3/17/22 4:00 PM, olcott wrote:
>>>>>>>>>> On 3/17/2022 2:30 PM, Richard Damon wrote:
>>>>>>>>>>>
>>>>>>>>>>> On 3/17/22 10:06 AM, olcott wrote:
>>>>>>>>>>>> On 3/16/2022 10:02 PM, Richard Damon wrote:
>>>>>>>>>>>> Ĥ applied to ⟨Ĥ⟩ reaches its final state only when
>>>>>>>>>>>> embedded_H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ aborts its simulation.
>>>>>>>>>>>
>>>>>>>>>>> Right, but it DOES reach its final state, so embedded_H, to
>>>>>>>>>>> be correct, must take that into account. it doesn't, so it
>>>>>>>>>>> gives the WRONG answer.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> No BRAIN DEAD MORON the simulated ⟨Ĥ⟩ never reaches its own
>>>>>>>>>> final state.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The CORRECT Simulation shows that it does.
>>>>>>>>>
>>>>>>>>> H's simulation only doesn't reach that final state because H
>>>>>>>>> aborted it simulation.
>>>>>>>>>
>>>>>>>>
>>>>>>>> We are not talking about the simulation reaching the final state
>>>>>>>> of the simulation BRAIN DEAD MORON we are talking about the
>>>>>>>> simulated input reaching its own final state.
>>>>>>>>
>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>>>    Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates
>>>>>>>> ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>>>>>>>
>>>>>>>> Then these steps would keep repeating:
>>>>>>>>    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates
>>>>>>>> ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>>>>>>>    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates
>>>>>>>> ⟨Ĥ3⟩ ⟨Ĥ4⟩
>>>>>>>>    Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates
>>>>>>>> ⟨Ĥ4⟩ ⟨Ĥ5⟩...
>>>>>>>>
>>>>>>>> The simulated input never reaches its own final state whether or
>>>>>>>> not embedded_H aborts this simulation.
>>>>>>>>
>>>>>>>
>>>>>>> No, because if embedded_H aborts its simulation, then the trace
>>>>>>> must be:
>>>>>>>
>>>>>>> When H^ is applied <H^>
>>>>>>> H^0 copies its input <H^1> to <H^2> then H0 simulates <H^1> <H^2>
>>>>>>> H^1 copies its input <H^2> to <H^3> then H1 simulates <H^2> <H^3>
>>>>>>> H^2 copies its input <H^3> to <H^4> then H2 simulates <H^3> <H^4>
>>>>>>> ... n levels (to when H0 aborts
>>>>>>> H0 goes to H0.Qn and H^0 HALTS.
>>>>>>>
>>>>>>
>>>>>> Incorrect notation.
>>>>>>
>>>>>> 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⟩
>>>>>>
>>>>>> When the original executing (not simulated) embedded_H sees the
>>>>>> infinitely repeating pattern then it aborts its simulation killing
>>>>>> every simulation in the whole process tree.
>>>>>
>>>>> LEAVING THE ORIGINAL H^ running!!!!
>>>>>
>>>>> That is the one that reaches its final state.
>>>>>
>>>>
>>>> The original Ĥ is the same computation as embedded_H and as I have
>>>> said dozens of times no halt decider ever computes the halt status
>>>> of its actual self. Halt deciders only compute the halt status of
>>>> their inputs.
>>>>
>>>>
>>>
>>> Why not? and how can you tell?
>>
>> Deciders only compute the mapping from their input to their own accept
>> or reject state.
>
> Which has NOTHING to do with whether on not that mapping depends on the
> machine that the decider is part of.
>
>> I have proven that the simulated input to embedded_H cannot possibly
>> reach its own final state and you are simply too freaking stupid to
>> see this.
>>
>
> The fact the PARTIAL simulation done by the Halt Decider doesn't reach a
> Halting state is NOT proof that the machine does not halt.
>
The fact that neither a partial nor a full simulation of the input could
possibly reach the final state of this input conclusively proves that it
never halts YOU BRAIN DEAD MORON.

--
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/17/22 9:26 PM, olcott wrote:
> On 3/17/2022 8:09 PM, Richard Damon wrote:
>>
>> On 3/17/22 8:53 PM, olcott wrote:
>>> On 3/17/2022 7:48 PM, Richard Damon wrote:
>>>> On 3/17/22 8:37 PM, olcott wrote:
>>>>> On 3/17/2022 7:26 PM, Richard Damon wrote:
>>>>>> On 3/17/22 8:20 PM, olcott wrote:
>>>>>>> On 3/17/2022 5:30 PM, Richard Damon wrote:
>>>>>>>>
>>>>>>>> On 3/17/22 5:30 PM, olcott wrote:
>>>>>>>>> On 3/17/2022 3:36 PM, Richard Damon wrote:
>>>>>>>>>>
>>>>>>>>>> On 3/17/22 4:00 PM, olcott wrote:
>>>>>>>>>>> On 3/17/2022 2:30 PM, Richard Damon wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> On 3/17/22 10:06 AM, olcott wrote:
>>>>>>>>>>>>> On 3/16/2022 10:02 PM, Richard Damon wrote:
>>>>>>>>>>>>> Ĥ applied to ⟨Ĥ⟩ reaches its final state only when
>>>>>>>>>>>>> embedded_H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ aborts its simulation.
>>>>>>>>>>>>
>>>>>>>>>>>> Right, but it DOES reach its final state, so embedded_H, to
>>>>>>>>>>>> be correct, must take that into account. it doesn't, so it
>>>>>>>>>>>> gives the WRONG answer.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> No BRAIN DEAD MORON the simulated ⟨Ĥ⟩ never reaches its own
>>>>>>>>>>> final state.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The CORRECT Simulation shows that it does.
>>>>>>>>>>
>>>>>>>>>> H's simulation only doesn't reach that final state because H
>>>>>>>>>> aborted it simulation.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> We are not talking about the simulation reaching the final
>>>>>>>>> state of the simulation BRAIN DEAD MORON we are talking about
>>>>>>>>> the simulated input reaching its own final state.
>>>>>>>>>
>>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>>>>    Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates
>>>>>>>>> ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>>>>>>>>
>>>>>>>>> Then these steps would keep repeating:
>>>>>>>>>    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates
>>>>>>>>> ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>>>>>>>>    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates
>>>>>>>>> ⟨Ĥ3⟩ ⟨Ĥ4⟩
>>>>>>>>>    Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates
>>>>>>>>> ⟨Ĥ4⟩ ⟨Ĥ5⟩...
>>>>>>>>>
>>>>>>>>> The simulated input never reaches its own final state whether
>>>>>>>>> or not embedded_H aborts this simulation.
>>>>>>>>>
>>>>>>>>
>>>>>>>> No, because if embedded_H aborts its simulation, then the trace
>>>>>>>> must be:
>>>>>>>>
>>>>>>>> When H^ is applied <H^>
>>>>>>>> H^0 copies its input <H^1> to <H^2> then H0 simulates <H^1> <H^2>
>>>>>>>> H^1 copies its input <H^2> to <H^3> then H1 simulates <H^2> <H^3>
>>>>>>>> H^2 copies its input <H^3> to <H^4> then H2 simulates <H^3> <H^4>
>>>>>>>> ... n levels (to when H0 aborts
>>>>>>>> H0 goes to H0.Qn and H^0 HALTS.
>>>>>>>>
>>>>>>>
>>>>>>> Incorrect notation.
>>>>>>>
>>>>>>> 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⟩
>>>>>>>
>>>>>>> When the original executing (not simulated) embedded_H sees the
>>>>>>> infinitely repeating pattern then it aborts its simulation
>>>>>>> killing every simulation in the whole process tree.
>>>>>>
>>>>>> LEAVING THE ORIGINAL H^ running!!!!
>>>>>>
>>>>>> That is the one that reaches its final state.
>>>>>>
>>>>>
>>>>> The original Ĥ is the same computation as embedded_H and as I have
>>>>> said dozens of times no halt decider ever computes the halt status
>>>>> of its actual self. Halt deciders only compute the halt status of
>>>>> their inputs.
>>>>>
>>>>>
>>>>
>>>> Why not? and how can you tell?
>>>
>>> Deciders only compute the mapping from their input to their own
>>> accept or reject state.
>>
>> Which has NOTHING to do with whether on not that mapping depends on
>> the machine that the decider is part of.
>>
>>> I have proven that the simulated input to embedded_H cannot possibly
>>> reach its own final state and you are simply too freaking stupid to
>>> see this.
>>>
>>
>> The fact the PARTIAL simulation done by the Halt Decider doesn't reach
>> a Halting state is NOT proof that the machine does not halt.
>>
> The fact that neither a partial nor a full simulation of the input could
> possibly reach the final state of this input conclusively proves that it
> never halts YOU BRAIN DEAD MORON.
>

Please check your brain again.

Partial simulations prove nothing about halting.

If H <H^> <H^> -> H.Qn then BY CONSTRUCTION H^ <H^> also goes to H^.Qn
and Halts.

The fact that H's PARTIAL simulation doesn't see this, just proves that
it (and thus YOU) used invalid logic to conclude that the CORRECT
simulation of H's input wouldn't halt even if H goes to H.Qn, because it
NEVER thought of that case.

H only assumes that it will never abort, and thus never go to H.Qn, and
from that concludes its input will not Halt, neglecting that by aborting
its simulation and going to H.Qn it has violated its assumption, and is
now guilty of using a false premise in an implication, which is unsound.

This is a common flaw for you, you never actually make sure your
premises are actually true, when you apply your logical arguements, and
thus you get unsound results.

(And many times you just assert as True a premise that is actaully
false, throwing your logic into inconsistency).

On 3/17/2022 9:08 PM, Richard Damon wrote:
> On 3/17/22 9:26 PM, olcott wrote:
>> On 3/17/2022 8:09 PM, Richard Damon wrote:
>>>
>>> On 3/17/22 8:53 PM, olcott wrote:
>>>> On 3/17/2022 7:48 PM, Richard Damon wrote:
>>>>> On 3/17/22 8:37 PM, olcott wrote:
>>>>>> On 3/17/2022 7:26 PM, Richard Damon wrote:
>>>>>>> On 3/17/22 8:20 PM, olcott wrote:
>>>>>>>> On 3/17/2022 5:30 PM, Richard Damon wrote:
>>>>>>>>>
>>>>>>>>> On 3/17/22 5:30 PM, olcott wrote:
>>>>>>>>>> On 3/17/2022 3:36 PM, Richard Damon wrote:
>>>>>>>>>>>
>>>>>>>>>>> On 3/17/22 4:00 PM, olcott wrote:
>>>>>>>>>>>> On 3/17/2022 2:30 PM, Richard Damon wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 3/17/22 10:06 AM, olcott wrote:
>>>>>>>>>>>>>> On 3/16/2022 10:02 PM, Richard Damon wrote:
>>>>>>>>>>>>>> Ĥ applied to ⟨Ĥ⟩ reaches its final state only when
>>>>>>>>>>>>>> embedded_H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ aborts its simulation.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Right, but it DOES reach its final state, so embedded_H, to
>>>>>>>>>>>>> be correct, must take that into account. it doesn't, so it
>>>>>>>>>>>>> gives the WRONG answer.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> No BRAIN DEAD MORON the simulated ⟨Ĥ⟩ never reaches its own
>>>>>>>>>>>> final state.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The CORRECT Simulation shows that it does.
>>>>>>>>>>>
>>>>>>>>>>> H's simulation only doesn't reach that final state because H
>>>>>>>>>>> aborted it simulation.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> We are not talking about the simulation reaching the final
>>>>>>>>>> state of the simulation BRAIN DEAD MORON we are talking about
>>>>>>>>>> the simulated input reaching its own final state.
>>>>>>>>>>
>>>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>>>>>    Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates
>>>>>>>>>> ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>>>>>>>>>
>>>>>>>>>> Then these steps would keep repeating:
>>>>>>>>>>    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates
>>>>>>>>>> ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>>>>>>>>>    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates
>>>>>>>>>> ⟨Ĥ3⟩ ⟨Ĥ4⟩
>>>>>>>>>>    Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates
>>>>>>>>>> ⟨Ĥ4⟩ ⟨Ĥ5⟩...
>>>>>>>>>>
>>>>>>>>>> The simulated input never reaches its own final state whether
>>>>>>>>>> or not embedded_H aborts this simulation.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> No, because if embedded_H aborts its simulation, then the trace
>>>>>>>>> must be:
>>>>>>>>>
>>>>>>>>> When H^ is applied <H^>
>>>>>>>>> H^0 copies its input <H^1> to <H^2> then H0 simulates <H^1> <H^2>
>>>>>>>>> H^1 copies its input <H^2> to <H^3> then H1 simulates <H^2> <H^3>
>>>>>>>>> H^2 copies its input <H^3> to <H^4> then H2 simulates <H^3> <H^4>
>>>>>>>>> ... n levels (to when H0 aborts
>>>>>>>>> H0 goes to H0.Qn and H^0 HALTS.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Incorrect notation.
>>>>>>>>
>>>>>>>> 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⟩
>>>>>>>>
>>>>>>>> When the original executing (not simulated) embedded_H sees the
>>>>>>>> infinitely repeating pattern then it aborts its simulation
>>>>>>>> killing every simulation in the whole process tree.
>>>>>>>
>>>>>>> LEAVING THE ORIGINAL H^ running!!!!
>>>>>>>
>>>>>>> That is the one that reaches its final state.
>>>>>>>
>>>>>>
>>>>>> The original Ĥ is the same computation as embedded_H and as I have
>>>>>> said dozens of times no halt decider ever computes the halt status
>>>>>> of its actual self. Halt deciders only compute the halt status of
>>>>>> their inputs.
>>>>>>
>>>>>>
>>>>>
>>>>> Why not? and how can you tell?
>>>>
>>>> Deciders only compute the mapping from their input to their own
>>>> accept or reject state.
>>>
>>> Which has NOTHING to do with whether on not that mapping depends on
>>> the machine that the decider is part of.
>>>
>>>> I have proven that the simulated input to embedded_H cannot possibly
>>>> reach its own final state and you are simply too freaking stupid to
>>>> see this.
>>>>
>>>
>>> The fact the PARTIAL simulation done by the Halt Decider doesn't
>>> reach a Halting state is NOT proof that the machine does not halt.
>>>
>> The fact that neither a partial nor a full simulation of the input
>> could possibly reach the final state of this input conclusively proves
>> that it never halts YOU BRAIN DEAD MORON.
>>
>
> Please check your brain again.
>
> Partial simulations prove nothing about halting.

neither a partial nor a full simulation of the input
could possibly reach the final state of this input

neither a partial nor a full simulation of the input
could possibly reach the final state of this input

neither a partial nor a full simulation of the input
could possibly reach the final state of this input

neither a partial nor a full simulation of the input
could possibly reach the final state of this input

neither a partial nor a full simulation of the input
could possibly reach the final state of this input

neither a partial nor a full simulation of the input
could possibly reach the final state of this input

neither a partial nor a full simulation of the input
could possibly reach the final state of this input

neither a partial nor a full simulation of the input
could possibly reach the final state of this input

neither a partial nor a full simulation of the input
could possibly reach the final state of this input

neither a partial nor a full simulation of the input
could possibly reach the final state of this input

neither a partial nor a full simulation of the input
could possibly reach the final state of this input

neither a partial nor a full simulation of the input
could possibly reach the final state of this input

neither a partial nor a full simulation of the input
could possibly reach the final state of this input

neither a partial nor a full simulation of the input
could possibly reach the final state of this input

On 3/17/22 10:56 PM, olcott wrote (many times):

> neither a partial nor a full simulation of the input
> could possibly reach the final state of this input
>

3 year old behavior and a LIE.

A CORRECT FULL SIMULATION of the input WILL reach the final state if H
aborts its simulation, having done just a partial simulation, and went
to H.Qn.

This has been PROVEN, and even accepted by you in the past.

What doesn't happen is H being able to reach that point in its
simulation due to it not being 'smart' enough. And this doesn't acutally
matter, no matter how much you want it to be, because that isn't what
the definition of 'Halting' asks about.

Halting ALWAYS asks about the behavior of the actual computation. We can
replace that with a simulation, IF the simulation meets the requrements
of being a actual UTM, because by the definition of a UTM, that matches
the behavior of the actual computation. Your H does not meet this
definition, so it does not provide direct proof of Non-Halting.

If H <H^> <H^> answer Non-Halting by going to H.Qn, then H^ <H^> is
Halting, and thus <H^> <H^> represents a Halting Computation and thus H
was WRONG about the input <H^> <H^>

I H <H^> <H^> does NOT abort its simulation, then yes, it shows that the
input (which is a different input because it was built on a different H)
is non-halting, but will fail to give that answer, so it is still wrong.
Knowing the answer but not giving it doesn't meet the requirements of a
Halt Decider.

You are making the elementary error of using the wrong definition of
your terms.

Your behavior shows that you don't actually care about the field or
about what is actually true.

On 3/18/2022 8:22 AM, Richard Damon wrote:
> On 3/17/22 10:56 PM, olcott wrote (many times):
>
>> neither a partial nor a full simulation of the input
>> could possibly reach the final state of this input
>>
>
> 3 year old behavior and a LIE.
>
> A CORRECT FULL SIMULATION of the input WILL reach the final state if H
> aborts its simulation,
So in other words once a process has been killed such that it is no
longer running it will still finish running even though it is dead.

If you yank the power cord from your computer while it is compiling a
C++ program the machine will still complete the compilation process
totally unaware that it is completely dead.

BRAIN DEAD MORON.

--
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/18/22 10:14 AM, olcott wrote:
> On 3/18/2022 8:22 AM, Richard Damon wrote:
>> On 3/17/22 10:56 PM, olcott wrote (many times):
>>
>>> neither a partial nor a full simulation of the input
>>> could possibly reach the final state of this input
>>>
>>
>> 3 year old behavior and a LIE.
>>
>> A CORRECT FULL SIMULATION of the input WILL reach the final state if H
>> aborts its simulation,
> So in other words once a process has been killed such that it is no
> longer running it will still finish running even though it is dead.

Category Error. Turing Machines are NOT 'Processes' like in a computer.
The simulation isn't the actual machine, just a simulation of it.

>
> If you yank the power cord from your computer while it is compiling a
> C++ program the machine will still complete the compilation process
> totally unaware that it is completely dead.

Bad analogy. If you turn off the game because your team is doing baddly,
the game doesn't stop.

Remember, H is just SIMULATING the operation of the machine, it isn't
the machine itself.

Perhaps a different thing with your example, yanking the power cord from
your computer while it is compiling a C++ program doesn't affect whether
that C++ program is valid or not, just if you know it is. The program
either has errors or it doesn't, just like H^(<H^>) will either
eventually Halt or not. Aborting the running of H^ mid-operation doesn't
affect what it would do if actually fully run, which is what Halting
talks about.

H is just DECIDING on the properties of H^, not actually creating the
existence of it. H^ exists and has behavior on all inputs whether we
actually perform the operation on some actual hardware.

In particular, the program H^ applied to <H^> WILL either complete to a
Halt or never come to a halt when actually run, whether or not we
actually run it. H is just a tool to try to determine what this will be,
it DOESN'T actually define that results.

You seem to fundamentally not understand this aspect of Turing Machine,
or Computations in general. The Computation is what WOULD/WILL happen if
we actually did perform the calculation. It is a THEORETICAL quantity,
not actually based on actually performing the action. Starting and
aborting a physical implementation of that calculation doesn't mean the
Computation can't ever be done.

You seem to not to be able to tell the difference between the 'abstract'
concept of the actual behavior of the defined computation of H^ when
applied to the description of itself, to the concrete instance of H
simulating this behavior.

>
> BRAIN DEAD MORON.
>

Good and apt signature!

On 3/18/2022 9:47 AM, Richard Damon wrote:
>
> On 3/18/22 10:14 AM, olcott wrote:
>> On 3/18/2022 8:22 AM, Richard Damon wrote:
>>> On 3/17/22 10:56 PM, olcott wrote (many times):
>>>
>>>> neither a partial nor a full simulation of the input
>>>> could possibly reach the final state of this input
>>>>
>>>
>>> 3 year old behavior and a LIE.
>>>
>>> A CORRECT FULL SIMULATION of the input WILL reach the final state if
>>> H aborts its simulation,
>> So in other words once a process has been killed such that it is no
>> longer running it will still finish running even though it is dead.
>
> Category Error. Turing Machines are NOT 'Processes' like in a computer.
> The simulation isn't the actual machine, just a simulation of it.
>
There is a Turing machine that is being executed: embedded_H and there
is a Turing machine description: ⟨Ĥ⟩ that is being simulated by this
first Turing machine. When embedded_H aborts its simulation, the
simulated machine: ⟨Ĥ⟩ immediately stops and is totally dead.

--
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/18/22 10:53 AM, olcott wrote:
> On 3/18/2022 9:47 AM, Richard Damon wrote:
>>
>> On 3/18/22 10:14 AM, olcott wrote:
>>> On 3/18/2022 8:22 AM, Richard Damon wrote:
>>>> On 3/17/22 10:56 PM, olcott wrote (many times):
>>>>
>>>>> neither a partial nor a full simulation of the input
>>>>> could possibly reach the final state of this input
>>>>>
>>>>
>>>> 3 year old behavior and a LIE.
>>>>
>>>> A CORRECT FULL SIMULATION of the input WILL reach the final state if
>>>> H aborts its simulation,
>>> So in other words once a process has been killed such that it is no
>>> longer running it will still finish running even though it is dead.
>>
>> Category Error. Turing Machines are NOT 'Processes' like in a
>> computer. The simulation isn't the actual machine, just a simulation
>> of it.
>>
> There is a Turing machine that is being executed: embedded_H and there
> is a Turing machine description: ⟨Ĥ⟩ that is being simulated by this
> first Turing machine. When embedded_H aborts its simulation, the
> simulated machine: ⟨Ĥ⟩ immediately stops and is totally dead.
>

The SIMULATION stops, the behavior of the ACTUAL Turing Machine, which
is what HALT refers to, does NOT.

Your focus on the PARTIAL simulation by H, is incorrect for Halting, and
is what makes your whole argument about POOP and not Halting.

Remember the DEFINITION of what H is supposed to do to be correct:

H applied to <M> w needs to go to H.Qy if M applied to w Halts.
H applied to <M> w needs to go to H.Qn if M applied to w never Halts.

The criteria is on M not <M>, and thus H^, not <H^>, so the partial
simulation of H on this input isn't important, only what the ACTUAL
Turing Machine would have done.

This IS a mapping of the actual input, <M> w, but the result of that
mapping (which is allowed to be ANYTHING that can based solely on that
input) is dependent on the behavior of the described Computation
(Machine applied to input). Note, there are many mappings that aren't
computable, and the theory allows for them, it just says that the
mapping/Function isn't called 'Computable'. If H can't actually
determine the needed result, it might be because the mapping/Function
just isn't Computable, which is what the Halting Theorem states, that
the Halting Function/mapping is not finite computable by a Turing
Machine (or equivalent).

You keep on saying that this actual behavior doesn't matter, but there
is absolutely ZERO basis to make that claim, as it is the DEFINITION.
There is NO exception in the definition for M including a copy of H in
its algorithm. This may make a simulating Halt decider much harder (or
impossible) to actually implement, but that just shows that this method
is incorrect, not that the definition is wrong.

On 3/18/2022 10:49 AM, Richard Damon wrote:
>
> On 3/18/22 10:53 AM, olcott wrote:
>> On 3/18/2022 9:47 AM, Richard Damon wrote:
>>>
>>> On 3/18/22 10:14 AM, olcott wrote:
>>>> On 3/18/2022 8:22 AM, Richard Damon wrote:
>>>>> On 3/17/22 10:56 PM, olcott wrote (many times):
>>>>>
>>>>>> neither a partial nor a full simulation of the input
>>>>>> could possibly reach the final state of this input
>>>>>>
>>>>>
>>>>> 3 year old behavior and a LIE.
>>>>>
>>>>> A CORRECT FULL SIMULATION of the input WILL reach the final state
>>>>> if H aborts its simulation,
>>>> So in other words once a process has been killed such that it is no
>>>> longer running it will still finish running even though it is dead.
>>>
>>> Category Error. Turing Machines are NOT 'Processes' like in a
>>> computer. The simulation isn't the actual machine, just a simulation
>>> of it.
>>>
>> There is a Turing machine that is being executed: embedded_H and there
>> is a Turing machine description: ⟨Ĥ⟩ that is being simulated by this
>> first Turing machine. When embedded_H aborts its simulation, the
>> simulated machine: ⟨Ĥ⟩ immediately stops and is totally dead.
>>
>
> The SIMULATION stops, the behavior of the ACTUAL Turing Machine, which
> is what HALT refers to, does NOT.
>

No BRAIN DEAD MORON this is not true, I keep calling you a BRAIN DEAD
MORON because after I have explain all the details you cannot remember
what I just said.

A decider maps its inputs to its own accept reject state.
A halt decider does not compute the halt status of itself.

A decider maps its inputs to its own accept reject state.
A halt decider does not compute the halt status of itself.

A decider maps its inputs to its own accept reject state.
A halt decider does not compute the halt status of itself.

A decider maps its inputs to its own accept reject state.
A halt decider does not compute the halt status of itself.

A decider maps its inputs to its own accept reject state.
A halt decider does not compute the halt status of itself.

A decider maps its inputs to its own accept reject state.
A halt decider does not compute the halt status of itself.

A decider maps its inputs to its own accept reject state.
A halt decider does not compute the halt status of itself.

A decider maps its inputs to its own accept reject state.
A halt decider does not compute the halt status of itself.

A decider maps its inputs to its own accept reject state.
A halt decider does not compute the halt status of itself.

A decider maps its inputs to its own accept reject state.
A halt decider does not compute the halt status of itself.

A decider maps its inputs to its own accept reject state.
A halt decider does not compute the halt status of itself.

A decider maps its inputs to its own accept reject state.
A halt decider does not compute the halt status of itself.

A decider maps its inputs to its own accept reject state.
A halt decider does not compute the halt status of itself.

A decider maps its inputs to its own accept reject state.
A halt decider does not compute the halt status of itself.

A decider maps its inputs to its own accept reject state.
A halt decider does not compute the halt status of itself.

A decider maps its inputs to its own accept reject state.
A halt decider does not compute the halt status of itself.

A decider maps its inputs to its own accept reject state.
A halt decider does not compute the halt status of itself.

A decider maps its inputs to its own accept reject state.
A halt decider does not compute the halt status of itself.

A decider maps its inputs to its own accept reject state.
A halt decider does not compute the halt status of itself.

A decider maps its inputs to its own accept reject state.
A halt decider does not compute the halt status of itself.

A decider maps its inputs to its own accept reject state.
A halt decider does not compute the halt status of itself.

A decider maps its inputs to its own accept reject state.
A halt decider does not compute the halt status of itself.

A decider maps its inputs to its own accept reject state.
A halt decider does not compute the halt status of itself.

A decider maps its inputs to its own accept reject state.
A halt decider does not compute the halt status of itself.

A decider maps its inputs to its own accept reject state.
A halt decider does not compute the halt status of itself.

A decider maps its inputs to its own accept reject state.
A halt decider does not compute the halt status of itself.

A decider maps its inputs to its own accept reject state.
A halt decider does not compute the halt status of itself.

A decider maps its inputs to its own accept reject state.
A halt decider does not compute the halt status of itself.

A decider maps its inputs to its own accept reject state.
A halt decider does not compute the halt status of itself.

A decider maps its inputs to its own accept reject state.
A halt decider does not compute the halt status of itself.

--
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/18/22 11:58 AM, olcott wrote:
> On 3/18/2022 10:49 AM, Richard Damon wrote:
>>
>> On 3/18/22 10:53 AM, olcott wrote:
>>> On 3/18/2022 9:47 AM, Richard Damon wrote:
>>>>
>>>> On 3/18/22 10:14 AM, olcott wrote:
>>>>> On 3/18/2022 8:22 AM, Richard Damon wrote:
>>>>>> On 3/17/22 10:56 PM, olcott wrote (many times):
>>>>>>
>>>>>>> neither a partial nor a full simulation of the input
>>>>>>> could possibly reach the final state of this input
>>>>>>>
>>>>>>
>>>>>> 3 year old behavior and a LIE.
>>>>>>
>>>>>> A CORRECT FULL SIMULATION of the input WILL reach the final state
>>>>>> if H aborts its simulation,
>>>>> So in other words once a process has been killed such that it is no
>>>>> longer running it will still finish running even though it is dead.
>>>>
>>>> Category Error. Turing Machines are NOT 'Processes' like in a
>>>> computer. The simulation isn't the actual machine, just a simulation
>>>> of it.
>>>>
>>> There is a Turing machine that is being executed: embedded_H and
>>> there is a Turing machine description: ⟨Ĥ⟩ that is being simulated by
>>> this first Turing machine. When embedded_H aborts its simulation, the
>>> simulated machine: ⟨Ĥ⟩ immediately stops and is totally dead.
>>>
>>
>> The SIMULATION stops, the behavior of the ACTUAL Turing Machine, which
>> is what HALT refers to, does NOT.
>>
>
> No BRAIN DEAD MORON this is not true, I keep calling you a BRAIN DEAD
> MORON because after I have explain all the details you cannot remember
> what I just said.
>
> A decider maps its inputs to its own accept reject state.
> A halt decider does not compute the halt status of itself.
>
> A decider maps its inputs to its own accept reject state.
> A halt decider does not compute the halt status of itself.
>
> A decider maps its inputs to its own accept reject state.
> A halt decider does not compute the halt status of itself.
>
> A decider maps its inputs to its own accept reject state.
> A halt decider does not compute the halt status of itself.
>
> A decider maps its inputs to its own accept reject state.
> A halt decider does not compute the halt status of itself.
>
> A decider maps its inputs to its own accept reject state.
> A halt decider does not compute the halt status of itself.
>
> A decider maps its inputs to its own accept reject state.
> A halt decider does not compute the halt status of itself.
>
> A decider maps its inputs to its own accept reject state.
> A halt decider does not compute the halt status of itself.
>
> A decider maps its inputs to its own accept reject state.
> A halt decider does not compute the halt status of itself.
>
> A decider maps its inputs to its own accept reject state.
> A halt decider does not compute the halt status of itself.
>
> A decider maps its inputs to its own accept reject state.
> A halt decider does not compute the halt status of itself.
>
> A decider maps its inputs to its own accept reject state.
> A halt decider does not compute the halt status of itself.
>
> A decider maps its inputs to its own accept reject state.
> A halt decider does not compute the halt status of itself.
>
> A decider maps its inputs to its own accept reject state.
> A halt decider does not compute the halt status of itself.
>
> A decider maps its inputs to its own accept reject state.
> A halt decider does not compute the halt status of itself.
>
> A decider maps its inputs to its own accept reject state.
> A halt decider does not compute the halt status of itself.
>
> A decider maps its inputs to its own accept reject state.
> A halt decider does not compute the halt status of itself.
>
> A decider maps its inputs to its own accept reject state.
> A halt decider does not compute the halt status of itself.
>
> A decider maps its inputs to its own accept reject state.
> A halt decider does not compute the halt status of itself.
>
> A decider maps its inputs to its own accept reject state.
> A halt decider does not compute the halt status of itself.
>
> A decider maps its inputs to its own accept reject state.
> A halt decider does not compute the halt status of itself.
>
> A decider maps its inputs to its own accept reject state.
> A halt decider does not compute the halt status of itself.
>
> A decider maps its inputs to its own accept reject state.
> A halt decider does not compute the halt status of itself.
>
> A decider maps its inputs to its own accept reject state.
> A halt decider does not compute the halt status of itself.
>
> A decider maps its inputs to its own accept reject state.
> A halt decider does not compute the halt status of itself.
>
> A decider maps its inputs to its own accept reject state.
> A halt decider does not compute the halt status of itself.
>
> A decider maps its inputs to its own accept reject state.
> A halt decider does not compute the halt status of itself.
>
> A decider maps its inputs to its own accept reject state.
> A halt decider does not compute the halt status of itself.
>
> A decider maps its inputs to its own accept reject state.
> A halt decider does not compute the halt status of itself.
>
> A decider maps its inputs to its own accept reject state.
> A halt decider does not compute the halt status of itself.
>

Your 3 year old mind doesn't understand what a decider does.

A decider needs to map its input to the CORRECT output based on the map
it is computing.

Yes, a halt decider doesn't normally decide on itself, but it does need
to decide based on what its input specifies, and it that includes a copy
of itself, it needs to decide on what that input specifies, which can
include its own behavior.

H <H^> <H^> needs to decide on the behavior of H^ <H^> which happens to
use H <H^> H^> in its calculation, so H DOES need to figure out what
that behavior is to be correct. To say otherwise is just a lie, as it is
true BY DEFINITION.

The fact you don't understand that, means you need to think a bit
harder, and banish the mental blocks you have setup.

You need to find REAL Truth, not the propaganda you have convinces your
self.

FAIL.