On 9/4/2021 5:39 PM, Richard Damon wrote:
> On 9/4/21 6:15 PM, olcott wrote:
>> On 9/4/2021 5:01 PM, Richard Damon wrote:
>>> On 9/4/21 4:59 PM, olcott wrote:
>>>> On 9/4/2021 3:48 PM, Richard Damon wrote:
>>>>> On 9/4/21 2:47 PM, olcott wrote:
>>>>>> On 9/4/2021 1:15 PM, Richard Damon wrote:
>>>>>>> On 9/4/21 1:46 PM, olcott wrote:
>>>>>>>> On 9/4/2021 12:34 PM, Richard Damon wrote:
>>>>>>>>> On 9/4/21 1:21 PM, olcott wrote:
>>>>>>>>>> On 9/4/2021 12:13 PM, Richard Damon wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> He says:
>>>>>>>>>>>
>>>>>>>>>>> If M enters an infinite loop, then no matter how long we wait,
>>>>>>>>>>> we can
>>>>>>>>>>> never be sure that M is in fact in a loop. It may simply be a
>>>>>>>>>>> case
>>>>>>>>>>> of a
>>>>>>>>>>> very long computation. What we need is an algorithm that can
>>>>>>>>>>> determine
>>>>>>>>>>> the correct answer for any M and w by performing some analysis
>>>>>>>>>>> on the
>>>>>>>>>>> machine's description and the input. But as we now show, no such
>>>>>>>>>>> algorithm exists.
>>>>>>>>>>>
>>>>>>>>>>> Thus he recognized that the issue with a simulating decider would
>>>>>>>>>>> be it
>>>>>>>>>>
>>>>>>>>>> No he recognized the very obvious issue of using a simulator
>>>>>>>>>> instead of
>>>>>>>>>> a decider. No one besides me has ever considered a simulating halt
>>>>>>>>>> decider that examines the simulated execution trace for non
>>>>>>>>>> halting
>>>>>>>>>> patterns of behavior.
>>>>>>>>>
>>>>>>>>> Nope, He understood the issues involved. Maybe if you had studied
>>>>>>>>> some
>>>>>>>>> of the field you would know that the limitation of Halt Deciding by
>>>>>>>>> Simulating are WELL known, and have been shown to be impossible in
>>>>>>>>> general.
>>>>>>>>>
>>>>>>>>
>>>>>>>> In the text that you referenced he was only referring to using a
>>>>>>>> simulator as a decider. He was not referring to using a simulating
>>>>>>>> decider that examines the execution trace of the simulation to look
>>>>>>>> for
>>>>>>>> non halting behavior patterns.
>>>>>>>
>>>>>>> Nope, maybe he doesn't explicitly call it that, but his words
>>>>>>> definitely
>>>>>>> reference the well known and studied limitation of simulation for
>>>>>>> halt
>>>>>>> deciding.
>>>>>>
>>>>>> Of course. If you want to tell if an infinite loops halts you sure as
>>>>>> Hell can't simply wait and see what happens.
>>>>>>
>>>>>> It is getting to the point where I am convinced that you are simply
>>>>>> lying. If you are aware of any source besides me that proposes a
>>>>>> simulating halt decider that specifically examines the execution trace
>>>>>> of its simulation to match non-halting behavior patterns of its input
>>>>>> then PUT UP OR SHUT UP !!!
>>>>>>
>>>>>
>>>>> Most of the stuff I know was pre-internet, so not easy to find.
>>>>>
>>>>> Here is one example of a reference to this from a decade ago:
>>>>> https://math.stackexchange.com/questions/27606/detecting-cycles-in-off-line-turing-machines
>>>>>
>>>>>
>>>>>
>>>>> This mentions one of the techniques used for detecting SOME forms of
>>>>> infinite loops.
>>>>>
>>>>> Here is another person needing to solve the halting problem for a
>>>>> limited case, and was given a few examples of classical methods (like
>>>>> detecting repeating state) to detect an infinite loop.
>>>>>
>>>>> https://try2explore.com/questions/10671161
>>>>>
>>>>> And then there is this article on detecting the non-termination of
>>>>> Turing Machines, to look for solutions to things like the Busy-Beaver
>>>>> problem:
>>>>>
>>>>> https://dl.acm.org/doi/pdf/10.5555/1273694.1273703
>>>>>
>>>>> While not specifically a 'simulating Halt Decider' it is trying to
>>>>> solve
>>>>> the same basic problem.
>>>>>
>>>>>>> Maybe the fact that you refuse to study the field means you
>>>>>>> don't recognize that, and are dooming yourself to repeating all the
>>>>>>> mistakes that have been worked through over the century,
>>>>>>
>>>>>> PUT UP OR SHUT UP !!!
>>>>>> PUT UP OR SHUT UP !!!
>>>>>> PUT UP OR SHUT UP !!!
>>>>>> PUT UP OR SHUT UP !!!
>>>>>
>>>>> Will you now SHUT UP that NO ONE has looked at this before?
>>>>
>>>> My original words included to the same extent that I have.
>>>>
>>>> None-the-less is seems clear that you now do understand that when Linz
>>>> referred to a UTM he was only referring to using a UTM as a halt
>>>> decider, not using a hybrid UTM halt decider that examines the execution
>>>> trace of its input.
>>>>
>>>
>>> Nope, because I remember when I was in school, it was already
>>> established that Simulating Halt Deciding did not show much promise as
>>> there were serious limits as to what you could detect. Linz knew that
>>> and knew that mentiones in passing that it couldn't know enough to make
>>> the decision.
>>>
>>> Also, since he proved it for ALL Halt deciders, he proved it for
>>> Simulating Halt Deciders, as those are within the class of Halt
>>> Deciders, and can't do anything that a 'generic' Halt Decider can't do.
>>>
>>
>> None-the-less int main() { H1(P,P); } does correctly report that its
>> input halts on the basis that H(P,P) does correctly report that its
>> input never halts.
>>
>
> But since H^ was built on H, it is H that needs to get the answer right,
> not H1, and it doesn't
>
> If you want to claim that they are the same machine, you need to explain
> how they give different answers for the same input, which shows they are
> Computations.
>
>> If you knew the x86 language and software engineering well enough you
>> would know that the following execution trace of the simulation of P(P)
>> matches the infinite recursion behavior pattern and you would know that
>> the infinite recursion behavior pattern is correct.
>>
>
> Nope, since it skips over the CONDITIONAL code of H.
>
> That code needs to be traced and shown to be unconditional.
>
>> THAT YOU SIMPLY DON'T KNOW THESE THINGS WELL ENOUGH IS PROVEN BY THE
>> FACT THAT YOU ALWAYS CHANGE THE SUBJECT INSTEAD OF DIRECT POINTING OUT
>> ANY ERROR
>>
>
> WRONG. I keep pointing out that you build your arguement on false
> foundations.
> >
>> Begin Local Halt Decider Simulation at Machine Address:c36
>> [00000c36][002117ca][002117ce] 55          push ebp
>> [00000c37][002117ca][002117ce] 8bec        mov ebp,esp
>> [00000c39][002117ca][002117ce] 8b4508      mov eax,[ebp+08]
>> [00000c3c][002117c6][00000c36] 50          push eax       // push P
>> [00000c3d][002117c6][00000c36] 8b4d08      mov ecx,[ebp+08]
>> [00000c40][002117c2][00000c36] 51          push ecx       // push P
>> [00000c41][002117be][00000c46] e820fdffff  call 00000966  // call H(P,P)
>>
>> [00000c36][0025c1f2][0025c1f6] 55          push ebp
>> [00000c37][0025c1f2][0025c1f6] 8bec        mov ebp,esp
>> [00000c39][0025c1f2][0025c1f6] 8b4508      mov eax,[ebp+08]
>> [00000c3c][0025c1ee][00000c36] 50          push eax       // push P
>> [00000c3d][0025c1ee][00000c36] 8b4d08      mov ecx,[ebp+08]
>> [00000c40][0025c1ea][00000c36] 51          push ecx       // push P
>> [00000c41][0025c1e6][00000c46] e820fdffff  call 00000966  // call H(P,P)
>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>
>> This infinite recursion detection criteria are met by the above
>> execution trace:
>> (a) P calls H twice in sequence from the same machine address.
>> (b) With the same parameters: (P,P) to H.
>> (c) With no conditional branch or indexed jump instructions in the
>> execution trace of P.
>
> Only because the trace is incorrect.
>
>> (d) We know that there are no return instructions in H because we know
>> that H is in pure simulation mode.
>
>
> The H can NEVER answer even as a top level machine, so THAT is false too.
>
> Remember there is no such thing a 'Pure Simulator Mode', something is or
> it isn't a Pure Simulator. H isn't if it ever answer H(H^,H^)

That the entire time that the halt decider is making its halt status
decision the halt decider has no behavior what-so-ever that can have any
effect on the behavior of its simulated input seems to be beyond your
intellectual capacity to comprehend.

>
> FAIL.
>

--
Copyright 2021 Pete Olcott

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