Re: The key mistake of the Peter Linz HP proof [ Liar Liar pants on fire ]

From	Mr Flibble <flibble@reddwarf.jmc>
Newsgroups	comp.theory
Subject	Re: The key mistake of the Peter Linz HP proof [ Liar Liar pants on fire ]
Message-ID	<20210917192719.00001cc0@reddwarf.jmc> (permalink)
References	(18 earlier) <08udndz4u-u5Q678nZ2dnUU7-dXNnZ2d@giganews.com> <P0SYI.23667$md6.11113@fx36.iad> <fPmdnUyPuOOHba78nZ2dnUU7-QnNnZ2d@giganews.com> <LASYI.13939$rsCb.9272@fx01.iad> <_IOdnQE0FbMxZa78nZ2dnUU7-eXNnZ2d@giganews.com>
Organization	Jupiter Mining Corp
Date	2021-09-17 19:27 +0100

Show all headers | View raw

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

Thread

The key mistake of the Peter Linz HP proof olcott <NoOne@NoWhere.com> - 2021-09-03 19:18 -0500
  Re: The key mistake of the Peter Linz HP proof Richard Damon <Richard@Damon-Family.org> - 2021-09-03 21:05 -0400
    Re: The key mistake of the Peter Linz HP proof olcott <NoOne@NoWhere.com> - 2021-09-03 20:18 -0500
      Re: The key mistake of the Peter Linz HP proof Richard Damon <Richard@Damon-Family.org> - 2021-09-03 21:53 -0400
        Re: The key mistake of the Peter Linz HP proof olcott <NoOne@NoWhere.com> - 2021-09-03 21:13 -0500
          Re: The key mistake of the Peter Linz HP proof Richard Damon <Richard@Damon-Family.org> - 2021-09-04 06:50 -0400
            Re: The key mistake of the Peter Linz HP proof olcott <NoOne@NoWhere.com> - 2021-09-04 08:52 -0500
              Re: The key mistake of the Peter Linz HP proof Richard Damon <Richard@Damon-Family.org> - 2021-09-04 10:14 -0400
            Re: The key mistake of the Peter Linz HP proof olcott <NoOne@NoWhere.com> - 2021-09-04 09:06 -0500
              Re: The key mistake of the Peter Linz HP proof Richard Damon <Richard@Damon-Family.org> - 2021-09-04 10:18 -0400
                Re: The key mistake of the Peter Linz HP proof olcott <NoOne@NoWhere.com> - 2021-09-04 09:58 -0500
                Re: The key mistake of the Peter Linz HP proof Richard Damon <Richard@Damon-Family.org> - 2021-09-04 11:16 -0400
                Re: The key mistake of the Peter Linz HP proof olcott <polcott2@gmail.com> - 2021-09-04 10:19 -0500
                Re: The key mistake of the Peter Linz HP proof Richard Damon <Richard@Damon-Family.org> - 2021-09-04 11:40 -0400
                Re: The key mistake of the Peter Linz HP proof olcott <NoOne@NoWhere.com> - 2021-09-04 11:09 -0500
                Re: The key mistake of the Peter Linz HP proof Richard Damon <Richard@Damon-Family.org> - 2021-09-04 12:33 -0400
                Re: The key mistake of the Peter Linz HP proof olcott <NoOne@NoWhere.com> - 2021-09-04 11:55 -0500
                Re: The key mistake of the Peter Linz HP proof Richard Damon <Richard@Damon-Family.org> - 2021-09-04 13:13 -0400
                Re: The key mistake of the Peter Linz HP proof olcott <NoOne@NoWhere.com> - 2021-09-04 12:21 -0500
                Re: The key mistake of the Peter Linz HP proof Richard Damon <news.x.richarddamon@xoxy.net> - 2021-09-04 13:34 -0400
                Re: The key mistake of the Peter Linz HP proof olcott <NoOne@NoWhere.com> - 2021-09-04 12:46 -0500
                Re: The key mistake of the Peter Linz HP proof Richard Damon <Richard@Damon-Family.org> - 2021-09-04 14:15 -0400
                Re: The key mistake of the Peter Linz HP proof olcott <NoOne@NoWhere.com> - 2021-09-04 13:47 -0500
                Re: The key mistake of the Peter Linz HP proof Richard Damon <Richard@Damon-Family.org> - 2021-09-04 16:48 -0400
                Re: The key mistake of the Peter Linz HP proof olcott <NoOne@NoWhere.com> - 2021-09-04 15:59 -0500
                Re: The key mistake of the Peter Linz HP proof Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-04 22:11 +0100
                Re: The key mistake of the Peter Linz HP proof Richard Damon <Richard@Damon-Family.org> - 2021-09-04 18:01 -0400
                Re: The key mistake of the Peter Linz HP proof [ Liar Liar pants on fire ] olcott <NoOne@NoWhere.com> - 2021-09-04 17:15 -0500
                Re: The key mistake of the Peter Linz HP proof [ Liar Liar pants on fire ] Richard Damon <Richard@Damon-Family.org> - 2021-09-04 18:39 -0400
                Re: The key mistake of the Peter Linz HP proof [ Liar Liar pants on fire ] olcott <NoOne@NoWhere.com> - 2021-09-04 17:52 -0500
                Re: The key mistake of the Peter Linz HP proof [ Liar Liar pants on fire ] Richard Damon <Richard@Damon-Family.org> - 2021-09-04 19:09 -0400
                Re: The key mistake of the Peter Linz HP proof [ Liar Liar pants on fire ] Mr Flibble <flibble@reddwarf.jmc> - 2021-09-17 19:27 +0100
                Re: The key mistake of the Peter Linz HP proof [ Liar Liar pants on fire ] olcott <NoOne@NoWhere.com> - 2021-09-17 13:41 -0500
                Re: The key mistake of the Peter Linz HP proof [ Liar Liar pants on fire ] Richard Damon <Richard@Damon-Family.org> - 2021-09-17 15:15 -0400
                Re: The key mistake of the Peter Linz HP proof [ Liar Liar pants on fire ] olcott <NoOne@NoWhere.com> - 2021-09-17 14:19 -0500
                Re: The key mistake of the Peter Linz HP proof [ Liar Liar pants on fire ] Richard Damon <Richard@Damon-Family.org> - 2021-09-17 16:02 -0400
                Re: The key mistake of the Peter Linz HP proof [ Liar Liar pants on fire ] Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-09-17 15:11 -0700
                Re: The key mistake of the Peter Linz HP proof [ Liar Liar pants on fire ] olcott <NoOne@NoWhere.com> - 2021-09-17 17:36 -0500
                Re: The key mistake of the Peter Linz HP proof [ Liar Liar pants on fire ] Richard Damon <Richard@Damon-Family.org> - 2021-09-17 19:28 -0400
                Re: The key mistake of the Peter Linz HP proof olcott <NoOne@NoWhere.com> - 2021-09-04 10:16 -0500
                Re: The key mistake of the Peter Linz HP proof Richard Damon <Richard@Damon-Family.org> - 2021-09-04 11:44 -0400
              Re: The key mistake of the Peter Linz HP proof Richard Damon <Richard@Damon-Family.org> - 2021-09-04 11:43 -0400
  Re: The key mistake of the Peter Linz HP proof Alan Mackenzie <acm@muc.de> - 2021-09-04 18:04 +0000
    Re: The key mistake of the Peter Linz HP proof olcott <NoOne@NoWhere.com> - 2021-09-04 13:13 -0500
      Re: The key mistake of the Peter Linz HP proof Richard Damon <Richard@Damon-Family.org> - 2021-09-04 14:25 -0400
        Re: The key mistake of the Peter Linz HP proof Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-04 21:47 +0100
          Re: The key mistake of the Peter Linz HP proof Alan Mackenzie <acm@muc.de> - 2021-09-05 09:37 +0000
            Re: The key mistake of the Peter Linz HP proof: [ Ĥ applied to ⟨Ĥ⟩ ] olcott <NoOne@NoWhere.com> - 2021-09-05 09:46 -0500
              Re: The key mistake of the Peter Linz HP proof: [ Ĥ applied to ⟨Ĥ⟩ ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-05 16:08 +0100
              Re: The key mistake of the Peter Linz HP proof: [ Ĥ applied to ⟨Ĥ⟩ ] Richard Damon <news.x.richarddamon@xoxy.net> - 2021-09-05 12:41 -0400
  Re: The key mistake of the Peter Linz HP proof Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-04 22:40 +0100

csiph-web