On Sat, 4 Sep 2021 17:52:27 -0500
olcott <NoOne@NoWhere.com> 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.

The ad hominem attack is a logical fallacy: attack the argument and not
the person and progress might be made.

/Flibble