Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.theory > #49731 > unrolled thread
| Started by | Mr Flibble <flibble@reddwarf.jmc> |
|---|---|
| First post | 2022-05-05 17:50 +0100 |
| Last post | 2022-05-06 16:39 +0300 |
| Articles | 20 on this page of 67 — 7 participants |
Back to article view | Back to comp.theory
On recursion and infinite recursion (reprise #3) Mr Flibble <flibble@reddwarf.jmc> - 2022-05-05 17:50 +0100
Re: On recursion and infinite recursion (reprise #3) olcott <polcott2@gmail.com> - 2022-05-05 13:58 -0500
Re: On recursion and infinite recursion (reprise #3) Ben <ben.usenet@bsb.me.uk> - 2022-05-05 20:56 +0100
Re: On recursion and infinite recursion (reprise #3) olcott <polcott2@gmail.com> - 2022-05-05 17:15 -0500
Re: On recursion and infinite recursion (reprise #3) Ben <ben.usenet@bsb.me.uk> - 2022-05-06 02:43 +0100
Re: On recursion and infinite recursion (reprise #3) olcott <polcott2@gmail.com> - 2022-05-05 20:59 -0500
Re: On recursion and infinite recursion (reprise #3) Ben <ben.usenet@bsb.me.uk> - 2022-05-06 04:08 +0100
Re: On recursion and infinite recursion (reprise #3) Ben <ben.usenet@bsb.me.uk> - 2022-05-05 20:51 +0100
Re: On recursion and infinite recursion (reprise #3) Mr Flibble <flibble@reddwarf.jmc> - 2022-05-05 20:52 +0100
Re: On recursion and infinite recursion (reprise #3) Ben <ben.usenet@bsb.me.uk> - 2022-05-05 21:15 +0100
Re: On recursion and infinite recursion (reprise #3) Mr Flibble <flibble@reddwarf.jmc> - 2022-05-05 21:16 +0100
Re: On recursion and infinite recursion (reprise #3) olcott <polcott2@gmail.com> - 2022-05-05 16:35 -0500
Re: On recursion and infinite recursion (reprise #3) olcott <polcott2@gmail.com> - 2022-05-05 16:37 -0500
Re: On recursion and infinite recursion (reprise #3) Ben <ben.usenet@bsb.me.uk> - 2022-05-06 02:38 +0100
Re: On recursion and infinite recursion (reprise #3) olcott <polcott2@gmail.com> - 2022-05-05 20:42 -0500
Re: On recursion and infinite recursion (reprise #3) Ben <ben.usenet@bsb.me.uk> - 2022-05-06 03:59 +0100
Re: On recursion and infinite recursion (reprise #3) Richard Damon <Richard@Damon-Family.org> - 2022-05-05 22:33 -0400
Re: On recursion and infinite recursion (reprise #3) Mr Flibble <flibble@reddwarf.jmc> - 2022-05-06 15:02 +0100
Re: On recursion and infinite recursion (reprise #3) Python <python@example.invalid> - 2022-05-06 16:18 +0200
Re: On recursion and infinite recursion (reprise #3) olcott <polcott2@gmail.com> - 2022-05-06 11:55 -0500
Re: On recursion and infinite recursion (reprise #3) Mikko <mikko.levanto@iki.fi> - 2022-05-07 12:52 +0300
Re: On recursion and infinite recursion (reprise #3) Mr Flibble <flibble@reddwarf.jmc> - 2022-05-07 13:42 +0100
Re: On recursion and infinite recursion (reprise #3) Mikko <mikko.levanto@iki.fi> - 2022-05-07 16:59 +0300
Re: On recursion and infinite recursion (reprise #3) Mr Flibble <flibble@reddwarf.jmc> - 2022-05-07 15:06 +0100
Re: On recursion and infinite recursion (reprise #3) Mikko <mikko.levanto@iki.fi> - 2022-05-07 17:16 +0300
Re: On recursion and infinite recursion (reprise #3) Mr Flibble <flibble@reddwarf.jmc> - 2022-05-07 15:20 +0100
Re: On recursion and infinite recursion (reprise #3) Mikko <mikko.levanto@iki.fi> - 2022-05-07 18:13 +0300
Re: On recursion and infinite recursion (reprise #3) Mr Flibble <flibble@reddwarf.jmc> - 2022-05-07 16:19 +0100
Re: On recursion and infinite recursion (reprise #3) olcott <polcott2@gmail.com> - 2022-05-07 11:03 -0500
Re: On recursion and infinite recursion (reprise #3) Ben <ben.usenet@bsb.me.uk> - 2022-05-07 23:41 +0100
Re: On recursion and infinite recursion (reprise #3) Mr Flibble <flibble@reddwarf.jmc> - 2022-05-07 23:43 +0100
Re: On recursion and infinite recursion (reprise #3) Richard Damon <Richard@Damon-Family.org> - 2022-05-07 19:59 -0400
Re: On recursion and infinite recursion (reprise #3) Mr Flibble <flibble@reddwarf.jmc> - 2022-05-08 01:01 +0100
Re: On recursion and infinite recursion (reprise #3) Richard Damon <Richard@Damon-Family.org> - 2022-05-07 20:18 -0400
Re: On recursion and infinite recursion (reprise #3) Mr Flibble <flibble@reddwarf.jmc> - 2022-05-08 01:55 +0100
Re: On recursion and infinite recursion (reprise #3) Mikko <mikko.levanto@iki.fi> - 2022-05-08 11:31 +0300
Re: On recursion and infinite recursion (reprise #3) Mr Flibble <flibble@reddwarf.jmc> - 2022-05-08 09:49 +0100
Re: On recursion and infinite recursion (reprise #3) Mikko <mikko.levanto@iki.fi> - 2022-05-08 13:00 +0300
Re: On recursion and infinite recursion (reprise #3) Mr Flibble <flibble@reddwarf.jmc> - 2022-05-08 12:57 +0100
Re: On recursion and infinite recursion (reprise #3) Richard Damon <Richard@Damon-Family.org> - 2022-05-08 07:45 -0400
Re: On recursion and infinite recursion (reprise #3) Mr Flibble <flibble@reddwarf.jmc> - 2022-05-08 13:02 +0100
Re: On recursion and infinite recursion (reprise #3) Richard Damon <Richard@Damon-Family.org> - 2022-05-08 08:31 -0400
Re: On recursion and infinite recursion (reprise #3) Mr Flibble <flibble@reddwarf.jmc> - 2022-05-08 13:39 +0100
Re: On recursion and infinite recursion (reprise #3) Richard Damon <Richard@Damon-Family.org> - 2022-05-08 14:10 -0400
Re: On recursion and infinite recursion (reprise #3) Mr Flibble <flibble@reddwarf.jmc> - 2022-05-08 20:06 +0100
Re: On recursion and infinite recursion (reprise #3) Richard Damon <Richard@Damon-Family.org> - 2022-05-08 15:39 -0400
Re: On recursion and infinite recursion (reprise #3) Mr Flibble <flibble@reddwarf.jmc> - 2022-05-08 21:14 +0100
Re: On recursion and infinite recursion (reprise #3) Richard Damon <Richard@Damon-Family.org> - 2022-05-08 17:40 -0400
Re: On recursion and infinite recursion (reprise #3) Mr Flibble <flibble@reddwarf.jmc> - 2022-05-08 23:04 +0100
Re: On recursion and infinite recursion (reprise #3) Ben <ben.usenet@bsb.me.uk> - 2022-05-09 00:26 +0100
Re: On recursion and infinite recursion (reprise #3) Richard Damon <Richard@Damon-Family.org> - 2022-05-08 19:40 -0400
Re: On recursion and infinite recursion (reprise #3) olcott <NoOne@NoWhere.com> - 2022-05-09 10:55 -0500
Re: On recursion and infinite recursion (reprise #3) Richard Damon <Richard@Damon-Family.org> - 2022-05-09 20:13 -0400
Re: On recursion and infinite recursion (reprise #3) olcott <NoOne@NoWhere.com> - 2022-05-09 10:51 -0500
Re: On recursion and infinite recursion (reprise #3) Mr Flibble <flibble@reddwarf.jmc> - 2022-05-09 18:31 +0100
Re: On recursion and infinite recursion (reprise #3) olcott <NoOne@NoWhere.com> - 2022-05-09 12:36 -0500
Re: On recursion and infinite recursion (reprise #3) Richard Damon <Richard@Damon-Family.org> - 2022-05-09 20:15 -0400
Re: On recursion and infinite recursion (reprise #3) Richard Damon <Richard@Damon-Family.org> - 2022-05-09 20:14 -0400
Re: On recursion and infinite recursion (reprise #3) olcott <NoOne@NoWhere.com> - 2022-05-09 10:49 -0500
Re: On recursion and infinite recursion (reprise #3) Mr Flibble <flibble@reddwarf.jmc> - 2022-05-09 18:31 +0100
Re: On recursion and infinite recursion (reprise #3) olcott <NoOne@NoWhere.com> - 2022-05-09 12:37 -0500
Re: On recursion and infinite recursion (reprise #3) olcott <NoOne@NoWhere.com> - 2022-05-09 10:47 -0500
Re: On recursion and infinite recursion (reprise #3) Mikko <mikko.levanto@iki.fi> - 2022-05-09 19:33 +0300
Re: On recursion and infinite recursion (reprise #3) olcott <NoOne@NoWhere.com> - 2022-05-09 11:36 -0500
Re: On recursion and infinite recursion (reprise #3) Richard Damon <Richard@Damon-Family.org> - 2022-05-09 20:17 -0400
Re: On recursion and infinite recursion (reprise #3) olcott <polcott2@gmail.com> - 2022-05-07 11:06 -0500
Re: On recursion and infinite recursion (reprise #3) Mikko <mikko.levanto@iki.fi> - 2022-05-06 16:39 +0300
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
| From | Mr Flibble <flibble@reddwarf.jmc> |
|---|---|
| Date | 2022-05-08 13:02 +0100 |
| Message-ID | <20220508130212.00007ab6@reddwarf.jmc> |
| In reply to | #50022 |
On Sun, 8 May 2022 07:45:52 -0400 Richard Damon <Richard@Damon-Family.org> wrote: > On 5/8/22 4:49 AM, Mr Flibble wrote: > > On Sun, 8 May 2022 11:31:08 +0300 > > Mikko <mikko.levanto@iki.fi> wrote: > > > >> On 2022-05-07 15:19:01 +0000, Mr Flibble said: > >> > >>> On Sat, 7 May 2022 18:13:08 +0300 > >>> Mikko <mikko.levanto@iki.fi> wrote: > >>> > >>>> On 2022-05-07 14:20:17 +0000, Mr Flibble said: > >>>> > >>>>> On Sat, 7 May 2022 17:16:31 +0300 > >>>>> Mikko <mikko.levanto@iki.fi> wrote: > >>>>> > >>>>>> On 2022-05-07 14:06:12 +0000, Mr Flibble said: > >>>>>> > >>>>>>> On Sat, 7 May 2022 16:59:55 +0300 > >>>>>>> Mikko <mikko.levanto@iki.fi> wrote: > >>>>>>> > >>>>>>>> On 2022-05-07 12:42:50 +0000, Mr Flibble said: > >>>>>>>> > >>>>>>>>> On Sat, 7 May 2022 12:52:58 +0300 > >>>>>>>>> Mikko <mikko.levanto@iki.fi> wrote: > >>>>>>>>> > >>>>>>>>>> On 2022-05-06 14:02:53 +0000, Mr Flibble said: > >>>>>>>>>> > >>>>>>>>>>> The decider could never be compiled and run in the first > >>>>>>>>>>> place due to the category error in the definition of the > >>>>>>>>>>> proof. > >>>>>>>>>> > >>>>>>>>>> An error in the definition of the proof does not prevent > >>>>>>>>>> compilation and execution of the program. > >>>>>>>>> > >>>>>>>>> In this case the error in the definition of the proof > >>>>>>>> > >>>>>>>> No part of the proof is identified as errorneous, so the rest > >>>>>>>> is irrelevant. Anyway, > >>>>>>>> > >>>>>>>>> does prevent compilation unless > >>>>>>>> > >>>>>>>> There is no option here, so the "unless" is void. > >>>>>>>> > >>>>>>>>> the decider is made part of the program that is being > >>>>>>>>> decided > >>>>>>>> > >>>>>>>> The decider is made a part of the program discussed in the > >>>>>>>> proof. > >>>>>>>>> in which case we get a function call-like infinite recursion > >>>>>>>>> instead > >>>>>>>> > >>>>>>>> We get or we don't get, depending on how the halt decider > >>>>>>>> candidate attempts to decide. > >>>>>>>> > >>>>>>>>> (as described by Pete Olcott) and we are attempting (and > >>>>>>>>> failing) to decide if a procedure halts rather than if a > >>>>>>>>> program halts. > >>>>>>>> > >>>>>>>> In any case, the decider candidate fails to give the correct > >>>>>>>> answer, and therefore is not a halt decider. Note that this > >>>>>>>> is correctly inferred in the proof. Therefore either the > >>>>>>>> conclusion of the proof is correct or you are wrong. > >>>>>>> > >>>>>>> No answer is ever given due to the infinite recursion. > >>>>>> > >>>>>> True about some candidates, false about others. For example, a > >>>>>> candidate that always says "no" is not infinitely recursive but > >>>>>> is wrong in the particular case discussed in the proof. But > >>>>>> anyway, you have confirmed the conclusion of the proof. > >>>>> > >>>>> False. The proof is not cognisant of the presence of the > >>>>> infinite recursion. The decider can never return an answer of > >>>>> halts/doesn't halt due to the infinite recursion. > >>>> > >>>> The correct term is decider candidate. It is not a decider > >>>> because the infinite recursion prevents it from halting in > >>>> finite time. > >>>> > >>>> You cannot call the proof incorrect merely because it agrees with > >>>> you. > >>> > >>> Try actually reading what Strachey wrote: a contradiction arises > >>> based on the result of evaluating T[P] however T[P] is never > >>> evaluated due to the infinite recursion: a fact ignored by the > >>> proof. > >> > >> If you can prove that the program does give the correct result in > >> that case you have proven Strachey wrong. Otherwise you haven't. > > > > Strachey is wrong because he neglected to account for the infinite > > recursion; this should be obvious to anyone who has actually read > > and understood what Strachey wrote: it seems that you haven't. > > > > /Flibble > > > > No, because if T gets stuck in an infinite recursion, it is wrong, > because it failed to answer in finite time. > > If T does answer in finite time, then there never was an infinite > recursion. > > All you have shown is that there exists a WRONG method to build a T > that gets stuck, Like a T that needs to run its input to completion > to answer about it. I have shown that [Strachey, 1965] contains an infinite recursion and is thus invalid. /Flibble
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-05-08 08:31 -0400 |
| Message-ID | <iKOdK.8684$t72a.8070@fx10.iad> |
| In reply to | #50024 |
On 5/8/22 8:02 AM, Mr Flibble wrote: > On Sun, 8 May 2022 07:45:52 -0400 > Richard Damon <Richard@Damon-Family.org> wrote: > >> On 5/8/22 4:49 AM, Mr Flibble wrote: >>> On Sun, 8 May 2022 11:31:08 +0300 >>> Mikko <mikko.levanto@iki.fi> wrote: >>> >>>> On 2022-05-07 15:19:01 +0000, Mr Flibble said: >>>> >>>>> On Sat, 7 May 2022 18:13:08 +0300 >>>>> Mikko <mikko.levanto@iki.fi> wrote: >>>>> >>>>>> On 2022-05-07 14:20:17 +0000, Mr Flibble said: >>>>>> >>>>>>> On Sat, 7 May 2022 17:16:31 +0300 >>>>>>> Mikko <mikko.levanto@iki.fi> wrote: >>>>>>> >>>>>>>> On 2022-05-07 14:06:12 +0000, Mr Flibble said: >>>>>>>> >>>>>>>>> On Sat, 7 May 2022 16:59:55 +0300 >>>>>>>>> Mikko <mikko.levanto@iki.fi> wrote: >>>>>>>>> >>>>>>>>>> On 2022-05-07 12:42:50 +0000, Mr Flibble said: >>>>>>>>>> >>>>>>>>>>> On Sat, 7 May 2022 12:52:58 +0300 >>>>>>>>>>> Mikko <mikko.levanto@iki.fi> wrote: >>>>>>>>>>> >>>>>>>>>>>> On 2022-05-06 14:02:53 +0000, Mr Flibble said: >>>>>>>>>>>> >>>>>>>>>>>>> The decider could never be compiled and run in the first >>>>>>>>>>>>> place due to the category error in the definition of the >>>>>>>>>>>>> proof. >>>>>>>>>>>> >>>>>>>>>>>> An error in the definition of the proof does not prevent >>>>>>>>>>>> compilation and execution of the program. >>>>>>>>>>> >>>>>>>>>>> In this case the error in the definition of the proof >>>>>>>>>> >>>>>>>>>> No part of the proof is identified as errorneous, so the rest >>>>>>>>>> is irrelevant. Anyway, >>>>>>>>>> >>>>>>>>>>> does prevent compilation unless >>>>>>>>>> >>>>>>>>>> There is no option here, so the "unless" is void. >>>>>>>>>> >>>>>>>>>>> the decider is made part of the program that is being >>>>>>>>>>> decided >>>>>>>>>> >>>>>>>>>> The decider is made a part of the program discussed in the >>>>>>>>>> proof. >>>>>>>>>>> in which case we get a function call-like infinite recursion >>>>>>>>>>> instead >>>>>>>>>> >>>>>>>>>> We get or we don't get, depending on how the halt decider >>>>>>>>>> candidate attempts to decide. >>>>>>>>>> >>>>>>>>>>> (as described by Pete Olcott) and we are attempting (and >>>>>>>>>>> failing) to decide if a procedure halts rather than if a >>>>>>>>>>> program halts. >>>>>>>>>> >>>>>>>>>> In any case, the decider candidate fails to give the correct >>>>>>>>>> answer, and therefore is not a halt decider. Note that this >>>>>>>>>> is correctly inferred in the proof. Therefore either the >>>>>>>>>> conclusion of the proof is correct or you are wrong. >>>>>>>>> >>>>>>>>> No answer is ever given due to the infinite recursion. >>>>>>>> >>>>>>>> True about some candidates, false about others. For example, a >>>>>>>> candidate that always says "no" is not infinitely recursive but >>>>>>>> is wrong in the particular case discussed in the proof. But >>>>>>>> anyway, you have confirmed the conclusion of the proof. >>>>>>> >>>>>>> False. The proof is not cognisant of the presence of the >>>>>>> infinite recursion. The decider can never return an answer of >>>>>>> halts/doesn't halt due to the infinite recursion. >>>>>> >>>>>> The correct term is decider candidate. It is not a decider >>>>>> because the infinite recursion prevents it from halting in >>>>>> finite time. >>>>>> >>>>>> You cannot call the proof incorrect merely because it agrees with >>>>>> you. >>>>> >>>>> Try actually reading what Strachey wrote: a contradiction arises >>>>> based on the result of evaluating T[P] however T[P] is never >>>>> evaluated due to the infinite recursion: a fact ignored by the >>>>> proof. >>>> >>>> If you can prove that the program does give the correct result in >>>> that case you have proven Strachey wrong. Otherwise you haven't. >>> >>> Strachey is wrong because he neglected to account for the infinite >>> recursion; this should be obvious to anyone who has actually read >>> and understood what Strachey wrote: it seems that you haven't. >>> >>> /Flibble >>> >> >> No, because if T gets stuck in an infinite recursion, it is wrong, >> because it failed to answer in finite time. >> >> If T does answer in finite time, then there never was an infinite >> recursion. >> >> All you have shown is that there exists a WRONG method to build a T >> that gets stuck, Like a T that needs to run its input to completion >> to answer about it. > > I have shown that [Strachey, 1965] contains an infinite recursion and > is thus invalid. > > /Flibble > No, you haven't. All you have shown is that one way to attempt to make the program that Strachev says doesn't exist, fails due to getting caught in infinite recursion. That just helps confirm Strachev, not refute it.
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibble@reddwarf.jmc> |
|---|---|
| Date | 2022-05-08 13:39 +0100 |
| Message-ID | <20220508133909.00007b6b@reddwarf.jmc> |
| In reply to | #50026 |
On Sun, 8 May 2022 08:31:10 -0400 Richard Damon <Richard@Damon-Family.org> wrote: > On 5/8/22 8:02 AM, Mr Flibble wrote: > > On Sun, 8 May 2022 07:45:52 -0400 > > Richard Damon <Richard@Damon-Family.org> wrote: > > > >> On 5/8/22 4:49 AM, Mr Flibble wrote: > >>> On Sun, 8 May 2022 11:31:08 +0300 > >>> Mikko <mikko.levanto@iki.fi> wrote: > >>> > >>>> On 2022-05-07 15:19:01 +0000, Mr Flibble said: > >>>> > >>>>> On Sat, 7 May 2022 18:13:08 +0300 > >>>>> Mikko <mikko.levanto@iki.fi> wrote: > >>>>> > >>>>>> On 2022-05-07 14:20:17 +0000, Mr Flibble said: > >>>>>> > >>>>>>> On Sat, 7 May 2022 17:16:31 +0300 > >>>>>>> Mikko <mikko.levanto@iki.fi> wrote: > >>>>>>> > >>>>>>>> On 2022-05-07 14:06:12 +0000, Mr Flibble said: > >>>>>>>> > >>>>>>>>> On Sat, 7 May 2022 16:59:55 +0300 > >>>>>>>>> Mikko <mikko.levanto@iki.fi> wrote: > >>>>>>>>> > >>>>>>>>>> On 2022-05-07 12:42:50 +0000, Mr Flibble said: > >>>>>>>>>> > >>>>>>>>>>> On Sat, 7 May 2022 12:52:58 +0300 > >>>>>>>>>>> Mikko <mikko.levanto@iki.fi> wrote: > >>>>>>>>>>> > >>>>>>>>>>>> On 2022-05-06 14:02:53 +0000, Mr Flibble said: > >>>>>>>>>>>> > >>>>>>>>>>>>> The decider could never be compiled and run in the first > >>>>>>>>>>>>> place due to the category error in the definition of the > >>>>>>>>>>>>> proof. > >>>>>>>>>>>> > >>>>>>>>>>>> An error in the definition of the proof does not prevent > >>>>>>>>>>>> compilation and execution of the program. > >>>>>>>>>>> > >>>>>>>>>>> In this case the error in the definition of the proof > >>>>>>>>>> > >>>>>>>>>> No part of the proof is identified as errorneous, so the > >>>>>>>>>> rest is irrelevant. Anyway, > >>>>>>>>>> > >>>>>>>>>>> does prevent compilation unless > >>>>>>>>>> > >>>>>>>>>> There is no option here, so the "unless" is void. > >>>>>>>>>> > >>>>>>>>>>> the decider is made part of the program that is being > >>>>>>>>>>> decided > >>>>>>>>>> > >>>>>>>>>> The decider is made a part of the program discussed in the > >>>>>>>>>> proof. > >>>>>>>>>>> in which case we get a function call-like infinite > >>>>>>>>>>> recursion instead > >>>>>>>>>> > >>>>>>>>>> We get or we don't get, depending on how the halt decider > >>>>>>>>>> candidate attempts to decide. > >>>>>>>>>> > >>>>>>>>>>> (as described by Pete Olcott) and we are attempting (and > >>>>>>>>>>> failing) to decide if a procedure halts rather than if a > >>>>>>>>>>> program halts. > >>>>>>>>>> > >>>>>>>>>> In any case, the decider candidate fails to give the > >>>>>>>>>> correct answer, and therefore is not a halt decider. Note > >>>>>>>>>> that this is correctly inferred in the proof. Therefore > >>>>>>>>>> either the conclusion of the proof is correct or you are > >>>>>>>>>> wrong. > >>>>>>>>> > >>>>>>>>> No answer is ever given due to the infinite recursion. > >>>>>>>> > >>>>>>>> True about some candidates, false about others. For example, > >>>>>>>> a candidate that always says "no" is not infinitely > >>>>>>>> recursive but is wrong in the particular case discussed in > >>>>>>>> the proof. But anyway, you have confirmed the conclusion of > >>>>>>>> the proof. > >>>>>>> > >>>>>>> False. The proof is not cognisant of the presence of the > >>>>>>> infinite recursion. The decider can never return an answer of > >>>>>>> halts/doesn't halt due to the infinite recursion. > >>>>>> > >>>>>> The correct term is decider candidate. It is not a decider > >>>>>> because the infinite recursion prevents it from halting in > >>>>>> finite time. > >>>>>> > >>>>>> You cannot call the proof incorrect merely because it agrees > >>>>>> with you. > >>>>> > >>>>> Try actually reading what Strachey wrote: a contradiction arises > >>>>> based on the result of evaluating T[P] however T[P] is never > >>>>> evaluated due to the infinite recursion: a fact ignored by the > >>>>> proof. > >>>> > >>>> If you can prove that the program does give the correct result in > >>>> that case you have proven Strachey wrong. Otherwise you haven't. > >>>> > >>> > >>> Strachey is wrong because he neglected to account for the infinite > >>> recursion; this should be obvious to anyone who has actually read > >>> and understood what Strachey wrote: it seems that you haven't. > >>> > >>> /Flibble > >>> > >> > >> No, because if T gets stuck in an infinite recursion, it is wrong, > >> because it failed to answer in finite time. > >> > >> If T does answer in finite time, then there never was an infinite > >> recursion. > >> > >> All you have shown is that there exists a WRONG method to build a T > >> that gets stuck, Like a T that needs to run its input to completion > >> to answer about it. > > > > I have shown that [Strachey, 1965] contains an infinite recursion > > and is thus invalid. > > > > /Flibble > > > > No, you haven't. All you have shown is that one way to attempt to > make the program that Strachev says doesn't exist, fails due to > getting caught in infinite recursion. > > That just helps confirm Strachev, not refute it. Nope. Strachey's proof is based on a contradiction relating to evaluating the result of T[P] however T[P] can never be evaluated if there is an infinite recursion. /Flibble
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-05-08 14:10 -0400 |
| Message-ID | <9ITdK.2055$wYy9.1130@fx11.iad> |
| In reply to | #50027 |
On 5/8/22 8:39 AM, Mr Flibble wrote: > On Sun, 8 May 2022 08:31:10 -0400 > Richard Damon <Richard@Damon-Family.org> wrote: > >> On 5/8/22 8:02 AM, Mr Flibble wrote: >>> On Sun, 8 May 2022 07:45:52 -0400 >>> Richard Damon <Richard@Damon-Family.org> wrote: >>> >>>> On 5/8/22 4:49 AM, Mr Flibble wrote: >>>>> On Sun, 8 May 2022 11:31:08 +0300 >>>>> Mikko <mikko.levanto@iki.fi> wrote: >>>>> >>>>>> On 2022-05-07 15:19:01 +0000, Mr Flibble said: >>>>>> >>>>>>> On Sat, 7 May 2022 18:13:08 +0300 >>>>>>> Mikko <mikko.levanto@iki.fi> wrote: >>>>>>> >>>>>>>> On 2022-05-07 14:20:17 +0000, Mr Flibble said: >>>>>>>> >>>>>>>>> On Sat, 7 May 2022 17:16:31 +0300 >>>>>>>>> Mikko <mikko.levanto@iki.fi> wrote: >>>>>>>>> >>>>>>>>>> On 2022-05-07 14:06:12 +0000, Mr Flibble said: >>>>>>>>>> >>>>>>>>>>> On Sat, 7 May 2022 16:59:55 +0300 >>>>>>>>>>> Mikko <mikko.levanto@iki.fi> wrote: >>>>>>>>>>> >>>>>>>>>>>> On 2022-05-07 12:42:50 +0000, Mr Flibble said: >>>>>>>>>>>> >>>>>>>>>>>>> On Sat, 7 May 2022 12:52:58 +0300 >>>>>>>>>>>>> Mikko <mikko.levanto@iki.fi> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> On 2022-05-06 14:02:53 +0000, Mr Flibble said: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> The decider could never be compiled and run in the first >>>>>>>>>>>>>>> place due to the category error in the definition of the >>>>>>>>>>>>>>> proof. >>>>>>>>>>>>>> >>>>>>>>>>>>>> An error in the definition of the proof does not prevent >>>>>>>>>>>>>> compilation and execution of the program. >>>>>>>>>>>>> >>>>>>>>>>>>> In this case the error in the definition of the proof >>>>>>>>>>>> >>>>>>>>>>>> No part of the proof is identified as errorneous, so the >>>>>>>>>>>> rest is irrelevant. Anyway, >>>>>>>>>>>> >>>>>>>>>>>>> does prevent compilation unless >>>>>>>>>>>> >>>>>>>>>>>> There is no option here, so the "unless" is void. >>>>>>>>>>>> >>>>>>>>>>>>> the decider is made part of the program that is being >>>>>>>>>>>>> decided >>>>>>>>>>>> >>>>>>>>>>>> The decider is made a part of the program discussed in the >>>>>>>>>>>> proof. >>>>>>>>>>>>> in which case we get a function call-like infinite >>>>>>>>>>>>> recursion instead >>>>>>>>>>>> >>>>>>>>>>>> We get or we don't get, depending on how the halt decider >>>>>>>>>>>> candidate attempts to decide. >>>>>>>>>>>> >>>>>>>>>>>>> (as described by Pete Olcott) and we are attempting (and >>>>>>>>>>>>> failing) to decide if a procedure halts rather than if a >>>>>>>>>>>>> program halts. >>>>>>>>>>>> >>>>>>>>>>>> In any case, the decider candidate fails to give the >>>>>>>>>>>> correct answer, and therefore is not a halt decider. Note >>>>>>>>>>>> that this is correctly inferred in the proof. Therefore >>>>>>>>>>>> either the conclusion of the proof is correct or you are >>>>>>>>>>>> wrong. >>>>>>>>>>> >>>>>>>>>>> No answer is ever given due to the infinite recursion. >>>>>>>>>> >>>>>>>>>> True about some candidates, false about others. For example, >>>>>>>>>> a candidate that always says "no" is not infinitely >>>>>>>>>> recursive but is wrong in the particular case discussed in >>>>>>>>>> the proof. But anyway, you have confirmed the conclusion of >>>>>>>>>> the proof. >>>>>>>>> >>>>>>>>> False. The proof is not cognisant of the presence of the >>>>>>>>> infinite recursion. The decider can never return an answer of >>>>>>>>> halts/doesn't halt due to the infinite recursion. >>>>>>>> >>>>>>>> The correct term is decider candidate. It is not a decider >>>>>>>> because the infinite recursion prevents it from halting in >>>>>>>> finite time. >>>>>>>> >>>>>>>> You cannot call the proof incorrect merely because it agrees >>>>>>>> with you. >>>>>>> >>>>>>> Try actually reading what Strachey wrote: a contradiction arises >>>>>>> based on the result of evaluating T[P] however T[P] is never >>>>>>> evaluated due to the infinite recursion: a fact ignored by the >>>>>>> proof. >>>>>> >>>>>> If you can prove that the program does give the correct result in >>>>>> that case you have proven Strachey wrong. Otherwise you haven't. >>>>>> >>>>> >>>>> Strachey is wrong because he neglected to account for the infinite >>>>> recursion; this should be obvious to anyone who has actually read >>>>> and understood what Strachey wrote: it seems that you haven't. >>>>> >>>>> /Flibble >>>>> >>>> >>>> No, because if T gets stuck in an infinite recursion, it is wrong, >>>> because it failed to answer in finite time. >>>> >>>> If T does answer in finite time, then there never was an infinite >>>> recursion. >>>> >>>> All you have shown is that there exists a WRONG method to build a T >>>> that gets stuck, Like a T that needs to run its input to completion >>>> to answer about it. >>> >>> I have shown that [Strachey, 1965] contains an infinite recursion >>> and is thus invalid. >>> >>> /Flibble >>> >> >> No, you haven't. All you have shown is that one way to attempt to >> make the program that Strachev says doesn't exist, fails due to >> getting caught in infinite recursion. >> >> That just helps confirm Strachev, not refute it. > > Nope. Strachey's proof is based on a contradiction relating to > evaluating the result of T[P] however T[P] can never be evaluated if > there is an infinite recursion. > > /Flibble > Nope, because if T actually meets the requirement to be able to take ANY program and answer, then it need to be able to take a program that uses a copy of T in it, as that is a valid program. If T gets into an infinite recursion on such a program, it is that *T* fails to meet the requirements, not that the such a program is invalid to give to T. This means that the program T is Strachey's proof can't just execute its input to get the needed answer, as that makes it (T) not meet its requirements. Thus, the "recursion" error isn't in the proof of impossibility, but in the candidate T that is attempting to be the counter example for the proof. Recursion is allowed in programming and in math. If you try to just ban it, you will find you logic can't handle what it needs to.
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibble@reddwarf.jmc> |
|---|---|
| Date | 2022-05-08 20:06 +0100 |
| Message-ID | <20220508200637.0000491c@reddwarf.jmc> |
| In reply to | #50032 |
On Sun, 8 May 2022 14:10:13 -0400 Richard Damon <Richard@Damon-Family.org> wrote: > On 5/8/22 8:39 AM, Mr Flibble wrote: > > On Sun, 8 May 2022 08:31:10 -0400 > > Richard Damon <Richard@Damon-Family.org> wrote: > > > >> On 5/8/22 8:02 AM, Mr Flibble wrote: > >>> On Sun, 8 May 2022 07:45:52 -0400 > >>> Richard Damon <Richard@Damon-Family.org> wrote: > >>> > >>>> On 5/8/22 4:49 AM, Mr Flibble wrote: > >>>>> On Sun, 8 May 2022 11:31:08 +0300 > >>>>> Mikko <mikko.levanto@iki.fi> wrote: > >>>>> > >>>>>> On 2022-05-07 15:19:01 +0000, Mr Flibble said: > >>>>>> > >>>>>>> On Sat, 7 May 2022 18:13:08 +0300 > >>>>>>> Mikko <mikko.levanto@iki.fi> wrote: > >>>>>>> > >>>>>>>> On 2022-05-07 14:20:17 +0000, Mr Flibble said: > >>>>>>>> > >>>>>>>>> On Sat, 7 May 2022 17:16:31 +0300 > >>>>>>>>> Mikko <mikko.levanto@iki.fi> wrote: > >>>>>>>>> > >>>>>>>>>> On 2022-05-07 14:06:12 +0000, Mr Flibble said: > >>>>>>>>>> > >>>>>>>>>>> On Sat, 7 May 2022 16:59:55 +0300 > >>>>>>>>>>> Mikko <mikko.levanto@iki.fi> wrote: > >>>>>>>>>>> > >>>>>>>>>>>> On 2022-05-07 12:42:50 +0000, Mr Flibble said: > >>>>>>>>>>>> > >>>>>>>>>>>>> On Sat, 7 May 2022 12:52:58 +0300 > >>>>>>>>>>>>> Mikko <mikko.levanto@iki.fi> wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>>> On 2022-05-06 14:02:53 +0000, Mr Flibble said: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> The decider could never be compiled and run in the > >>>>>>>>>>>>>>> first place due to the category error in the > >>>>>>>>>>>>>>> definition of the proof. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> An error in the definition of the proof does not > >>>>>>>>>>>>>> prevent compilation and execution of the program. > >>>>>>>>>>>>> > >>>>>>>>>>>>> In this case the error in the definition of the proof > >>>>>>>>>>>> > >>>>>>>>>>>> No part of the proof is identified as errorneous, so the > >>>>>>>>>>>> rest is irrelevant. Anyway, > >>>>>>>>>>>> > >>>>>>>>>>>>> does prevent compilation unless > >>>>>>>>>>>> > >>>>>>>>>>>> There is no option here, so the "unless" is void. > >>>>>>>>>>>> > >>>>>>>>>>>>> the decider is made part of the program that is being > >>>>>>>>>>>>> decided > >>>>>>>>>>>> > >>>>>>>>>>>> The decider is made a part of the program discussed in > >>>>>>>>>>>> the proof. > >>>>>>>>>>>>> in which case we get a function call-like infinite > >>>>>>>>>>>>> recursion instead > >>>>>>>>>>>> > >>>>>>>>>>>> We get or we don't get, depending on how the halt decider > >>>>>>>>>>>> candidate attempts to decide. > >>>>>>>>>>>> > >>>>>>>>>>>>> (as described by Pete Olcott) and we are attempting (and > >>>>>>>>>>>>> failing) to decide if a procedure halts rather than if a > >>>>>>>>>>>>> program halts. > >>>>>>>>>>>> > >>>>>>>>>>>> In any case, the decider candidate fails to give the > >>>>>>>>>>>> correct answer, and therefore is not a halt decider. Note > >>>>>>>>>>>> that this is correctly inferred in the proof. Therefore > >>>>>>>>>>>> either the conclusion of the proof is correct or you are > >>>>>>>>>>>> wrong. > >>>>>>>>>>> > >>>>>>>>>>> No answer is ever given due to the infinite recursion. > >>>>>>>>>> > >>>>>>>>>> True about some candidates, false about others. For > >>>>>>>>>> example, a candidate that always says "no" is not > >>>>>>>>>> infinitely recursive but is wrong in the particular case > >>>>>>>>>> discussed in the proof. But anyway, you have confirmed the > >>>>>>>>>> conclusion of the proof. > >>>>>>>>> > >>>>>>>>> False. The proof is not cognisant of the presence of the > >>>>>>>>> infinite recursion. The decider can never return an answer > >>>>>>>>> of halts/doesn't halt due to the infinite recursion. > >>>>>>>> > >>>>>>>> The correct term is decider candidate. It is not a decider > >>>>>>>> because the infinite recursion prevents it from halting in > >>>>>>>> finite time. > >>>>>>>> > >>>>>>>> You cannot call the proof incorrect merely because it agrees > >>>>>>>> with you. > >>>>>>> > >>>>>>> Try actually reading what Strachey wrote: a contradiction > >>>>>>> arises based on the result of evaluating T[P] however T[P] is > >>>>>>> never evaluated due to the infinite recursion: a fact ignored > >>>>>>> by the proof. > >>>>>> > >>>>>> If you can prove that the program does give the correct result > >>>>>> in that case you have proven Strachey wrong. Otherwise you > >>>>>> haven't. > >>>>> > >>>>> Strachey is wrong because he neglected to account for the > >>>>> infinite recursion; this should be obvious to anyone who has > >>>>> actually read and understood what Strachey wrote: it seems that > >>>>> you haven't. > >>>>> > >>>>> /Flibble > >>>>> > >>>> > >>>> No, because if T gets stuck in an infinite recursion, it is > >>>> wrong, because it failed to answer in finite time. > >>>> > >>>> If T does answer in finite time, then there never was an infinite > >>>> recursion. > >>>> > >>>> All you have shown is that there exists a WRONG method to build > >>>> a T that gets stuck, Like a T that needs to run its input to > >>>> completion to answer about it. > >>> > >>> I have shown that [Strachey, 1965] contains an infinite recursion > >>> and is thus invalid. > >>> > >>> /Flibble > >>> > >> > >> No, you haven't. All you have shown is that one way to attempt to > >> make the program that Strachev says doesn't exist, fails due to > >> getting caught in infinite recursion. > >> > >> That just helps confirm Strachev, not refute it. > > > > Nope. Strachey's proof is based on a contradiction relating to > > evaluating the result of T[P] however T[P] can never be evaluated if > > there is an infinite recursion. > > > > /Flibble > > > > Nope, because if T actually meets the requirement to be able to take > ANY program and answer, then it need to be able to take a program > that uses a copy of T in it, as that is a valid program. > > If T gets into an infinite recursion on such a program, it is that > *T* fails to meet the requirements, not that the such a program is > invalid to give to T. > > This means that the program T is Strachey's proof can't just execute > its input to get the needed answer, as that makes it (T) not meet its > requirements. > > Thus, the "recursion" error isn't in the proof of impossibility, but > in the candidate T that is attempting to be the counter example for > the proof. > > Recursion is allowed in programming and in math. If you try to just > ban it, you will find you logic can't handle what it needs to. You are simply wrong, and fractally so. Try reading what Strachey actually wrote. /Flibble
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-05-08 15:39 -0400 |
| Message-ID | <U%UdK.8711$t72a.8053@fx10.iad> |
| In reply to | #50037 |
On 5/8/22 3:06 PM, Mr Flibble wrote: > On Sun, 8 May 2022 14:10:13 -0400 > Richard Damon <Richard@Damon-Family.org> wrote: > >> On 5/8/22 8:39 AM, Mr Flibble wrote: >>> On Sun, 8 May 2022 08:31:10 -0400 >>> Richard Damon <Richard@Damon-Family.org> wrote: >>> >>>> On 5/8/22 8:02 AM, Mr Flibble wrote: >>>>> On Sun, 8 May 2022 07:45:52 -0400 >>>>> Richard Damon <Richard@Damon-Family.org> wrote: >>>>> >>>>>> On 5/8/22 4:49 AM, Mr Flibble wrote: >>>>>>> On Sun, 8 May 2022 11:31:08 +0300 >>>>>>> Mikko <mikko.levanto@iki.fi> wrote: >>>>>>> >>>>>>>> On 2022-05-07 15:19:01 +0000, Mr Flibble said: >>>>>>>> >>>>>>>>> On Sat, 7 May 2022 18:13:08 +0300 >>>>>>>>> Mikko <mikko.levanto@iki.fi> wrote: >>>>>>>>> >>>>>>>>>> On 2022-05-07 14:20:17 +0000, Mr Flibble said: >>>>>>>>>> >>>>>>>>>>> On Sat, 7 May 2022 17:16:31 +0300 >>>>>>>>>>> Mikko <mikko.levanto@iki.fi> wrote: >>>>>>>>>>> >>>>>>>>>>>> On 2022-05-07 14:06:12 +0000, Mr Flibble said: >>>>>>>>>>>> >>>>>>>>>>>>> On Sat, 7 May 2022 16:59:55 +0300 >>>>>>>>>>>>> Mikko <mikko.levanto@iki.fi> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> On 2022-05-07 12:42:50 +0000, Mr Flibble said: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Sat, 7 May 2022 12:52:58 +0300 >>>>>>>>>>>>>>> Mikko <mikko.levanto@iki.fi> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 2022-05-06 14:02:53 +0000, Mr Flibble said: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The decider could never be compiled and run in the >>>>>>>>>>>>>>>>> first place due to the category error in the >>>>>>>>>>>>>>>>> definition of the proof. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> An error in the definition of the proof does not >>>>>>>>>>>>>>>> prevent compilation and execution of the program. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> In this case the error in the definition of the proof >>>>>>>>>>>>>> >>>>>>>>>>>>>> No part of the proof is identified as errorneous, so the >>>>>>>>>>>>>> rest is irrelevant. Anyway, >>>>>>>>>>>>>> >>>>>>>>>>>>>>> does prevent compilation unless >>>>>>>>>>>>>> >>>>>>>>>>>>>> There is no option here, so the "unless" is void. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> the decider is made part of the program that is being >>>>>>>>>>>>>>> decided >>>>>>>>>>>>>> >>>>>>>>>>>>>> The decider is made a part of the program discussed in >>>>>>>>>>>>>> the proof. >>>>>>>>>>>>>>> in which case we get a function call-like infinite >>>>>>>>>>>>>>> recursion instead >>>>>>>>>>>>>> >>>>>>>>>>>>>> We get or we don't get, depending on how the halt decider >>>>>>>>>>>>>> candidate attempts to decide. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> (as described by Pete Olcott) and we are attempting (and >>>>>>>>>>>>>>> failing) to decide if a procedure halts rather than if a >>>>>>>>>>>>>>> program halts. >>>>>>>>>>>>>> >>>>>>>>>>>>>> In any case, the decider candidate fails to give the >>>>>>>>>>>>>> correct answer, and therefore is not a halt decider. Note >>>>>>>>>>>>>> that this is correctly inferred in the proof. Therefore >>>>>>>>>>>>>> either the conclusion of the proof is correct or you are >>>>>>>>>>>>>> wrong. >>>>>>>>>>>>> >>>>>>>>>>>>> No answer is ever given due to the infinite recursion. >>>>>>>>>>>> >>>>>>>>>>>> True about some candidates, false about others. For >>>>>>>>>>>> example, a candidate that always says "no" is not >>>>>>>>>>>> infinitely recursive but is wrong in the particular case >>>>>>>>>>>> discussed in the proof. But anyway, you have confirmed the >>>>>>>>>>>> conclusion of the proof. >>>>>>>>>>> >>>>>>>>>>> False. The proof is not cognisant of the presence of the >>>>>>>>>>> infinite recursion. The decider can never return an answer >>>>>>>>>>> of halts/doesn't halt due to the infinite recursion. >>>>>>>>>> >>>>>>>>>> The correct term is decider candidate. It is not a decider >>>>>>>>>> because the infinite recursion prevents it from halting in >>>>>>>>>> finite time. >>>>>>>>>> >>>>>>>>>> You cannot call the proof incorrect merely because it agrees >>>>>>>>>> with you. >>>>>>>>> >>>>>>>>> Try actually reading what Strachey wrote: a contradiction >>>>>>>>> arises based on the result of evaluating T[P] however T[P] is >>>>>>>>> never evaluated due to the infinite recursion: a fact ignored >>>>>>>>> by the proof. >>>>>>>> >>>>>>>> If you can prove that the program does give the correct result >>>>>>>> in that case you have proven Strachey wrong. Otherwise you >>>>>>>> haven't. >>>>>>> >>>>>>> Strachey is wrong because he neglected to account for the >>>>>>> infinite recursion; this should be obvious to anyone who has >>>>>>> actually read and understood what Strachey wrote: it seems that >>>>>>> you haven't. >>>>>>> >>>>>>> /Flibble >>>>>>> >>>>>> >>>>>> No, because if T gets stuck in an infinite recursion, it is >>>>>> wrong, because it failed to answer in finite time. >>>>>> >>>>>> If T does answer in finite time, then there never was an infinite >>>>>> recursion. >>>>>> >>>>>> All you have shown is that there exists a WRONG method to build >>>>>> a T that gets stuck, Like a T that needs to run its input to >>>>>> completion to answer about it. >>>>> >>>>> I have shown that [Strachey, 1965] contains an infinite recursion >>>>> and is thus invalid. >>>>> >>>>> /Flibble >>>>> >>>> >>>> No, you haven't. All you have shown is that one way to attempt to >>>> make the program that Strachev says doesn't exist, fails due to >>>> getting caught in infinite recursion. >>>> >>>> That just helps confirm Strachev, not refute it. >>> >>> Nope. Strachey's proof is based on a contradiction relating to >>> evaluating the result of T[P] however T[P] can never be evaluated if >>> there is an infinite recursion. >>> >>> /Flibble >>> >> >> Nope, because if T actually meets the requirement to be able to take >> ANY program and answer, then it need to be able to take a program >> that uses a copy of T in it, as that is a valid program. >> >> If T gets into an infinite recursion on such a program, it is that >> *T* fails to meet the requirements, not that the such a program is >> invalid to give to T. >> >> This means that the program T is Strachey's proof can't just execute >> its input to get the needed answer, as that makes it (T) not meet its >> requirements. >> >> Thus, the "recursion" error isn't in the proof of impossibility, but >> in the candidate T that is attempting to be the counter example for >> the proof. >> >> Recursion is allowed in programming and in math. If you try to just >> ban it, you will find you logic can't handle what it needs to. > > You are simply wrong, and fractally so. Try reading what Strachey > actually wrote. > > /Flibble > I have. T[R] is defined to be a boolean function that returns True if routine R (taking no parameters) Halts, and False if R never halts. Thus, for ANY input program, T must itself Halt, that requirement INCLUDES if R calls T[R], so if T gerts into infinite recursion and thus not answer, T has failed its specification. If you want to define that T can't take the R he defines, then why is that NOT a program? What "rule of programs" has it violated, note R getting stuck in an infinite loop is one of the purposes that T is supposed to handle. T has no requirement that the input R halts or in fact, any requirement other than it be a program. Thus the fact that R gets "hung up" in an infinite recursion isn't an error in building R, but it IS a error in the design of T, as T is REQUIRED, to meet its definition to always answer. Thus, your claim about T not answering because it got stuck in an infinite recursion is just a statement that a T built that way jus fails to meet its requriement. Note, there is NO requirement in the problem that T[R] actually runs R, and in fact, you are proving that it CAN'T (at least not without some way to stop it) as that leads to T inherently failing for this sort of program. Note, any "rule" you try to invent that prohibits this "impossible program" must also take into account the "compliant" program C that should be allowed that just calls T[C] and doesn't what it says, and the two fixed behavior ones that call T with themselfs and then unconditionally Halt or Loop. All three of these should be "legal" as they do have definite answers that work, so arguements on contrariness don't apply.
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibble@reddwarf.jmc> |
|---|---|
| Date | 2022-05-08 21:14 +0100 |
| Message-ID | <20220508211421.000031a0@reddwarf.jmc> |
| In reply to | #50040 |
On Sun, 8 May 2022 15:39:32 -0400 Richard Damon <Richard@Damon-Family.org> wrote: > On 5/8/22 3:06 PM, Mr Flibble wrote: > > On Sun, 8 May 2022 14:10:13 -0400 > > Richard Damon <Richard@Damon-Family.org> wrote: > > > >> On 5/8/22 8:39 AM, Mr Flibble wrote: > >>> On Sun, 8 May 2022 08:31:10 -0400 > >>> Richard Damon <Richard@Damon-Family.org> wrote: > >>> > >>>> On 5/8/22 8:02 AM, Mr Flibble wrote: > >>>>> On Sun, 8 May 2022 07:45:52 -0400 > >>>>> Richard Damon <Richard@Damon-Family.org> wrote: > >>>>> > >>>>>> On 5/8/22 4:49 AM, Mr Flibble wrote: > >>>>>>> On Sun, 8 May 2022 11:31:08 +0300 > >>>>>>> Mikko <mikko.levanto@iki.fi> wrote: > >>>>>>> > >>>>>>>> On 2022-05-07 15:19:01 +0000, Mr Flibble said: > >>>>>>>> > >>>>>>>>> On Sat, 7 May 2022 18:13:08 +0300 > >>>>>>>>> Mikko <mikko.levanto@iki.fi> wrote: > >>>>>>>>> > >>>>>>>>>> On 2022-05-07 14:20:17 +0000, Mr Flibble said: > >>>>>>>>>> > >>>>>>>>>>> On Sat, 7 May 2022 17:16:31 +0300 > >>>>>>>>>>> Mikko <mikko.levanto@iki.fi> wrote: > >>>>>>>>>>> > >>>>>>>>>>>> On 2022-05-07 14:06:12 +0000, Mr Flibble said: > >>>>>>>>>>>> > >>>>>>>>>>>>> On Sat, 7 May 2022 16:59:55 +0300 > >>>>>>>>>>>>> Mikko <mikko.levanto@iki.fi> wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>>> On 2022-05-07 12:42:50 +0000, Mr Flibble said: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> On Sat, 7 May 2022 12:52:58 +0300 > >>>>>>>>>>>>>>> Mikko <mikko.levanto@iki.fi> wrote: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> On 2022-05-06 14:02:53 +0000, Mr Flibble said: > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> The decider could never be compiled and run in the > >>>>>>>>>>>>>>>>> first place due to the category error in the > >>>>>>>>>>>>>>>>> definition of the proof. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> An error in the definition of the proof does not > >>>>>>>>>>>>>>>> prevent compilation and execution of the program. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> In this case the error in the definition of the proof > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> No part of the proof is identified as errorneous, so > >>>>>>>>>>>>>> the rest is irrelevant. Anyway, > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> does prevent compilation unless > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> There is no option here, so the "unless" is void. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> the decider is made part of the program that is being > >>>>>>>>>>>>>>> decided > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> The decider is made a part of the program discussed in > >>>>>>>>>>>>>> the proof. > >>>>>>>>>>>>>>> in which case we get a function call-like infinite > >>>>>>>>>>>>>>> recursion instead > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> We get or we don't get, depending on how the halt > >>>>>>>>>>>>>> decider candidate attempts to decide. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> (as described by Pete Olcott) and we are attempting > >>>>>>>>>>>>>>> (and failing) to decide if a procedure halts rather > >>>>>>>>>>>>>>> than if a program halts. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> In any case, the decider candidate fails to give the > >>>>>>>>>>>>>> correct answer, and therefore is not a halt decider. > >>>>>>>>>>>>>> Note that this is correctly inferred in the proof. > >>>>>>>>>>>>>> Therefore either the conclusion of the proof is > >>>>>>>>>>>>>> correct or you are wrong. > >>>>>>>>>>>>> > >>>>>>>>>>>>> No answer is ever given due to the infinite recursion. > >>>>>>>>>>>> > >>>>>>>>>>>> True about some candidates, false about others. For > >>>>>>>>>>>> example, a candidate that always says "no" is not > >>>>>>>>>>>> infinitely recursive but is wrong in the particular case > >>>>>>>>>>>> discussed in the proof. But anyway, you have confirmed > >>>>>>>>>>>> the conclusion of the proof. > >>>>>>>>>>> > >>>>>>>>>>> False. The proof is not cognisant of the presence of the > >>>>>>>>>>> infinite recursion. The decider can never return an > >>>>>>>>>>> answer of halts/doesn't halt due to the infinite > >>>>>>>>>>> recursion. > >>>>>>>>>> > >>>>>>>>>> The correct term is decider candidate. It is not a decider > >>>>>>>>>> because the infinite recursion prevents it from halting in > >>>>>>>>>> finite time. > >>>>>>>>>> > >>>>>>>>>> You cannot call the proof incorrect merely because it > >>>>>>>>>> agrees with you. > >>>>>>>>> > >>>>>>>>> Try actually reading what Strachey wrote: a contradiction > >>>>>>>>> arises based on the result of evaluating T[P] however T[P] > >>>>>>>>> is never evaluated due to the infinite recursion: a fact > >>>>>>>>> ignored by the proof. > >>>>>>>> > >>>>>>>> If you can prove that the program does give the correct > >>>>>>>> result in that case you have proven Strachey wrong. > >>>>>>>> Otherwise you haven't. > >>>>>>> > >>>>>>> Strachey is wrong because he neglected to account for the > >>>>>>> infinite recursion; this should be obvious to anyone who has > >>>>>>> actually read and understood what Strachey wrote: it seems > >>>>>>> that you haven't. > >>>>>>> > >>>>>>> /Flibble > >>>>>>> > >>>>>> > >>>>>> No, because if T gets stuck in an infinite recursion, it is > >>>>>> wrong, because it failed to answer in finite time. > >>>>>> > >>>>>> If T does answer in finite time, then there never was an > >>>>>> infinite recursion. > >>>>>> > >>>>>> All you have shown is that there exists a WRONG method to build > >>>>>> a T that gets stuck, Like a T that needs to run its input to > >>>>>> completion to answer about it. > >>>>> > >>>>> I have shown that [Strachey, 1965] contains an infinite > >>>>> recursion and is thus invalid. > >>>>> > >>>>> /Flibble > >>>>> > >>>> > >>>> No, you haven't. All you have shown is that one way to attempt to > >>>> make the program that Strachev says doesn't exist, fails due to > >>>> getting caught in infinite recursion. > >>>> > >>>> That just helps confirm Strachev, not refute it. > >>> > >>> Nope. Strachey's proof is based on a contradiction relating to > >>> evaluating the result of T[P] however T[P] can never be evaluated > >>> if there is an infinite recursion. > >>> > >>> /Flibble > >>> > >> > >> Nope, because if T actually meets the requirement to be able to > >> take ANY program and answer, then it need to be able to take a > >> program that uses a copy of T in it, as that is a valid program. > >> > >> If T gets into an infinite recursion on such a program, it is that > >> *T* fails to meet the requirements, not that the such a program is > >> invalid to give to T. > >> > >> This means that the program T is Strachey's proof can't just > >> execute its input to get the needed answer, as that makes it (T) > >> not meet its requirements. > >> > >> Thus, the "recursion" error isn't in the proof of impossibility, > >> but in the candidate T that is attempting to be the counter > >> example for the proof. > >> > >> Recursion is allowed in programming and in math. If you try to just > >> ban it, you will find you logic can't handle what it needs to. > > > > You are simply wrong, and fractally so. Try reading what Strachey > > actually wrote. > > > > /Flibble > > > > I have. > > T[R] is defined to be a boolean function that returns True if routine > R (taking no parameters) Halts, and False if R never halts. > > Thus, for ANY input program, T must itself Halt, that requirement > INCLUDES if R calls T[R], so if T gerts into infinite recursion and > thus not answer, T has failed its specification. > > If you want to define that T can't take the R he defines, then why is > that NOT a program? What "rule of programs" has it violated, note R > getting stuck in an infinite loop is one of the purposes that T is > supposed to handle. > > T has no requirement that the input R halts or in fact, any > requirement other than it be a program. Thus the fact that R gets > "hung up" in an infinite recursion isn't an error in building R, but > it IS a error in the design of T, as T is REQUIRED, to meet its > definition to always answer. > > Thus, your claim about T not answering because it got stuck in an > infinite recursion is just a statement that a T built that way jus > fails to meet its requriement. > > Note, there is NO requirement in the problem that T[R] actually runs > R, and in fact, you are proving that it CAN'T (at least not without > some way to stop it) as that leads to T inherently failing for this > sort of program. > > Note, any "rule" you try to invent that prohibits this "impossible > program" must also take into account the "compliant" program C that > should be allowed that just calls T[C] and doesn't what it says, and > the two fixed behavior ones that call T with themselfs and then > unconditionally Halt or Loop. All three of these should be "legal" as > they do have definite answers that work, so arguements on > contrariness don't apply. You continue to be wrong and fractally so. The infinite recursion will ALWAYS happen according to the definition of the proof. Again: read AND UNDERSTAND what Strachey actually wrote. /Flibble
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-05-08 17:40 -0400 |
| Message-ID | <ENWdK.7593$VwRc.5901@fx01.iad> |
| In reply to | #50041 |
On 5/8/22 4:14 PM, Mr Flibble wrote: > On Sun, 8 May 2022 15:39:32 -0400 > Richard Damon <Richard@Damon-Family.org> wrote: > >> On 5/8/22 3:06 PM, Mr Flibble wrote: >>> On Sun, 8 May 2022 14:10:13 -0400 >>> Richard Damon <Richard@Damon-Family.org> wrote: >>> >>>> On 5/8/22 8:39 AM, Mr Flibble wrote: >>>>> On Sun, 8 May 2022 08:31:10 -0400 >>>>> Richard Damon <Richard@Damon-Family.org> wrote: >>>>> >>>>>> On 5/8/22 8:02 AM, Mr Flibble wrote: >>>>>>> On Sun, 8 May 2022 07:45:52 -0400 >>>>>>> Richard Damon <Richard@Damon-Family.org> wrote: >>>>>>> >>>>>>>> On 5/8/22 4:49 AM, Mr Flibble wrote: >>>>>>>>> On Sun, 8 May 2022 11:31:08 +0300 >>>>>>>>> Mikko <mikko.levanto@iki.fi> wrote: >>>>>>>>> >>>>>>>>>> On 2022-05-07 15:19:01 +0000, Mr Flibble said: >>>>>>>>>> >>>>>>>>>>> On Sat, 7 May 2022 18:13:08 +0300 >>>>>>>>>>> Mikko <mikko.levanto@iki.fi> wrote: >>>>>>>>>>> >>>>>>>>>>>> On 2022-05-07 14:20:17 +0000, Mr Flibble said: >>>>>>>>>>>> >>>>>>>>>>>>> On Sat, 7 May 2022 17:16:31 +0300 >>>>>>>>>>>>> Mikko <mikko.levanto@iki.fi> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> On 2022-05-07 14:06:12 +0000, Mr Flibble said: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Sat, 7 May 2022 16:59:55 +0300 >>>>>>>>>>>>>>> Mikko <mikko.levanto@iki.fi> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 2022-05-07 12:42:50 +0000, Mr Flibble said: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Sat, 7 May 2022 12:52:58 +0300 >>>>>>>>>>>>>>>>> Mikko <mikko.levanto@iki.fi> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 2022-05-06 14:02:53 +0000, Mr Flibble said: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> The decider could never be compiled and run in the >>>>>>>>>>>>>>>>>>> first place due to the category error in the >>>>>>>>>>>>>>>>>>> definition of the proof. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> An error in the definition of the proof does not >>>>>>>>>>>>>>>>>> prevent compilation and execution of the program. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> In this case the error in the definition of the proof >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> No part of the proof is identified as errorneous, so >>>>>>>>>>>>>>>> the rest is irrelevant. Anyway, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> does prevent compilation unless >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> There is no option here, so the "unless" is void. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> the decider is made part of the program that is being >>>>>>>>>>>>>>>>> decided >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The decider is made a part of the program discussed in >>>>>>>>>>>>>>>> the proof. >>>>>>>>>>>>>>>>> in which case we get a function call-like infinite >>>>>>>>>>>>>>>>> recursion instead >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> We get or we don't get, depending on how the halt >>>>>>>>>>>>>>>> decider candidate attempts to decide. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> (as described by Pete Olcott) and we are attempting >>>>>>>>>>>>>>>>> (and failing) to decide if a procedure halts rather >>>>>>>>>>>>>>>>> than if a program halts. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> In any case, the decider candidate fails to give the >>>>>>>>>>>>>>>> correct answer, and therefore is not a halt decider. >>>>>>>>>>>>>>>> Note that this is correctly inferred in the proof. >>>>>>>>>>>>>>>> Therefore either the conclusion of the proof is >>>>>>>>>>>>>>>> correct or you are wrong. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> No answer is ever given due to the infinite recursion. >>>>>>>>>>>>>> >>>>>>>>>>>>>> True about some candidates, false about others. For >>>>>>>>>>>>>> example, a candidate that always says "no" is not >>>>>>>>>>>>>> infinitely recursive but is wrong in the particular case >>>>>>>>>>>>>> discussed in the proof. But anyway, you have confirmed >>>>>>>>>>>>>> the conclusion of the proof. >>>>>>>>>>>>> >>>>>>>>>>>>> False. The proof is not cognisant of the presence of the >>>>>>>>>>>>> infinite recursion. The decider can never return an >>>>>>>>>>>>> answer of halts/doesn't halt due to the infinite >>>>>>>>>>>>> recursion. >>>>>>>>>>>> >>>>>>>>>>>> The correct term is decider candidate. It is not a decider >>>>>>>>>>>> because the infinite recursion prevents it from halting in >>>>>>>>>>>> finite time. >>>>>>>>>>>> >>>>>>>>>>>> You cannot call the proof incorrect merely because it >>>>>>>>>>>> agrees with you. >>>>>>>>>>> >>>>>>>>>>> Try actually reading what Strachey wrote: a contradiction >>>>>>>>>>> arises based on the result of evaluating T[P] however T[P] >>>>>>>>>>> is never evaluated due to the infinite recursion: a fact >>>>>>>>>>> ignored by the proof. >>>>>>>>>> >>>>>>>>>> If you can prove that the program does give the correct >>>>>>>>>> result in that case you have proven Strachey wrong. >>>>>>>>>> Otherwise you haven't. >>>>>>>>> >>>>>>>>> Strachey is wrong because he neglected to account for the >>>>>>>>> infinite recursion; this should be obvious to anyone who has >>>>>>>>> actually read and understood what Strachey wrote: it seems >>>>>>>>> that you haven't. >>>>>>>>> >>>>>>>>> /Flibble >>>>>>>>> >>>>>>>> >>>>>>>> No, because if T gets stuck in an infinite recursion, it is >>>>>>>> wrong, because it failed to answer in finite time. >>>>>>>> >>>>>>>> If T does answer in finite time, then there never was an >>>>>>>> infinite recursion. >>>>>>>> >>>>>>>> All you have shown is that there exists a WRONG method to build >>>>>>>> a T that gets stuck, Like a T that needs to run its input to >>>>>>>> completion to answer about it. >>>>>>> >>>>>>> I have shown that [Strachey, 1965] contains an infinite >>>>>>> recursion and is thus invalid. >>>>>>> >>>>>>> /Flibble >>>>>>> >>>>>> >>>>>> No, you haven't. All you have shown is that one way to attempt to >>>>>> make the program that Strachev says doesn't exist, fails due to >>>>>> getting caught in infinite recursion. >>>>>> >>>>>> That just helps confirm Strachev, not refute it. >>>>> >>>>> Nope. Strachey's proof is based on a contradiction relating to >>>>> evaluating the result of T[P] however T[P] can never be evaluated >>>>> if there is an infinite recursion. >>>>> >>>>> /Flibble >>>>> >>>> >>>> Nope, because if T actually meets the requirement to be able to >>>> take ANY program and answer, then it need to be able to take a >>>> program that uses a copy of T in it, as that is a valid program. >>>> >>>> If T gets into an infinite recursion on such a program, it is that >>>> *T* fails to meet the requirements, not that the such a program is >>>> invalid to give to T. >>>> >>>> This means that the program T is Strachey's proof can't just >>>> execute its input to get the needed answer, as that makes it (T) >>>> not meet its requirements. >>>> >>>> Thus, the "recursion" error isn't in the proof of impossibility, >>>> but in the candidate T that is attempting to be the counter >>>> example for the proof. >>>> >>>> Recursion is allowed in programming and in math. If you try to just >>>> ban it, you will find you logic can't handle what it needs to. >>> >>> You are simply wrong, and fractally so. Try reading what Strachey >>> actually wrote. >>> >>> /Flibble >>> >> >> I have. >> >> T[R] is defined to be a boolean function that returns True if routine >> R (taking no parameters) Halts, and False if R never halts. >> >> Thus, for ANY input program, T must itself Halt, that requirement >> INCLUDES if R calls T[R], so if T gerts into infinite recursion and >> thus not answer, T has failed its specification. >> >> If you want to define that T can't take the R he defines, then why is >> that NOT a program? What "rule of programs" has it violated, note R >> getting stuck in an infinite loop is one of the purposes that T is >> supposed to handle. >> >> T has no requirement that the input R halts or in fact, any >> requirement other than it be a program. Thus the fact that R gets >> "hung up" in an infinite recursion isn't an error in building R, but >> it IS a error in the design of T, as T is REQUIRED, to meet its >> definition to always answer. >> >> Thus, your claim about T not answering because it got stuck in an >> infinite recursion is just a statement that a T built that way jus >> fails to meet its requriement. >> >> Note, there is NO requirement in the problem that T[R] actually runs >> R, and in fact, you are proving that it CAN'T (at least not without >> some way to stop it) as that leads to T inherently failing for this >> sort of program. >> >> Note, any "rule" you try to invent that prohibits this "impossible >> program" must also take into account the "compliant" program C that >> should be allowed that just calls T[C] and doesn't what it says, and >> the two fixed behavior ones that call T with themselfs and then >> unconditionally Halt or Loop. All three of these should be "legal" as >> they do have definite answers that work, so arguements on >> contrariness don't apply. > > You continue to be wrong and fractally so. The infinite recursion will > ALWAYS happen according to the definition of the proof. Again: read AND > UNDERSTAND what Strachey actually wrote. > > /Flibble > Nope. Yes, R will call/invoke T to get a value, but T does not (and in fact can not) invoke R to determine if it halts, so no infinite recursion. Note, you are making the error of assuming that the only way to even try to determine if a program will halt is to just run it. In fact, if T does do some partial running to get information, it must strictly limit how much it allows the program to run to get the data it needs, or it will fail to meet the requirement to decide. Once it has in place that sort of limit, no infinite recursion becomes possible, because T won't partially run its input forever. This is just like Olcott's H, if it is going to answer, MUST abort its simulation to give an answer, and it will always give the wrong answer bucause it didn't get enough information, and did it analysis with the false assumption that the copy of H in P/H^ won't abort its simulation since it didn't simulate long enough to see it.
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibble@reddwarf.jmc> |
|---|---|
| Date | 2022-05-08 23:04 +0100 |
| Message-ID | <20220508230420.0000053f@reddwarf.jmc> |
| In reply to | #50043 |
On Sun, 8 May 2022 17:40:52 -0400 Richard Damon <Richard@Damon-Family.org> wrote: > On 5/8/22 4:14 PM, Mr Flibble wrote: > > On Sun, 8 May 2022 15:39:32 -0400 > > Richard Damon <Richard@Damon-Family.org> wrote: > > > >> On 5/8/22 3:06 PM, Mr Flibble wrote: > >>> On Sun, 8 May 2022 14:10:13 -0400 > >>> Richard Damon <Richard@Damon-Family.org> wrote: > >>> > >>>> On 5/8/22 8:39 AM, Mr Flibble wrote: > >>>>> On Sun, 8 May 2022 08:31:10 -0400 > >>>>> Richard Damon <Richard@Damon-Family.org> wrote: > >>>>> > >>>>>> On 5/8/22 8:02 AM, Mr Flibble wrote: > >>>>>>> On Sun, 8 May 2022 07:45:52 -0400 > >>>>>>> Richard Damon <Richard@Damon-Family.org> wrote: > >>>>>>> > >>>>>>>> On 5/8/22 4:49 AM, Mr Flibble wrote: > >>>>>>>>> On Sun, 8 May 2022 11:31:08 +0300 > >>>>>>>>> Mikko <mikko.levanto@iki.fi> wrote: > >>>>>>>>> > >>>>>>>>>> On 2022-05-07 15:19:01 +0000, Mr Flibble said: > >>>>>>>>>> > >>>>>>>>>>> On Sat, 7 May 2022 18:13:08 +0300 > >>>>>>>>>>> Mikko <mikko.levanto@iki.fi> wrote: > >>>>>>>>>>> > >>>>>>>>>>>> On 2022-05-07 14:20:17 +0000, Mr Flibble said: > >>>>>>>>>>>> > >>>>>>>>>>>>> On Sat, 7 May 2022 17:16:31 +0300 > >>>>>>>>>>>>> Mikko <mikko.levanto@iki.fi> wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>>> On 2022-05-07 14:06:12 +0000, Mr Flibble said: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> On Sat, 7 May 2022 16:59:55 +0300 > >>>>>>>>>>>>>>> Mikko <mikko.levanto@iki.fi> wrote: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> On 2022-05-07 12:42:50 +0000, Mr Flibble said: > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> On Sat, 7 May 2022 12:52:58 +0300 > >>>>>>>>>>>>>>>>> Mikko <mikko.levanto@iki.fi> wrote: > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> On 2022-05-06 14:02:53 +0000, Mr Flibble said: > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> The decider could never be compiled and run in the > >>>>>>>>>>>>>>>>>>> first place due to the category error in the > >>>>>>>>>>>>>>>>>>> definition of the proof. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> An error in the definition of the proof does not > >>>>>>>>>>>>>>>>>> prevent compilation and execution of the program. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> In this case the error in the definition of the > >>>>>>>>>>>>>>>>> proof > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> No part of the proof is identified as errorneous, so > >>>>>>>>>>>>>>>> the rest is irrelevant. Anyway, > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> does prevent compilation unless > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> There is no option here, so the "unless" is void. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> the decider is made part of the program that is > >>>>>>>>>>>>>>>>> being decided > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> The decider is made a part of the program discussed > >>>>>>>>>>>>>>>> in the proof. > >>>>>>>>>>>>>>>>> in which case we get a function call-like infinite > >>>>>>>>>>>>>>>>> recursion instead > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> We get or we don't get, depending on how the halt > >>>>>>>>>>>>>>>> decider candidate attempts to decide. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> (as described by Pete Olcott) and we are attempting > >>>>>>>>>>>>>>>>> (and failing) to decide if a procedure halts rather > >>>>>>>>>>>>>>>>> than if a program halts. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> In any case, the decider candidate fails to give the > >>>>>>>>>>>>>>>> correct answer, and therefore is not a halt decider. > >>>>>>>>>>>>>>>> Note that this is correctly inferred in the proof. > >>>>>>>>>>>>>>>> Therefore either the conclusion of the proof is > >>>>>>>>>>>>>>>> correct or you are wrong. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> No answer is ever given due to the infinite > >>>>>>>>>>>>>>> recursion. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> True about some candidates, false about others. For > >>>>>>>>>>>>>> example, a candidate that always says "no" is not > >>>>>>>>>>>>>> infinitely recursive but is wrong in the particular > >>>>>>>>>>>>>> case discussed in the proof. But anyway, you have > >>>>>>>>>>>>>> confirmed the conclusion of the proof. > >>>>>>>>>>>>> > >>>>>>>>>>>>> False. The proof is not cognisant of the presence of the > >>>>>>>>>>>>> infinite recursion. The decider can never return an > >>>>>>>>>>>>> answer of halts/doesn't halt due to the infinite > >>>>>>>>>>>>> recursion. > >>>>>>>>>>>> > >>>>>>>>>>>> The correct term is decider candidate. It is not a > >>>>>>>>>>>> decider because the infinite recursion prevents it from > >>>>>>>>>>>> halting in finite time. > >>>>>>>>>>>> > >>>>>>>>>>>> You cannot call the proof incorrect merely because it > >>>>>>>>>>>> agrees with you. > >>>>>>>>>>> > >>>>>>>>>>> Try actually reading what Strachey wrote: a contradiction > >>>>>>>>>>> arises based on the result of evaluating T[P] however T[P] > >>>>>>>>>>> is never evaluated due to the infinite recursion: a fact > >>>>>>>>>>> ignored by the proof. > >>>>>>>>>> > >>>>>>>>>> If you can prove that the program does give the correct > >>>>>>>>>> result in that case you have proven Strachey wrong. > >>>>>>>>>> Otherwise you haven't. > >>>>>>>>> > >>>>>>>>> Strachey is wrong because he neglected to account for the > >>>>>>>>> infinite recursion; this should be obvious to anyone who has > >>>>>>>>> actually read and understood what Strachey wrote: it seems > >>>>>>>>> that you haven't. > >>>>>>>>> > >>>>>>>>> /Flibble > >>>>>>>>> > >>>>>>>> > >>>>>>>> No, because if T gets stuck in an infinite recursion, it is > >>>>>>>> wrong, because it failed to answer in finite time. > >>>>>>>> > >>>>>>>> If T does answer in finite time, then there never was an > >>>>>>>> infinite recursion. > >>>>>>>> > >>>>>>>> All you have shown is that there exists a WRONG method to > >>>>>>>> build a T that gets stuck, Like a T that needs to run its > >>>>>>>> input to completion to answer about it. > >>>>>>> > >>>>>>> I have shown that [Strachey, 1965] contains an infinite > >>>>>>> recursion and is thus invalid. > >>>>>>> > >>>>>>> /Flibble > >>>>>>> > >>>>>> > >>>>>> No, you haven't. All you have shown is that one way to attempt > >>>>>> to make the program that Strachev says doesn't exist, fails > >>>>>> due to getting caught in infinite recursion. > >>>>>> > >>>>>> That just helps confirm Strachev, not refute it. > >>>>> > >>>>> Nope. Strachey's proof is based on a contradiction relating to > >>>>> evaluating the result of T[P] however T[P] can never be > >>>>> evaluated if there is an infinite recursion. > >>>>> > >>>>> /Flibble > >>>>> > >>>> > >>>> Nope, because if T actually meets the requirement to be able to > >>>> take ANY program and answer, then it need to be able to take a > >>>> program that uses a copy of T in it, as that is a valid program. > >>>> > >>>> If T gets into an infinite recursion on such a program, it is > >>>> that *T* fails to meet the requirements, not that the such a > >>>> program is invalid to give to T. > >>>> > >>>> This means that the program T is Strachey's proof can't just > >>>> execute its input to get the needed answer, as that makes it (T) > >>>> not meet its requirements. > >>>> > >>>> Thus, the "recursion" error isn't in the proof of impossibility, > >>>> but in the candidate T that is attempting to be the counter > >>>> example for the proof. > >>>> > >>>> Recursion is allowed in programming and in math. If you try to > >>>> just ban it, you will find you logic can't handle what it needs > >>>> to. > >>> > >>> You are simply wrong, and fractally so. Try reading what Strachey > >>> actually wrote. > >>> > >>> /Flibble > >>> > >> > >> I have. > >> > >> T[R] is defined to be a boolean function that returns True if > >> routine R (taking no parameters) Halts, and False if R never halts. > >> > >> Thus, for ANY input program, T must itself Halt, that requirement > >> INCLUDES if R calls T[R], so if T gerts into infinite recursion and > >> thus not answer, T has failed its specification. > >> > >> If you want to define that T can't take the R he defines, then why > >> is that NOT a program? What "rule of programs" has it violated, > >> note R getting stuck in an infinite loop is one of the purposes > >> that T is supposed to handle. > >> > >> T has no requirement that the input R halts or in fact, any > >> requirement other than it be a program. Thus the fact that R gets > >> "hung up" in an infinite recursion isn't an error in building R, > >> but it IS a error in the design of T, as T is REQUIRED, to meet its > >> definition to always answer. > >> > >> Thus, your claim about T not answering because it got stuck in an > >> infinite recursion is just a statement that a T built that way jus > >> fails to meet its requriement. > >> > >> Note, there is NO requirement in the problem that T[R] actually > >> runs R, and in fact, you are proving that it CAN'T (at least not > >> without some way to stop it) as that leads to T inherently failing > >> for this sort of program. > >> > >> Note, any "rule" you try to invent that prohibits this "impossible > >> program" must also take into account the "compliant" program C that > >> should be allowed that just calls T[C] and doesn't what it says, > >> and the two fixed behavior ones that call T with themselfs and then > >> unconditionally Halt or Loop. All three of these should be "legal" > >> as they do have definite answers that work, so arguements on > >> contrariness don't apply. > > > > You continue to be wrong and fractally so. The infinite recursion > > will ALWAYS happen according to the definition of the proof. Again: > > read AND UNDERSTAND what Strachey actually wrote. > > > > /Flibble > > > > Nope. Yes, R will call/invoke T to get a value, but T does not (and > in fact can not) invoke R to determine if it halts, so no infinite > recursion. > > Note, you are making the error of assuming that the only way to even > try to determine if a program will halt is to just run it. > > In fact, if T does do some partial running to get information, it > must strictly limit how much it allows the program to run to get the > data it needs, or it will fail to meet the requirement to decide. > > Once it has in place that sort of limit, no infinite recursion > becomes possible, because T won't partially run its input forever. > > This is just like Olcott's H, if it is going to answer, MUST abort > its simulation to give an answer, and it will always give the wrong > answer bucause it didn't get enough information, and did it analysis > with the false assumption that the copy of H in P/H^ won't abort its > simulation since it didn't simulate long enough to see it. Confusion lay with what Strachey said: "T[R] = True if R terminates if run" "if run" doesn't have to mean T[R] runs R. HOWEVER it would be nice to know what T[R] actually means in the obsolete CPL programming language Strachey is using (R is a ROUTINE passed as an argument to T a FUNCTION). Didn't spot anything obvious in http://www.ancientgeek.org.uk/CPL/CPL_Elementary_Programming_Manual.pdf but I only had a cursory look. So modulo the outcome of that CPL question I agree with you and Olcott is wrong if his mistake is the same as mine. Any other business? /Flibble
[toc] | [prev] | [next] | [standalone]
| From | Ben <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-05-09 00:26 +0100 |
| Message-ID | <87r153sj1r.fsf@bsb.me.uk> |
| In reply to | #50045 |
Mr Flibble <flibble@reddwarf.jmc> writes: > On Sun, 8 May 2022 17:40:52 -0400 > Richard Damon <Richard@Damon-Family.org> wrote: <cut> >> Nope. Yes, R will call/invoke T to get a value, but T does not (and >> in fact can not) invoke R to determine if it halts, so no infinite >> recursion. >> >> Note, you are making the error of assuming that the only way to even >> try to determine if a program will halt is to just run it. <cut> > Confusion lay with what Strachey said: > > "T[R] = True if R terminates if run" > > "if run" doesn't have to mean T[R] runs R. > > HOWEVER it would be nice to know what T[R] actually means in the > obsolete CPL programming language Strachey is using (R is a ROUTINE > passed as an argument to T a FUNCTION). That's all it is, like T(R) in C (with R a void function being the closest thing to a routine in C). But, as you've seen, there's a basic problem with all sketches like this. You have to imagine that whatever T /might/ be able to do won't be enough, despite knowing that T can't really do anything with a routine but call it. We might speculate that this implementation of CPL provides a SourceOf[R] function that recovers the source code for R, or maybe T can inspect the compiled code via that argument (as you can do in non-standard C code) and make the decision based on that. This is not a problem for Turing machines, because a TM can only be provided with a string of symbols that represents (in some agreed encoding) a TM/input pair. The TM has access to every deducible fact about that TM/input pair and the proof just shows that halting is not one of those deducible facts. A good middle ground between CPL and and Turing machine is Lisp, as Lisp programs have the same form as Lisp data. A halt decider for Lisp would be passed an S-expression like this: (defun halt_decider (exp) ...) with the specification that (halt_decider e) returns true if (eval e) would terminate and false otherwise. halt_decider can't actually run (eval e) to find out, of course, but the function can examine the expression to determine it's structure and could decide on that basis. The function could even include a Lisp interpreter so as to carry out a partial interpretation of (eval e) which, along with any other examination of e that the programmer can imagine, could be used to make the decision. These are all techniques motivated by the features of Lisp itself where CPL (at least without any extensions) can do nothing with a routine other than call it. > So modulo the outcome of that CPL question I agree with you and Olcott > is wrong if his mistake is the same as mine. A rare thing in Usenet. Kudos. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-05-08 19:40 -0400 |
| Message-ID | <8yYdK.6345$6iMa.2142@fx39.iad> |
| In reply to | #50045 |
On 5/8/22 6:04 PM, Mr Flibble wrote: > On Sun, 8 May 2022 17:40:52 -0400 > Richard Damon <Richard@Damon-Family.org> wrote: > >> On 5/8/22 4:14 PM, Mr Flibble wrote: >>> On Sun, 8 May 2022 15:39:32 -0400 >>> Richard Damon <Richard@Damon-Family.org> wrote: >>> >>>> On 5/8/22 3:06 PM, Mr Flibble wrote: >>>>> On Sun, 8 May 2022 14:10:13 -0400 >>>>> Richard Damon <Richard@Damon-Family.org> wrote: >>>>> >>>>>> On 5/8/22 8:39 AM, Mr Flibble wrote: >>>>>>> On Sun, 8 May 2022 08:31:10 -0400 >>>>>>> Richard Damon <Richard@Damon-Family.org> wrote: >>>>>>> >>>>>>>> On 5/8/22 8:02 AM, Mr Flibble wrote: >>>>>>>>> On Sun, 8 May 2022 07:45:52 -0400 >>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote: >>>>>>>>> >>>>>>>>>> On 5/8/22 4:49 AM, Mr Flibble wrote: >>>>>>>>>>> On Sun, 8 May 2022 11:31:08 +0300 >>>>>>>>>>> Mikko <mikko.levanto@iki.fi> wrote: >>>>>>>>>>> >>>>>>>>>>>> On 2022-05-07 15:19:01 +0000, Mr Flibble said: >>>>>>>>>>>> >>>>>>>>>>>>> On Sat, 7 May 2022 18:13:08 +0300 >>>>>>>>>>>>> Mikko <mikko.levanto@iki.fi> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> On 2022-05-07 14:20:17 +0000, Mr Flibble said: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Sat, 7 May 2022 17:16:31 +0300 >>>>>>>>>>>>>>> Mikko <mikko.levanto@iki.fi> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 2022-05-07 14:06:12 +0000, Mr Flibble said: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Sat, 7 May 2022 16:59:55 +0300 >>>>>>>>>>>>>>>>> Mikko <mikko.levanto@iki.fi> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 2022-05-07 12:42:50 +0000, Mr Flibble said: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Sat, 7 May 2022 12:52:58 +0300 >>>>>>>>>>>>>>>>>>> Mikko <mikko.levanto@iki.fi> wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On 2022-05-06 14:02:53 +0000, Mr Flibble said: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> The decider could never be compiled and run in the >>>>>>>>>>>>>>>>>>>>> first place due to the category error in the >>>>>>>>>>>>>>>>>>>>> definition of the proof. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> An error in the definition of the proof does not >>>>>>>>>>>>>>>>>>>> prevent compilation and execution of the program. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> In this case the error in the definition of the >>>>>>>>>>>>>>>>>>> proof >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> No part of the proof is identified as errorneous, so >>>>>>>>>>>>>>>>>> the rest is irrelevant. Anyway, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> does prevent compilation unless >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> There is no option here, so the "unless" is void. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> the decider is made part of the program that is >>>>>>>>>>>>>>>>>>> being decided >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> The decider is made a part of the program discussed >>>>>>>>>>>>>>>>>> in the proof. >>>>>>>>>>>>>>>>>>> in which case we get a function call-like infinite >>>>>>>>>>>>>>>>>>> recursion instead >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> We get or we don't get, depending on how the halt >>>>>>>>>>>>>>>>>> decider candidate attempts to decide. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> (as described by Pete Olcott) and we are attempting >>>>>>>>>>>>>>>>>>> (and failing) to decide if a procedure halts rather >>>>>>>>>>>>>>>>>>> than if a program halts. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> In any case, the decider candidate fails to give the >>>>>>>>>>>>>>>>>> correct answer, and therefore is not a halt decider. >>>>>>>>>>>>>>>>>> Note that this is correctly inferred in the proof. >>>>>>>>>>>>>>>>>> Therefore either the conclusion of the proof is >>>>>>>>>>>>>>>>>> correct or you are wrong. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> No answer is ever given due to the infinite >>>>>>>>>>>>>>>>> recursion. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> True about some candidates, false about others. For >>>>>>>>>>>>>>>> example, a candidate that always says "no" is not >>>>>>>>>>>>>>>> infinitely recursive but is wrong in the particular >>>>>>>>>>>>>>>> case discussed in the proof. But anyway, you have >>>>>>>>>>>>>>>> confirmed the conclusion of the proof. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> False. The proof is not cognisant of the presence of the >>>>>>>>>>>>>>> infinite recursion. The decider can never return an >>>>>>>>>>>>>>> answer of halts/doesn't halt due to the infinite >>>>>>>>>>>>>>> recursion. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The correct term is decider candidate. It is not a >>>>>>>>>>>>>> decider because the infinite recursion prevents it from >>>>>>>>>>>>>> halting in finite time. >>>>>>>>>>>>>> >>>>>>>>>>>>>> You cannot call the proof incorrect merely because it >>>>>>>>>>>>>> agrees with you. >>>>>>>>>>>>> >>>>>>>>>>>>> Try actually reading what Strachey wrote: a contradiction >>>>>>>>>>>>> arises based on the result of evaluating T[P] however T[P] >>>>>>>>>>>>> is never evaluated due to the infinite recursion: a fact >>>>>>>>>>>>> ignored by the proof. >>>>>>>>>>>> >>>>>>>>>>>> If you can prove that the program does give the correct >>>>>>>>>>>> result in that case you have proven Strachey wrong. >>>>>>>>>>>> Otherwise you haven't. >>>>>>>>>>> >>>>>>>>>>> Strachey is wrong because he neglected to account for the >>>>>>>>>>> infinite recursion; this should be obvious to anyone who has >>>>>>>>>>> actually read and understood what Strachey wrote: it seems >>>>>>>>>>> that you haven't. >>>>>>>>>>> >>>>>>>>>>> /Flibble >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> No, because if T gets stuck in an infinite recursion, it is >>>>>>>>>> wrong, because it failed to answer in finite time. >>>>>>>>>> >>>>>>>>>> If T does answer in finite time, then there never was an >>>>>>>>>> infinite recursion. >>>>>>>>>> >>>>>>>>>> All you have shown is that there exists a WRONG method to >>>>>>>>>> build a T that gets stuck, Like a T that needs to run its >>>>>>>>>> input to completion to answer about it. >>>>>>>>> >>>>>>>>> I have shown that [Strachey, 1965] contains an infinite >>>>>>>>> recursion and is thus invalid. >>>>>>>>> >>>>>>>>> /Flibble >>>>>>>>> >>>>>>>> >>>>>>>> No, you haven't. All you have shown is that one way to attempt >>>>>>>> to make the program that Strachev says doesn't exist, fails >>>>>>>> due to getting caught in infinite recursion. >>>>>>>> >>>>>>>> That just helps confirm Strachev, not refute it. >>>>>>> >>>>>>> Nope. Strachey's proof is based on a contradiction relating to >>>>>>> evaluating the result of T[P] however T[P] can never be >>>>>>> evaluated if there is an infinite recursion. >>>>>>> >>>>>>> /Flibble >>>>>>> >>>>>> >>>>>> Nope, because if T actually meets the requirement to be able to >>>>>> take ANY program and answer, then it need to be able to take a >>>>>> program that uses a copy of T in it, as that is a valid program. >>>>>> >>>>>> If T gets into an infinite recursion on such a program, it is >>>>>> that *T* fails to meet the requirements, not that the such a >>>>>> program is invalid to give to T. >>>>>> >>>>>> This means that the program T is Strachey's proof can't just >>>>>> execute its input to get the needed answer, as that makes it (T) >>>>>> not meet its requirements. >>>>>> >>>>>> Thus, the "recursion" error isn't in the proof of impossibility, >>>>>> but in the candidate T that is attempting to be the counter >>>>>> example for the proof. >>>>>> >>>>>> Recursion is allowed in programming and in math. If you try to >>>>>> just ban it, you will find you logic can't handle what it needs >>>>>> to. >>>>> >>>>> You are simply wrong, and fractally so. Try reading what Strachey >>>>> actually wrote. >>>>> >>>>> /Flibble >>>>> >>>> >>>> I have. >>>> >>>> T[R] is defined to be a boolean function that returns True if >>>> routine R (taking no parameters) Halts, and False if R never halts. >>>> >>>> Thus, for ANY input program, T must itself Halt, that requirement >>>> INCLUDES if R calls T[R], so if T gerts into infinite recursion and >>>> thus not answer, T has failed its specification. >>>> >>>> If you want to define that T can't take the R he defines, then why >>>> is that NOT a program? What "rule of programs" has it violated, >>>> note R getting stuck in an infinite loop is one of the purposes >>>> that T is supposed to handle. >>>> >>>> T has no requirement that the input R halts or in fact, any >>>> requirement other than it be a program. Thus the fact that R gets >>>> "hung up" in an infinite recursion isn't an error in building R, >>>> but it IS a error in the design of T, as T is REQUIRED, to meet its >>>> definition to always answer. >>>> >>>> Thus, your claim about T not answering because it got stuck in an >>>> infinite recursion is just a statement that a T built that way jus >>>> fails to meet its requriement. >>>> >>>> Note, there is NO requirement in the problem that T[R] actually >>>> runs R, and in fact, you are proving that it CAN'T (at least not >>>> without some way to stop it) as that leads to T inherently failing >>>> for this sort of program. >>>> >>>> Note, any "rule" you try to invent that prohibits this "impossible >>>> program" must also take into account the "compliant" program C that >>>> should be allowed that just calls T[C] and doesn't what it says, >>>> and the two fixed behavior ones that call T with themselfs and then >>>> unconditionally Halt or Loop. All three of these should be "legal" >>>> as they do have definite answers that work, so arguements on >>>> contrariness don't apply. >>> >>> You continue to be wrong and fractally so. The infinite recursion >>> will ALWAYS happen according to the definition of the proof. Again: >>> read AND UNDERSTAND what Strachey actually wrote. >>> >>> /Flibble >>> >> >> Nope. Yes, R will call/invoke T to get a value, but T does not (and >> in fact can not) invoke R to determine if it halts, so no infinite >> recursion. >> >> Note, you are making the error of assuming that the only way to even >> try to determine if a program will halt is to just run it. >> >> In fact, if T does do some partial running to get information, it >> must strictly limit how much it allows the program to run to get the >> data it needs, or it will fail to meet the requirement to decide. >> >> Once it has in place that sort of limit, no infinite recursion >> becomes possible, because T won't partially run its input forever. >> >> This is just like Olcott's H, if it is going to answer, MUST abort >> its simulation to give an answer, and it will always give the wrong >> answer bucause it didn't get enough information, and did it analysis >> with the false assumption that the copy of H in P/H^ won't abort its >> simulation since it didn't simulate long enough to see it. > > Confusion lay with what Strachey said: > > "T[R] = True if R terminates if run" > > "if run" doesn't have to mean T[R] runs R. > > HOWEVER it would be nice to know what T[R] actually means in the > obsolete CPL programming language Strachey is using (R is a ROUTINE > passed as an argument to T a FUNCTION). Didn't spot anything obvious in > http://www.ancientgeek.org.uk/CPL/CPL_Elementary_Programming_Manual.pdf > but I only had a cursory look. > > So modulo the outcome of that CPL question I agree with you and Olcott > is wrong if his mistake is the same as mine. > > Any other business? > > /Flibble > Strachey doesn't say how to write T, and since he proves that creating a correct program T is impossibe, I wouldn't expect him to. What the test is, though, is simple. Take the program T, and the program R, and first run T[R] (that is the program T with its input being some sort of representation of R, be it source code, or the machine language equivalent for the full program R, or whatever, and look at the result, Then you just run the program R as a seperate execution. If T[R] returned true, then if it was correct, R will Halt. If T[R} returned false, then if it was correct, R will never Halt. Now, this test can't always be definitive, since just because after some time R hasn't halted, we can't be sure that it will never halt (in the general case, there are a number of specific cases that we can prove, just not all), there may be case where T[R] returns true that we can't easily invalidate (becuase R won't halt for us, but also doesn't do something we can prove to be non-halting) and there may be cases where T[R] returns false, that we can't verify (again, because R won't halt for use, but also doesn't do something we can prove to be non-halting). But, in the case of his "Impossible Program", we can see that if we wait long enough for T[R] to answer, then when we run R, we can wait that same amount of time to get the answer from its copy of T[R], and then the behavior WILL be provablye Halting (because it does) or provably non-halting (because it goes back to its begining, so we have a simple infinite loop). Thus we can actually prove, for both answers out of T, that T is wrong, The only way for T to avoid giving a wrong answer, is to not answer, and that means that it has failed it basic requirements, becuase it was defined to ALWAYS answer.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-05-09 10:55 -0500 |
| Message-ID | <sdydnb3I-KTLpOT_nZ2dnUU7_81g4p2d@giganews.com> |
| In reply to | #50045 |
On 5/8/2022 5:04 PM, Mr Flibble wrote:
> On Sun, 8 May 2022 17:40:52 -0400
> Richard Damon <Richard@Damon-Family.org> wrote:
>
>> On 5/8/22 4:14 PM, Mr Flibble wrote:
>>> On Sun, 8 May 2022 15:39:32 -0400
>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>
>>>> On 5/8/22 3:06 PM, Mr Flibble wrote:
>>>>> On Sun, 8 May 2022 14:10:13 -0400
>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>
>>>>>> On 5/8/22 8:39 AM, Mr Flibble wrote:
>>>>>>> On Sun, 8 May 2022 08:31:10 -0400
>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>
>>>>>>>> On 5/8/22 8:02 AM, Mr Flibble wrote:
>>>>>>>>> On Sun, 8 May 2022 07:45:52 -0400
>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>
>>>>>>>>>> On 5/8/22 4:49 AM, Mr Flibble wrote:
>>>>>>>>>>> On Sun, 8 May 2022 11:31:08 +0300
>>>>>>>>>>> Mikko <mikko.levanto@iki.fi> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On 2022-05-07 15:19:01 +0000, Mr Flibble said:
>>>>>>>>>>>>
>>>>>>>>>>>>> On Sat, 7 May 2022 18:13:08 +0300
>>>>>>>>>>>>> Mikko <mikko.levanto@iki.fi> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 2022-05-07 14:20:17 +0000, Mr Flibble said:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Sat, 7 May 2022 17:16:31 +0300
>>>>>>>>>>>>>>> Mikko <mikko.levanto@iki.fi> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 2022-05-07 14:06:12 +0000, Mr Flibble said:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Sat, 7 May 2022 16:59:55 +0300
>>>>>>>>>>>>>>>>> Mikko <mikko.levanto@iki.fi> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 2022-05-07 12:42:50 +0000, Mr Flibble said:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Sat, 7 May 2022 12:52:58 +0300
>>>>>>>>>>>>>>>>>>> Mikko <mikko.levanto@iki.fi> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 2022-05-06 14:02:53 +0000, Mr Flibble said:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> The decider could never be compiled and run in the
>>>>>>>>>>>>>>>>>>>>> first place due to the category error in the
>>>>>>>>>>>>>>>>>>>>> definition of the proof.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> An error in the definition of the proof does not
>>>>>>>>>>>>>>>>>>>> prevent compilation and execution of the program.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> In this case the error in the definition of the
>>>>>>>>>>>>>>>>>>> proof
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> No part of the proof is identified as errorneous, so
>>>>>>>>>>>>>>>>>> the rest is irrelevant. Anyway,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> does prevent compilation unless
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> There is no option here, so the "unless" is void.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> the decider is made part of the program that is
>>>>>>>>>>>>>>>>>>> being decided
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The decider is made a part of the program discussed
>>>>>>>>>>>>>>>>>> in the proof.
>>>>>>>>>>>>>>>>>>> in which case we get a function call-like infinite
>>>>>>>>>>>>>>>>>>> recursion instead
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> We get or we don't get, depending on how the halt
>>>>>>>>>>>>>>>>>> decider candidate attempts to decide.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> (as described by Pete Olcott) and we are attempting
>>>>>>>>>>>>>>>>>>> (and failing) to decide if a procedure halts rather
>>>>>>>>>>>>>>>>>>> than if a program halts.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> In any case, the decider candidate fails to give the
>>>>>>>>>>>>>>>>>> correct answer, and therefore is not a halt decider.
>>>>>>>>>>>>>>>>>> Note that this is correctly inferred in the proof.
>>>>>>>>>>>>>>>>>> Therefore either the conclusion of the proof is
>>>>>>>>>>>>>>>>>> correct or you are wrong.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> No answer is ever given due to the infinite
>>>>>>>>>>>>>>>>> recursion.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> True about some candidates, false about others. For
>>>>>>>>>>>>>>>> example, a candidate that always says "no" is not
>>>>>>>>>>>>>>>> infinitely recursive but is wrong in the particular
>>>>>>>>>>>>>>>> case discussed in the proof. But anyway, you have
>>>>>>>>>>>>>>>> confirmed the conclusion of the proof.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> False. The proof is not cognisant of the presence of the
>>>>>>>>>>>>>>> infinite recursion. The decider can never return an
>>>>>>>>>>>>>>> answer of halts/doesn't halt due to the infinite
>>>>>>>>>>>>>>> recursion.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The correct term is decider candidate. It is not a
>>>>>>>>>>>>>> decider because the infinite recursion prevents it from
>>>>>>>>>>>>>> halting in finite time.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You cannot call the proof incorrect merely because it
>>>>>>>>>>>>>> agrees with you.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Try actually reading what Strachey wrote: a contradiction
>>>>>>>>>>>>> arises based on the result of evaluating T[P] however T[P]
>>>>>>>>>>>>> is never evaluated due to the infinite recursion: a fact
>>>>>>>>>>>>> ignored by the proof.
>>>>>>>>>>>>
>>>>>>>>>>>> If you can prove that the program does give the correct
>>>>>>>>>>>> result in that case you have proven Strachey wrong.
>>>>>>>>>>>> Otherwise you haven't.
>>>>>>>>>>>
>>>>>>>>>>> Strachey is wrong because he neglected to account for the
>>>>>>>>>>> infinite recursion; this should be obvious to anyone who has
>>>>>>>>>>> actually read and understood what Strachey wrote: it seems
>>>>>>>>>>> that you haven't.
>>>>>>>>>>>
>>>>>>>>>>> /Flibble
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> No, because if T gets stuck in an infinite recursion, it is
>>>>>>>>>> wrong, because it failed to answer in finite time.
>>>>>>>>>>
>>>>>>>>>> If T does answer in finite time, then there never was an
>>>>>>>>>> infinite recursion.
>>>>>>>>>>
>>>>>>>>>> All you have shown is that there exists a WRONG method to
>>>>>>>>>> build a T that gets stuck, Like a T that needs to run its
>>>>>>>>>> input to completion to answer about it.
>>>>>>>>>
>>>>>>>>> I have shown that [Strachey, 1965] contains an infinite
>>>>>>>>> recursion and is thus invalid.
>>>>>>>>>
>>>>>>>>> /Flibble
>>>>>>>>>
>>>>>>>>
>>>>>>>> No, you haven't. All you have shown is that one way to attempt
>>>>>>>> to make the program that Strachev says doesn't exist, fails
>>>>>>>> due to getting caught in infinite recursion.
>>>>>>>>
>>>>>>>> That just helps confirm Strachev, not refute it.
>>>>>>>
>>>>>>> Nope. Strachey's proof is based on a contradiction relating to
>>>>>>> evaluating the result of T[P] however T[P] can never be
>>>>>>> evaluated if there is an infinite recursion.
>>>>>>>
>>>>>>> /Flibble
>>>>>>>
>>>>>>
>>>>>> Nope, because if T actually meets the requirement to be able to
>>>>>> take ANY program and answer, then it need to be able to take a
>>>>>> program that uses a copy of T in it, as that is a valid program.
>>>>>>
>>>>>> If T gets into an infinite recursion on such a program, it is
>>>>>> that *T* fails to meet the requirements, not that the such a
>>>>>> program is invalid to give to T.
>>>>>>
>>>>>> This means that the program T is Strachey's proof can't just
>>>>>> execute its input to get the needed answer, as that makes it (T)
>>>>>> not meet its requirements.
>>>>>>
>>>>>> Thus, the "recursion" error isn't in the proof of impossibility,
>>>>>> but in the candidate T that is attempting to be the counter
>>>>>> example for the proof.
>>>>>>
>>>>>> Recursion is allowed in programming and in math. If you try to
>>>>>> just ban it, you will find you logic can't handle what it needs
>>>>>> to.
>>>>>
>>>>> You are simply wrong, and fractally so. Try reading what Strachey
>>>>> actually wrote.
>>>>>
>>>>> /Flibble
>>>>>
>>>>
>>>> I have.
>>>>
>>>> T[R] is defined to be a boolean function that returns True if
>>>> routine R (taking no parameters) Halts, and False if R never halts.
>>>>
>>>> Thus, for ANY input program, T must itself Halt, that requirement
>>>> INCLUDES if R calls T[R], so if T gerts into infinite recursion and
>>>> thus not answer, T has failed its specification.
>>>>
>>>> If you want to define that T can't take the R he defines, then why
>>>> is that NOT a program? What "rule of programs" has it violated,
>>>> note R getting stuck in an infinite loop is one of the purposes
>>>> that T is supposed to handle.
>>>>
>>>> T has no requirement that the input R halts or in fact, any
>>>> requirement other than it be a program. Thus the fact that R gets
>>>> "hung up" in an infinite recursion isn't an error in building R,
>>>> but it IS a error in the design of T, as T is REQUIRED, to meet its
>>>> definition to always answer.
>>>>
>>>> Thus, your claim about T not answering because it got stuck in an
>>>> infinite recursion is just a statement that a T built that way jus
>>>> fails to meet its requriement.
>>>>
>>>> Note, there is NO requirement in the problem that T[R] actually
>>>> runs R, and in fact, you are proving that it CAN'T (at least not
>>>> without some way to stop it) as that leads to T inherently failing
>>>> for this sort of program.
>>>>
>>>> Note, any "rule" you try to invent that prohibits this "impossible
>>>> program" must also take into account the "compliant" program C that
>>>> should be allowed that just calls T[C] and doesn't what it says,
>>>> and the two fixed behavior ones that call T with themselfs and then
>>>> unconditionally Halt or Loop. All three of these should be "legal"
>>>> as they do have definite answers that work, so arguements on
>>>> contrariness don't apply.
>>>
>>> You continue to be wrong and fractally so. The infinite recursion
>>> will ALWAYS happen according to the definition of the proof. Again:
>>> read AND UNDERSTAND what Strachey actually wrote.
>>>
>>> /Flibble
>>>
>>
>> Nope. Yes, R will call/invoke T to get a value, but T does not (and
>> in fact can not) invoke R to determine if it halts, so no infinite
>> recursion.
>>
>> Note, you are making the error of assuming that the only way to even
>> try to determine if a program will halt is to just run it.
>>
>> In fact, if T does do some partial running to get information, it
>> must strictly limit how much it allows the program to run to get the
>> data it needs, or it will fail to meet the requirement to decide.
>>
>> Once it has in place that sort of limit, no infinite recursion
>> becomes possible, because T won't partially run its input forever.
>>
>> This is just like Olcott's H, if it is going to answer, MUST abort
>> its simulation to give an answer, and it will always give the wrong
>> answer bucause it didn't get enough information, and did it analysis
>> with the false assumption that the copy of H in P/H^ won't abort its
>> simulation since it didn't simulate long enough to see it.
>
> Confusion lay with what Strachey said:
>
> "T[R] = True if R terminates if run"
>
> "if run" doesn't have to mean T[R] runs R.
>
> HOWEVER it would be nice to know what T[R] actually means in the
> obsolete CPL programming language Strachey is using (R is a ROUTINE
> passed as an argument to T a FUNCTION). Didn't spot anything obvious in
> http://www.ancientgeek.org.uk/CPL/CPL_Elementary_Programming_Manual.pdf
> but I only had a cursory look.
>
This version is clearer:
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H1((u32)P, (u32)P));
}
> So modulo the outcome of that CPL question I agree with you and Olcott
> is wrong if his mistake is the same as mine.
>
> Any other business?
>
> /Flibble
>
--
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-05-09 20:13 -0400 |
| Message-ID | <A6ieK.2248$wYy9.735@fx11.iad> |
| In reply to | #50084 |
On 5/9/22 11:55 AM, olcott wrote:
> On 5/8/2022 5:04 PM, Mr Flibble wrote:
>> On Sun, 8 May 2022 17:40:52 -0400
>> Richard Damon <Richard@Damon-Family.org> wrote:
>>
>>> On 5/8/22 4:14 PM, Mr Flibble wrote:
>>>> On Sun, 8 May 2022 15:39:32 -0400
>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>> On 5/8/22 3:06 PM, Mr Flibble wrote:
>>>>>> On Sun, 8 May 2022 14:10:13 -0400
>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>> On 5/8/22 8:39 AM, Mr Flibble wrote:
>>>>>>>> On Sun, 8 May 2022 08:31:10 -0400
>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>> On 5/8/22 8:02 AM, Mr Flibble wrote:
>>>>>>>>>> On Sun, 8 May 2022 07:45:52 -0400
>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>> On 5/8/22 4:49 AM, Mr Flibble wrote:
>>>>>>>>>>>> On Sun, 8 May 2022 11:31:08 +0300
>>>>>>>>>>>> Mikko <mikko.levanto@iki.fi> wrote:
>>>>>>>>>>>>> On 2022-05-07 15:19:01 +0000, Mr Flibble said:
>>>>>>>>>>>>>> On Sat, 7 May 2022 18:13:08 +0300
>>>>>>>>>>>>>> Mikko <mikko.levanto@iki.fi> wrote:
>>>>>>>>>>>>>>> On 2022-05-07 14:20:17 +0000, Mr Flibble said:
>>>>>>>>>>>>>>>> On Sat, 7 May 2022 17:16:31 +0300
>>>>>>>>>>>>>>>> Mikko <mikko.levanto@iki.fi> wrote:
>>>>>>>>>>>>>>>>> On 2022-05-07 14:06:12 +0000, Mr Flibble said:
>>>>>>>>>>>>>>>>>> On Sat, 7 May 2022 16:59:55 +0300
>>>>>>>>>>>>>>>>>> Mikko <mikko.levanto@iki.fi> wrote:
>>>>>>>>>>>>>>>>>>> On 2022-05-07 12:42:50 +0000, Mr Flibble said:
>>>>>>>>>>>>>>>>>>>> On Sat, 7 May 2022 12:52:58 +0300
>>>>>>>>>>>>>>>>>>>> Mikko <mikko.levanto@iki.fi> wrote:
>>>>>>>>>>>>>>>>>>>>> On 2022-05-06 14:02:53 +0000, Mr Flibble said:
>>>>>>>>>>>>>>>>>>>>>> The decider could never be compiled and run in the
>>>>>>>>>>>>>>>>>>>>>> first place due to the category error in the
>>>>>>>>>>>>>>>>>>>>>> definition of the proof.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> An error in the definition of the proof does not
>>>>>>>>>>>>>>>>>>>>> prevent compilation and execution of the program.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> In this case the error in the definition of the
>>>>>>>>>>>>>>>>>>>> proof
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> No part of the proof is identified as errorneous, so
>>>>>>>>>>>>>>>>>>> the rest is irrelevant. Anyway,
>>>>>>>>>>>>>>>>>>>> does prevent compilation unless
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> There is no option here, so the "unless" is void.
>>>>>>>>>>>>>>>>>>>> the decider is made part of the program that is
>>>>>>>>>>>>>>>>>>>> being decided
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The decider is made a part of the program discussed
>>>>>>>>>>>>>>>>>>> in the proof.
>>>>>>>>>>>>>>>>>>>> in which case we get a function call-like infinite
>>>>>>>>>>>>>>>>>>>> recursion instead
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> We get or we don't get, depending on how the halt
>>>>>>>>>>>>>>>>>>> decider candidate attempts to decide.
>>>>>>>>>>>>>>>>>>>> (as described by Pete Olcott) and we are attempting
>>>>>>>>>>>>>>>>>>>> (and failing) to decide if a procedure halts rather
>>>>>>>>>>>>>>>>>>>> than if a program halts.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> In any case, the decider candidate fails to give the
>>>>>>>>>>>>>>>>>>> correct answer, and therefore is not a halt decider.
>>>>>>>>>>>>>>>>>>> Note that this is correctly inferred in the proof.
>>>>>>>>>>>>>>>>>>> Therefore either the conclusion of the proof is
>>>>>>>>>>>>>>>>>>> correct or you are wrong.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> No answer is ever given due to the infinite
>>>>>>>>>>>>>>>>>> recursion.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> True about some candidates, false about others. For
>>>>>>>>>>>>>>>>> example, a candidate that always says "no" is not
>>>>>>>>>>>>>>>>> infinitely recursive but is wrong in the particular
>>>>>>>>>>>>>>>>> case discussed in the proof. But anyway, you have
>>>>>>>>>>>>>>>>> confirmed the conclusion of the proof.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> False. The proof is not cognisant of the presence of the
>>>>>>>>>>>>>>>> infinite recursion. The decider can never return an
>>>>>>>>>>>>>>>> answer of halts/doesn't halt due to the infinite
>>>>>>>>>>>>>>>> recursion.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The correct term is decider candidate. It is not a
>>>>>>>>>>>>>>> decider because the infinite recursion prevents it from
>>>>>>>>>>>>>>> halting in finite time.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You cannot call the proof incorrect merely because it
>>>>>>>>>>>>>>> agrees with you.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Try actually reading what Strachey wrote: a contradiction
>>>>>>>>>>>>>> arises based on the result of evaluating T[P] however T[P]
>>>>>>>>>>>>>> is never evaluated due to the infinite recursion: a fact
>>>>>>>>>>>>>> ignored by the proof.
>>>>>>>>>>>>>
>>>>>>>>>>>>> If you can prove that the program does give the correct
>>>>>>>>>>>>> result in that case you have proven Strachey wrong.
>>>>>>>>>>>>> Otherwise you haven't.
>>>>>>>>>>>>
>>>>>>>>>>>> Strachey is wrong because he neglected to account for the
>>>>>>>>>>>> infinite recursion; this should be obvious to anyone who has
>>>>>>>>>>>> actually read and understood what Strachey wrote: it seems
>>>>>>>>>>>> that you haven't.
>>>>>>>>>>>>
>>>>>>>>>>>> /Flibble
>>>>>>>>>>>
>>>>>>>>>>> No, because if T gets stuck in an infinite recursion, it is
>>>>>>>>>>> wrong, because it failed to answer in finite time.
>>>>>>>>>>>
>>>>>>>>>>> If T does answer in finite time, then there never was an
>>>>>>>>>>> infinite recursion.
>>>>>>>>>>>
>>>>>>>>>>> All you have shown is that there exists a WRONG method to
>>>>>>>>>>> build a T that gets stuck, Like a T that needs to run its
>>>>>>>>>>> input to completion to answer about it.
>>>>>>>>>>
>>>>>>>>>> I have shown that [Strachey, 1965] contains an infinite
>>>>>>>>>> recursion and is thus invalid.
>>>>>>>>>>
>>>>>>>>>> /Flibble
>>>>>>>>>
>>>>>>>>> No, you haven't. All you have shown is that one way to attempt
>>>>>>>>> to make the program that Strachev says doesn't exist, fails
>>>>>>>>> due to getting caught in infinite recursion.
>>>>>>>>>
>>>>>>>>> That just helps confirm Strachev, not refute it.
>>>>>>>>
>>>>>>>> Nope. Strachey's proof is based on a contradiction relating to
>>>>>>>> evaluating the result of T[P] however T[P] can never be
>>>>>>>> evaluated if there is an infinite recursion.
>>>>>>>>
>>>>>>>> /Flibble
>>>>>>>
>>>>>>> Nope, because if T actually meets the requirement to be able to
>>>>>>> take ANY program and answer, then it need to be able to take a
>>>>>>> program that uses a copy of T in it, as that is a valid program.
>>>>>>>
>>>>>>> If T gets into an infinite recursion on such a program, it is
>>>>>>> that *T* fails to meet the requirements, not that the such a
>>>>>>> program is invalid to give to T.
>>>>>>>
>>>>>>> This means that the program T is Strachey's proof can't just
>>>>>>> execute its input to get the needed answer, as that makes it (T)
>>>>>>> not meet its requirements.
>>>>>>>
>>>>>>> Thus, the "recursion" error isn't in the proof of impossibility,
>>>>>>> but in the candidate T that is attempting to be the counter
>>>>>>> example for the proof.
>>>>>>>
>>>>>>> Recursion is allowed in programming and in math. If you try to
>>>>>>> just ban it, you will find you logic can't handle what it needs
>>>>>>> to.
>>>>>>
>>>>>> You are simply wrong, and fractally so. Try reading what Strachey
>>>>>> actually wrote.
>>>>>>
>>>>>> /Flibble
>>>>>
>>>>> I have.
>>>>>
>>>>> T[R] is defined to be a boolean function that returns True if
>>>>> routine R (taking no parameters) Halts, and False if R never halts.
>>>>>
>>>>> Thus, for ANY input program, T must itself Halt, that requirement
>>>>> INCLUDES if R calls T[R], so if T gerts into infinite recursion and
>>>>> thus not answer, T has failed its specification.
>>>>>
>>>>> If you want to define that T can't take the R he defines, then why
>>>>> is that NOT a program? What "rule of programs" has it violated,
>>>>> note R getting stuck in an infinite loop is one of the purposes
>>>>> that T is supposed to handle.
>>>>>
>>>>> T has no requirement that the input R halts or in fact, any
>>>>> requirement other than it be a program. Thus the fact that R gets
>>>>> "hung up" in an infinite recursion isn't an error in building R,
>>>>> but it IS a error in the design of T, as T is REQUIRED, to meet its
>>>>> definition to always answer.
>>>>>
>>>>> Thus, your claim about T not answering because it got stuck in an
>>>>> infinite recursion is just a statement that a T built that way jus
>>>>> fails to meet its requriement.
>>>>>
>>>>> Note, there is NO requirement in the problem that T[R] actually
>>>>> runs R, and in fact, you are proving that it CAN'T (at least not
>>>>> without some way to stop it) as that leads to T inherently failing
>>>>> for this sort of program.
>>>>>
>>>>> Note, any "rule" you try to invent that prohibits this "impossible
>>>>> program" must also take into account the "compliant" program C that
>>>>> should be allowed that just calls T[C] and doesn't what it says,
>>>>> and the two fixed behavior ones that call T with themselfs and then
>>>>> unconditionally Halt or Loop. All three of these should be "legal"
>>>>> as they do have definite answers that work, so arguements on
>>>>> contrariness don't apply.
>>>>
>>>> You continue to be wrong and fractally so. The infinite recursion
>>>> will ALWAYS happen according to the definition of the proof. Again:
>>>> read AND UNDERSTAND what Strachey actually wrote.
>>>>
>>>> /Flibble
>>>
>>> Nope. Yes, R will call/invoke T to get a value, but T does not (and
>>> in fact can not) invoke R to determine if it halts, so no infinite
>>> recursion.
>>>
>>> Note, you are making the error of assuming that the only way to even
>>> try to determine if a program will halt is to just run it.
>>>
>>> In fact, if T does do some partial running to get information, it
>>> must strictly limit how much it allows the program to run to get the
>>> data it needs, or it will fail to meet the requirement to decide.
>>>
>>> Once it has in place that sort of limit, no infinite recursion
>>> becomes possible, because T won't partially run its input forever.
>>>
>>> This is just like Olcott's H, if it is going to answer, MUST abort
>>> its simulation to give an answer, and it will always give the wrong
>>> answer bucause it didn't get enough information, and did it analysis
>>> with the false assumption that the copy of H in P/H^ won't abort its
>>> simulation since it didn't simulate long enough to see it.
>>
>> Confusion lay with what Strachey said:
>>
>> "T[R] = True if R terminates if run"
>>
>> "if run" doesn't have to mean T[R] runs R.
>>
>> HOWEVER it would be nice to know what T[R] actually means in the
>> obsolete CPL programming language Strachey is using (R is a ROUTINE
>> passed as an argument to T a FUNCTION). Didn't spot anything obvious in
>> http://www.ancientgeek.org.uk/CPL/CPL_Elementary_Programming_Manual.pdf
>> but I only had a cursory look.
>>
>
>
> This version is clearer:
> void P(u32 x)
> {
> if (H(x, x))
> HERE: goto HERE;
> return;
> }
>
> int main()
> {
> Output("Input_Halts = ", H1((u32)P, (u32)P));
> }
>
Which just shows that H1 can get the right answer for P(P), so H is just
wrong to say it doesn't Halt.
>
>> So modulo the outcome of that CPL question I agree with you and Olcott
>> is wrong if his mistake is the same as mine.
>>
>> Any other business?
>>
>> /Flibble
>>
>
>
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-05-09 10:51 -0500 |
| Message-ID | <sdydnYPI-KQGpeT_nZ2dnUU7_81g4p2d@giganews.com> |
| In reply to | #50027 |
On 5/8/2022 7:39 AM, Mr Flibble wrote: > On Sun, 8 May 2022 08:31:10 -0400 > Richard Damon <Richard@Damon-Family.org> wrote: > >> On 5/8/22 8:02 AM, Mr Flibble wrote: >>> On Sun, 8 May 2022 07:45:52 -0400 >>> Richard Damon <Richard@Damon-Family.org> wrote: >>> >>>> On 5/8/22 4:49 AM, Mr Flibble wrote: >>>>> On Sun, 8 May 2022 11:31:08 +0300 >>>>> Mikko <mikko.levanto@iki.fi> wrote: >>>>> >>>>>> On 2022-05-07 15:19:01 +0000, Mr Flibble said: >>>>>> >>>>>>> On Sat, 7 May 2022 18:13:08 +0300 >>>>>>> Mikko <mikko.levanto@iki.fi> wrote: >>>>>>> >>>>>>>> On 2022-05-07 14:20:17 +0000, Mr Flibble said: >>>>>>>> >>>>>>>>> On Sat, 7 May 2022 17:16:31 +0300 >>>>>>>>> Mikko <mikko.levanto@iki.fi> wrote: >>>>>>>>> >>>>>>>>>> On 2022-05-07 14:06:12 +0000, Mr Flibble said: >>>>>>>>>> >>>>>>>>>>> On Sat, 7 May 2022 16:59:55 +0300 >>>>>>>>>>> Mikko <mikko.levanto@iki.fi> wrote: >>>>>>>>>>> >>>>>>>>>>>> On 2022-05-07 12:42:50 +0000, Mr Flibble said: >>>>>>>>>>>> >>>>>>>>>>>>> On Sat, 7 May 2022 12:52:58 +0300 >>>>>>>>>>>>> Mikko <mikko.levanto@iki.fi> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> On 2022-05-06 14:02:53 +0000, Mr Flibble said: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> The decider could never be compiled and run in the first >>>>>>>>>>>>>>> place due to the category error in the definition of the >>>>>>>>>>>>>>> proof. >>>>>>>>>>>>>> >>>>>>>>>>>>>> An error in the definition of the proof does not prevent >>>>>>>>>>>>>> compilation and execution of the program. >>>>>>>>>>>>> >>>>>>>>>>>>> In this case the error in the definition of the proof >>>>>>>>>>>> >>>>>>>>>>>> No part of the proof is identified as errorneous, so the >>>>>>>>>>>> rest is irrelevant. Anyway, >>>>>>>>>>>> >>>>>>>>>>>>> does prevent compilation unless >>>>>>>>>>>> >>>>>>>>>>>> There is no option here, so the "unless" is void. >>>>>>>>>>>> >>>>>>>>>>>>> the decider is made part of the program that is being >>>>>>>>>>>>> decided >>>>>>>>>>>> >>>>>>>>>>>> The decider is made a part of the program discussed in the >>>>>>>>>>>> proof. >>>>>>>>>>>>> in which case we get a function call-like infinite >>>>>>>>>>>>> recursion instead >>>>>>>>>>>> >>>>>>>>>>>> We get or we don't get, depending on how the halt decider >>>>>>>>>>>> candidate attempts to decide. >>>>>>>>>>>> >>>>>>>>>>>>> (as described by Pete Olcott) and we are attempting (and >>>>>>>>>>>>> failing) to decide if a procedure halts rather than if a >>>>>>>>>>>>> program halts. >>>>>>>>>>>> >>>>>>>>>>>> In any case, the decider candidate fails to give the >>>>>>>>>>>> correct answer, and therefore is not a halt decider. Note >>>>>>>>>>>> that this is correctly inferred in the proof. Therefore >>>>>>>>>>>> either the conclusion of the proof is correct or you are >>>>>>>>>>>> wrong. >>>>>>>>>>> >>>>>>>>>>> No answer is ever given due to the infinite recursion. >>>>>>>>>> >>>>>>>>>> True about some candidates, false about others. For example, >>>>>>>>>> a candidate that always says "no" is not infinitely >>>>>>>>>> recursive but is wrong in the particular case discussed in >>>>>>>>>> the proof. But anyway, you have confirmed the conclusion of >>>>>>>>>> the proof. >>>>>>>>> >>>>>>>>> False. The proof is not cognisant of the presence of the >>>>>>>>> infinite recursion. The decider can never return an answer of >>>>>>>>> halts/doesn't halt due to the infinite recursion. >>>>>>>> >>>>>>>> The correct term is decider candidate. It is not a decider >>>>>>>> because the infinite recursion prevents it from halting in >>>>>>>> finite time. >>>>>>>> >>>>>>>> You cannot call the proof incorrect merely because it agrees >>>>>>>> with you. >>>>>>> >>>>>>> Try actually reading what Strachey wrote: a contradiction arises >>>>>>> based on the result of evaluating T[P] however T[P] is never >>>>>>> evaluated due to the infinite recursion: a fact ignored by the >>>>>>> proof. >>>>>> >>>>>> If you can prove that the program does give the correct result in >>>>>> that case you have proven Strachey wrong. Otherwise you haven't. >>>>>> >>>>> >>>>> Strachey is wrong because he neglected to account for the infinite >>>>> recursion; this should be obvious to anyone who has actually read >>>>> and understood what Strachey wrote: it seems that you haven't. >>>>> >>>>> /Flibble >>>>> >>>> >>>> No, because if T gets stuck in an infinite recursion, it is wrong, >>>> because it failed to answer in finite time. >>>> >>>> If T does answer in finite time, then there never was an infinite >>>> recursion. >>>> >>>> All you have shown is that there exists a WRONG method to build a T >>>> that gets stuck, Like a T that needs to run its input to completion >>>> to answer about it. >>> >>> I have shown that [Strachey, 1965] contains an infinite recursion >>> and is thus invalid. >>> >>> /Flibble >>> >> >> No, you haven't. All you have shown is that one way to attempt to >> make the program that Strachev says doesn't exist, fails due to >> getting caught in infinite recursion. >> >> That just helps confirm Strachev, not refute it. > > Nope. Strachey's proof is based on a contradiction relating to > evaluating the result of T[P] however T[P] can never be evaluated if > there is an infinite recursion. > > /Flibble > They all have this same basis. The infinite recursion itself is evaluated. -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibble@reddwarf.jmc> |
|---|---|
| Date | 2022-05-09 18:31 +0100 |
| Message-ID | <20220509183114.0000448f@reddwarf.jmc> |
| In reply to | #50081 |
On Mon, 9 May 2022 10:51:54 -0500 olcott <NoOne@NoWhere.com> wrote: > On 5/8/2022 7:39 AM, Mr Flibble wrote: > > On Sun, 8 May 2022 08:31:10 -0400 > > Richard Damon <Richard@Damon-Family.org> wrote: > > > >> On 5/8/22 8:02 AM, Mr Flibble wrote: > >>> On Sun, 8 May 2022 07:45:52 -0400 > >>> Richard Damon <Richard@Damon-Family.org> wrote: > >>> > >>>> On 5/8/22 4:49 AM, Mr Flibble wrote: > >>>>> On Sun, 8 May 2022 11:31:08 +0300 > >>>>> Mikko <mikko.levanto@iki.fi> wrote: > >>>>> > >>>>>> On 2022-05-07 15:19:01 +0000, Mr Flibble said: > >>>>>> > >>>>>>> On Sat, 7 May 2022 18:13:08 +0300 > >>>>>>> Mikko <mikko.levanto@iki.fi> wrote: > >>>>>>> > >>>>>>>> On 2022-05-07 14:20:17 +0000, Mr Flibble said: > >>>>>>>> > >>>>>>>>> On Sat, 7 May 2022 17:16:31 +0300 > >>>>>>>>> Mikko <mikko.levanto@iki.fi> wrote: > >>>>>>>>> > >>>>>>>>>> On 2022-05-07 14:06:12 +0000, Mr Flibble said: > >>>>>>>>>> > >>>>>>>>>>> On Sat, 7 May 2022 16:59:55 +0300 > >>>>>>>>>>> Mikko <mikko.levanto@iki.fi> wrote: > >>>>>>>>>>> > >>>>>>>>>>>> On 2022-05-07 12:42:50 +0000, Mr Flibble said: > >>>>>>>>>>>> > >>>>>>>>>>>>> On Sat, 7 May 2022 12:52:58 +0300 > >>>>>>>>>>>>> Mikko <mikko.levanto@iki.fi> wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>>> On 2022-05-06 14:02:53 +0000, Mr Flibble said: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> The decider could never be compiled and run in the > >>>>>>>>>>>>>>> first place due to the category error in the > >>>>>>>>>>>>>>> definition of the proof. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> An error in the definition of the proof does not > >>>>>>>>>>>>>> prevent compilation and execution of the program. > >>>>>>>>>>>>> > >>>>>>>>>>>>> In this case the error in the definition of the proof > >>>>>>>>>>>> > >>>>>>>>>>>> No part of the proof is identified as errorneous, so the > >>>>>>>>>>>> rest is irrelevant. Anyway, > >>>>>>>>>>>> > >>>>>>>>>>>>> does prevent compilation unless > >>>>>>>>>>>> > >>>>>>>>>>>> There is no option here, so the "unless" is void. > >>>>>>>>>>>> > >>>>>>>>>>>>> the decider is made part of the program that is being > >>>>>>>>>>>>> decided > >>>>>>>>>>>> > >>>>>>>>>>>> The decider is made a part of the program discussed in > >>>>>>>>>>>> the proof. > >>>>>>>>>>>>> in which case we get a function call-like infinite > >>>>>>>>>>>>> recursion instead > >>>>>>>>>>>> > >>>>>>>>>>>> We get or we don't get, depending on how the halt decider > >>>>>>>>>>>> candidate attempts to decide. > >>>>>>>>>>>> > >>>>>>>>>>>>> (as described by Pete Olcott) and we are attempting (and > >>>>>>>>>>>>> failing) to decide if a procedure halts rather than if a > >>>>>>>>>>>>> program halts. > >>>>>>>>>>>> > >>>>>>>>>>>> In any case, the decider candidate fails to give the > >>>>>>>>>>>> correct answer, and therefore is not a halt decider. Note > >>>>>>>>>>>> that this is correctly inferred in the proof. Therefore > >>>>>>>>>>>> either the conclusion of the proof is correct or you are > >>>>>>>>>>>> wrong. > >>>>>>>>>>> > >>>>>>>>>>> No answer is ever given due to the infinite recursion. > >>>>>>>>>> > >>>>>>>>>> True about some candidates, false about others. For > >>>>>>>>>> example, a candidate that always says "no" is not > >>>>>>>>>> infinitely recursive but is wrong in the particular case > >>>>>>>>>> discussed in the proof. But anyway, you have confirmed the > >>>>>>>>>> conclusion of the proof. > >>>>>>>>> > >>>>>>>>> False. The proof is not cognisant of the presence of the > >>>>>>>>> infinite recursion. The decider can never return an answer > >>>>>>>>> of halts/doesn't halt due to the infinite recursion. > >>>>>>>> > >>>>>>>> The correct term is decider candidate. It is not a decider > >>>>>>>> because the infinite recursion prevents it from halting in > >>>>>>>> finite time. > >>>>>>>> > >>>>>>>> You cannot call the proof incorrect merely because it agrees > >>>>>>>> with you. > >>>>>>> > >>>>>>> Try actually reading what Strachey wrote: a contradiction > >>>>>>> arises based on the result of evaluating T[P] however T[P] is > >>>>>>> never evaluated due to the infinite recursion: a fact ignored > >>>>>>> by the proof. > >>>>>> > >>>>>> If you can prove that the program does give the correct result > >>>>>> in that case you have proven Strachey wrong. Otherwise you > >>>>>> haven't. > >>>>> > >>>>> Strachey is wrong because he neglected to account for the > >>>>> infinite recursion; this should be obvious to anyone who has > >>>>> actually read and understood what Strachey wrote: it seems that > >>>>> you haven't. > >>>>> > >>>>> /Flibble > >>>>> > >>>> > >>>> No, because if T gets stuck in an infinite recursion, it is > >>>> wrong, because it failed to answer in finite time. > >>>> > >>>> If T does answer in finite time, then there never was an infinite > >>>> recursion. > >>>> > >>>> All you have shown is that there exists a WRONG method to build > >>>> a T that gets stuck, Like a T that needs to run its input to > >>>> completion to answer about it. > >>> > >>> I have shown that [Strachey, 1965] contains an infinite recursion > >>> and is thus invalid. > >>> > >>> /Flibble > >>> > >> > >> No, you haven't. All you have shown is that one way to attempt to > >> make the program that Strachev says doesn't exist, fails due to > >> getting caught in infinite recursion. > >> > >> That just helps confirm Strachev, not refute it. > > > > Nope. Strachey's proof is based on a contradiction relating to > > evaluating the result of T[P] however T[P] can never be evaluated if > > there is an infinite recursion. > > > > /Flibble > > > > They all have this same basis. > The infinite recursion itself is evaluated. Have you not read my retraction? I was in error: there is no infinite recursion. /Flibble
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-05-09 12:36 -0500 |
| Message-ID | <zPadnWhY_5qczOT_nZ2dnUU7_81g4p2d@giganews.com> |
| In reply to | #50102 |
On 5/9/2022 12:31 PM, Mr Flibble wrote: > On Mon, 9 May 2022 10:51:54 -0500 > olcott <NoOne@NoWhere.com> wrote: > >> On 5/8/2022 7:39 AM, Mr Flibble wrote: >>> On Sun, 8 May 2022 08:31:10 -0400 >>> Richard Damon <Richard@Damon-Family.org> wrote: >>> >>>> On 5/8/22 8:02 AM, Mr Flibble wrote: >>>>> On Sun, 8 May 2022 07:45:52 -0400 >>>>> Richard Damon <Richard@Damon-Family.org> wrote: >>>>> >>>>>> On 5/8/22 4:49 AM, Mr Flibble wrote: >>>>>>> On Sun, 8 May 2022 11:31:08 +0300 >>>>>>> Mikko <mikko.levanto@iki.fi> wrote: >>>>>>> >>>>>>>> On 2022-05-07 15:19:01 +0000, Mr Flibble said: >>>>>>>> >>>>>>>>> On Sat, 7 May 2022 18:13:08 +0300 >>>>>>>>> Mikko <mikko.levanto@iki.fi> wrote: >>>>>>>>> >>>>>>>>>> On 2022-05-07 14:20:17 +0000, Mr Flibble said: >>>>>>>>>> >>>>>>>>>>> On Sat, 7 May 2022 17:16:31 +0300 >>>>>>>>>>> Mikko <mikko.levanto@iki.fi> wrote: >>>>>>>>>>> >>>>>>>>>>>> On 2022-05-07 14:06:12 +0000, Mr Flibble said: >>>>>>>>>>>> >>>>>>>>>>>>> On Sat, 7 May 2022 16:59:55 +0300 >>>>>>>>>>>>> Mikko <mikko.levanto@iki.fi> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> On 2022-05-07 12:42:50 +0000, Mr Flibble said: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Sat, 7 May 2022 12:52:58 +0300 >>>>>>>>>>>>>>> Mikko <mikko.levanto@iki.fi> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 2022-05-06 14:02:53 +0000, Mr Flibble said: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The decider could never be compiled and run in the >>>>>>>>>>>>>>>>> first place due to the category error in the >>>>>>>>>>>>>>>>> definition of the proof. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> An error in the definition of the proof does not >>>>>>>>>>>>>>>> prevent compilation and execution of the program. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> In this case the error in the definition of the proof >>>>>>>>>>>>>> >>>>>>>>>>>>>> No part of the proof is identified as errorneous, so the >>>>>>>>>>>>>> rest is irrelevant. Anyway, >>>>>>>>>>>>>> >>>>>>>>>>>>>>> does prevent compilation unless >>>>>>>>>>>>>> >>>>>>>>>>>>>> There is no option here, so the "unless" is void. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> the decider is made part of the program that is being >>>>>>>>>>>>>>> decided >>>>>>>>>>>>>> >>>>>>>>>>>>>> The decider is made a part of the program discussed in >>>>>>>>>>>>>> the proof. >>>>>>>>>>>>>>> in which case we get a function call-like infinite >>>>>>>>>>>>>>> recursion instead >>>>>>>>>>>>>> >>>>>>>>>>>>>> We get or we don't get, depending on how the halt decider >>>>>>>>>>>>>> candidate attempts to decide. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> (as described by Pete Olcott) and we are attempting (and >>>>>>>>>>>>>>> failing) to decide if a procedure halts rather than if a >>>>>>>>>>>>>>> program halts. >>>>>>>>>>>>>> >>>>>>>>>>>>>> In any case, the decider candidate fails to give the >>>>>>>>>>>>>> correct answer, and therefore is not a halt decider. Note >>>>>>>>>>>>>> that this is correctly inferred in the proof. Therefore >>>>>>>>>>>>>> either the conclusion of the proof is correct or you are >>>>>>>>>>>>>> wrong. >>>>>>>>>>>>> >>>>>>>>>>>>> No answer is ever given due to the infinite recursion. >>>>>>>>>>>> >>>>>>>>>>>> True about some candidates, false about others. For >>>>>>>>>>>> example, a candidate that always says "no" is not >>>>>>>>>>>> infinitely recursive but is wrong in the particular case >>>>>>>>>>>> discussed in the proof. But anyway, you have confirmed the >>>>>>>>>>>> conclusion of the proof. >>>>>>>>>>> >>>>>>>>>>> False. The proof is not cognisant of the presence of the >>>>>>>>>>> infinite recursion. The decider can never return an answer >>>>>>>>>>> of halts/doesn't halt due to the infinite recursion. >>>>>>>>>> >>>>>>>>>> The correct term is decider candidate. It is not a decider >>>>>>>>>> because the infinite recursion prevents it from halting in >>>>>>>>>> finite time. >>>>>>>>>> >>>>>>>>>> You cannot call the proof incorrect merely because it agrees >>>>>>>>>> with you. >>>>>>>>> >>>>>>>>> Try actually reading what Strachey wrote: a contradiction >>>>>>>>> arises based on the result of evaluating T[P] however T[P] is >>>>>>>>> never evaluated due to the infinite recursion: a fact ignored >>>>>>>>> by the proof. >>>>>>>> >>>>>>>> If you can prove that the program does give the correct result >>>>>>>> in that case you have proven Strachey wrong. Otherwise you >>>>>>>> haven't. >>>>>>> >>>>>>> Strachey is wrong because he neglected to account for the >>>>>>> infinite recursion; this should be obvious to anyone who has >>>>>>> actually read and understood what Strachey wrote: it seems that >>>>>>> you haven't. >>>>>>> >>>>>>> /Flibble >>>>>>> >>>>>> >>>>>> No, because if T gets stuck in an infinite recursion, it is >>>>>> wrong, because it failed to answer in finite time. >>>>>> >>>>>> If T does answer in finite time, then there never was an infinite >>>>>> recursion. >>>>>> >>>>>> All you have shown is that there exists a WRONG method to build >>>>>> a T that gets stuck, Like a T that needs to run its input to >>>>>> completion to answer about it. >>>>> >>>>> I have shown that [Strachey, 1965] contains an infinite recursion >>>>> and is thus invalid. >>>>> >>>>> /Flibble >>>>> >>>> >>>> No, you haven't. All you have shown is that one way to attempt to >>>> make the program that Strachev says doesn't exist, fails due to >>>> getting caught in infinite recursion. >>>> >>>> That just helps confirm Strachev, not refute it. >>> >>> Nope. Strachey's proof is based on a contradiction relating to >>> evaluating the result of T[P] however T[P] can never be evaluated if >>> there is an infinite recursion. >>> >>> /Flibble >>> >> >> They all have this same basis. >> The infinite recursion itself is evaluated. > > Have you not read my retraction? I was in error: there is no infinite > recursion. > > /Flibble > I spent 15,000 hours on this since 2004, all of my messages are still in this group. I have known more about this since you first began, and I know more about that after your retraction. The idea of category error applied to instances of pathological self-reference is a new idea. -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-05-09 20:15 -0400 |
| Message-ID | <G8ieK.2250$wYy9.1764@fx11.iad> |
| In reply to | #50106 |
On 5/9/22 1:36 PM, olcott wrote: > On 5/9/2022 12:31 PM, Mr Flibble wrote: >> On Mon, 9 May 2022 10:51:54 -0500 >> olcott <NoOne@NoWhere.com> wrote: >> >>> On 5/8/2022 7:39 AM, Mr Flibble wrote: >>>> On Sun, 8 May 2022 08:31:10 -0400 >>>> Richard Damon <Richard@Damon-Family.org> wrote: >>>>> On 5/8/22 8:02 AM, Mr Flibble wrote: >>>>>> On Sun, 8 May 2022 07:45:52 -0400 >>>>>> Richard Damon <Richard@Damon-Family.org> wrote: >>>>>>> On 5/8/22 4:49 AM, Mr Flibble wrote: >>>>>>>> On Sun, 8 May 2022 11:31:08 +0300 >>>>>>>> Mikko <mikko.levanto@iki.fi> wrote: >>>>>>>>> On 2022-05-07 15:19:01 +0000, Mr Flibble said: >>>>>>>>>> On Sat, 7 May 2022 18:13:08 +0300 >>>>>>>>>> Mikko <mikko.levanto@iki.fi> wrote: >>>>>>>>>>> On 2022-05-07 14:20:17 +0000, Mr Flibble said: >>>>>>>>>>>> On Sat, 7 May 2022 17:16:31 +0300 >>>>>>>>>>>> Mikko <mikko.levanto@iki.fi> wrote: >>>>>>>>>>>>> On 2022-05-07 14:06:12 +0000, Mr Flibble said: >>>>>>>>>>>>>> On Sat, 7 May 2022 16:59:55 +0300 >>>>>>>>>>>>>> Mikko <mikko.levanto@iki.fi> wrote: >>>>>>>>>>>>>>> On 2022-05-07 12:42:50 +0000, Mr Flibble said: >>>>>>>>>>>>>>>> On Sat, 7 May 2022 12:52:58 +0300 >>>>>>>>>>>>>>>> Mikko <mikko.levanto@iki.fi> wrote: >>>>>>>>>>>>>>>>> On 2022-05-06 14:02:53 +0000, Mr Flibble said: >>>>>>>>>>>>>>>>>> The decider could never be compiled and run in the >>>>>>>>>>>>>>>>>> first place due to the category error in the >>>>>>>>>>>>>>>>>> definition of the proof. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> An error in the definition of the proof does not >>>>>>>>>>>>>>>>> prevent compilation and execution of the program. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> In this case the error in the definition of the proof >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> No part of the proof is identified as errorneous, so the >>>>>>>>>>>>>>> rest is irrelevant. Anyway, >>>>>>>>>>>>>>>> does prevent compilation unless >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> There is no option here, so the "unless" is void. >>>>>>>>>>>>>>>> the decider is made part of the program that is being >>>>>>>>>>>>>>>> decided >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The decider is made a part of the program discussed in >>>>>>>>>>>>>>> the proof. >>>>>>>>>>>>>>>> in which case we get a function call-like infinite >>>>>>>>>>>>>>>> recursion instead >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> We get or we don't get, depending on how the halt decider >>>>>>>>>>>>>>> candidate attempts to decide. >>>>>>>>>>>>>>>> (as described by Pete Olcott) and we are attempting (and >>>>>>>>>>>>>>>> failing) to decide if a procedure halts rather than if a >>>>>>>>>>>>>>>> program halts. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> In any case, the decider candidate fails to give the >>>>>>>>>>>>>>> correct answer, and therefore is not a halt decider. Note >>>>>>>>>>>>>>> that this is correctly inferred in the proof. Therefore >>>>>>>>>>>>>>> either the conclusion of the proof is correct or you are >>>>>>>>>>>>>>> wrong. >>>>>>>>>>>>>> >>>>>>>>>>>>>> No answer is ever given due to the infinite recursion. >>>>>>>>>>>>> >>>>>>>>>>>>> True about some candidates, false about others. For >>>>>>>>>>>>> example, a candidate that always says "no" is not >>>>>>>>>>>>> infinitely recursive but is wrong in the particular case >>>>>>>>>>>>> discussed in the proof. But anyway, you have confirmed the >>>>>>>>>>>>> conclusion of the proof. >>>>>>>>>>>> >>>>>>>>>>>> False. The proof is not cognisant of the presence of the >>>>>>>>>>>> infinite recursion. The decider can never return an answer >>>>>>>>>>>> of halts/doesn't halt due to the infinite recursion. >>>>>>>>>>> >>>>>>>>>>> The correct term is decider candidate. It is not a decider >>>>>>>>>>> because the infinite recursion prevents it from halting in >>>>>>>>>>> finite time. >>>>>>>>>>> >>>>>>>>>>> You cannot call the proof incorrect merely because it agrees >>>>>>>>>>> with you. >>>>>>>>>> >>>>>>>>>> Try actually reading what Strachey wrote: a contradiction >>>>>>>>>> arises based on the result of evaluating T[P] however T[P] is >>>>>>>>>> never evaluated due to the infinite recursion: a fact ignored >>>>>>>>>> by the proof. >>>>>>>>> >>>>>>>>> If you can prove that the program does give the correct result >>>>>>>>> in that case you have proven Strachey wrong. Otherwise you >>>>>>>>> haven't. >>>>>>>> >>>>>>>> Strachey is wrong because he neglected to account for the >>>>>>>> infinite recursion; this should be obvious to anyone who has >>>>>>>> actually read and understood what Strachey wrote: it seems that >>>>>>>> you haven't. >>>>>>>> >>>>>>>> /Flibble >>>>>>> >>>>>>> No, because if T gets stuck in an infinite recursion, it is >>>>>>> wrong, because it failed to answer in finite time. >>>>>>> >>>>>>> If T does answer in finite time, then there never was an infinite >>>>>>> recursion. >>>>>>> >>>>>>> All you have shown is that there exists a WRONG method to build >>>>>>> a T that gets stuck, Like a T that needs to run its input to >>>>>>> completion to answer about it. >>>>>> >>>>>> I have shown that [Strachey, 1965] contains an infinite recursion >>>>>> and is thus invalid. >>>>>> >>>>>> /Flibble >>>>> >>>>> No, you haven't. All you have shown is that one way to attempt to >>>>> make the program that Strachev says doesn't exist, fails due to >>>>> getting caught in infinite recursion. >>>>> >>>>> That just helps confirm Strachev, not refute it. >>>> >>>> Nope. Strachey's proof is based on a contradiction relating to >>>> evaluating the result of T[P] however T[P] can never be evaluated if >>>> there is an infinite recursion. >>>> >>>> /Flibble >>> >>> They all have this same basis. >>> The infinite recursion itself is evaluated. >> Have you not read my retraction? I was in error: there is no infinite >> recursion. >> >> /Flibble >> > > I spent 15,000 hours on this since 2004, all of my messages are still in > this group. I have known more about this since you first began, and I > know more about that after your retraction. > > The idea of category error applied to instances of pathological > self-reference is a new idea. > You have WASTED 15,000 hours on this. You are committing the category error, and are just wrong.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-05-09 20:14 -0400 |
| Message-ID | <F7ieK.2249$wYy9.888@fx11.iad> |
| In reply to | #50081 |
On 5/9/22 11:51 AM, olcott wrote: > On 5/8/2022 7:39 AM, Mr Flibble wrote: >> On Sun, 8 May 2022 08:31:10 -0400 >> Richard Damon <Richard@Damon-Family.org> wrote: >> >>> On 5/8/22 8:02 AM, Mr Flibble wrote: >>>> On Sun, 8 May 2022 07:45:52 -0400 >>>> Richard Damon <Richard@Damon-Family.org> wrote: >>>>> On 5/8/22 4:49 AM, Mr Flibble wrote: >>>>>> On Sun, 8 May 2022 11:31:08 +0300 >>>>>> Mikko <mikko.levanto@iki.fi> wrote: >>>>>>> On 2022-05-07 15:19:01 +0000, Mr Flibble said: >>>>>>>> On Sat, 7 May 2022 18:13:08 +0300 >>>>>>>> Mikko <mikko.levanto@iki.fi> wrote: >>>>>>>>> On 2022-05-07 14:20:17 +0000, Mr Flibble said: >>>>>>>>>> On Sat, 7 May 2022 17:16:31 +0300 >>>>>>>>>> Mikko <mikko.levanto@iki.fi> wrote: >>>>>>>>>>> On 2022-05-07 14:06:12 +0000, Mr Flibble said: >>>>>>>>>>>> On Sat, 7 May 2022 16:59:55 +0300 >>>>>>>>>>>> Mikko <mikko.levanto@iki.fi> wrote: >>>>>>>>>>>>> On 2022-05-07 12:42:50 +0000, Mr Flibble said: >>>>>>>>>>>>>> On Sat, 7 May 2022 12:52:58 +0300 >>>>>>>>>>>>>> Mikko <mikko.levanto@iki.fi> wrote: >>>>>>>>>>>>>>> On 2022-05-06 14:02:53 +0000, Mr Flibble said: >>>>>>>>>>>>>>>> The decider could never be compiled and run in the first >>>>>>>>>>>>>>>> place due to the category error in the definition of the >>>>>>>>>>>>>>>> proof. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> An error in the definition of the proof does not prevent >>>>>>>>>>>>>>> compilation and execution of the program. >>>>>>>>>>>>>> >>>>>>>>>>>>>> In this case the error in the definition of the proof >>>>>>>>>>>>> >>>>>>>>>>>>> No part of the proof is identified as errorneous, so the >>>>>>>>>>>>> rest is irrelevant. Anyway, >>>>>>>>>>>>>> does prevent compilation unless >>>>>>>>>>>>> >>>>>>>>>>>>> There is no option here, so the "unless" is void. >>>>>>>>>>>>>> the decider is made part of the program that is being >>>>>>>>>>>>>> decided >>>>>>>>>>>>> >>>>>>>>>>>>> The decider is made a part of the program discussed in the >>>>>>>>>>>>> proof. >>>>>>>>>>>>>> in which case we get a function call-like infinite >>>>>>>>>>>>>> recursion instead >>>>>>>>>>>>> >>>>>>>>>>>>> We get or we don't get, depending on how the halt decider >>>>>>>>>>>>> candidate attempts to decide. >>>>>>>>>>>>>> (as described by Pete Olcott) and we are attempting (and >>>>>>>>>>>>>> failing) to decide if a procedure halts rather than if a >>>>>>>>>>>>>> program halts. >>>>>>>>>>>>> >>>>>>>>>>>>> In any case, the decider candidate fails to give the >>>>>>>>>>>>> correct answer, and therefore is not a halt decider. Note >>>>>>>>>>>>> that this is correctly inferred in the proof. Therefore >>>>>>>>>>>>> either the conclusion of the proof is correct or you are >>>>>>>>>>>>> wrong. >>>>>>>>>>>> >>>>>>>>>>>> No answer is ever given due to the infinite recursion. >>>>>>>>>>> >>>>>>>>>>> True about some candidates, false about others. For example, >>>>>>>>>>> a candidate that always says "no" is not infinitely >>>>>>>>>>> recursive but is wrong in the particular case discussed in >>>>>>>>>>> the proof. But anyway, you have confirmed the conclusion of >>>>>>>>>>> the proof. >>>>>>>>>> >>>>>>>>>> False. The proof is not cognisant of the presence of the >>>>>>>>>> infinite recursion. The decider can never return an answer of >>>>>>>>>> halts/doesn't halt due to the infinite recursion. >>>>>>>>> >>>>>>>>> The correct term is decider candidate. It is not a decider >>>>>>>>> because the infinite recursion prevents it from halting in >>>>>>>>> finite time. >>>>>>>>> >>>>>>>>> You cannot call the proof incorrect merely because it agrees >>>>>>>>> with you. >>>>>>>> >>>>>>>> Try actually reading what Strachey wrote: a contradiction arises >>>>>>>> based on the result of evaluating T[P] however T[P] is never >>>>>>>> evaluated due to the infinite recursion: a fact ignored by the >>>>>>>> proof. >>>>>>> >>>>>>> If you can prove that the program does give the correct result in >>>>>>> that case you have proven Strachey wrong. Otherwise you haven't. >>>>>> >>>>>> Strachey is wrong because he neglected to account for the infinite >>>>>> recursion; this should be obvious to anyone who has actually read >>>>>> and understood what Strachey wrote: it seems that you haven't. >>>>>> >>>>>> /Flibble >>>>> >>>>> No, because if T gets stuck in an infinite recursion, it is wrong, >>>>> because it failed to answer in finite time. >>>>> >>>>> If T does answer in finite time, then there never was an infinite >>>>> recursion. >>>>> >>>>> All you have shown is that there exists a WRONG method to build a T >>>>> that gets stuck, Like a T that needs to run its input to completion >>>>> to answer about it. >>>> >>>> I have shown that [Strachey, 1965] contains an infinite recursion >>>> and is thus invalid. >>>> >>>> /Flibble >>> >>> No, you haven't. All you have shown is that one way to attempt to >>> make the program that Strachev says doesn't exist, fails due to >>> getting caught in infinite recursion. >>> >>> That just helps confirm Strachev, not refute it. >> >> Nope. Strachey's proof is based on a contradiction relating to >> evaluating the result of T[P] however T[P] can never be evaluated if >> there is an infinite recursion. >> >> /Flibble >> > > They all have this same basis. > The infinite recursion itself is evaluated. > Except as I showed Flibble, there isn't actually infinite recursion in the definition, just in that particular design of H, which shows that that design fails, not the problem is invalid.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-05-09 10:49 -0500 |
| Message-ID | <sdydnYDI-KSGpeT_nZ2dnUU7_81g4p2d@giganews.com> |
| In reply to | #50016 |
On 5/8/2022 3:49 AM, Mr Flibble wrote: > On Sun, 8 May 2022 11:31:08 +0300 > Mikko <mikko.levanto@iki.fi> wrote: > >> On 2022-05-07 15:19:01 +0000, Mr Flibble said: >> >>> On Sat, 7 May 2022 18:13:08 +0300 >>> Mikko <mikko.levanto@iki.fi> wrote: >>> >>>> On 2022-05-07 14:20:17 +0000, Mr Flibble said: >>>> >>>>> On Sat, 7 May 2022 17:16:31 +0300 >>>>> Mikko <mikko.levanto@iki.fi> wrote: >>>>> >>>>>> On 2022-05-07 14:06:12 +0000, Mr Flibble said: >>>>>> >>>>>>> On Sat, 7 May 2022 16:59:55 +0300 >>>>>>> Mikko <mikko.levanto@iki.fi> wrote: >>>>>>> >>>>>>>> On 2022-05-07 12:42:50 +0000, Mr Flibble said: >>>>>>>> >>>>>>>>> On Sat, 7 May 2022 12:52:58 +0300 >>>>>>>>> Mikko <mikko.levanto@iki.fi> wrote: >>>>>>>>> >>>>>>>>>> On 2022-05-06 14:02:53 +0000, Mr Flibble said: >>>>>>>>>> >>>>>>>>>>> The decider could never be compiled and run in the first >>>>>>>>>>> place due to the category error in the definition of the >>>>>>>>>>> proof. >>>>>>>>>> >>>>>>>>>> An error in the definition of the proof does not prevent >>>>>>>>>> compilation and execution of the program. >>>>>>>>> >>>>>>>>> In this case the error in the definition of the proof >>>>>>>> >>>>>>>> No part of the proof is identified as errorneous, so the rest >>>>>>>> is irrelevant. Anyway, >>>>>>>> >>>>>>>>> does prevent compilation unless >>>>>>>> >>>>>>>> There is no option here, so the "unless" is void. >>>>>>>> >>>>>>>>> the decider is made part of the program that is being decided >>>>>>>>> >>>>>>>> >>>>>>>> The decider is made a part of the program discussed in the >>>>>>>> proof. >>>>>>>>> in which case we get a function call-like infinite recursion >>>>>>>>> instead >>>>>>>> >>>>>>>> We get or we don't get, depending on how the halt decider >>>>>>>> candidate attempts to decide. >>>>>>>> >>>>>>>>> (as described by Pete Olcott) and we are attempting (and >>>>>>>>> failing) to decide if a procedure halts rather than if a >>>>>>>>> program halts. >>>>>>>> >>>>>>>> In any case, the decider candidate fails to give the correct >>>>>>>> answer, and therefore is not a halt decider. Note that this is >>>>>>>> correctly inferred in the proof. Therefore either the >>>>>>>> conclusion of the proof is correct or you are wrong. >>>>>>> >>>>>>> No answer is ever given due to the infinite recursion. >>>>>> >>>>>> True about some candidates, false about others. For example, a >>>>>> candidate that always says "no" is not infinitely recursive but >>>>>> is wrong in the particular case discussed in the proof. But >>>>>> anyway, you have confirmed the conclusion of the proof. >>>>> >>>>> False. The proof is not cognisant of the presence of the infinite >>>>> recursion. The decider can never return an answer of >>>>> halts/doesn't halt due to the infinite recursion. >>>> >>>> The correct term is decider candidate. It is not a decider because >>>> the infinite recursion prevents it from halting in finite time. >>>> >>>> You cannot call the proof incorrect merely because it agrees with >>>> you. >>> >>> Try actually reading what Strachey wrote: a contradiction arises >>> based on the result of evaluating T[P] however T[P] is never >>> evaluated due to the infinite recursion: a fact ignored by the >>> proof. >> >> If you can prove that the program does give the correct result in that >> case you have proven Strachey wrong. Otherwise you haven't. > > Strachey is wrong because he neglected to account for the infinite > recursion; this should be obvious to anyone who has actually read and > understood what Strachey wrote: it seems that you haven't. > > /Flibble > It took me from 2004 until 2016 studying nothing more than the first two pages of this proof: https://www.liarparadox.org/Linz_Proof.pdf to realize that infinite recursion is specified. -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibble@reddwarf.jmc> |
|---|---|
| Date | 2022-05-09 18:31 +0100 |
| Message-ID | <20220509183142.000044d7@reddwarf.jmc> |
| In reply to | #50080 |
On Mon, 9 May 2022 10:49:47 -0500 olcott <NoOne@NoWhere.com> wrote: > On 5/8/2022 3:49 AM, Mr Flibble wrote: > > On Sun, 8 May 2022 11:31:08 +0300 > > Mikko <mikko.levanto@iki.fi> wrote: > > > >> On 2022-05-07 15:19:01 +0000, Mr Flibble said: > >> > >>> On Sat, 7 May 2022 18:13:08 +0300 > >>> Mikko <mikko.levanto@iki.fi> wrote: > >>> > >>>> On 2022-05-07 14:20:17 +0000, Mr Flibble said: > >>>> > >>>>> On Sat, 7 May 2022 17:16:31 +0300 > >>>>> Mikko <mikko.levanto@iki.fi> wrote: > >>>>> > >>>>>> On 2022-05-07 14:06:12 +0000, Mr Flibble said: > >>>>>> > >>>>>>> On Sat, 7 May 2022 16:59:55 +0300 > >>>>>>> Mikko <mikko.levanto@iki.fi> wrote: > >>>>>>> > >>>>>>>> On 2022-05-07 12:42:50 +0000, Mr Flibble said: > >>>>>>>> > >>>>>>>>> On Sat, 7 May 2022 12:52:58 +0300 > >>>>>>>>> Mikko <mikko.levanto@iki.fi> wrote: > >>>>>>>>> > >>>>>>>>>> On 2022-05-06 14:02:53 +0000, Mr Flibble said: > >>>>>>>>>> > >>>>>>>>>>> The decider could never be compiled and run in the first > >>>>>>>>>>> place due to the category error in the definition of the > >>>>>>>>>>> proof. > >>>>>>>>>> > >>>>>>>>>> An error in the definition of the proof does not prevent > >>>>>>>>>> compilation and execution of the program. > >>>>>>>>> > >>>>>>>>> In this case the error in the definition of the proof > >>>>>>>> > >>>>>>>> No part of the proof is identified as errorneous, so the rest > >>>>>>>> is irrelevant. Anyway, > >>>>>>>> > >>>>>>>>> does prevent compilation unless > >>>>>>>> > >>>>>>>> There is no option here, so the "unless" is void. > >>>>>>>> > >>>>>>>>> the decider is made part of the program that is being > >>>>>>>>> decided > >>>>>>>> > >>>>>>>> The decider is made a part of the program discussed in the > >>>>>>>> proof. > >>>>>>>>> in which case we get a function call-like infinite recursion > >>>>>>>>> instead > >>>>>>>> > >>>>>>>> We get or we don't get, depending on how the halt decider > >>>>>>>> candidate attempts to decide. > >>>>>>>> > >>>>>>>>> (as described by Pete Olcott) and we are attempting (and > >>>>>>>>> failing) to decide if a procedure halts rather than if a > >>>>>>>>> program halts. > >>>>>>>> > >>>>>>>> In any case, the decider candidate fails to give the correct > >>>>>>>> answer, and therefore is not a halt decider. Note that this > >>>>>>>> is correctly inferred in the proof. Therefore either the > >>>>>>>> conclusion of the proof is correct or you are wrong. > >>>>>>> > >>>>>>> No answer is ever given due to the infinite recursion. > >>>>>> > >>>>>> True about some candidates, false about others. For example, a > >>>>>> candidate that always says "no" is not infinitely recursive but > >>>>>> is wrong in the particular case discussed in the proof. But > >>>>>> anyway, you have confirmed the conclusion of the proof. > >>>>> > >>>>> False. The proof is not cognisant of the presence of the > >>>>> infinite recursion. The decider can never return an answer of > >>>>> halts/doesn't halt due to the infinite recursion. > >>>> > >>>> The correct term is decider candidate. It is not a decider > >>>> because the infinite recursion prevents it from halting in > >>>> finite time. > >>>> > >>>> You cannot call the proof incorrect merely because it agrees with > >>>> you. > >>> > >>> Try actually reading what Strachey wrote: a contradiction arises > >>> based on the result of evaluating T[P] however T[P] is never > >>> evaluated due to the infinite recursion: a fact ignored by the > >>> proof. > >> > >> If you can prove that the program does give the correct result in > >> that case you have proven Strachey wrong. Otherwise you haven't. > > > > Strachey is wrong because he neglected to account for the infinite > > recursion; this should be obvious to anyone who has actually read > > and understood what Strachey wrote: it seems that you haven't. > > > > /Flibble > > > > It took me from 2004 until 2016 studying nothing more than the first > two pages of this proof: https://www.liarparadox.org/Linz_Proof.pdf > to realize that infinite recursion is specified. Have you not read my retraction? I was in error: there is no infinite recursion. /Flibble
[toc] | [prev] | [next] | [standalone]
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
Back to top | Article view | comp.theory
csiph-web