On 9/4/21 6:52 PM, olcott wrote:
> 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.

But, once H makes its decision and leave that state, it PROVES thst it
NEVER WAS a pure simulator.

It isn't the H that is doing the simulation that is the problem, it is
the assumption that the simulator you are simulation will FOREVER be a
PURE Simulator and NEVER abort its simulation that is the problem. This
behavior doesn't affect the behavior of the machine the simulated
simulator was simulating, but DOES affect the behavior of the machine
that the top simulator was simulating and this simulated simulator
returns an answer to, that the top level simulator assumed could never
happen because it stopped it simulation before that.

As you say, the top level simulator can have no affext on the machine it
is simulating (assuming it is a correct simulation), so even though it
didn't get to that part of the machine behavior. it is still the
behavior of the machine that was being simulated (just never seen).

That machine is shown to have Halting Behavior, just like the top level
H^ machine (which you call sometimes P) but H calls it INCORRECTLY
non-halting.

FAIL.

YOU are the one who doesn't understand what really happens.

The ONLY way that this description fails is if H isn't a computation,
and the top level H was actually right that it never halts its
simulation, but then H has disquailfied itself from even being a Decider
for failing to be a Computation.

FALI AGAIN.

>
>>
>> FAIL.
>>
>
>