On 1/30/2022 8:20 PM, Richard Damon wrote:
> On 1/30/22 9:05 PM, olcott wrote:
>> On 1/30/2022 7:45 PM, Richard Damon wrote:
>>> On 1/30/22 7:21 PM, olcott wrote:
>>>> On 1/30/2022 6:01 PM, Richard Damon wrote:
>>>>> On 1/30/22 6:35 PM, olcott wrote:
>>>>>> On 1/30/2022 5:30 PM, Richard Damon wrote:
>>>>>>> On 1/30/22 6:12 PM, olcott wrote:
>>>>>>>> On 1/30/2022 4:39 PM, Richard Damon wrote:
>>>>>>>>> On 1/30/22 4:21 PM, olcott wrote:
>>>>>>>>>> On 1/30/2022 2:54 PM, Richard Damon wrote:
>>>>>>>>>>> On 1/30/22 3:09 PM, olcott wrote:
>>>>>>>>>>
>>>>>>>>>>>> Because all simulating halt deciders are deciders they are
>>>>>>>>>>>> only accountable for computing the mapping from their input
>>>>>>>>>>>> finite strings to an accept or reject state on the basis of
>>>>>>>>>>>> whether or not their correct simulation of this input can
>>>>>>>>>>>> possibly reach the final state of this simulated input in
>>>>>>>>>>>> any finite number of steps.
>>>>>>>>>>>>
>>>>>>>>>>>> It is like you put a guard on the front door that is
>>>>>>>>>>>> supposed to report anyone coming in the front door (the
>>>>>>>>>>>> actual inputs). Then someone comes in the back door (non
>>>>>>>>>>>> inputs) and the guard does not report this. Since the guard
>>>>>>>>>>>> is only supposed to report people coming in the front door
>>>>>>>>>>>> it is incorrect to say that the guard made a mistake by not
>>>>>>>>>>>> reporting people that came in the back door.
>>>>>>>>>>>>
>>>>>>>>>>>> embedded_H is not supposed to report on the halt status of
>>>>>>>>>>>> the computation that it is contained within: Ĥ applied to ⟨Ĥ⟩.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> So, you have just admitted that you aren't working on the
>>>>>>>>>>> Halting Problem, so any claims therein are just lies.
>>>>>>>>>>>
>>>>>>>>>>> Since the definition of the Halting Problem refers to the
>>>>>>>>>>> ACTUAL behavior of the machine the input represents, and NOT
>>>>>>>>>>> the partial simulation that some simulating halt decider
>>>>>>>>>>> might do, you are admitting that you H is NOT using the
>>>>>>>>>>> Halting Problem definition and thus your claims that your
>>>>>>>>>>> results apply to the Halting problem are just lies.
>>>>>>>>>>>
>>>>>>>>>>> For the Halting Problem, the correct results for the inputs
>>>>>>>>>>> is based on the actual behavior of the machine, or its
>>>>>>>>>>> equivalent the simulation of the input with a REAL UTM. Thus
>>>>>>>>>>> the 'Front Door' to the problem s based on that, so either
>>>>>>>>>>> you your guards are lying or, what seems more likely, you
>>>>>>>>>>> posted them to the wrong door.
>>>>>>>>>>>
>>>>>>>>>>> You have basically just proved that you have totally wasted
>>>>>>>>>>> the last years of your life, as you have been working on the
>>>>>>>>>>> wrong problem, because you just don't understand what the
>>>>>>>>>>> problem you wanted to solve actually was.
>>>>>>>>>>>
>>>>>>>>>>> FAIL.
>>>>>>>>>>
>>>>>>>>>> Sum(int X, int Y) { return X + Y );
>>>>>>>>>>
>>>>>>>>>> It is true that halt deciders must report on the actual
>>>>>>>>>> behavior of their actual inputs in the same way that Sum(2,5)
>>>>>>>>>> must return 7.
>>>>>>>>>
>>>>>>>>> Right, and the correct answer for if H(wM, w) should report
>>>>>>>>> halting is if M x will reach a final state in a finite number
>>>>>>>>> of steps. This is identical to if UTM(wM, w) will halt. Dosn't
>>>>>>>>> matter what you think otherwise, that IS the definition of the
>>>>>>>>> actual behavior.
>>>>>>>>>
>>>>>>>>> It is NOT something based on the partial simulation that H does.
>>>>>>>>>
>>>>>>>>
>>>>>>>> The you cannot understand how all kinds of infinite behavior
>>>>>>>> patterns can be easily recognized in a finite number of steps is
>>>>>>>> not any mistake on my part:
>>>>>>>
>>>>>>> Yes, MANY can, but not ALL.
>>>>>>>
>>>>>>> If you need to change the definition, then you are not working on
>>>>>>> the halting problem.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> I don't have to change the definition I merely make it much more
>>>>>> precise:
>>>>>
>>>>> Except that the original definition IS exactly precise. The is a
>>>>> single WELL DEFINED answer for any instance of the question. The
>>>>> fact that you see some abiguity just shows you don't really
>>>>> understand the field.
>>>>>
>>>>>>
>>>>>> (1) Halting is defined as reaching a final state.
>>>>>
>>>>> But you change the 'of what'.
>>>>
>>>> A directly executed TM halts when it reaches the final state of this
>>>> directly executed TM.
>>>>
>>>> A simulated TM description halts when the simulated TM description
>>>> reaches it final state.
>>>>
>>>
>>> Right, but if the simulator isn't a real UTM and stops simulating,
>>> the 'pure simulation' continues until it either halts or runs for ever.
>>>
>>
>> H.q0 Wm W ⊢* H.qy
>> iff UTM Wm W reaches its final state
>>
>> H.q0 Wm W ⊢* H.qn
>> iff UTM Wm W never reaches its final state
>
>
> Right, and that is the REAL UTM, not H playing one on TV and stopping
> when it thinks it has an answer.
As your scatterbrained mind keep repeating....
Yet I have kept correcting. It is not necessary for a simulating halt
decider to execute an infinite number of steps of an infinite sequence
of configurations for it to determine that a pure simulation of its
input would never stop running.

_Infinite_Loop()
[00000946](01) 55 push ebp
[00000947](02) 8bec mov ebp,esp
[00000949](02) ebfe jmp 00000949
[0000094b](01) 5d pop ebp
[0000094c](01) c3 ret
Size in bytes:(0007) [0000094c]

It is self-evident that the second time the instruction at [00000949] is
executed with no other instructions inbetween an infinite loop has been
recognized.

_Infinite_Recursion()
[00000926](01) 55 push ebp
[00000927](02) 8bec mov ebp,esp
[00000929](03) 8b4508 mov eax,[ebp+08]
[0000092c](01) 50 push eax
[0000092d](05) e8f4ffffff call 00000926
[00000932](03) 83c404 add esp,+04
[00000935](01) 5d pop ebp
[00000936](01) c3 ret
Size in bytes:(0017) [00000936]

Begin Local Halt Decider Simulation Execution Trace Stored at:211356

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[00000926][00211342][00211346] 55 push ebp
[00000927][00211342][00211346] 8bec mov ebp,esp
[00000929][00211342][00211346] 8b4508 mov eax,[ebp+08]
[0000092c][0021133e][00000777] 50 push eax
[0000092d][0021133a][00000932] e8f4ffffff call 00000926
[00000926][00211336][00211342] 55 push ebp
[00000927][00211336][00211342] 8bec mov ebp,esp
[00000929][00211336][00211342] 8b4508 mov eax,[ebp+08]
[0000092c][00211332][00000777] 50 push eax
[0000092d][0021132e][00000932] e8f4ffffff call 00000926
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

It is self-evident that the second time the instruction at [0000092d] is
executed with with the same input infinite recursion has been recognized.

It is self evident that when Ĥ is applied to ⟨Ĥ⟩ simulated ⟨Ĥ⟩ applied
to ⟨Ĥ⟩ never transitions to ⟨Ĥ⟩.qn.

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

--
Copyright 2021 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer