Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.theory > #38786 > unrolled thread
| Started by | olcott <NoOne@NoWhere.com> |
|---|---|
| First post | 2021-09-03 19:18 -0500 |
| Last post | 2021-09-04 22:40 +0100 |
| Articles | 20 on this page of 51 — 8 participants |
Back to article view | Back to comp.theory
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
Page 2 of 3 — ← Prev page 1 [2] 3 Next page →
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-09-04 12:46 -0500 |
| Message-ID | <C7OdneoKVKpgLa78nZ2dnUU7-WFQAAAA@giganews.com> |
| In reply to | #38834 |
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. > They can answer some SPECIFIC forms of infinite behavior, but can not in > general. > > I think part of your problem is that YOU don't understand some of the > forms that are proven impossible, as shown by your claim that 'ALL' of > the proofs of the Halting Problem are based on this one method, which is > a demonstratably false statement. > > It may be the only one you understand, but it isn't the only one. > -- Copyright 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2021-09-04 14:15 -0400 |
| Message-ID | <%IOYI.30135$VZ1.3323@fx08.iad> |
| In reply to | #38837 |
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. 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, > >> They can answer some SPECIFIC forms of infinite behavior, but can not in >> general. >> >> I think part of your problem is that YOU don't understand some of the >> forms that are proven impossible, as shown by your claim that 'ALL' of >> the proofs of the Halting Problem are based on this one method, which is >> a demonstratably false statement. >> >> It may be the only one you understand, but it isn't the only one. >> > >
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-09-04 13:47 -0500 |
| Message-ID | <EvqdncHbTYDcIq78nZ2dnUU7-UfNnZ2d@giganews.com> |
| In reply to | #38843 |
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 !!! > 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 !!! > >> >>> They can answer some SPECIFIC forms of infinite behavior, but can not in >>> general. >>> >>> I think part of your problem is that YOU don't understand some of the >>> forms that are proven impossible, as shown by your claim that 'ALL' of >>> the proofs of the Halting Problem are based on this one method, which is >>> a demonstratably false statement. >>> >>> It may be the only one you understand, but it isn't the only one. >>> >> >> > -- Copyright 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2021-09-04 16:48 -0400 |
| Message-ID | <TYQYI.1171$g_4.1135@fx14.iad> |
| In reply to | #38847 |
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? > >> >>> >>>> They can answer some SPECIFIC forms of infinite behavior, but can >>>> not in >>>> general. >>>> >>>> I think part of your problem is that YOU don't understand some of the >>>> forms that are proven impossible, as shown by your claim that 'ALL' of >>>> the proofs of the Halting Problem are based on this one method, >>>> which is >>>> a demonstratably false statement. >>>> >>>> It may be the only one you understand, but it isn't the only one. >>>> >>> >>> >> > >
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-09-04 15:59 -0500 |
| Message-ID | <08udndz4u-u5Q678nZ2dnUU7-dXNnZ2d@giganews.com> |
| In reply to | #38858 |
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. >> >>> >>>> >>>>> They can answer some SPECIFIC forms of infinite behavior, but can >>>>> not in >>>>> general. >>>>> >>>>> I think part of your problem is that YOU don't understand some of the >>>>> forms that are proven impossible, as shown by your claim that 'ALL' of >>>>> the proofs of the Halting Problem are based on this one method, >>>>> which is >>>>> a demonstratably false statement. >>>>> >>>>> It may be the only one you understand, but it isn't the only one. >>>>> >>>> >>>> >>> >> >> > -- Copyright 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2021-09-04 22:11 +0100 |
| Message-ID | <87bl58oxlc.fsf@bsb.me.uk> |
| In reply to | #38860 |
olcott <NoOne@NoWhere.com> writes: > 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: >>>> 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 !!! <examples posted> >> Will you now SHUT UP that NO ONE has looked at this before? > > My original words included to the same extent that I have. Ah, well, you are on pretty safe ground there as it's hard to imagine anyone publishing as shallow an analysis of loop detection as you have posted here. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2021-09-04 18:01 -0400 |
| Message-ID | <P0SYI.23667$md6.11113@fx36.iad> |
| In reply to | #38860 |
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. >>> >>>> >>>>> >>>>>> They can answer some SPECIFIC forms of infinite behavior, but can >>>>>> not in >>>>>> general. >>>>>> >>>>>> I think part of your problem is that YOU don't understand some of the >>>>>> forms that are proven impossible, as shown by your claim that >>>>>> 'ALL' of >>>>>> the proofs of the Halting Problem are based on this one method, >>>>>> which is >>>>>> a demonstratably false statement. >>>>>> >>>>>> It may be the only one you understand, but it isn't the only one. >>>>>> >>>>> >>>>> >>>> >>> >>> >> > >
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-09-04 17:15 -0500 |
| Subject | Re: The key mistake of the Peter Linz HP proof [ Liar Liar pants on fire ] |
| Message-ID | <fPmdnUyPuOOHba78nZ2dnUU7-QnNnZ2d@giganews.com> |
| In reply to | #38872 |
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.
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.
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
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.
(d) We know that there are no return instructions in H because we know
that H is in pure simulation mode.
>>>>
>>>>>
>>>>>>
>>>>>>> They can answer some SPECIFIC forms of infinite behavior, but can
>>>>>>> not in
>>>>>>> general.
>>>>>>>
>>>>>>> I think part of your problem is that YOU don't understand some of the
>>>>>>> forms that are proven impossible, as shown by your claim that
>>>>>>> 'ALL' of
>>>>>>> the proofs of the Halting Problem are based on this one method,
>>>>>>> which is
>>>>>>> a demonstratably false statement.
>>>>>>>
>>>>>>> It may be the only one you understand, but it isn't the only one.
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>
--
Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2021-09-04 18:39 -0400 |
| Subject | Re: The key mistake of the Peter Linz HP proof [ Liar Liar pants on fire ] |
| Message-ID | <LASYI.13939$rsCb.9272@fx01.iad> |
| In reply to | #38873 |
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^)
FAIL.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-09-04 17:52 -0500 |
| Subject | Re: The key mistake of the Peter Linz HP proof [ Liar Liar pants on fire ] |
| Message-ID | <_IOdnQE0FbMxZa78nZ2dnUU7-eXNnZ2d@giganews.com> |
| In reply to | #38876 |
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
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2021-09-04 19:09 -0400 |
| Subject | Re: The key mistake of the Peter Linz HP proof [ Liar Liar pants on fire ] |
| Message-ID | <k0TYI.67741$Kv2.19882@fx47.iad> |
| In reply to | #38879 |
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.
>>
>
>
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibble@reddwarf.jmc> |
|---|---|
| Date | 2021-09-17 19:27 +0100 |
| Subject | Re: The key mistake of the Peter Linz HP proof [ Liar Liar pants on fire ] |
| Message-ID | <20210917192719.00001cc0@reddwarf.jmc> |
| In reply to | #38879 |
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
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-09-17 13:41 -0500 |
| Subject | Re: The key mistake of the Peter Linz HP proof [ Liar Liar pants on fire ] |
| Message-ID | <m6KdncZvr9L_fNn8nZ2dnUU7-UHNnZ2d@giganews.com> |
| In reply to | #39377 |
On 9/17/2021 1:27 PM, Mr Flibble wrote:
> 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
>
It seems to be an objective fact that most people here simply do not
want an honest dialogue and/or lack the intellectual capacity /
prerequisite knowledge to comprehend what is being said.
This is assessed on the basis that no actual valid reasoning is applied
as rebuttals to my ideas. Most of the fake rebuttals are the dishonest
dodge tactic of changing the subject rather than directly addressing any
key points that have been made, AKA the strawman error:
A straw man (sometimes written as strawman) is a form of argument and an
informal fallacy of having the impression of refuting an argument,
whereas the real subject of the argument was not addressed or refuted,
but instead replaced with a false one.
https://en.wikipedia.org/wiki/Straw_man
--
Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2021-09-17 15:15 -0400 |
| Subject | Re: The key mistake of the Peter Linz HP proof [ Liar Liar pants on fire ] |
| Message-ID | <uP51J.56157$Dr.34035@fx40.iad> |
| In reply to | #39378 |
On 9/17/21 2:41 PM, olcott wrote:
> On 9/17/2021 1:27 PM, Mr Flibble wrote:
>> 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
>>
>
> It seems to be an objective fact that most people here simply do not
> want an honest dialogue and/or lack the intellectual capacity /
> prerequisite knowledge to comprehend what is being said.
>
> This is assessed on the basis that no actual valid reasoning is applied
> as rebuttals to my ideas. Most of the fake rebuttals are the dishonest
> dodge tactic of changing the subject rather than directly addressing any
> key points that have been made, AKA the strawman error:
>
> A straw man (sometimes written as strawman) is a form of argument and an
> informal fallacy of having the impression of refuting an argument,
> whereas the real subject of the argument was not addressed or refuted,
> but instead replaced with a false one.
> https://en.wikipedia.org/wiki/Straw_man
>
It is an objective fact that MANY actual valid rebuttals have been made
to your arguements, to which you have rarely, if ever, actually made any
attempt to refure.
You have shown an UTTER lack of the prerequisite knowledge of the field
you are making claims about.
You claim things to be 'obvious by the meaning of their words', yet you
show you have no real understanding of the actual meaning of the words,
particulally as the relate to the field you claim to be making a major
discovery in.
You seem to have no idea what a Computation really is, and thus no idea
what a Computational Equivalent is, which is the foundation for your
arguement.
You seem to have no real understand of what a Turing Machine is, you may
be able to spout a few words that sort of make sense about them, but
have shown NO ability to actually create one or understand how they
work. You make 'obvious' claims about them that are definitionally false.
YOU are the one who doesn't seem to be willing to engage in an honest
dialog, ignoring or bashing people if they won't follow the script that
you want followed. A discussion is NOT scripted in that manner. When a
statement you make has broken groundwork behind it, that groundwork IS
open for discussion.
You come claiming to look for input to help improve your 'proof', if
that REALLY is your goal, take the input, your whole argument is on
broken premises, and NOBODY will accept a paper based on that.
You need to learn what an actual proof needs to look like, EVERYTHING
that you have broght forward has been really low level philosophical
rhetoric which might be suitable for the broader discussion of
comparative logical theory, but do not meet the requirements of the
rigorous mathematically logic using in this area of theory.
I think part of the issue is that you seem to be thinking under a
different fundamental rule of how logic works than what this branch
uses, but I don't think you understand that, and you just seem to think
that the logic used in mathemematics is just 'wrong', not understanding
that it was proved a long time ago that the logic system you seem to
want to think in just is incompatible with the basics of mathematics and
is unable to deal with it.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-09-17 14:19 -0500 |
| Subject | Re: The key mistake of the Peter Linz HP proof [ Liar Liar pants on fire ] |
| Message-ID | <waCdnfYTg6mid9n8nZ2dnUU7-WvNnZ2d@giganews.com> |
| In reply to | #39379 |
On 9/17/2021 2:15 PM, Richard Damon wrote:
>
> On 9/17/21 2:41 PM, olcott wrote:
>> On 9/17/2021 1:27 PM, Mr Flibble wrote:
>>> 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
>>>
>>
>> It seems to be an objective fact that most people here simply do not
>> want an honest dialogue and/or lack the intellectual capacity /
>> prerequisite knowledge to comprehend what is being said.
>>
>> This is assessed on the basis that no actual valid reasoning is applied
>> as rebuttals to my ideas. Most of the fake rebuttals are the dishonest
>> dodge tactic of changing the subject rather than directly addressing any
>> key points that have been made, AKA the strawman error:
>>
>> A straw man (sometimes written as strawman) is a form of argument and an
>> informal fallacy of having the impression of refuting an argument,
>> whereas the real subject of the argument was not addressed or refuted,
>> but instead replaced with a false one.
>> https://en.wikipedia.org/wiki/Straw_man
>>
>
> It is an objective fact that MANY actual valid rebuttals have been made
> to your arguements,
Gullible fools may believe this.
Gullible fools are not bright enough to recognize a subtle case of the
strawman error.
--
Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2021-09-17 16:02 -0400 |
| Subject | Re: The key mistake of the Peter Linz HP proof [ Liar Liar pants on fire ] |
| Message-ID | <8v61J.15703$4X4.7150@fx27.iad> |
| In reply to | #39381 |
On 9/17/21 3:19 PM, olcott wrote:
> On 9/17/2021 2:15 PM, Richard Damon wrote:
>>
>> On 9/17/21 2:41 PM, olcott wrote:
>>> On 9/17/2021 1:27 PM, Mr Flibble wrote:
>>>> 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
>>>>
>>>
>>> It seems to be an objective fact that most people here simply do not
>>> want an honest dialogue and/or lack the intellectual capacity /
>>> prerequisite knowledge to comprehend what is being said.
>>>
>>> This is assessed on the basis that no actual valid reasoning is applied
>>> as rebuttals to my ideas. Most of the fake rebuttals are the dishonest
>>> dodge tactic of changing the subject rather than directly addressing any
>>> key points that have been made, AKA the strawman error:
>>>
>>> A straw man (sometimes written as strawman) is a form of argument and an
>>> informal fallacy of having the impression of refuting an argument,
>>> whereas the real subject of the argument was not addressed or refuted,
>>> but instead replaced with a false one.
>>> https://en.wikipedia.org/wiki/Straw_man
>>>
>>
>> It is an objective fact that MANY actual valid rebuttals have been made
>> to your arguements,
> Gullible fools may believe this.
>
> Gullible fools are not bright enough to recognize a subtle case of the
> strawman error.
>
That is YOUR opinion, which isn't going to carry much weight.
As I have said, either get into HONEST discussions and actually talk
through the issues being rasie so you have a chance to improve your
paper, or
Just go ahead and write and submit the paper, which you know in your
heart will just get rejected and get it over with,
You current path is just leaving behind a legacy showing you to be a
fool that thinks he knows more than the experts even though he can't
define the fundamental terms (and occationally in lucid moments even
admits to this sort of thing).
Your behavior is NOT improving your position, and has perhaps made you
unemployable by anyone who does a searh and any of this comes up. Your
legacy will forever be tarnished and you will be considered forever a crank.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2021-09-17 15:11 -0700 |
| Subject | Re: The key mistake of the Peter Linz HP proof [ Liar Liar pants on fire ] |
| Message-ID | <82a41216-506e-48d9-9276-059beabd6b9en@googlegroups.com> |
| In reply to | #39378 |
On Friday, 17 September 2021 at 19:41:45 UTC+1, olcott wrote: > > A straw man (sometimes written as strawman) is a form of argument and an > informal fallacy of having the impression of refuting an argument, > whereas the real subject of the argument was not addressed or refuted, > but instead replaced with a false one. > I wrote a book called "12 Common Atheist Arguments (refuted)" where I presented 12 common arguments made by atheists, and refuted them. Inevitably I was accused of presenting "strawman" argments. However when I asked "how has that argument been weakened and why is the case I presented weak?" I didn't get many sensible replies. I did get one for the "Evil Bible" argument. A chap on alt.atheism used to post scriptures such as the ones demanding the extermination of the Amalekites. He said that his posts were an argument against God as most Christians conceived Him, but not a God of grandeur and vengeance as the Ancient Israelites conceived Him. But he did concede that his goal was to show that God didn't exist. So he kind of had a point, but not a very strong one. If you can't explain how your arguments have been weakened, and why the weakened versions are weak, but the corrected versions are stronger, then you can't really plead "strawman". It's rhetorically a dangerous plea, since it involves conceding that there are weak arguments that can be advanced for your case.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-09-17 17:36 -0500 |
| Subject | Re: The key mistake of the Peter Linz HP proof [ Liar Liar pants on fire ] |
| Message-ID | <eN2dnQ_2fc_ihdj8nZ2dnUU7-WvNnZ2d@giganews.com> |
| In reply to | #39385 |
On 9/17/2021 5:11 PM, Malcolm McLean wrote: > On Friday, 17 September 2021 at 19:41:45 UTC+1, olcott wrote: >> >> A straw man (sometimes written as strawman) is a form of argument and an >> informal fallacy of having the impression of refuting an argument, >> whereas the real subject of the argument was not addressed or refuted, >> but instead replaced with a false one. >> > I wrote a book called "12 Common Atheist Arguments (refuted)" where I > presented 12 common arguments made by atheists, and refuted them. > Inevitably I was accused of presenting "strawman" argments. However > when I asked "how has that argument been weakened and why is the > case I presented weak?" I didn't get many sensible replies. I did get one > for the "Evil Bible" argument. A chap on alt.atheism used to post scriptures > such as the ones demanding the extermination of the Amalekites. > He said that his posts were an argument against God as most Christians > conceived Him, but not a God of grandeur and vengeance as the Ancient > Israelites conceived Him. But he did concede that his goal was to show that > God didn't exist. > > So he kind of had a point, but not a very strong one. > > If you can't explain how your arguments have been weakened, and why the > weakened versions are weak, but the corrected versions are stronger, > then you can't really plead "strawman". It's rhetorically a dangerous plea, > since it involves conceding that there are weak arguments that can be > advanced for your case. > I don't really care whether others understand that none of what has been presented as a rebuttal can accurately be construed as such mostly because hardly anyone here really cares about that. Their goal is to look like that have provided a rebuttal to others here. Of the people here you may be the only one that has any serious interest in the actual truth. If you pay very close attention you will notice that when I make a point that X is proved by A,B,C, every rebuttal always changes the subject away from the exactly precise proposition of X into another proposition entirely that is very subtly different than X, hence an actual case of strawman. -- Copyright 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2021-09-17 19:28 -0400 |
| Subject | Re: The key mistake of the Peter Linz HP proof [ Liar Liar pants on fire ] |
| Message-ID | <Ew91J.29515$6U3.4911@fx43.iad> |
| In reply to | #39386 |
On 9/17/21 6:36 PM, olcott wrote: > On 9/17/2021 5:11 PM, Malcolm McLean wrote: >> On Friday, 17 September 2021 at 19:41:45 UTC+1, olcott wrote: >>> >>> A straw man (sometimes written as strawman) is a form of argument and an >>> informal fallacy of having the impression of refuting an argument, >>> whereas the real subject of the argument was not addressed or refuted, >>> but instead replaced with a false one. >>> >> I wrote a book called "12 Common Atheist Arguments (refuted)" where I >> presented 12 common arguments made by atheists, and refuted them. >> Inevitably I was accused of presenting "strawman" argments. However >> when I asked "how has that argument been weakened and why is the >> case I presented weak?" I didn't get many sensible replies. I did get one >> for the "Evil Bible" argument. A chap on alt.atheism used to post >> scriptures >> such as the ones demanding the extermination of the Amalekites. >> He said that his posts were an argument against God as most Christians >> conceived Him, but not a God of grandeur and vengeance as the Ancient >> Israelites conceived Him. But he did concede that his goal was to show >> that >> God didn't exist. >> >> So he kind of had a point, but not a very strong one. >> >> If you can't explain how your arguments have been weakened, and why the >> weakened versions are weak, but the corrected versions are stronger, >> then you can't really plead "strawman". It's rhetorically a dangerous >> plea, >> since it involves conceding that there are weak arguments that can be >> advanced for your case. >> > > I don't really care whether others understand that none of what has been > presented as a rebuttal can accurately be construed as such mostly > because hardly anyone here really cares about that. Their goal is to > look like that have provided a rebuttal to others here. Then why do you keep on making the claim. Either you care, and are working on cleaning up your proof, and thus need to take into account the refutations, and either show how they don't actually refute your statement or fix your proof so the refutations don't apply. or, you don't care, and think you are done, so then you should just write the paper and submit it. You are basically falling into Einstein's definition of insanity. > > Of the people here you may be the only one that has any serious interest > in the actual truth. > > If you pay very close attention you will notice that when I make a point > that X is proved by A,B,C, every rebuttal always changes the subject > away from the exactly precise proposition of X into another proposition > entirely that is very subtly different than X, hence an actual case of > strawman. > Normally thats because the X that A, B, C prove isn't the X that you claim to be true due to proof. Also, normally at least one of the A, B, C aren't actually true if read in the same manner as needed to combine to prove your claimed X.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-09-04 10:16 -0500 |
| Message-ID | <lIOdnaRe2ItREK78nZ2dnUU7-QXNnZ2d@giganews.com> |
| In reply to | #38808 |
On 9/4/2021 9:18 AM, Richard Damon wrote:
> On 9/4/21 10:06 AM, olcott wrote:
>> On 9/4/2021 5:50 AM, Richard Damon wrote:
>>> On 9/3/21 10:13 PM, olcott wrote:
>>>> On 9/3/2021 8:53 PM, Richard Damon wrote:
>>>>> On 9/3/21 9:18 PM, olcott wrote:
>>>>>> On 9/3/2021 8:05 PM, Richard Damon wrote:
>>>>>>> On 9/3/21 8:18 PM, olcott wrote:
>>>>>>>> In computability theory, the halting problem is the
>>>>>>>> problem of determining, from a description of an arbitrary
>>>>>>>> computer program and an input,
>>>>>>>>
>>>>>>>> whether the simulation of this program must be aborted to
>>>>>>>> prevent it from running forever.
>>>>>>>>
>>>>>>>> The above criteria is valid on the basis of the known equivalence
>>>>>>>> between the direct execution of a computation and its simulation
>>>>>>>> by a UTM. The same criteria universally works on all inputs allowing
>>>>>>>> their halting status to be correctly decided.
>>>>>>>>
>>>>>>>> The Peter Linz H is defined to be a simulating halt decider that
>>>>>>>> applies
>>>>>>>> the above criteria and the halt decider at Ĥ.qx is an exact copy
>>>>>>>> of H.
>>>>>>>>
>>>>>>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qy ∞
>>>>>>>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ halts, and
>>>>>>>>
>>>>>>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>>>>>>>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ does not halt
>>>>>>>>
>>>>>>>> The mistake of the Linz proof is forming a conclusion
>>>>>>>> based on Ĥ applied to its own Turing machine description ⟨Ĥ⟩.
>>>>>>>>
>>>>>>>> This is only answering the question:
>>>>>>>> Can changes be made to an otherwise correct halt decider
>>>>>>>> such that this halt decider is no longer correct?
>>>>>>>>
>>>>>>>> The required question is:
>>>>>>>> Does the original H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decide the halt
>>>>>>>> status
>>>>>>>> of its input?
>>>>>>>>
>>>>>>>> Yes the original H does correctly decide the halt status of ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>>
>>>>>>>> This is proved in section V3 of my paper by the analogous example
>>>>>>>> of:
>>>>>>>> int main() { H1(P,P); } // analogous to H applied to ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>>
>>>>>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> The full Linz Proof:
>>>>>>>> https://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf
>>>>>>>>
>>>>>>>
>>>>>>> So, do you claim H1 is the SAME computation as H, and thus neither is
>>>>>>> actually a computation as the same computation can't give two
>>>>>>> different
>>>>>>> answers to the same input.
>>>>>>>
>>>>>>
>>>>>> I claim that H1 has identical machine code as H.
>>>>>> Their execution order makes them distinctly different computations.
>>>>>>
>>>>>> H1 can see that H(P,P) aborts the simulation of its input.
>>>>>> H(P,P) cannot see anything that aborts the simulation of its input.
>>>>>>
>>>>>> This execution sequence order makes them distinctly different
>>>>>> computations.
>>>>>>
>>>>>> This is exactly the same as the when the original Linz H is applied to
>>>>>> ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>>>
>>>>> IF H1 is a different computation than H, then the fact that it can get
>>>>> the answer right doesn't matter, as it wasn't the computation that H^
>>>>> was built on.
>>>>>
>>>>
>>>> The Linz Ĥ is only required to have an exact copy of the Linz H at Ĥ.qx.
>>>> It turns out that using my simulating halt decider criteria H would
>>>> correctly report that its input ⟨Ĥ⟩ ⟨Ĥ⟩ halts.
>>>
>>> Not quite, you are missing the meaning of words here. H was supposed to
>>> be a Turing Machine, an exact copy of a Turing Machine will behave
>>> identically to the original. This is a fundamental property of being a
>>> Computation, if you make an exact copy of the algorithm, you will get
>>> the identical behavior.
>> I have empirically proved that this is merely a false assumption.
>> int main() { H1(P,P); } sees a different execution trace than H(P,P).
>>
>> In the first case we have a halt decider that sees another halt decider
>> abort the simulation of its input.
>>
>> In the second case we have a halt decider that does not see another halt
>> decider abort the simulation of its input.
>>
>> The execution order of with H1 before H derives a different execution
>> trace for H1 than for H.
>>
>> H1 is an identical copy of H and has different behavior than H because
>> its execution trace input is different than H.
>>
>
> Since Execution Trace is NOT defined as an input to that Computation
> (the only inputs are the representation of the machine and its input),
> the dependency of the result on that just proves that H and H1 are not
> properly Computation, and thus not eligable to be a Decider.
>
> PERIOD. DEFINITION.
The input to the halt deciders is their different execution trace thus
the halt deciders are a pure function of their input.
> H is NOT the Computational Equivalent of the Turing Machine it is
> claimed to be, as that machine would be Computation (as Turing Machines,
> but structure HAVE to be), so you argument fails at line 1 when you make
> that claim.
>
> You clearly do not understand the meaning of Computation as used in the
> field you are trying to muddle in.
>
--
Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
[toc] | [prev] | [next] | [standalone]
Page 2 of 3 — ← Prev page 1 [2] 3 Next page →
Back to top | Article view | comp.theory
csiph-web