Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

I have not yet begun to byte!


devel / comp.theory / Re: On recursion and infinite recursion (reprise #3)

SubjectAuthor
* On recursion and infinite recursion (reprise #3)Mr Flibble
+* On recursion and infinite recursion (reprise #3)olcott
|`* On recursion and infinite recursion (reprise #3)Ben
| `* On recursion and infinite recursion (reprise #3)olcott
|  `* On recursion and infinite recursion (reprise #3)Ben
|   `* On recursion and infinite recursion (reprise #3)olcott
|    `- On recursion and infinite recursion (reprise #3)Ben
+* On recursion and infinite recursion (reprise #3)Ben
|+* On recursion and infinite recursion (reprise #3)Mr Flibble
||+* On recursion and infinite recursion (reprise #3)Ben
|||`- On recursion and infinite recursion (reprise #3)Mr Flibble
||`- On recursion and infinite recursion (reprise #3)olcott
|`* On recursion and infinite recursion (reprise #3)olcott
| `* On recursion and infinite recursion (reprise #3)Ben
|  `* On recursion and infinite recursion (reprise #3)olcott
|   `- On recursion and infinite recursion (reprise #3)Ben
+* On recursion and infinite recursion (reprise #3)Richard Damon
|`* On recursion and infinite recursion (reprise #3)Mr Flibble
| +* On recursion and infinite recursion (reprise #3)Python
| |`- On recursion and infinite recursion (reprise #3)olcott
| `* On recursion and infinite recursion (reprise #3)Mikko
|  `* On recursion and infinite recursion (reprise #3)Mr Flibble
|   `* On recursion and infinite recursion (reprise #3)Mikko
|    `* On recursion and infinite recursion (reprise #3)Mr Flibble
|     `* On recursion and infinite recursion (reprise #3)Mikko
|      `* On recursion and infinite recursion (reprise #3)Mr Flibble
|       +* On recursion and infinite recursion (reprise #3)Mikko
|       |`* On recursion and infinite recursion (reprise #3)Mr Flibble
|       | +- On recursion and infinite recursion (reprise #3)olcott
|       | +* On recursion and infinite recursion (reprise #3)Ben
|       | |`* On recursion and infinite recursion (reprise #3)Mr Flibble
|       | | `* On recursion and infinite recursion (reprise #3)Richard Damon
|       | |  `* On recursion and infinite recursion (reprise #3)Mr Flibble
|       | |   `* On recursion and infinite recursion (reprise #3)Richard Damon
|       | |    `- On recursion and infinite recursion (reprise #3)Mr Flibble
|       | `* On recursion and infinite recursion (reprise #3)Mikko
|       |  +* On recursion and infinite recursion (reprise #3)Mr Flibble
|       |  |+* On recursion and infinite recursion (reprise #3)Mikko
|       |  ||`- On recursion and infinite recursion (reprise #3)Mr Flibble
|       |  |+* On recursion and infinite recursion (reprise #3)Richard Damon
|       |  ||`* On recursion and infinite recursion (reprise #3)Mr Flibble
|       |  || `* On recursion and infinite recursion (reprise #3)Richard Damon
|       |  ||  `* On recursion and infinite recursion (reprise #3)Mr Flibble
|       |  ||   +* On recursion and infinite recursion (reprise #3)Richard Damon
|       |  ||   |`* On recursion and infinite recursion (reprise #3)Mr Flibble
|       |  ||   | `* On recursion and infinite recursion (reprise #3)Richard Damon
|       |  ||   |  `* On recursion and infinite recursion (reprise #3)Mr Flibble
|       |  ||   |   `* On recursion and infinite recursion (reprise #3)Richard Damon
|       |  ||   |    `* On recursion and infinite recursion (reprise #3)Mr Flibble
|       |  ||   |     +- On recursion and infinite recursion (reprise #3)Ben
|       |  ||   |     +- On recursion and infinite recursion (reprise #3)Richard Damon
|       |  ||   |     `* On recursion and infinite recursion (reprise #3)olcott
|       |  ||   |      `- On recursion and infinite recursion (reprise #3)Richard Damon
|       |  ||   `* On recursion and infinite recursion (reprise #3)olcott
|       |  ||    +* On recursion and infinite recursion (reprise #3)Mr Flibble
|       |  ||    |`* On recursion and infinite recursion (reprise #3)olcott
|       |  ||    | `- On recursion and infinite recursion (reprise #3)Richard Damon
|       |  ||    `- On recursion and infinite recursion (reprise #3)Richard Damon
|       |  |`* On recursion and infinite recursion (reprise #3)olcott
|       |  | `* On recursion and infinite recursion (reprise #3)Mr Flibble
|       |  |  `- On recursion and infinite recursion (reprise #3)olcott
|       |  `* On recursion and infinite recursion (reprise #3)olcott
|       |   `* On recursion and infinite recursion (reprise #3)Mikko
|       |    `* On recursion and infinite recursion (reprise #3)olcott
|       |     `- On recursion and infinite recursion (reprise #3)Richard Damon
|       `- On recursion and infinite recursion (reprise #3)olcott
`- On recursion and infinite recursion (reprise #3)Mikko

Pages:123
Re: On recursion and infinite recursion (reprise #3)

<20220508230420.0000053f@reddwarf.jmc>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=31959&group=comp.theory#31959

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!usenet.goja.nl.eu.org!weretis.net!feeder8.news.weretis.net!feeder1.feed.usenet.farm!feed.usenet.farm!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.ams4!peer.am4.highwinds-media.com!news.highwinds-media.com!fx06.ams4.POSTED!not-for-mail
From: flib...@reddwarf.jmc (Mr Flibble)
Newsgroups: comp.theory
Subject: Re: On recursion and infinite recursion (reprise #3)
Message-ID: <20220508230420.0000053f@reddwarf.jmc>
References: <20220505175034.0000253c@reddwarf.jmc>
<5O%cK.17$wYy9.0@fx11.iad>
<20220506150253.00007c7f@reddwarf.jmc>
<t55fhq$u5e$1@dont-email.me>
<20220507134250.00007acc@reddwarf.jmc>
<t55u0r$7lf$1@dont-email.me>
<20220507150612.00003fab@reddwarf.jmc>
<t55uvv$fpf$1@dont-email.me>
<20220507152017.00000990@reddwarf.jmc>
<t562a4$9ao$1@dont-email.me>
<20220507161901.00002e54@reddwarf.jmc>
<t57v4c$7do$1@dont-email.me>
<20220508094913.00002e7c@reddwarf.jmc>
<Q3OdK.15730$Bm21.3438@fx07.iad>
<20220508130212.00007ab6@reddwarf.jmc>
<iKOdK.8684$t72a.8070@fx10.iad>
<20220508133909.00007b6b@reddwarf.jmc>
<9ITdK.2055$wYy9.1130@fx11.iad>
<20220508200637.0000491c@reddwarf.jmc>
<U%UdK.8711$t72a.8053@fx10.iad>
<20220508211421.000031a0@reddwarf.jmc>
<ENWdK.7593$VwRc.5901@fx01.iad>
Organization: Jupiter Mining Corp
X-Newsreader: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-w64-mingw32)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Lines: 259
X-Complaints-To: abuse@eweka.nl
NNTP-Posting-Date: Sun, 08 May 2022 22:04:20 UTC
Date: Sun, 8 May 2022 23:04:20 +0100
X-Received-Bytes: 13096
 by: Mr Flibble - Sun, 8 May 2022 22:04 UTC

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.


Click here to read the complete article
Re: On recursion and infinite recursion (reprise #3)

<87r153sj1r.fsf@bsb.me.uk>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=31966&group=comp.theory#31966

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ben.use...@bsb.me.uk (Ben)
Newsgroups: comp.theory
Subject: Re: On recursion and infinite recursion (reprise #3)
Date: Mon, 09 May 2022 00:26:08 +0100
Organization: A noiseless patient Spider
Lines: 69
Message-ID: <87r153sj1r.fsf@bsb.me.uk>
References: <20220505175034.0000253c@reddwarf.jmc>
<t55fhq$u5e$1@dont-email.me> <20220507134250.00007acc@reddwarf.jmc>
<t55u0r$7lf$1@dont-email.me> <20220507150612.00003fab@reddwarf.jmc>
<t55uvv$fpf$1@dont-email.me> <20220507152017.00000990@reddwarf.jmc>
<t562a4$9ao$1@dont-email.me> <20220507161901.00002e54@reddwarf.jmc>
<t57v4c$7do$1@dont-email.me> <20220508094913.00002e7c@reddwarf.jmc>
<Q3OdK.15730$Bm21.3438@fx07.iad>
<20220508130212.00007ab6@reddwarf.jmc> <iKOdK.8684$t72a.8070@fx10.iad>
<20220508133909.00007b6b@reddwarf.jmc> <9ITdK.2055$wYy9.1130@fx11.iad>
<20220508200637.0000491c@reddwarf.jmc> <U%UdK.8711$t72a.8053@fx10.iad>
<20220508211421.000031a0@reddwarf.jmc> <ENWdK.7593$VwRc.5901@fx01.iad>
<20220508230420.0000053f@reddwarf.jmc>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="618c43d03445855480f9653e38dab192";
logging-data="21147"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19N89YBLOEV/CA9y6FdJ5ASC0dj9DxMspM="
Cancel-Lock: sha1:I07FnIJg+6UXFkEMmXCeNOdA5Tc=
sha1:qT3BoE4PNDzW3u3Elg3F1BZ2WSw=
X-BSB-Auth: 1.3f0e74c8ba21440aaffd.20220509002608BST.87r153sj1r.fsf@bsb.me.uk
 by: Ben - Sun, 8 May 2022 23:26 UTC

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.

Re: On recursion and infinite recursion (reprise #3)

<8yYdK.6345$6iMa.2142@fx39.iad>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=31968&group=comp.theory#31968

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!news.samoylyk.net!news.uzoreto.com!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx39.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.9.0
Subject: Re: On recursion and infinite recursion (reprise #3)
Content-Language: en-US
Newsgroups: comp.theory
References: <20220505175034.0000253c@reddwarf.jmc> <5O%cK.17$wYy9.0@fx11.iad>
<20220506150253.00007c7f@reddwarf.jmc> <t55fhq$u5e$1@dont-email.me>
<20220507134250.00007acc@reddwarf.jmc> <t55u0r$7lf$1@dont-email.me>
<20220507150612.00003fab@reddwarf.jmc> <t55uvv$fpf$1@dont-email.me>
<20220507152017.00000990@reddwarf.jmc> <t562a4$9ao$1@dont-email.me>
<20220507161901.00002e54@reddwarf.jmc> <t57v4c$7do$1@dont-email.me>
<20220508094913.00002e7c@reddwarf.jmc> <Q3OdK.15730$Bm21.3438@fx07.iad>
<20220508130212.00007ab6@reddwarf.jmc> <iKOdK.8684$t72a.8070@fx10.iad>
<20220508133909.00007b6b@reddwarf.jmc> <9ITdK.2055$wYy9.1130@fx11.iad>
<20220508200637.0000491c@reddwarf.jmc> <U%UdK.8711$t72a.8053@fx10.iad>
<20220508211421.000031a0@reddwarf.jmc> <ENWdK.7593$VwRc.5901@fx01.iad>
<20220508230420.0000053f@reddwarf.jmc>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <20220508230420.0000053f@reddwarf.jmc>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 298
Message-ID: <8yYdK.6345$6iMa.2142@fx39.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Sun, 8 May 2022 19:40:52 -0400
X-Received-Bytes: 15246
 by: Richard Damon - Sun, 8 May 2022 23:40 UTC

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
>


Click here to read the complete article
Re: On recursion and infinite recursion (reprise #3)

<sdydnYHI-KQIquT_nZ2dnUU7_81g4p2d@giganews.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=31993&group=comp.theory#31993

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Mon, 09 May 2022 10:47:33 -0500
Date: Mon, 9 May 2022 10:47:33 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.0
Subject: Re: On recursion and infinite recursion (reprise #3)
Content-Language: en-US
Newsgroups: comp.theory
References: <20220505175034.0000253c@reddwarf.jmc> <5O%cK.17$wYy9.0@fx11.iad>
<20220506150253.00007c7f@reddwarf.jmc> <t55fhq$u5e$1@dont-email.me>
<20220507134250.00007acc@reddwarf.jmc> <t55u0r$7lf$1@dont-email.me>
<20220507150612.00003fab@reddwarf.jmc> <t55uvv$fpf$1@dont-email.me>
<20220507152017.00000990@reddwarf.jmc> <t562a4$9ao$1@dont-email.me>
<20220507161901.00002e54@reddwarf.jmc> <t57v4c$7do$1@dont-email.me>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <t57v4c$7do$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <sdydnYHI-KQIquT_nZ2dnUU7_81g4p2d@giganews.com>
Lines: 95
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-GYqU4/IxDN3AWPWbVu5qN85JZw5mKu6QdpE4zMomOCDD08HCL4nzJunGwOQ4mqWqCgjXv/WlLw+ck9w!NuSr2IxbMqEq1pWFu3jde+3ZzqIEPa1w0FwrtL1pyjDhXS2bdAVuk/jq9alUSbAvLokSebazKOM=
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 5106
 by: olcott - Mon, 9 May 2022 15:47 UTC

On 5/8/2022 3:31 AM, Mikko 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.
>

This is true, yet only true for simulating halt deciders.

> If you can prove that the program does give the correct result in that
> case you have proven Strachey wrong. Otherwise you haven't.
>
> Mikko
>

The halt decider merely needs to recognize and report the infinite
recursion.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

Re: On recursion and infinite recursion (reprise #3)

<sdydnYDI-KSGpeT_nZ2dnUU7_81g4p2d@giganews.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=31994&group=comp.theory#31994

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!1.us.feeder.erje.net!feeder.erje.net!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Mon, 09 May 2022 10:49:47 -0500
Date: Mon, 9 May 2022 10:49:47 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.0
Subject: Re: On recursion and infinite recursion (reprise #3)
Content-Language: en-US
Newsgroups: comp.theory
References: <20220505175034.0000253c@reddwarf.jmc> <5O%cK.17$wYy9.0@fx11.iad>
<20220506150253.00007c7f@reddwarf.jmc> <t55fhq$u5e$1@dont-email.me>
<20220507134250.00007acc@reddwarf.jmc> <t55u0r$7lf$1@dont-email.me>
<20220507150612.00003fab@reddwarf.jmc> <t55uvv$fpf$1@dont-email.me>
<20220507152017.00000990@reddwarf.jmc> <t562a4$9ao$1@dont-email.me>
<20220507161901.00002e54@reddwarf.jmc> <t57v4c$7do$1@dont-email.me>
<20220508094913.00002e7c@reddwarf.jmc>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <20220508094913.00002e7c@reddwarf.jmc>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <sdydnYDI-KSGpeT_nZ2dnUU7_81g4p2d@giganews.com>
Lines: 104
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-SxxvNPNfVpnBYIdzT4IEhqV3RdA54eYu1pY3EQ+XS0p+HkOooFKhQjrWrMfvUBbKpK/TrJ+9EdwKGV7!aKjmJAgRZzN9BmVfZyEHn43J4hqL0MOEsmQFsEBjevSdP1koVAelGChKcdroMzkr+9qERd93Qiw=
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 5659
 by: olcott - Mon, 9 May 2022 15:49 UTC

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

Re: On recursion and infinite recursion (reprise #3)

<sdydnYPI-KQGpeT_nZ2dnUU7_81g4p2d@giganews.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=31995&group=comp.theory#31995

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Mon, 09 May 2022 10:51:55 -0500
Date: Mon, 9 May 2022 10:51:54 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.0
Subject: Re: On recursion and infinite recursion (reprise #3)
Content-Language: en-US
Newsgroups: comp.theory
References: <20220505175034.0000253c@reddwarf.jmc> <5O%cK.17$wYy9.0@fx11.iad>
<20220506150253.00007c7f@reddwarf.jmc> <t55fhq$u5e$1@dont-email.me>
<20220507134250.00007acc@reddwarf.jmc> <t55u0r$7lf$1@dont-email.me>
<20220507150612.00003fab@reddwarf.jmc> <t55uvv$fpf$1@dont-email.me>
<20220507152017.00000990@reddwarf.jmc> <t562a4$9ao$1@dont-email.me>
<20220507161901.00002e54@reddwarf.jmc> <t57v4c$7do$1@dont-email.me>
<20220508094913.00002e7c@reddwarf.jmc> <Q3OdK.15730$Bm21.3438@fx07.iad>
<20220508130212.00007ab6@reddwarf.jmc> <iKOdK.8684$t72a.8070@fx10.iad>
<20220508133909.00007b6b@reddwarf.jmc>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <20220508133909.00007b6b@reddwarf.jmc>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <sdydnYPI-KQGpeT_nZ2dnUU7_81g4p2d@giganews.com>
Lines: 144
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-iRt0RqjiBtwWPkuMviw3w+yMYmLq2vGqpumPtDV7BVvwm7FJBK2QeaYEIPQAd3YtHQs8TJLQIgd+CvX!AZk9rkKJSFxHGVRknLCvxkZbbJb+RL5KxXpSVXcXfkdLLhDjvxjaK7TviKHXFSr6cOJiEsUOtT8=
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 7435
 by: olcott - Mon, 9 May 2022 15:51 UTC

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

Re: On recursion and infinite recursion (reprise #3)

<sdydnb3I-KTLpOT_nZ2dnUU7_81g4p2d@giganews.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=31998&group=comp.theory#31998

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Mon, 09 May 2022 10:55:02 -0500
Date: Mon, 9 May 2022 10:55:01 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.0
Subject: Re: On recursion and infinite recursion (reprise #3)
Content-Language: en-US
Newsgroups: comp.theory
References: <20220505175034.0000253c@reddwarf.jmc> <5O%cK.17$wYy9.0@fx11.iad>
<20220506150253.00007c7f@reddwarf.jmc> <t55fhq$u5e$1@dont-email.me>
<20220507134250.00007acc@reddwarf.jmc> <t55u0r$7lf$1@dont-email.me>
<20220507150612.00003fab@reddwarf.jmc> <t55uvv$fpf$1@dont-email.me>
<20220507152017.00000990@reddwarf.jmc> <t562a4$9ao$1@dont-email.me>
<20220507161901.00002e54@reddwarf.jmc> <t57v4c$7do$1@dont-email.me>
<20220508094913.00002e7c@reddwarf.jmc> <Q3OdK.15730$Bm21.3438@fx07.iad>
<20220508130212.00007ab6@reddwarf.jmc> <iKOdK.8684$t72a.8070@fx10.iad>
<20220508133909.00007b6b@reddwarf.jmc> <9ITdK.2055$wYy9.1130@fx11.iad>
<20220508200637.0000491c@reddwarf.jmc> <U%UdK.8711$t72a.8053@fx10.iad>
<20220508211421.000031a0@reddwarf.jmc> <ENWdK.7593$VwRc.5901@fx01.iad>
<20220508230420.0000053f@reddwarf.jmc>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <20220508230420.0000053f@reddwarf.jmc>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <sdydnb3I-KTLpOT_nZ2dnUU7_81g4p2d@giganews.com>
Lines: 284
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-7Loe1ZnJvDpOdbDOpo7plyTns45kBuShiVJmJO2VogI1eiT5daWyKagPgkvjdOcVNh2o5gx7BVR12zT!WaDP2RDb8+CVqHMJD10XZdc7qYEpvPnPJ6AA9M1Gs+5nwU0WjkJTC9ERJZWIR0vCdScofvpHuOE=
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 14002
 by: olcott - Mon, 9 May 2022 15:55 UTC

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.
>


Click here to read the complete article
Re: On recursion and infinite recursion (reprise #3)

<t5bfoi$6g3$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=32004&group=comp.theory#32004

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: mikko.le...@iki.fi (Mikko)
Newsgroups: comp.theory
Subject: Re: On recursion and infinite recursion (reprise #3)
Date: Mon, 9 May 2022 19:33:22 +0300
Organization: -
Lines: 86
Message-ID: <t5bfoi$6g3$1@dont-email.me>
References: <20220505175034.0000253c@reddwarf.jmc> <5O%cK.17$wYy9.0@fx11.iad> <20220506150253.00007c7f@reddwarf.jmc> <t55fhq$u5e$1@dont-email.me> <20220507134250.00007acc@reddwarf.jmc> <t55u0r$7lf$1@dont-email.me> <20220507150612.00003fab@reddwarf.jmc> <t55uvv$fpf$1@dont-email.me> <20220507152017.00000990@reddwarf.jmc> <t562a4$9ao$1@dont-email.me> <20220507161901.00002e54@reddwarf.jmc> <t57v4c$7do$1@dont-email.me> <sdydnYHI-KQIquT_nZ2dnUU7_81g4p2d@giganews.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: reader02.eternal-september.org; posting-host="871f45336a9d605f6a33740f951bf412";
logging-data="6659"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX180fNypNuJm93eUzoiAAuX0"
User-Agent: Unison/2.2
Cancel-Lock: sha1:xnErhFZU2QZWaWwJGsOeotGVwoI=
 by: Mikko - Mon, 9 May 2022 16:33 UTC

On 2022-05-09 15:47:33 +0000, olcott said:

> On 5/8/2022 3:31 AM, Mikko 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.
>>
>
> This is true, yet only true for simulating halt deciders.

The erroneus statement is already retracted.

Mikko

Re: On recursion and infinite recursion (reprise #3)

<boqdnXo91P1m3-T_nZ2dnUU7_8xh4p2d@giganews.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=32005&group=comp.theory#32005

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Mon, 09 May 2022 11:36:11 -0500
Date: Mon, 9 May 2022 11:36:11 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.0
Subject: Re: On recursion and infinite recursion (reprise #3)
Content-Language: en-US
Newsgroups: comp.theory
References: <20220505175034.0000253c@reddwarf.jmc> <5O%cK.17$wYy9.0@fx11.iad>
<20220506150253.00007c7f@reddwarf.jmc> <t55fhq$u5e$1@dont-email.me>
<20220507134250.00007acc@reddwarf.jmc> <t55u0r$7lf$1@dont-email.me>
<20220507150612.00003fab@reddwarf.jmc> <t55uvv$fpf$1@dont-email.me>
<20220507152017.00000990@reddwarf.jmc> <t562a4$9ao$1@dont-email.me>
<20220507161901.00002e54@reddwarf.jmc> <t57v4c$7do$1@dont-email.me>
<sdydnYHI-KQIquT_nZ2dnUU7_81g4p2d@giganews.com> <t5bfoi$6g3$1@dont-email.me>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <t5bfoi$6g3$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <boqdnXo91P1m3-T_nZ2dnUU7_8xh4p2d@giganews.com>
Lines: 99
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-ye6qsCuNEba1yp7MsTq3+Gs9/K7mw1HBGlf4nDQNyXf/yZaZDQohUBpMG12vnWfuxXbx2c19ZWgzpTU!IP38zO0K60eO91tlV052s3ErxsSx2ShXRuHIGhbeja1NgBrPjvDHtL7jwXrv54JBeerLerdlUwk=
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 5521
 by: olcott - Mon, 9 May 2022 16:36 UTC

On 5/9/2022 11:33 AM, Mikko wrote:
> On 2022-05-09 15:47:33 +0000, olcott said:
>
>> On 5/8/2022 3:31 AM, Mikko 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.
>>>
>>
>> This is true, yet only true for simulating halt deciders.
>
> The erroneus statement is already retracted.
>
> Mikko
>

It turns out that it was never erroneous, it was merely missing a key
detail, that the halt decider must base its halting status decision on
the behavior of its simulation of its input. In that case the
contradictory part of the input is never reached.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

Re: On recursion and infinite recursion (reprise #3)

<20220509183114.0000448f@reddwarf.jmc>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=32016&group=comp.theory#32016

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!news.mb-net.net!open-news-network.org!news.mind.de!bolzen.all.de!npeer.as286.net!npeer-ng0.as286.net!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer01.ams4!peer.am4.highwinds-media.com!news.highwinds-media.com!fx06.ams4.POSTED!not-for-mail
From: flib...@reddwarf.jmc (Mr Flibble)
Newsgroups: comp.theory
Subject: Re: On recursion and infinite recursion (reprise #3)
Message-ID: <20220509183114.0000448f@reddwarf.jmc>
References: <20220505175034.0000253c@reddwarf.jmc>
<5O%cK.17$wYy9.0@fx11.iad>
<20220506150253.00007c7f@reddwarf.jmc>
<t55fhq$u5e$1@dont-email.me>
<20220507134250.00007acc@reddwarf.jmc>
<t55u0r$7lf$1@dont-email.me>
<20220507150612.00003fab@reddwarf.jmc>
<t55uvv$fpf$1@dont-email.me>
<20220507152017.00000990@reddwarf.jmc>
<t562a4$9ao$1@dont-email.me>
<20220507161901.00002e54@reddwarf.jmc>
<t57v4c$7do$1@dont-email.me>
<20220508094913.00002e7c@reddwarf.jmc>
<Q3OdK.15730$Bm21.3438@fx07.iad>
<20220508130212.00007ab6@reddwarf.jmc>
<iKOdK.8684$t72a.8070@fx10.iad>
<20220508133909.00007b6b@reddwarf.jmc>
<sdydnYPI-KQGpeT_nZ2dnUU7_81g4p2d@giganews.com>
Organization: Jupiter Mining Corp
X-Newsreader: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-w64-mingw32)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Lines: 147
X-Complaints-To: abuse@eweka.nl
NNTP-Posting-Date: Mon, 09 May 2022 17:31:13 UTC
Date: Mon, 9 May 2022 18:31:14 +0100
X-Received-Bytes: 7392
 by: Mr Flibble - Mon, 9 May 2022 17:31 UTC

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.

Click here to read the complete article

Re: On recursion and infinite recursion (reprise #3)

<20220509183142.000044d7@reddwarf.jmc>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=32017&group=comp.theory#32017

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!ecngs!feeder2.ecngs.de!178.20.174.213.MISMATCH!feeder1.feed.usenet.farm!feed.usenet.farm!peer03.ams4!peer.am4.highwinds-media.com!news.highwinds-media.com!fx06.ams4.POSTED!not-for-mail
From: flib...@reddwarf.jmc (Mr Flibble)
Newsgroups: comp.theory
Subject: Re: On recursion and infinite recursion (reprise #3)
Message-ID: <20220509183142.000044d7@reddwarf.jmc>
References: <20220505175034.0000253c@reddwarf.jmc>
<5O%cK.17$wYy9.0@fx11.iad>
<20220506150253.00007c7f@reddwarf.jmc>
<t55fhq$u5e$1@dont-email.me>
<20220507134250.00007acc@reddwarf.jmc>
<t55u0r$7lf$1@dont-email.me>
<20220507150612.00003fab@reddwarf.jmc>
<t55uvv$fpf$1@dont-email.me>
<20220507152017.00000990@reddwarf.jmc>
<t562a4$9ao$1@dont-email.me>
<20220507161901.00002e54@reddwarf.jmc>
<t57v4c$7do$1@dont-email.me>
<20220508094913.00002e7c@reddwarf.jmc>
<sdydnYDI-KSGpeT_nZ2dnUU7_81g4p2d@giganews.com>
Organization: Jupiter Mining Corp
X-Newsreader: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-w64-mingw32)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Lines: 107
X-Complaints-To: abuse@eweka.nl
NNTP-Posting-Date: Mon, 09 May 2022 17:31:40 UTC
Date: Mon, 9 May 2022 18:31:42 +0100
X-Received-Bytes: 5422
 by: Mr Flibble - Mon, 9 May 2022 17:31 UTC

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

Re: On recursion and infinite recursion (reprise #3)

<zPadnWhY_5qczOT_nZ2dnUU7_81g4p2d@giganews.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=32020&group=comp.theory#32020

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Mon, 09 May 2022 12:36:01 -0500
Date: Mon, 9 May 2022 12:36:00 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.0
Subject: Re: On recursion and infinite recursion (reprise #3)
Content-Language: en-US
Newsgroups: comp.theory
References: <20220505175034.0000253c@reddwarf.jmc> <5O%cK.17$wYy9.0@fx11.iad>
<20220506150253.00007c7f@reddwarf.jmc> <t55fhq$u5e$1@dont-email.me>
<20220507134250.00007acc@reddwarf.jmc> <t55u0r$7lf$1@dont-email.me>
<20220507150612.00003fab@reddwarf.jmc> <t55uvv$fpf$1@dont-email.me>
<20220507152017.00000990@reddwarf.jmc> <t562a4$9ao$1@dont-email.me>
<20220507161901.00002e54@reddwarf.jmc> <t57v4c$7do$1@dont-email.me>
<20220508094913.00002e7c@reddwarf.jmc> <Q3OdK.15730$Bm21.3438@fx07.iad>
<20220508130212.00007ab6@reddwarf.jmc> <iKOdK.8684$t72a.8070@fx10.iad>
<20220508133909.00007b6b@reddwarf.jmc>
<sdydnYPI-KQGpeT_nZ2dnUU7_81g4p2d@giganews.com>
<20220509183114.0000448f@reddwarf.jmc>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <20220509183114.0000448f@reddwarf.jmc>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <zPadnWhY_5qczOT_nZ2dnUU7_81g4p2d@giganews.com>
Lines: 162
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-g0i4RZyOnLIDggppAmOIxuCd3u9OZpYvRbwwybRLP68FarCVDyFTn3ElL/dedutKYcLWcwOAfIll2C/!swnmsVRDSqxGbLF1zt9nu2xhSS4Gtt8FGl5SXowMH3Yfy+J79R2J+uQdFUMsc0bvwW209BzuMHM=
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 8386
 by: olcott - Mon, 9 May 2022 17:36 UTC

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
>


Click here to read the complete article
Re: On recursion and infinite recursion (reprise #3)

<zPadnWtY_5rZzOT_nZ2dnUU7_81g4p2d@giganews.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=32021&group=comp.theory#32021

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Mon, 09 May 2022 12:37:07 -0500
Date: Mon, 9 May 2022 12:37:07 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.0
Subject: Re: On recursion and infinite recursion (reprise #3)
Content-Language: en-US
Newsgroups: comp.theory
References: <20220505175034.0000253c@reddwarf.jmc> <5O%cK.17$wYy9.0@fx11.iad>
<20220506150253.00007c7f@reddwarf.jmc> <t55fhq$u5e$1@dont-email.me>
<20220507134250.00007acc@reddwarf.jmc> <t55u0r$7lf$1@dont-email.me>
<20220507150612.00003fab@reddwarf.jmc> <t55uvv$fpf$1@dont-email.me>
<20220507152017.00000990@reddwarf.jmc> <t562a4$9ao$1@dont-email.me>
<20220507161901.00002e54@reddwarf.jmc> <t57v4c$7do$1@dont-email.me>
<20220508094913.00002e7c@reddwarf.jmc>
<sdydnYDI-KSGpeT_nZ2dnUU7_81g4p2d@giganews.com>
<20220509183142.000044d7@reddwarf.jmc>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <20220509183142.000044d7@reddwarf.jmc>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <zPadnWtY_5rZzOT_nZ2dnUU7_81g4p2d@giganews.com>
Lines: 118
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-DQWxlhRf0oTb7YeIu6B5pJRSdr7mxX1ORUL8RZGRrHDW4F/zw+CJsHk5Lzi4agTVUKzqV/GpetQkl3u!uewwkVjYJgi5ef0h4lR3pdSUcAEcGRzwL0My7mgDC3Y1F9nk0Y5CyzLlMKQZnFfLcPWU0JW2RJM=
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 6358
 by: olcott - Mon, 9 May 2022 17:37 UTC

On 5/9/2022 12:31 PM, Mr Flibble wrote:
> 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
>

Since I proved that there is infinite recursion since 2016 your
retraction that there is no infinite recursion is simply incorrect.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

Re: On recursion and infinite recursion (reprise #3)

<A6ieK.2248$wYy9.735@fx11.iad>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=32080&group=comp.theory#32080

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx11.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.9.0
Subject: Re: On recursion and infinite recursion (reprise #3)
Content-Language: en-US
Newsgroups: comp.theory
References: <20220505175034.0000253c@reddwarf.jmc> <5O%cK.17$wYy9.0@fx11.iad>
<20220506150253.00007c7f@reddwarf.jmc> <t55fhq$u5e$1@dont-email.me>
<20220507134250.00007acc@reddwarf.jmc> <t55u0r$7lf$1@dont-email.me>
<20220507150612.00003fab@reddwarf.jmc> <t55uvv$fpf$1@dont-email.me>
<20220507152017.00000990@reddwarf.jmc> <t562a4$9ao$1@dont-email.me>
<20220507161901.00002e54@reddwarf.jmc> <t57v4c$7do$1@dont-email.me>
<20220508094913.00002e7c@reddwarf.jmc> <Q3OdK.15730$Bm21.3438@fx07.iad>
<20220508130212.00007ab6@reddwarf.jmc> <iKOdK.8684$t72a.8070@fx10.iad>
<20220508133909.00007b6b@reddwarf.jmc> <9ITdK.2055$wYy9.1130@fx11.iad>
<20220508200637.0000491c@reddwarf.jmc> <U%UdK.8711$t72a.8053@fx10.iad>
<20220508211421.000031a0@reddwarf.jmc> <ENWdK.7593$VwRc.5901@fx01.iad>
<20220508230420.0000053f@reddwarf.jmc>
<sdydnb3I-KTLpOT_nZ2dnUU7_81g4p2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <sdydnb3I-KTLpOT_nZ2dnUU7_81g4p2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 262
Message-ID: <A6ieK.2248$wYy9.735@fx11.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Mon, 9 May 2022 20:13:21 -0400
X-Received-Bytes: 13385
 by: Richard Damon - Tue, 10 May 2022 00:13 UTC

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));
> }
>


Click here to read the complete article
Re: On recursion and infinite recursion (reprise #3)

<F7ieK.2249$wYy9.888@fx11.iad>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=32082&group=comp.theory#32082

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!news-out.netnews.com!news.alt.net!fdc2.netnews.com!feeder1.feed.usenet.farm!feed.usenet.farm!peer03.ams4!peer.am4.highwinds-media.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx11.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.9.0
Subject: Re: On recursion and infinite recursion (reprise #3)
Content-Language: en-US
Newsgroups: comp.theory
References: <20220505175034.0000253c@reddwarf.jmc> <5O%cK.17$wYy9.0@fx11.iad>
<20220506150253.00007c7f@reddwarf.jmc> <t55fhq$u5e$1@dont-email.me>
<20220507134250.00007acc@reddwarf.jmc> <t55u0r$7lf$1@dont-email.me>
<20220507150612.00003fab@reddwarf.jmc> <t55uvv$fpf$1@dont-email.me>
<20220507152017.00000990@reddwarf.jmc> <t562a4$9ao$1@dont-email.me>
<20220507161901.00002e54@reddwarf.jmc> <t57v4c$7do$1@dont-email.me>
<20220508094913.00002e7c@reddwarf.jmc> <Q3OdK.15730$Bm21.3438@fx07.iad>
<20220508130212.00007ab6@reddwarf.jmc> <iKOdK.8684$t72a.8070@fx10.iad>
<20220508133909.00007b6b@reddwarf.jmc>
<sdydnYPI-KQGpeT_nZ2dnUU7_81g4p2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <sdydnYPI-KQGpeT_nZ2dnUU7_81g4p2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 126
Message-ID: <F7ieK.2249$wYy9.888@fx11.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Mon, 9 May 2022 20:14:30 -0400
X-Received-Bytes: 7105
 by: Richard Damon - Tue, 10 May 2022 00:14 UTC

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.

Re: On recursion and infinite recursion (reprise #3)

<G8ieK.2250$wYy9.1764@fx11.iad>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=32083&group=comp.theory#32083

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!feeder1.feed.usenet.farm!feed.usenet.farm!peer02.ams4!peer.am4.highwinds-media.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx11.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.9.0
Subject: Re: On recursion and infinite recursion (reprise #3)
Content-Language: en-US
Newsgroups: comp.theory
References: <20220505175034.0000253c@reddwarf.jmc> <5O%cK.17$wYy9.0@fx11.iad>
<20220506150253.00007c7f@reddwarf.jmc> <t55fhq$u5e$1@dont-email.me>
<20220507134250.00007acc@reddwarf.jmc> <t55u0r$7lf$1@dont-email.me>
<20220507150612.00003fab@reddwarf.jmc> <t55uvv$fpf$1@dont-email.me>
<20220507152017.00000990@reddwarf.jmc> <t562a4$9ao$1@dont-email.me>
<20220507161901.00002e54@reddwarf.jmc> <t57v4c$7do$1@dont-email.me>
<20220508094913.00002e7c@reddwarf.jmc> <Q3OdK.15730$Bm21.3438@fx07.iad>
<20220508130212.00007ab6@reddwarf.jmc> <iKOdK.8684$t72a.8070@fx10.iad>
<20220508133909.00007b6b@reddwarf.jmc>
<sdydnYPI-KQGpeT_nZ2dnUU7_81g4p2d@giganews.com>
<20220509183114.0000448f@reddwarf.jmc>
<zPadnWhY_5qczOT_nZ2dnUU7_81g4p2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <zPadnWhY_5qczOT_nZ2dnUU7_81g4p2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 142
Message-ID: <G8ieK.2250$wYy9.1764@fx11.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Mon, 9 May 2022 20:15:36 -0400
X-Received-Bytes: 7892
 by: Richard Damon - Tue, 10 May 2022 00:15 UTC

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.
>


Click here to read the complete article
Re: On recursion and infinite recursion (reprise #3)

<GaieK.2251$wYy9.102@fx11.iad>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=32084&group=comp.theory#32084

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx11.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.9.0
Subject: Re: On recursion and infinite recursion (reprise #3)
Content-Language: en-US
Newsgroups: comp.theory
References: <20220505175034.0000253c@reddwarf.jmc> <5O%cK.17$wYy9.0@fx11.iad>
<20220506150253.00007c7f@reddwarf.jmc> <t55fhq$u5e$1@dont-email.me>
<20220507134250.00007acc@reddwarf.jmc> <t55u0r$7lf$1@dont-email.me>
<20220507150612.00003fab@reddwarf.jmc> <t55uvv$fpf$1@dont-email.me>
<20220507152017.00000990@reddwarf.jmc> <t562a4$9ao$1@dont-email.me>
<20220507161901.00002e54@reddwarf.jmc> <t57v4c$7do$1@dont-email.me>
<sdydnYHI-KQIquT_nZ2dnUU7_81g4p2d@giganews.com> <t5bfoi$6g3$1@dont-email.me>
<boqdnXo91P1m3-T_nZ2dnUU7_8xh4p2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <boqdnXo91P1m3-T_nZ2dnUU7_8xh4p2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 103
Message-ID: <GaieK.2251$wYy9.102@fx11.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Mon, 9 May 2022 20:17:44 -0400
X-Received-Bytes: 5533
 by: Richard Damon - Tue, 10 May 2022 00:17 UTC

On 5/9/22 12:36 PM, olcott wrote:
> On 5/9/2022 11:33 AM, Mikko wrote:
>> On 2022-05-09 15:47:33 +0000, olcott said:
>>
>>> On 5/8/2022 3:31 AM, Mikko 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.
>>>>
>>>
>>> This is true, yet only true for simulating halt deciders.
>>
>> The erroneus statement is already retracted.
>>
>> Mikko
>>
>
> It turns out that it was never erroneous, it was merely missing a key
> detail, that the halt decider must base its halting status decision on
> the behavior of its simulation of its input. In that case the
> contradictory part of the input is never reached.
>

Maybe H needs to base its decision on that, but the correct answer is
based on the simulation/execution of the ACTUAL machine the input
represents.

If it is impossible for H to deduce that behavior, that just shows that
it is impossibe to decide Halting, as Turing's Halting Theorem says.

Pages:123
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor