Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  nodelist  faq  login

Dijkstra probably hates me (Linus Torvalds, in kernel/sched.c)


computers / comp.ai.philosophy / Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (deciders within

SubjectAuthor
* Happy Thanksgiving to allolcott
`* Re: Happy Thanksgiving to allolcott
 +* Re: Happy Thanksgiving to allolcott
 |+- Re: Happy Thanksgiving to allolcott
 |`* Re: Happy Thanksgiving to allolcott
 | `* Re: Happy Thanksgiving to allolcott
 |  +- Re: Happy Thanksgiving to all (over your head)olcott
 |  `* Re: Happy Thanksgiving to all (Over your head)olcott
 |   +* Re: Happy Thanksgiving to all (Over your head)olcott
 |   |`* Re: Happy Thanksgiving to all (logical necessity)olcott
 |   | +* Re: Happy Thanksgiving to all (logical necessity)Mr Flibble
 |   | |`- Re: Happy Thanksgiving to all (logical necessity)olcott
 |   | +* Re: Happy Thanksgiving to all (logical necessity)olcott
 |   | |+* Re: Happy Thanksgiving to all (logical necessity)olcott
 |   | ||`- Re: Happy Thanksgiving to all (logical necessity)olcott
 |   | |`- Re: Happy Thanksgiving to all (logical necessity)olcott
 |   | `- Re: Happy Thanksgiving to all (logical necessity)olcott
 |   `* Re: Happy Thanksgiving to all (Over your head)Jeff Barnett
 |    `* Re: Happy Thanksgiving to all (logical necessity)olcott
 |     `* Re: Happy Thanksgiving to all (logical necessity)olcott
 |      +* Re: Happy Thanksgiving to all (logical necessity)olcott
 |      |`* Re: Happy Thanksgiving to all (logical necessity)Jeff Barnett
 |      | `* Re: Happy Thanksgiving to all (logical necessity)olcott
 |      |  `* Re: Happy Thanksgiving to all (logical necessity)olcott
 |      |   +- Re: Happy Thanksgiving to all (logical necessity)olcott
 |      |   `* Re: Happy Thanksgiving to all (logical necessity)olcott
 |      |    `* Re: Happy Thanksgiving to all (logical necessity)olcott
 |      |     +* Re: Happy Thanksgiving to all (logical necessity)(asleep at the switch)olcott
 |      |     |+* Re: Happy Thanksgiving to all (logical necessity)(asleep at theolcott
 |      |     ||`* Re: Happy Thanksgiving to all (logical necessity)(asleep at theChris M. Thomasson
 |      |     || `* Re: Happy Thanksgiving to all (logical necessity)(asleep at theJeff Barnett
 |      |     ||  `* Re: Happy Thanksgiving to all (logical necessity)(asleep at theChris M. Thomasson
 |      |     ||   `- Re: Happy Thanksgiving to all (logical necessity)(asleep at theJeff Barnett
 |      |     |+* Re: Happy Thanksgiving to all (logical necessity)(asleep at the switch)olcott
 |      |     ||`* Re: Happy Thanksgiving to all (logical necessity)(asleep at theKaz Kylheku
 |      |     || `* Re: Happy Thanksgiving to all (logical necessity)(asleep at theolcott
 |      |     ||  `* Re: Happy Thanksgiving to all (logical necessity)(asleep at theKaz Kylheku
 |      |     ||   +* Re: Happy Thanksgiving to all (logical necessity)(asleep at theolcott
 |      |     ||   |`- Re: Happy Thanksgiving to all (logical necessity)(asleep at the switch)olcott
 |      |     ||   `- Re: Happy Thanksgiving to all (logical necessity)(asleep at theolcott
 |      |     |`* Re: Happy Thanksgiving to all (logical necessity)(Numbskull?)olcott
 |      |     | +* Re: Happy Thanksgiving to all (logical necessity)[ Ben is a Numbskull !!! olcott
 |      |     | |`* Re: Happy Thanksgiving to all (logical necessity)[ Ben is a Numbskullolcott
 |      |     | | `- Re: Happy Thanksgiving to all (logical necessity)[ Ben is a Numbskullolcott
 |      |     | +* Re: Happy Thanksgiving to all (logical necessity)(Numbskull?)olcott
 |      |     | |`* Re: Refuting the Peter Linz HP proofolcott
 |      |     | | `* Re: Refuting the Peter Linz HP proofolcott
 |      |     | |  `* Re: Refuting the Peter Linz HP proofolcott
 |      |     | |   `- Re: Refuting the Peter Linz HP proofolcott
 |      |     | +* Re: Happy Thanksgiving to all (logical necessity)[ Effectiveolcott
 |      |     | |+- Re: Local halt decider enabled[ Effective Presentation ]olcott
 |      |     | |`* Re: Renaming DebugTrace() to H or Halts[ Effective Presentation ]olcott
 |      |     | | `* Re: Renaming DebugTrace() to H or Halts[ Effective Presentation ]olcott
 |      |     | |  +- Re: Renaming DebugTrace() to H or Halts[ Effective Presentation ]olcott
 |      |     | |  +* Re: Renaming DebugTrace() to H or Halts[ Effective Presentation ]olcott
 |      |     | |  |+- Re: Renaming DebugTrace() to H or Halts[ Effective Presentation ]olcott
 |      |     | |  |+* Re: Renaming DebugTrace() to H or Halts[ Effective Presentation ]olcott
 |      |     | |  ||`* Re: Renaming DebugTrace() to H or Halts[ Effective Presentation ]olcott
 |      |     | |  || +* Re: Renaming DebugTrace() to H or Halts[ Effective Presentation ]olcott
 |      |     | |  || |`- Re: Renaming DebugTrace() to H or Halts[ Effective Presentation ]olcott
 |      |     | |  || `* Re: Renaming DebugTrace() to H or Halts[ Effective Presentation ]olcott
 |      |     | |  ||  `* Re: Renaming DebugTrace() to H or Halts[ Effective Presentation ]olcott
 |      |     | |  ||   `* Re: Renaming DebugTrace() to H or Halts[ Effective Presentation ]olcott
 |      |     | |  ||    `* Re: Renaming DebugTrace() to H or Halts[ Effective Presentation ]olcott
 |      |     | |  ||     +- Re: Renaming DebugTrace() to H or Halts[ Effective Presentation ]olcott
 |      |     | |  ||     +- Re: Renaming DebugTrace() to H or Halts[ Effective Presentation ]olcott
 |      |     | |  ||     +* Re: Renaming DebugTrace() to H or Halts[ Effective Presentation ]olcott
 |      |     | |  ||     |`* Re: Renaming DebugTrace() to H or Halts[ Effective Presentation ]olcott
 |      |     | |  ||     | `* Re: Refutation of Peter Linz HP proof [ Logical Necessity ]olcott
 |      |     | |  ||     |  +* Re: Refutation of Peter Linz HP proof [ Logical Necessity ]Mr Flibble
 |      |     | |  ||     |  |`* Re: Refutation of Peter Linz HP proof [ Logical Necessity ]olcott
 |      |     | |  ||     |  | `- Re: Refutation of Peter Linz HP proof [ Logical Necessity ]Jeff Barnett
 |      |     | |  ||     |  +* Re: Refutation of Peter Linz HP proof [ Logical Necessity ]olcott
 |      |     | |  ||     |  |+* Re: Refutation of Peter Linz HP proof [ Logical Necessity ]olcott
 |      |     | |  ||     |  ||`* Re: Refutation of Peter Linz HP proof [ Logical Necessity ]Kaz Kylheku
 |      |     | |  ||     |  || `* Re: Refutation of Peter Linz HP proof [ Logical Necessity ]olcott
 |      |     | |  ||     |  ||  `* Re: Refutation of Peter Linz HP proof [ Logical Necessity ]Kaz Kylheku
 |      |     | |  ||     |  ||   `* Re: Refutation of Peter Linz HP proof [ Logical Necessity ]olcott
 |      |     | |  ||     |  ||    `* Re: Refutation of Peter Linz HP proof [ Logical Necessity ]Kaz Kylheku
 |      |     | |  ||     |  ||     `* Re: Refutation of Peter Linz HP proof [ divide by zero error returnsolcott
 |      |     | |  ||     |  ||      `* Re: Refutation of Peter Linz HP proof [ divide by zero errorKaz Kylheku
 |      |     | |  ||     |  ||       `- Re: Refutation of Peter Linz HP proof [ divide by zero error returnsolcott
 |      |     | |  ||     |  |+- Re: Refutation of Peter Linz HP proof [ Logical Necessity ]olcott
 |      |     | |  ||     |  |`* Re: Refutation of Peter Linz HP proof [ Recursion with TMs ]olcott
 |      |     | |  ||     |  | `* Re: Refutation of Peter Linz HP proof [ Recursion with TMs ]olcott
 |      |     | |  ||     |  |  `* Re: Refutation of Peter Linz HP proof [ Recursion with TMs ]olcott
 |      |     | |  ||     |  |   `- Re: Refutation of Peter Linz HP proof [ Recursion with TMs ]Mr Flibble
 |      |     | |  ||     |  `* Re: Refutation of Peter Linz HP proof [ Dishonest dodges ]olcott
 |      |     | |  ||     |   `- Re: Refutation of Peter Linz HP proof [ Dishonest dodges ]olcott
 |      |     | |  ||     `* Re: Renaming DebugTrace() to H or Halts[ Halts == Simulate ]olcott
 |      |     | |  ||      `* Re: Renaming DebugTrace() to H or Halts[ Halts == Simulate ]olcott
 |      |     | |  ||       `- Re: Renaming DebugTrace() to H or Halts[ Halts == Simulate ]olcott
 |      |     | |  |`- Re: Renaming DebugTrace() to H or Halts[ Effective Presentation ]olcott
 |      |     | |  +- Re: Renaming DebugTrace() to H or Halts[ Effective Presentation ]olcott
 |      |     | |  `- Re: Renaming DebugTrace() to H or Halts[ Effective Presentation ]olcott
 |      |     | `* Re: Happy Thanksgiving to all (logical necessity)(Numbskull?)olcott
 |      |     |  `* Re: Happy Thanksgiving to all (logical necessity)(Numbskull?)olcott
 |      |     |   +* Re: Both invocations of Confound_Halts() are decided consistentlyolcott
 |      |     |   |`- Re: Both invocations of Confound_Halts() are decided consistentlyolcott
 |      |     |   `- Re: Happy Thanksgiving to all (logical necessity)(Over Ben's head)olcott
 |      |     +* Re: Happy Thanksgiving to all (Ben is proven wrong by the actual facts)olcott
 |      |     +- Re: Happy Thanksgiving to all (Ben is proven wrong by the actualolcott
 |      |     `* Re: Happy Thanksgiving to all (Ben is proven wrong by the actual facts)olcott
 |      `* Re: Happy Thanksgiving to all (logical necessity)Jeff Barnett
 `* Re: Happy Thanksgiving to allKaz Kylheku

Pages:123456789101112131415161718
Subject: Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (deciders within infinite recursion)
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng
Date: Mon, 14 Dec 2020 21:42 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.snarked.org!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, 14 Dec 2020 15:42:39 -0600
Subject: Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (deciders within
infinite recursion)
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng
References: <3JSdnRrpiNHInV3CnZ2dnUU7-YHNnZ2d@giganews.com>
<EK-dnYNCHMf7UEnCnZ2dnUU7-UGdnZ2d@giganews.com> <rr2j08$4ur$1@dont-email.me>
<0KadnafWuKP6f0nCnZ2dnUU7-IPNnZ2d@giganews.com> <rr2oq2$ao3$1@dont-email.me>
<35OdnezHsPxac0nCnZ2dnUU7-YvNnZ2d@giganews.com> <rr2tlk$c32$1@dont-email.me>
<zp6dnf8CEZuHnUjCnZ2dnUU7-SfNnZ2d@giganews.com> <rr2vb1$mhs$1@dont-email.me>
<SrSdnbIYprUrnEjCnZ2dnUU7-U2dnZ2d@giganews.com> <rr30u4$2ba$1@dont-email.me>
<BcSdnZTygJfElkjCnZ2dnUU7-UednZ2d@giganews.com> <rr340r$l9i$1@dont-email.me>
<bo2dnRdK_KDeiEjCnZ2dnUU7-UnNnZ2d@giganews.com> <rr34ok$rof$1@dont-email.me>
<oaedncLQ-96MhEjCnZ2dnUU7-WnNnZ2d@giganews.com> <rr36c2$7dk$1@dont-email.me>
<-LCdnQjCJqk1vEjCnZ2dnUU7-eXNnZ2d@giganews.com> <rr39me$tev$1@dont-email.me>
<IdGdnS9EruNl6ErCnZ2dnUU7-QvNnZ2d@giganews.com> <rr7tvl$h7a$1@dont-email.me>
<DLCdnTdFDrYoHErCnZ2dnUU7-e3NnZ2d@giganews.com> <rr80h6$5t9$1@dont-email.me>
<ZeqdndRFYfJ9LkrCnZ2dnUU7-KnNnZ2d@giganews.com> <rr8fqc$hq$1@dont-email.me>
From: NoO...@NoWhere.com (olcott)
Date: Mon, 14 Dec 2020 15:42:33 -0600
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.5.1
MIME-Version: 1.0
In-Reply-To: <rr8fqc$hq$1@dont-email.me>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <b8udnRE6dKfSQUrCnZ2dnUU7-U3NnZ2d@giganews.com>
Lines: 43
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-mSB9J0y1mf8Tl38qYTll1VCNqhlmAaTsS39/D4Tfb3W7bTsSk0W2qy7IYSPf0YnkR6Vev2KTueX3id1!AI+rl9sn9ZtaQz9Lig1yEHb+s/f9u40Z/yZWzp7CMr4MbtPl4n8JeM2JLuoLKVLV8mNmoUGJI7iU
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: 3878
View all headers
On 12/14/2020 1:52 PM, André G. Isaak wrote:
On 2020-12-14 11:50, olcott wrote:
On 12/14/2020 9:31 AM, André G. Isaak wrote:
On 2020-12-14 08:16, olcott wrote:

Halts(H_Hat, H_Hat) is only a finite computation because it aborts the otherwise infinite recursion of its input according to this criteria:

And the Halts(H_Hat, H_Hat) called from within H_Hat should be a finite computation for the exact same reason. It has the exact same ability to abort its input as your outermost call to Halts() has.

If you were to run H_Hat(H_Hat) as an independent program, then it's call to Halts(H_Hat, H_Hat) would behave in exactly the same way as the call to Halts(H_Hat, H_Hat) described above.

In my halt deciding solution it is impossible to run anything as an independent program, everything is simulated so that nothing can be done behind the back of the halt decider.

Sort of like writing a program that predicts asteroid orbits but only allowing its predictions to be tested against your asteroid simulator so that reality can't do things behind the back of your predictor...

Yeah, that makes sense.

André



No it is more like writing an asteroid predictor from God's point of view.

Because it is well known common knowledge that the simulation of the Turing machine description of a Turing machine by a UTM is computationally equivalent to directly executing this TM my method is sound.

--
Copyright 2020 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre minds." Einstein


Subject: Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (deciders within
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.lang.asm.x86
Organization: A noiseless patient Spider
Date: Mon, 14 Dec 2020 21:56 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: NoO...@nospicedham.NoWhere.com (olcott)
Newsgroups: comp.theory,comp.ai.philosophy,comp.lang.asm.x86
Subject: Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (deciders within
Date: Mon, 14 Dec 2020 15:56:55 -0600
Organization: A noiseless patient Spider
Lines: 347
Approved: fbkotler@myfairpoint.net - comp.lang.asm.x86 moderation team.
Message-ID: <kcqdnSuH7702QkrCnZ2dnUU7-VvNnZ2d@giganews.com>
References: <3JSdnRrpiNHInV3CnZ2dnUU7-YHNnZ2d@giganews.com>
<rr2j08$4ur$1@dont-email.me> <0KadnafWuKP6f0nCnZ2dnUU7-IPNnZ2d@giganews.com>
<rr2oq2$ao3$1@dont-email.me> <35OdnezHsPxac0nCnZ2dnUU7-YvNnZ2d@giganews.com>
<rr2tlk$c32$1@dont-email.me> <zp6dnf8CEZuHnUjCnZ2dnUU7-SfNnZ2d@giganews.com>
<rr2vb1$mhs$1@dont-email.me> <SrSdnbIYprUrnEjCnZ2dnUU7-U2dnZ2d@giganews.com>
<rr30u4$2ba$1@dont-email.me> <BcSdnZTygJfElkjCnZ2dnUU7-UednZ2d@giganews.com>
<rr340r$l9i$1@dont-email.me> <bo2dnRdK_KDeiEjCnZ2dnUU7-UnNnZ2d@giganews.com>
<rr34ok$rof$1@dont-email.me> <oaedncLQ-96MhEjCnZ2dnUU7-WnNnZ2d@giganews.com>
<rr36c2$7dk$1@dont-email.me> <-LCdnQjCJqk1vEjCnZ2dnUU7-eXNnZ2d@giganews.com>
<rr39me$tev$1@dont-email.me> <IdGdnS9EruNl6ErCnZ2dnUU7-QvNnZ2d@giganews.com>
<rr7tvl$h7a$1@dont-email.me> <DLCdnTdFDrYoHErCnZ2dnUU7-e3NnZ2d@giganews.com>
<7fbe5f35-e17b-4964-888d-ef038a6a2126n@googlegroups.com>
<NuydnecrJuqQL0rCnZ2dnUU7-RHNnZ2d@giganews.com>
<20201214113311.509@kylheku.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: reader02.eternal-september.org; posting-host="7f19e0d1116082fd360d82ac1fedadb4";
logging-data="28288"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+G1G05Vd9k4rkQ5B6nAWyjY8bp83+m4qg="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.5.1
Cancel-Lock: sha1:TaFvV8RB28V3YgqOz97nFSADf6E=
View all headers
On 12/14/2020 2:02 PM, Kaz Kylheku wrote:
On 2020-12-14, olcott <NoOne@NoWhere.com> wrote:
On 12/14/2020 9:32 AM, Malcolm McLean wrote:
On Monday, 14 December 2020 at 15:16:13 UTC, olcott wrote:
On 12/14/2020 8:48 AM, André G. Isaak wrote:
On 2020-12-14 07:25, olcott wrote:
On 12/12/2020 2:37 PM, André G. Isaak wrote:
On 2020-12-12 13:01, olcott wrote:
On 12/12/2020 1:40 PM, André G. Isaak wrote:
On 2020-12-12 12:25, olcott wrote:
On 12/12/2020 1:13 PM, André G. Isaak wrote:
On 2020-12-12 12:08, olcott wrote:
On 12/12/2020 1:00 PM, André G. Isaak wrote:
On 2020-12-12 11:26, olcott wrote:
On 12/12/2020 12:08 PM, André G. Isaak wrote:
On 2020-12-12 10:45, olcott wrote:
On 12/12/2020 11:40 AM, André G. Isaak wrote:
On 2020-12-12 10:38, olcott wrote:
On 12/12/2020 11:12 AM, André G. Isaak wrote:
On 2020-12-12 09:24, olcott wrote:

<snip>

The outermost Halts() always returns a value to its
caller even though it must sometimes abort the
simulations of inner infinite invocations of itself.

And since it claims to be simulating those inner
instances and to abort those instances only in cases
where they would not otherwise halt, it is asserting that
there *are* inputs to Halts() which will not halt. Ergo,
it is asserting that Halts() is *not* a decider.

...in those cases where it does not halt and return a
value to its caller Halts() is not a decider. On those
invocations of Halts() where it does halt and return a
value to its caller it is a decider.

A program is either a decider or it isn't. There's no such
thing as a program which is sometimes a decider and
sometimes isn't.

André


You already know that is pure bullshit or the term "partial
decider" would not exist. What motive do you have for saying
things that you know are pure bullshit?

A partial decider is not a decider. More importantly, it is
not a "sometimes decider".

A partial decider makes a correct decision for a particular
class of inputs but may fail to halt for other inputs.


Your program sometimes halts and sometimes doesn't for the
*same* inputs. So you cannot even claim your program is a
partial decider, let alone an actual decider.

André


So in other words you "believe" against logic that some
infinitely recursive invocations <do> return a result to their
caller. That sounds nutty to me.

How you can possibly get that idea from what I wrote is utterly
beyond me.

I am saying that anything which has the possibility of getting
caught in infinite recursion cannot return a result and
therefore cannot constitute a decider.

André



Except in those cases that it has not been caught in infinite
recursion and does return a result to its caller.

Alternatively a function that can and does correctly detect
infinite recursion on itself and return its decision to its
caller does not count.

Basically you are saying that it is wrong all of the time even
though it is right some of the time.

No. I am saying that it is not a decider. A decider *must* return
a result for *all* inputs. That's the definition of 'decider'.
Something that only returns results in some instances is not a
decider. I don't know how I can make this any clearer...

André


The way that you are defining it when a function does correctly
decide that it has been infinitely invoked that even though this
decision is correct it does not count.

Since a partial decider <is> a decider for some inputs and not for
other inputs, then this same idea can be extended to some
invocations and not all invocations, otherwise correctly deciding
infinite recursion does not count even when the decision is correct.

A partial decider is not a decider any more than a half-dollar is a
dollar. A partial decider is something that correctly decides some
cases, not something which is a decider in some cases. Things are
either deciders or they aren't.

A partial decider that decides the {Linz, Sipser, Kozen}
counter-examples refutes these three proofs.

That a program correctly decides some cases does not make it a
decider in those cases. You could call it a partial decider, but
not a decider.

However, in the case of your program, you can't even call it that
because it sometimes returns and other times does not return *on
the same input*. A partial decider is something which decides some
set of inputs and fails to decide another, *disjoint* set of
inputs. Something which gets different results for the same input
isn't even a function, let alone a decider or partial decider.

André


So in other words when a partial decider correctly determines that
it has been invoked in infinite recursion it must fix the bug in
this infinitely recursive invocation so that it can report its
infinitely recursive invocation to its infinitely recursive caller,
that is no longer infinitely recursive because it fixed this bug.

<sarcasm>
That makes perfect sense to me.
</sarcasm>

No, I did not say that. You need to make at least some effort to read
for comprehension. I said that something which can be caught in
infinite recursion is *not* a decider. This is getting rather
tedious. Something that correctly decides some cases but not others
could be a partial decider, but not if it decides the *same* input in
some cases but not others.


01 void H_Hat(u32 P)
02 {
03 u32 Input_Halts = DebugTrace(P, P);
04 if (Input_Halts)
05 HERE: goto HERE;
06 else
07 HALT
08 }

Halts((u32)H_Hat,(u32)H_Hat) is correctly decided** as not halting
because it aborts the invocation of itself on line 03.

You've switched back from using Halts() to using DebugTrace(). Are these
intended to be distinct functions?

** Halts returns the correct halting determination.

According to your way of defining a decider:
(a) Halts is not a decider even though it correctly decides.
(b) Halts would be a decider if it aborted the infinite recursion of
any other function besides itself.

That is ridiculous!
Look, a decider is a type of *function*. To be a function, something
must consistently map the same input to the same result, but that isn't
what you get above. Assuming that your DebugTrace() and Halts() are
intended to be the same, you are claiming that

Halts(H_Hat, H_Hat)

returns false. This means Halts(H_Hat, H_Hat) is a finite computation.

But by returning false is is also claiming that the instance of
Halts(H_Hat, H_Hat) invoked from within H_Hat must be aborted as a
non-halting function.

This is a contradiction.
As I have said very many times (no one notices because they only glance
at a few of my words to contrive some lame basis for a rebuttal that
would fool the gullible):

Halts(H_Hat, H_Hat) is only a finite computation because it aborts the
otherwise infinite recursion of its input according to this criteria:

On 11/27/2020 9:02 PM, Ben Bacarisse wrote:
A computation that would not halt if its simulation were not
halted is indeed a non-halting computation.

If Halts aborts itself, is it halted or aborted? That's the question.


Halts() simulates H_Hat() that invokes Halts() in infinite recursion.
Halts() stops simulating H_Hat() including its infinite recursive
invocation of Halts(), returning its non-halting decision to main()
where it is output.

If we say "halted" then H_Hat inverts whatever result it returns,

It is not possible for an aborted function to invert any damn thing.

and :Halts" is wrong. If we say "aborted" then "Halts" isn't a function,
which is a slightly more subtle requirement of H_Hat.

Certainly an at least partial halt decider that bases its halting
decision by looking for patterns of behavior of its inputs can stop
simulating this input as soon as it detects any non-halting pattern.

It does not make any damn difference if it detects an infinite loop, or
infinite recursion. It also does not make any damn difference which
function is involved in infinite recursion. As long as Halts() detects
the non-halting behavior of its input then it can stop simulating this
input and report non-halting.

void H_Hat(u32 P)
{
    u32 Input_Halts = Halts(P, P);
    if (Input_Halts)
      HERE: goto HERE;
    else
      HALT
}


int main()
{
    u32 Input_Would_Halt = Halts((u32)H_Hat, (u32)H_Hat);
    Output("[Input_Would_Halt] =", Input_Would_Halt);
    HALT;
}

I finally renamed my internal DebugTrace() to Halts() now that it
finally does return its correct halting decision to main().

Your techique is suspicious, because you're transcribing the pseudo-code
from the usual halting proofs into the higher level C language, but then
are messing with the execution at a lower level. The mapping between the
C language and abstract concepts like "pure function of certain
arguments" only depends on certain conventions being upheld in the
machine language translation, and the expected execution model for which
the translation is made.


At the TM level is is merely the execution of a TM on a finite string, in this case the TM a a halt decider based on a UTM.

It is not the details of the C/x86 implementation that are important it is whether or not the architecture of the C/x86 implementation maps to a TM solution.

Click here to read the complete article
Subject: Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (deciders within infinite recursion)
From: Chris M. Thomasson
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng
Organization: Aioe.org NNTP Server
Date: Mon, 14 Dec 2020 23:37 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
Path: i2pn2.org!i2pn.org!aioe.org!NBiuIU74OKL7NpIOsbuNjQ.user.gioia.aioe.org.POSTED!not-for-mail
From: chris.m....@gmail.com (Chris M. Thomasson)
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng
Subject: Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (deciders within
infinite recursion)
Date: Mon, 14 Dec 2020 15:37:35 -0800
Organization: Aioe.org NNTP Server
Lines: 211
Message-ID: <rr8svu$3v5$1@gioia.aioe.org>
References: <3JSdnRrpiNHInV3CnZ2dnUU7-YHNnZ2d@giganews.com>
<rr2i8o$tee$1@dont-email.me> <EK-dnYNCHMf7UEnCnZ2dnUU7-UGdnZ2d@giganews.com>
<rr2j08$4ur$1@dont-email.me> <0KadnafWuKP6f0nCnZ2dnUU7-IPNnZ2d@giganews.com>
<rr2oq2$ao3$1@dont-email.me> <35OdnezHsPxac0nCnZ2dnUU7-YvNnZ2d@giganews.com>
<rr2tlk$c32$1@dont-email.me> <zp6dnf8CEZuHnUjCnZ2dnUU7-SfNnZ2d@giganews.com>
<rr2vb1$mhs$1@dont-email.me> <SrSdnbIYprUrnEjCnZ2dnUU7-U2dnZ2d@giganews.com>
<rr30u4$2ba$1@dont-email.me> <BcSdnZTygJfElkjCnZ2dnUU7-UednZ2d@giganews.com>
<rr340r$l9i$1@dont-email.me> <bo2dnRdK_KDeiEjCnZ2dnUU7-UnNnZ2d@giganews.com>
<rr34ok$rof$1@dont-email.me> <oaedncLQ-96MhEjCnZ2dnUU7-WnNnZ2d@giganews.com>
<rr36c2$7dk$1@dont-email.me> <-LCdnQjCJqk1vEjCnZ2dnUU7-eXNnZ2d@giganews.com>
<rr39me$tev$1@dont-email.me> <IdGdnS9EruNl6ErCnZ2dnUU7-QvNnZ2d@giganews.com>
<rr7tvl$h7a$1@dont-email.me> <DLCdnTdFDrYoHErCnZ2dnUU7-e3NnZ2d@giganews.com>
<rr80h6$5t9$1@dont-email.me> <ZeqdndRFYfJ9LkrCnZ2dnUU7-KnNnZ2d@giganews.com>
NNTP-Posting-Host: NBiuIU74OKL7NpIOsbuNjQ.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Complaints-To: abuse@aioe.org
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.5.1
Content-Language: en-US
X-Notice: Filtered by postfilter v. 0.9.2
View all headers
On 12/14/2020 10:50 AM, olcott wrote:
On 12/14/2020 9:31 AM, André G. Isaak wrote:
On 2020-12-14 08:16, olcott wrote:
On 12/14/2020 8:48 AM, André G. Isaak wrote:
On 2020-12-14 07:25, olcott wrote:
On 12/12/2020 2:37 PM, André G. Isaak wrote:
On 2020-12-12 13:01, olcott wrote:
On 12/12/2020 1:40 PM, André G. Isaak wrote:
On 2020-12-12 12:25, olcott wrote:
On 12/12/2020 1:13 PM, André G. Isaak wrote:
On 2020-12-12 12:08, olcott wrote:
On 12/12/2020 1:00 PM, André G. Isaak wrote:
On 2020-12-12 11:26, olcott wrote:
On 12/12/2020 12:08 PM, André G. Isaak wrote:
On 2020-12-12 10:45, olcott wrote:
On 12/12/2020 11:40 AM, André G. Isaak wrote:
On 2020-12-12 10:38, olcott wrote:
On 12/12/2020 11:12 AM, André G. Isaak wrote:
On 2020-12-12 09:24, olcott wrote:

<snip>

The outermost Halts() always returns a value to its caller even though it must sometimes abort the simulations of inner infinite invocations of itself.

And since it claims to be simulating those inner instances and to abort those instances only in cases where they would not otherwise halt, it is asserting that there *are* inputs to Halts() which will not halt. Ergo, it is asserting that Halts() is *not* a decider.

...in those cases where it does not halt and return a value to its caller Halts() is not a decider. On those invocations of Halts() where it does halt and return a value to its caller it is a decider.

A program is either a decider or it isn't. There's no such thing as a program which is sometimes a decider and sometimes isn't.

André


You already know that is pure bullshit or the term "partial decider" would not exist. What motive do you have for saying things that you know are pure bullshit?

A partial decider is not a decider. More importantly, it is not a "sometimes decider".

A partial decider makes a correct decision for a particular class of inputs but may fail to halt for other inputs.


Your program sometimes halts and sometimes doesn't for the *same* inputs. So you cannot even claim your program is a partial decider, let alone an actual decider.

André


So in other words you "believe" against logic that some infinitely recursive invocations <do> return a result to their caller. That sounds nutty to me.

How you can possibly get that idea from what I wrote is utterly beyond me.

I am saying that anything which has the possibility of getting caught in infinite recursion cannot return a result and therefore cannot constitute a decider.

André



Except in those cases that it has not been caught in infinite recursion and does return a result to its caller.

Alternatively a function that can and does correctly detect infinite recursion on itself and return its decision to its caller does not count.

Basically you are saying that it is wrong all of the time even though it is right some of the time.

No. I am saying that it is not a decider. A decider *must* return a result for *all* inputs. That's the definition of 'decider'. Something that only returns results in some instances is not a decider. I don't know how I can make this any clearer...

André


The way that you are defining it when a function does correctly decide that it has been infinitely invoked that even though this decision is correct it does not count.

Since a partial decider <is> a decider for some inputs and not for other inputs, then this same idea can be extended to some invocations and not all invocations, otherwise correctly deciding infinite recursion does not count even when the decision is correct.

A partial decider is not a decider any more than a half-dollar is a dollar. A partial decider is something that correctly decides some cases, not something which is a decider in some cases. Things are either deciders or they aren't.

A partial decider that decides the {Linz, Sipser, Kozen} counter-examples refutes these three proofs.

That a program correctly decides some cases does not make it a decider in those cases. You could call it a partial decider, but not a decider.

However, in the case of your program, you can't even call it that because it sometimes returns and other times does not return *on the same input*. A partial decider is something which decides some set of inputs and fails to decide another, *disjoint* set of inputs. Something which gets different results for the same input isn't even a function, let alone a decider or partial decider.

André


So in other words when a partial decider correctly determines that it has been invoked in infinite recursion it must fix the bug in this infinitely recursive invocation so that it can report its infinitely recursive invocation to its infinitely recursive caller, that is no longer infinitely recursive because it fixed this bug.

<sarcasm>
That makes perfect sense to me.
</sarcasm>

No, I did not say that. You need to make at least some effort to read for comprehension. I said that something which can be caught in infinite recursion is *not* a decider. This is getting rather tedious. Something that correctly decides some cases but not others could be a partial decider, but not if it decides the *same* input in some cases but not others.


01 void H_Hat(u32 P)
02 {
03   u32 Input_Halts = DebugTrace(P, P);
04   if (Input_Halts)
05     HERE: goto HERE;
06   else
07     HALT
08 }

Halts((u32)H_Hat,(u32)H_Hat) is correctly decided** as not halting because it aborts the invocation of itself on line 03.

You've switched back from using Halts() to using DebugTrace(). Are these intended to be distinct functions?

** Halts returns the correct halting determination.

According to your way of defining a decider:
(a) Halts is not a decider even though it correctly decides.
(b) Halts would be a decider if it aborted the infinite recursion of any other function besides itself.

That is ridiculous!
Look, a decider is a type of *function*. To be a function, something must consistently map the same input to the same result, but that isn't what you get above. Assuming that your DebugTrace() and Halts() are intended to be the same, you are claiming that

Halts(H_Hat, H_Hat)

returns false. This means Halts(H_Hat, H_Hat) is a finite computation.

But by returning false is is also claiming that the instance of Halts(H_Hat, H_Hat) invoked from within H_Hat must be aborted as a non-halting function.

This is a contradiction.

As I have said very many times (no one notices because they only glance at a few of my words to contrive some lame basis for a rebuttal that would fool the gullible):

Halts(H_Hat, H_Hat) is only a finite computation because it aborts the otherwise infinite recursion of its input according to this criteria:

And the Halts(H_Hat, H_Hat) called from within H_Hat should be a finite computation for the exact same reason. It has the exact same ability to abort its input as your outermost call to Halts() has.

If you were to run H_Hat(H_Hat) as an independent program, then it's call to Halts(H_Hat, H_Hat) would behave in exactly the same way as the call to Halts(H_Hat, H_Hat) described above.

In my halt deciding solution it is impossible to run anything as an independent program, everything is simulated so that nothing can be done behind the back of the halt decider.



So, I guess a TRNG is out of the question? lol.


Subject: Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (deciders within infinite recursion)
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng
Date: Tue, 15 Dec 2020 14:28 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.snarked.org!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Tue, 15 Dec 2020 08:28:48 -0600
Subject: Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (deciders within
infinite recursion)
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng
References: <3JSdnRrpiNHInV3CnZ2dnUU7-YHNnZ2d@giganews.com>
<35OdnezHsPxac0nCnZ2dnUU7-YvNnZ2d@giganews.com> <rr2tlk$c32$1@dont-email.me>
<zp6dnf8CEZuHnUjCnZ2dnUU7-SfNnZ2d@giganews.com> <rr2vb1$mhs$1@dont-email.me>
<SrSdnbIYprUrnEjCnZ2dnUU7-U2dnZ2d@giganews.com> <rr30u4$2ba$1@dont-email.me>
<BcSdnZTygJfElkjCnZ2dnUU7-UednZ2d@giganews.com> <rr340r$l9i$1@dont-email.me>
<bo2dnRdK_KDeiEjCnZ2dnUU7-UnNnZ2d@giganews.com> <rr34ok$rof$1@dont-email.me>
<oaedncLQ-96MhEjCnZ2dnUU7-WnNnZ2d@giganews.com> <rr36c2$7dk$1@dont-email.me>
<-LCdnQjCJqk1vEjCnZ2dnUU7-eXNnZ2d@giganews.com> <rr39me$tev$1@dont-email.me>
<IdGdnS9EruNl6ErCnZ2dnUU7-QvNnZ2d@giganews.com> <rr7tvl$h7a$1@dont-email.me>
<DLCdnTdFDrYoHErCnZ2dnUU7-e3NnZ2d@giganews.com> <rr80h6$5t9$1@dont-email.me>
<ZeqdndRFYfJ9LkrCnZ2dnUU7-KnNnZ2d@giganews.com> <rr8fqc$hq$1@dont-email.me>
<b8udnRE6dKfSQUrCnZ2dnUU7-U3NnZ2d@giganews.com> <rr8oug$1sm$1@dont-email.me>
<2tCdnYpd5begcErCnZ2dnUU7-cXNnZ2d@giganews.com> <rr9mqp$1h5$1@dont-email.me>
From: NoO...@NoWhere.com (olcott)
Date: Tue, 15 Dec 2020 08:28:43 -0600
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.5.1
MIME-Version: 1.0
In-Reply-To: <rr9mqp$1h5$1@dont-email.me>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <3dadnQwwG--9VUXCnZ2dnUU7-U_NnZ2d@giganews.com>
Lines: 80
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-iir0/bE+1H9ZyvGiLQnMeFwMMI4BjqhRlY7I66bEo/3jhKyCHB8+IK1MWkEzI9jiq9Z9I7LkuOYB+wo!vVMSme2G4UnV1FDdzasq23q5jNvWq8N8zCjyvCEIKxp5vROfrfj9dZHaez8xtCI2ZIUqYPvIjDrd
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: 5357
View all headers
On 12/15/2020 12:58 AM, André G. Isaak wrote:
On 2020-12-14 15:54, olcott wrote:
On 12/14/2020 4:28 PM, André G. Isaak wrote:
On 2020-12-14 14:42, olcott wrote:
On 12/14/2020 1:52 PM, André G. Isaak wrote:
On 2020-12-14 11:50, olcott wrote:
On 12/14/2020 9:31 AM, André G. Isaak wrote:
On 2020-12-14 08:16, olcott wrote:

Halts(H_Hat, H_Hat) is only a finite computation because it aborts the otherwise infinite recursion of its input according to this criteria:

And the Halts(H_Hat, H_Hat) called from within H_Hat should be a finite computation for the exact same reason. It has the exact same ability to abort its input as your outermost call to Halts() has.

If you were to run H_Hat(H_Hat) as an independent program, then it's call to Halts(H_Hat, H_Hat) would behave in exactly the same way as the call to Halts(H_Hat, H_Hat) described above.

In my halt deciding solution it is impossible to run anything as an independent program, everything is simulated so that nothing can be done behind the back of the halt decider.

Sort of like writing a program that predicts asteroid orbits but only allowing its predictions to be tested against your asteroid simulator so that reality can't do things behind the back of your predictor...

Yeah, that makes sense.

André



No it is more like writing an asteroid predictor from God's point of view.

I have no idea what it means for a halt decider (or asteroid predictor) to be written from 'God's point of view'.

Because it is well known common knowledge that the simulation of the Turing machine description of a Turing machine by a UTM is computationally equivalent to directly executing this TM

If simulating a TM in a UTM is computationally equivalent to directly executing a TM, then why insist on not allowing that direct execution?


The halt decider is inherently a simulator any code that it does not simulate is code that it cannot examine.

When we're testing the behaviour of the input as an independent computation, we're not *running* the halt decider. It isn't expected to examine anything in such cases.

André


I can't understand what you are saying. It seems like you are saying the a halt decider is not a halt decider, a thing is not itself.

This is the halt deciding principle:

On 11/27/2020 9:02 PM, Ben Bacarisse wrote:
 > A computation that would not halt if its simulation were not
 > halted is indeed a non-halting computation.

On Saturday, November 28, 2020 at 2:00:28 PM UTC-8, olcott wrote:
 > Every computation that would not halt if its simulation
 > were not halted is by logical necessity a non-halting computation.


--
Copyright 2020 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre minds." Einstein


Subject: Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (Halts() as an exception handler)
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng
Date: Tue, 15 Dec 2020 14:50 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!tr2.eu1.usenetexpress.com!feeder.usenetexpress.com!tr3.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Tue, 15 Dec 2020 08:50:37 -0600
Subject: Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (Halts() as an exception handler)
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng
References: <3JSdnRrpiNHInV3CnZ2dnUU7-YHNnZ2d@giganews.com> <rr2vb1$mhs$1@dont-email.me> <SrSdnbIYprUrnEjCnZ2dnUU7-U2dnZ2d@giganews.com> <rr30u4$2ba$1@dont-email.me> <BcSdnZTygJfElkjCnZ2dnUU7-UednZ2d@giganews.com> <rr340r$l9i$1@dont-email.me> <bo2dnRdK_KDeiEjCnZ2dnUU7-UnNnZ2d@giganews.com> <rr34ok$rof$1@dont-email.me> <oaedncLQ-96MhEjCnZ2dnUU7-WnNnZ2d@giganews.com> <rr36c2$7dk$1@dont-email.me> <-LCdnQjCJqk1vEjCnZ2dnUU7-eXNnZ2d@giganews.com> <rr39me$tev$1@dont-email.me> <IdGdnS9EruNl6ErCnZ2dnUU7-QvNnZ2d@giganews.com> <rr7tvl$h7a$1@dont-email.me> <DLCdnTdFDrYoHErCnZ2dnUU7-e3NnZ2d@giganews.com> <rr80h6$5t9$1@dont-email.me> <ZeqdndRFYfJ9LkrCnZ2dnUU7-KnNnZ2d@giganews.com> <rr8fqc$hq$1@dont-email.me> <b8udnRE6dKfSQUrCnZ2dnUU7-U3NnZ2d@giganews.com> <rr8oug$1sm$1@dont-email.me> <2tCdnYpd5begcErCnZ2dnUU7-cXNnZ2d@giganews.com> <KuTBH.3626$al2.1863@fx12.iad> <20201214163728.475@kylheku.com> <keadna-gk_oJj0XCnZ2dnUU7-UXNnZ2d@giganews.com> <20201215012611.762@kylheku.com>
From: NoO...@NoWhere.com (olcott)
Date: Tue, 15 Dec 2020 08:50:32 -0600
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1
MIME-Version: 1.0
In-Reply-To: <20201215012611.762@kylheku.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Message-ID: <q-adnV-qP4qgUEXCnZ2dnUU7-a_NnZ2d@giganews.com>
Lines: 66
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-kNsClM2eF1gpHLHyrZavZf7kKSJbgZCPQPQDAoy39rU4p4w+0H2WYbxtCGa6GQEmMM7KOgJbTw2LWwG!li1yF68qGs5RGZawrTAAS4cGVIyCJukGyRkW7FOQdNRlM0svcH1gm7lmmT5qVWhWhwkaUXZN2dUp
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: 4871
View all headers
On 12/15/2020 3:36 AM, Kaz Kylheku wrote:
On 2020-12-15, olcott <NoOne@NoWhere.com> wrote:
I have explained the difference between these two computations many times:

That's nice; you're not responding to the content of any of my points.

int main()
{
    Halts((u32)H_Hat, (u32)H_Hat);
    H_Hat((u32)H_Hat);
}

1. Those are not the two I'm talking about, but since our particular
H_Hat((u32)H_Hat) immediately calls Halts((u32)H_Hat, (u32)H_Hat), how
can there be a legitimate difference between those two?


The calls to Halts() are out-of-sync with each other.

2. I'm talking about both main() and H_Hat both making a call to
Halts((u32)H_Hat, (u32)H_Hat). One returns, producing a value which
indicates that the ... other one doesn't return? What?

How can exactly the same procedure both return and not return, unless it
isn't a pure function, or else not a function of just those arguments
that are apparent in the higher level language?


Global Halts() can return to the caller or it can return to the operating system in the same way that the "divide by zero" exception handler can catch an exception in the program or be caught by the operating system.

Whenever the infinite execution is first invoked by Halts() it can return a value that can be reported. This is like an exception handler catching a divide by zero error.

Whenever the infinite execution is NOT first invoked by Halts() this is exactly the same as an uncaught divide by zero error and reported by the operating system.

Expecting the infinitely recursive invocation of Halts() to return a value to H_Hat() is exactly the same as expecting a numeric value to be assigned to X in this computation: int X = 5 / 0;

It seems that people simply don't want to understand.

The difference between these two computations is the last gasp excuse
that people can use to posit that I may be incorrect.

If you want to prove things by hacking, you have to be prepared for
such at thing showing you wrong.  I'm surprised you wouldn't be prepared
for that, as a long-time programmer. You know, one flipped bit brings
down the show, and all that.  Likewise, in logic, one flawed step in a
chain of inferences, and the argument is toast.


The closest that anyone has "proved that I am wrong" on my halt decider is proving that they either don't understand what I am saying or they don't understand the subject matter.

--
Copyright 2020 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre minds." Einstein


Subject: Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (deciders within infinite recursion)
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng
Date: Tue, 15 Dec 2020 15:21 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!tr2.eu1.usenetexpress.com!feeder.usenetexpress.com!tr2.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Tue, 15 Dec 2020 09:21:40 -0600
Subject: Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (deciders within infinite recursion)
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng
References: <3JSdnRrpiNHInV3CnZ2dnUU7-YHNnZ2d@giganews.com> <zp6dnf8CEZuHnUjCnZ2dnUU7-SfNnZ2d@giganews.com> <rr2vb1$mhs$1@dont-email.me> <SrSdnbIYprUrnEjCnZ2dnUU7-U2dnZ2d@giganews.com> <rr30u4$2ba$1@dont-email.me> <BcSdnZTygJfElkjCnZ2dnUU7-UednZ2d@giganews.com> <rr340r$l9i$1@dont-email.me> <bo2dnRdK_KDeiEjCnZ2dnUU7-UnNnZ2d@giganews.com> <rr34ok$rof$1@dont-email.me> <oaedncLQ-96MhEjCnZ2dnUU7-WnNnZ2d@giganews.com> <rr36c2$7dk$1@dont-email.me> <-LCdnQjCJqk1vEjCnZ2dnUU7-eXNnZ2d@giganews.com> <rr39me$tev$1@dont-email.me> <IdGdnS9EruNl6ErCnZ2dnUU7-QvNnZ2d@giganews.com> <rr7tvl$h7a$1@dont-email.me> <DLCdnTdFDrYoHErCnZ2dnUU7-e3NnZ2d@giganews.com> <rr80h6$5t9$1@dont-email.me> <ZeqdndRFYfJ9LkrCnZ2dnUU7-KnNnZ2d@giganews.com> <rr8fqc$hq$1@dont-email.me> <b8udnRE6dKfSQUrCnZ2dnUU7-U3NnZ2d@giganews.com> <rr8oug$1sm$1@dont-email.me> <2tCdnYpd5begcErCnZ2dnUU7-cXNnZ2d@giganews.com> <rr9mqp$1h5$1@dont-email.me> <3dadnQwwG--9VUXCnZ2dnUU7-U_NnZ2d@giganews.com> <rrajkc$551$1@dont-email.me>
From: NoO...@NoWhere.com (olcott)
Date: Tue, 15 Dec 2020 09:21:35 -0600
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1
MIME-Version: 1.0
In-Reply-To: <rrajkc$551$1@dont-email.me>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <X5ydnW03xcIZSUXCnZ2dnUU7-KXNnZ2d@giganews.com>
Lines: 84
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-sTSszQ3GKGDS63jMD0vFgiyv5r5R0VugkzenfN5DuPTF+govVBCmPrIfJCulwJvKy+NGUBoZyIBzLS2!zpHb/uCllXMxoiGVPg6XX38GncRCc6lXwGhj/Q3w/xORew9Aj6ypuDWi350VNW+vOFRTkeyp8KRU
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: 5754
View all headers
On 12/15/2020 9:10 AM, André G. Isaak wrote:
On 2020-12-15 07:28, olcott wrote:
On 12/15/2020 12:58 AM, André G. Isaak wrote:
On 2020-12-14 15:54, olcott wrote:
On 12/14/2020 4:28 PM, André G. Isaak wrote:
On 2020-12-14 14:42, olcott wrote:
On 12/14/2020 1:52 PM, André G. Isaak wrote:
On 2020-12-14 11:50, olcott wrote:
On 12/14/2020 9:31 AM, André G. Isaak wrote:
On 2020-12-14 08:16, olcott wrote:

Halts(H_Hat, H_Hat) is only a finite computation because it aborts the otherwise infinite recursion of its input according to this criteria:

And the Halts(H_Hat, H_Hat) called from within H_Hat should be a finite computation for the exact same reason. It has the exact same ability to abort its input as your outermost call to Halts() has.

If you were to run H_Hat(H_Hat) as an independent program, then it's call to Halts(H_Hat, H_Hat) would behave in exactly the same way as the call to Halts(H_Hat, H_Hat) described above.

In my halt deciding solution it is impossible to run anything as an independent program, everything is simulated so that nothing can be done behind the back of the halt decider.

Sort of like writing a program that predicts asteroid orbits but only allowing its predictions to be tested against your asteroid simulator so that reality can't do things behind the back of your predictor...

Yeah, that makes sense.

André



No it is more like writing an asteroid predictor from God's point of view.

I have no idea what it means for a halt decider (or asteroid predictor) to be written from 'God's point of view'.

Because it is well known common knowledge that the simulation of the Turing machine description of a Turing machine by a UTM is computationally equivalent to directly executing this TM

If simulating a TM in a UTM is computationally equivalent to directly executing a TM, then why insist on not allowing that direct execution?


The halt decider is inherently a simulator any code that it does not simulate is code that it cannot examine.

When we're testing the behaviour of the input as an independent computation, we're not *running* the halt decider. It isn't expected to examine anything in such cases.

André


I can't understand what you are saying. It seems like you are saying the a halt decider is not a halt decider, a thing is not itself.

Above, I stated that the the behaviour of a program X *when run independently* is the metric against which the claims of the halt decider are to be evaluated.

Ah so you prove that you are ignorant of the common knowledge that the simulation of the Turing machine description of a TM by a UTM is equivalent to the direct execution of this TM.

Furthermore a UTM that examines the behavior of the machine that it is simulating is still a UTM. We might as well stop here until you understand these two key points because they are necessary prerequisites.

--
Copyright 2020 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre minds." Einstein


Subject: Re: Refuting the {Linz, Sipser, Kozen} HP Proofs
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng
Date: Tue, 15 Dec 2020 16:09 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.snarked.org!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Tue, 15 Dec 2020 10:10:03 -0600
Subject: Re: Refuting the {Linz, Sipser, Kozen} HP Proofs
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng
References: <3JSdnRrpiNHInV3CnZ2dnUU7-YHNnZ2d@giganews.com>
<neRxH.214851$2j.16728@fx38.iad>
<DZudnfRm5ZaoelrCnZ2dnUU7-W_NnZ2d@giganews.com>
<HxSxH.34144$Oa.28187@fx16.iad>
<ZMOdncRH0J-RZVrCnZ2dnUU7-TudnZ2d@giganews.com>
<20201202130444.97@kylheku.com>
<4ISdnZjauficjlXCnZ2dnUU7-X3NnZ2d@giganews.com>
<20201202170501.883@kylheku.com> <rqbjrt$1s4o$1@gioia.aioe.org>
<20201207211640.ab3cf977e95bac160b406d58@gmail.com>
<87lfe9mat5.fsf@bsb.me.uk>
<20201209144312.3fa9e12d9eb9f6e65a6bf909@gmail.com>
<20201209144609.d72f65772754e159081986d3@gmail.com>
<rqqg0h$jn8$1@dont-email.me>
<cadb3cac-1359-4e7d-ad13-611e6c65199en@googlegroups.com>
<XPadnV3i4dHqeE3CnZ2dnUU7-VWdnZ2d@giganews.com>
<1702717b-0369-4388-99c5-765f9fedc54en@googlegroups.com>
<87o8j3djj9.fsf@bsb.me.uk> <8OGdnawuHrSQPEzCnZ2dnUU7-bXNnZ2d@giganews.com>
<87ft4a8vdr.fsf@bsb.me.uk> <oPOdnaQ4DramzkjCnZ2dnUU7-bmdnZ2d@giganews.com>
<87v9d57srg.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Tue, 15 Dec 2020 10:09:58 -0600
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.5.1
MIME-Version: 1.0
In-Reply-To: <87v9d57srg.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Message-ID: <yK2dnXzXs69GQkXCnZ2dnUU7-dvNnZ2d@giganews.com>
Lines: 115
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-qIKbgqt3XYj2DJQAFSHWMbryoO6PxlZKAZkknSXEjHAG7q7arMAbR0lN3l3Wqam42wkhY4cG6h9ENW8!bXszxwJlqmhWPgqG8uwZg9iz823ypcM5tRi2PPWWYy6XVMvzqv913cf6Qq5FCfHC5T0SdrwcRUUw
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: 6335
View all headers
On 12/13/2020 7:14 AM, Ben Bacarisse wrote:
Code for contex:

bool Halts(u32 P, u32 I)
{
   bool Halted  = false;
   bool Aborted = false;
   while (!Halted && !Aborted)
   {
     Halted  = DebugStep(P, I);
     Aborted = Needs_To_Be_Aborted();
   }
   return !Aborted;

void Confound_Halts(u32 P) { if (Halts(P, P)) while (1); }

olcott <NoOne@NoWhere.com> writes:

On 12/12/2020 5:20 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
<cut>
int main()
{
    HERE: goto HERE;
    Confound_Halts((u32)Confound_Halts);
    Halts((u32)Confound_Halts, (u32)Confound_Halts);
}

I did not write this.  You should make that clear when writing
attributions.

  From the perspective of this master UTM all three lines of main()
specify infinite execution.

As far as my original point is  concerned you have already said that Halts
does not meet the challenge.  You've agreed that

(a) Halts(Confound_Halts, Confound_Halts) is false, and
(b) Confound_Halts(Confound_Halts) is a finite computation.

(b) Confound_Halts(Confound_Halts) IS NOT A FINITE COMPUTATION

I am aware that you have said both.  What you have not done is retract
what you said before*, namely that the input to halts is a finite
computation.  You can't expect to get away with saying both, you need to
say that you were wrong before.

And you appear to be also saying that you were also wrong to state that
Halts(Confound_Halts, Confound_Halts) returns false**.  In fact, you
appear to be saying now that that call does not return at all.


As I have always said
 >>> (a) Halts(Confound_Halts, Confound_Halts) is false,
returns false according to this criteria:

On 11/27/2020 9:02 PM, Ben Bacarisse wrote:
 > A computation that would not halt if its simulation were not
 > halted is indeed a non-halting computation.

On Saturday, November 28, 2020 at 2:00:28 PM UTC-8, olcott wrote:
 > Every computation that would not halt if its simulation
 > were not halted is by logical necessity a non-halting computation.

 >>> (b) Confound_Halts(Confound_Halts) is a finite computation.

The infinitely recursive invocation of Halts() by Confound_Halts() never returns anything to Confound_Halts() because infinitely recursive invocations never ever return.

If I ever said that either of these are finite computations I was incorrect, they are both unequivocal examples of infinite recursion.

int main()
{
   Confound_Halts(Confound_Halts);
}

int main()
{
   H_Hat(H_Hat);
}

Output_Debug_Trace() Trace_List.size(19)
---[00000661](01)  55                  push ebp
---[00000662](02)  8bec                mov ebp,esp
---[00000664](05)  6801060000          push 00000601
---[00000669](05)  e893ffffff          call 00000601   --CALL [00000601]
---[00000601](01)  55                  push ebp
---[00000602](02)  8bec                mov ebp,esp
---[00000604](01)  51                  push ecx
---[00000605](03)  8b4508              mov eax,[ebp+08]
---[00000608](01)  50                  push eax
---[00000609](03)  8b4d08              mov ecx,[ebp+08]
---[0000060c](01)  51                  push ecx
---[0000060d](05)  e8effdffff          call 00000401   --CALL [00000401]
---[00000601](01)  55                  push ebp
---[00000602](02)  8bec                mov ebp,esp
---[00000604](01)  51                  push ecx
---[00000605](03)  8b4508              mov eax,[ebp+08]
---[00000608](01)  50                  push eax
---[00000609](03)  8b4d08              mov ecx,[ebp+08]
---[0000060c](01)  51                  push ecx
---[0000060d](05)  e8effdffff          call 00000401   --CALL [00000401]
The PRIOR Instruction Specifies Infinite Recursion: Simulation Stopped:

In both of the above cases global Halts() terminates the execution of the above functions in the same way that an uncaught "divide by zero" error would be reported by the operating system.

--
Copyright 2020 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre minds." Einstein


Subject: Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (deciders within infinite recursion)
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng
Date: Tue, 15 Dec 2020 16:28 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!news.uzoreto.com!feeder1.feed.usenet.farm!feed.usenet.farm!feeder.usenetexpress.com!tr2.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Tue, 15 Dec 2020 10:28:56 -0600
Subject: Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (deciders within infinite recursion)
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng
References: <3JSdnRrpiNHInV3CnZ2dnUU7-YHNnZ2d@giganews.com> <SrSdnbIYprUrnEjCnZ2dnUU7-U2dnZ2d@giganews.com> <rr30u4$2ba$1@dont-email.me> <BcSdnZTygJfElkjCnZ2dnUU7-UednZ2d@giganews.com> <rr340r$l9i$1@dont-email.me> <bo2dnRdK_KDeiEjCnZ2dnUU7-UnNnZ2d@giganews.com> <rr34ok$rof$1@dont-email.me> <oaedncLQ-96MhEjCnZ2dnUU7-WnNnZ2d@giganews.com> <rr36c2$7dk$1@dont-email.me> <-LCdnQjCJqk1vEjCnZ2dnUU7-eXNnZ2d@giganews.com> <rr39me$tev$1@dont-email.me> <IdGdnS9EruNl6ErCnZ2dnUU7-QvNnZ2d@giganews.com> <rr7tvl$h7a$1@dont-email.me> <DLCdnTdFDrYoHErCnZ2dnUU7-e3NnZ2d@giganews.com> <rr80h6$5t9$1@dont-email.me> <ZeqdndRFYfJ9LkrCnZ2dnUU7-KnNnZ2d@giganews.com> <rr8fqc$hq$1@dont-email.me> <b8udnRE6dKfSQUrCnZ2dnUU7-U3NnZ2d@giganews.com> <rr8oug$1sm$1@dont-email.me> <2tCdnYpd5begcErCnZ2dnUU7-cXNnZ2d@giganews.com> <rr9mqp$1h5$1@dont-email.me> <3dadnQwwG--9VUXCnZ2dnUU7-U_NnZ2d@giganews.com> <rrajkc$551$1@dont-email.me> <X5ydnW03xcIZSUXCnZ2dnUU7-KXNnZ2d@giganews.com> <rram8m$oep$1@dont-email.me>
From: NoO...@NoWhere.com (olcott)
Date: Tue, 15 Dec 2020 10:28:51 -0600
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1
MIME-Version: 1.0
In-Reply-To: <rram8m$oep$1@dont-email.me>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <Mr2dnf4B2sjVeUXCnZ2dnUU7-a3NnZ2d@giganews.com>
Lines: 126
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-q46iVB/c38JT5y4FbCoHvOrdps9b7Yemb+LsYjjvFSSkMvZfmAdBJQ6QPN+YzcI6E/w6zF+v0q42C9G!mqLj7H1FHBB6UE5laysQETllgl4uFxbgAa1t8y9PH8KpKQu/QM2w0Okl/Q7aNQvgcjqTBSfuz8bZ
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: 7651
View all headers
On 12/15/2020 9:54 AM, André G. Isaak wrote:
On 2020-12-15 08:21, olcott wrote:
On 12/15/2020 9:10 AM, André G. Isaak wrote:
On 2020-12-15 07:28, olcott wrote:
On 12/15/2020 12:58 AM, André G. Isaak wrote:
On 2020-12-14 15:54, olcott wrote:
On 12/14/2020 4:28 PM, André G. Isaak wrote:
On 2020-12-14 14:42, olcott wrote:
On 12/14/2020 1:52 PM, André G. Isaak wrote:
On 2020-12-14 11:50, olcott wrote:
On 12/14/2020 9:31 AM, André G. Isaak wrote:
On 2020-12-14 08:16, olcott wrote:

Halts(H_Hat, H_Hat) is only a finite computation because it aborts the otherwise infinite recursion of its input according to this criteria:

And the Halts(H_Hat, H_Hat) called from within H_Hat should be a finite computation for the exact same reason. It has the exact same ability to abort its input as your outermost call to Halts() has.

If you were to run H_Hat(H_Hat) as an independent program, then it's call to Halts(H_Hat, H_Hat) would behave in exactly the same way as the call to Halts(H_Hat, H_Hat) described above.

In my halt deciding solution it is impossible to run anything as an independent program, everything is simulated so that nothing can be done behind the back of the halt decider.

Sort of like writing a program that predicts asteroid orbits but only allowing its predictions to be tested against your asteroid simulator so that reality can't do things behind the back of your predictor...

Yeah, that makes sense.

André



No it is more like writing an asteroid predictor from God's point of view.

I have no idea what it means for a halt decider (or asteroid predictor) to be written from 'God's point of view'.

Because it is well known common knowledge that the simulation of the Turing machine description of a Turing machine by a UTM is computationally equivalent to directly executing this TM

If simulating a TM in a UTM is computationally equivalent to directly executing a TM, then why insist on not allowing that direct execution?


The halt decider is inherently a simulator any code that it does not simulate is code that it cannot examine.

When we're testing the behaviour of the input as an independent computation, we're not *running* the halt decider. It isn't expected to examine anything in such cases.

André


I can't understand what you are saying. It seems like you are saying the a halt decider is not a halt decider, a thing is not itself.

Above, I stated that the the behaviour of a program X *when run independently* is the metric against which the claims of the halt decider are to be evaluated.

Ah so you prove that you are ignorant of the common knowledge that the simulation of the Turing machine description of a TM by a UTM is equivalent to the direct execution of this TM.

You keep repeating this, but are failing to grasp the point: to be blunt, I DON'T TRUST your simulator.

I don't give a rats ass. (AKA this is moot). You don't even have to trust it. You can determine that it would be correct even without seeing its code.

Knowing that it decides correctly requires:
(a) An elementary understanding of software engineering, such things as infinitely recursive invocations never return values to their caller.

(b) An elementary understanding of how the C programming language maps to x86 control flow instructions.

(c) An understanding of very elementary infinite recursion detection algorithms: whenever an execution trace shows a second call to the same function from the same machine address with no control flow instructions in-between THIS <IS> INFINITE RECURSION.

Yes, if a simulator is a perfect simulator, then running the program in the simulator and running it directly will have the same results. But, running it directly eliminates any possibility that the observed behaviour is the result of bugs in the simulator.

Yes and running it directly is exactly the same as requiring the umpire of a baseball game to make sure that he keeps his eyes closed while calling every play. Do you have the wit of a nit?

There is ABSOLUTELY no reason to insist that it be run inside a simulator if they really have the same results. By *insisting* that it be simulated, you are only reinforcing my view that your simulator is not trustworthy.

Furthermore a UTM that examines the behavior of the machine that it is simulating is still a UTM. We might as well stop here until you understand these two key points because they are necessary prerequisites.

The above is entirely irrelevant to anything that I actually said.

André



--
Copyright 2020 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre minds." Einstein


Subject: Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (Halts() as an exception handler)
From: Kaz Kylheku
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng
Followup: comp.theory
Organization: Aioe.org NNTP Server
Date: Tue, 15 Dec 2020 17:18 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
Path: i2pn2.org!i2pn.org!aioe.org!opIzC+UpU1FF0qsNaB+JHA.user.gioia.aioe.org.POSTED!not-for-mail
From: 563-365-...@kylheku.com (Kaz Kylheku)
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng
Subject: Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (Halts() as an
exception handler)
Followup-To: comp.theory
Date: Tue, 15 Dec 2020 17:18:42 +0000 (UTC)
Organization: Aioe.org NNTP Server
Lines: 76
Message-ID: <20201215090503.243@kylheku.com>
References: <3JSdnRrpiNHInV3CnZ2dnUU7-YHNnZ2d@giganews.com>
<SrSdnbIYprUrnEjCnZ2dnUU7-U2dnZ2d@giganews.com>
<rr30u4$2ba$1@dont-email.me>
<BcSdnZTygJfElkjCnZ2dnUU7-UednZ2d@giganews.com>
<rr340r$l9i$1@dont-email.me>
<bo2dnRdK_KDeiEjCnZ2dnUU7-UnNnZ2d@giganews.com>
<rr34ok$rof$1@dont-email.me>
<oaedncLQ-96MhEjCnZ2dnUU7-WnNnZ2d@giganews.com>
<rr36c2$7dk$1@dont-email.me>
<-LCdnQjCJqk1vEjCnZ2dnUU7-eXNnZ2d@giganews.com>
<rr39me$tev$1@dont-email.me>
<IdGdnS9EruNl6ErCnZ2dnUU7-QvNnZ2d@giganews.com>
<rr7tvl$h7a$1@dont-email.me>
<DLCdnTdFDrYoHErCnZ2dnUU7-e3NnZ2d@giganews.com>
<rr80h6$5t9$1@dont-email.me>
<ZeqdndRFYfJ9LkrCnZ2dnUU7-KnNnZ2d@giganews.com> <rr8fqc$hq$1@dont-email.me>
<b8udnRE6dKfSQUrCnZ2dnUU7-U3NnZ2d@giganews.com>
<rr8oug$1sm$1@dont-email.me>
<2tCdnYpd5begcErCnZ2dnUU7-cXNnZ2d@giganews.com>
<KuTBH.3626$al2.1863@fx12.iad> <20201214163728.475@kylheku.com>
<keadna-gk_oJj0XCnZ2dnUU7-UXNnZ2d@giganews.com>
<20201215012611.762@kylheku.com>
<q-adnV-qP4qgUEXCnZ2dnUU7-a_NnZ2d@giganews.com>
NNTP-Posting-Host: opIzC+UpU1FF0qsNaB+JHA.user.gioia.aioe.org
X-Complaints-To: abuse@aioe.org
User-Agent: slrn/1.0.3 (Linux)
X-Notice: Filtered by postfilter v. 0.9.2
View all headers
["Followup-To:" header set to comp.theory.]
On 2020-12-15, olcott <NoOne@NoWhere.com> wrote:
On 12/15/2020 3:36 AM, Kaz Kylheku wrote:
On 2020-12-15, olcott <NoOne@NoWhere.com> wrote:
I have explained the difference between these two computations many times:

That's nice; you're not responding to the content of any of my points.

int main()
{
    Halts((u32)H_Hat, (u32)H_Hat);
    H_Hat((u32)H_Hat);
}

1. Those are not the two I'm talking about, but since our particular
H_Hat((u32)H_Hat) immediately calls Halts((u32)H_Hat, (u32)H_Hat), how
can there be a legitimate difference between those two?


The calls to Halts() are out-of-sync with each other.

Can you site a reference for the definition of "sync" you are using?

What does it mean for calls to two pure functions to be "in sync", and
"out of sync", and how is is it possible under the definition of pure
function?

2. I'm talking about both main() and H_Hat both making a call to
Halts((u32)H_Hat, (u32)H_Hat). One returns, producing a value which
indicates that the ... other one doesn't return? What?

How can exactly the same procedure both return and not return, unless it
isn't a pure function, or else not a function of just those arguments
that are apparent in the higher level language?


Global Halts() can return to the caller or it can return to the
operating system in the same way that the "divide by zero" exception
handler can catch an exception in the program or be caught by the
operating system.

Whenever the infinite execution is first invoked by Halts() it can
return a value that can be reported.

If an infinite execution occurs in Halts, it means Halts has failed to
decide. If this infinite execution is detected, and that is used as a
pretext to abort Halts such that it appears to terminate, it must not be
turned into a successful return value from Halts. The caller must know
that Halts failed to decide.

This is like an exception handler
catching a divide by zero error.

Whenever the infinite execution is NOT first invoked by Halts() this is
exactly the same as an uncaught divide by zero error and reported by the
operating system.

OK, that is enough detail to pinpoint what is bogus in this apparatus.
You have a simulator which counts certain events which occur and then
chooses behaviors. I.e. there is a global state which drives behavior
changes.

Since this is not visible in the source code of H_Hat or Halts, you're
claiming you've refuted something.

The closest that anyone has "proved that I am wrong" on my halt decider
is proving that they either don't understand what I am saying or they
don't understand the subject matter.

You clearly don't understand the subject matter, if you think you can
mess with the behavior of functions based on monitoring what they are
doing, counting certain events, and then reacting differently to a
certain pattern of execution based on the value of the counter.

--
TXR Programming Language: http://nongnu.org/txr


Subject: Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (deciders within infinite recursion)
From: Kaz Kylheku
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng
Followup: comp.theory
Organization: Aioe.org NNTP Server
Date: Tue, 15 Dec 2020 17:38 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
Path: i2pn2.org!i2pn.org!aioe.org!opIzC+UpU1FF0qsNaB+JHA.user.gioia.aioe.org.POSTED!not-for-mail
From: 563-365-...@kylheku.com (Kaz Kylheku)
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng
Subject: Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (deciders
within infinite recursion)
Followup-To: comp.theory
Date: Tue, 15 Dec 2020 17:38:28 +0000 (UTC)
Organization: Aioe.org NNTP Server
Lines: 157
Message-ID: <20201215091909.850@kylheku.com>
References: <3JSdnRrpiNHInV3CnZ2dnUU7-YHNnZ2d@giganews.com>
<rr30u4$2ba$1@dont-email.me>
<BcSdnZTygJfElkjCnZ2dnUU7-UednZ2d@giganews.com>
<rr340r$l9i$1@dont-email.me>
<bo2dnRdK_KDeiEjCnZ2dnUU7-UnNnZ2d@giganews.com>
<rr34ok$rof$1@dont-email.me>
<oaedncLQ-96MhEjCnZ2dnUU7-WnNnZ2d@giganews.com>
<rr36c2$7dk$1@dont-email.me>
<-LCdnQjCJqk1vEjCnZ2dnUU7-eXNnZ2d@giganews.com>
<rr39me$tev$1@dont-email.me>
<IdGdnS9EruNl6ErCnZ2dnUU7-QvNnZ2d@giganews.com>
<rr7tvl$h7a$1@dont-email.me>
<DLCdnTdFDrYoHErCnZ2dnUU7-e3NnZ2d@giganews.com>
<rr80h6$5t9$1@dont-email.me>
<ZeqdndRFYfJ9LkrCnZ2dnUU7-KnNnZ2d@giganews.com> <rr8fqc$hq$1@dont-email.me>
<b8udnRE6dKfSQUrCnZ2dnUU7-U3NnZ2d@giganews.com>
<rr8oug$1sm$1@dont-email.me>
<2tCdnYpd5begcErCnZ2dnUU7-cXNnZ2d@giganews.com>
<rr9mqp$1h5$1@dont-email.me>
<3dadnQwwG--9VUXCnZ2dnUU7-U_NnZ2d@giganews.com>
<rrajkc$551$1@dont-email.me>
<X5ydnW03xcIZSUXCnZ2dnUU7-KXNnZ2d@giganews.com>
<rram8m$oep$1@dont-email.me>
<Mr2dnf4B2sjVeUXCnZ2dnUU7-a3NnZ2d@giganews.com>
NNTP-Posting-Host: opIzC+UpU1FF0qsNaB+JHA.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Complaints-To: abuse@aioe.org
User-Agent: slrn/1.0.3 (Linux)
X-Notice: Filtered by postfilter v. 0.9.2
View all headers
["Followup-To:" header set to comp.theory.]
On 2020-12-15, olcott <NoOne@NoWhere.com> wrote:
On 12/15/2020 9:54 AM, André G. Isaak wrote:
On 2020-12-15 08:21, olcott wrote:
On 12/15/2020 9:10 AM, André G. Isaak wrote:
On 2020-12-15 07:28, olcott wrote:
On 12/15/2020 12:58 AM, André G. Isaak wrote:
On 2020-12-14 15:54, olcott wrote:
On 12/14/2020 4:28 PM, André G. Isaak wrote:
On 2020-12-14 14:42, olcott wrote:
On 12/14/2020 1:52 PM, André G. Isaak wrote:
On 2020-12-14 11:50, olcott wrote:
On 12/14/2020 9:31 AM, André G. Isaak wrote:
On 2020-12-14 08:16, olcott wrote:

Halts(H_Hat, H_Hat) is only a finite computation because it
aborts the otherwise infinite recursion of its input
according to this criteria:

And the Halts(H_Hat, H_Hat) called from within H_Hat should
be a finite computation for the exact same reason. It has the
exact same ability to abort its input as your outermost call
to Halts() has.

If you were to run H_Hat(H_Hat) as an independent program,
then it's call to Halts(H_Hat, H_Hat) would behave in exactly
the same way as the call to Halts(H_Hat, H_Hat) described above.

In my halt deciding solution it is impossible to run anything
as an independent program, everything is simulated so that
nothing can be done behind the back of the halt decider.

Sort of like writing a program that predicts asteroid orbits
but only allowing its predictions to be tested against your
asteroid simulator so that reality can't do things behind the
back of your predictor...

Yeah, that makes sense.

André



No it is more like writing an asteroid predictor from God's
point of view.

I have no idea what it means for a halt decider (or asteroid
predictor) to be written from 'God's point of view'.

Because it is well known common knowledge that the simulation of
the Turing machine description of a Turing machine by a UTM is
computationally equivalent to directly executing this TM

If simulating a TM in a UTM is computationally equivalent to
directly executing a TM, then why insist on not allowing that
direct execution?


The halt decider is inherently a simulator any code that it does
not simulate is code that it cannot examine.

When we're testing the behaviour of the input as an independent
computation, we're not *running* the halt decider. It isn't
expected to examine anything in such cases.

André


I can't understand what you are saying. It seems like you are saying
the a halt decider is not a halt decider, a thing is not itself.

Above, I stated that the the behaviour of a program X *when run
independently* is the metric against which the claims of the halt
decider are to be evaluated.

Ah so you prove that you are ignorant of the common knowledge that the
simulation of the Turing machine description of a TM by a UTM is
equivalent to the direct execution of this TM.

You keep repeating this, but are failing to grasp the point: to be
blunt, I DON'T TRUST your simulator.

I don't give a rats ass. (AKA this is moot). You don't even have to
trust it. You can determine that it would be correct even without seeing
its code.

The simulator may be fine. It's obvious you have used it to perpetrate
hacks from which you are drawing invalid conclusions.

You believe that a simulator can interfere with the behavior of a
function, such that different executions of it with the same arguments
provokes a different reaction of the simulator, based on global state
information retained in that simulator.

I have a new fakehalts2.c which does something I believe to be very
similar to your descriptions. Because my program is honestly coded,
there is no need to conceal anything inside a simulator; the fraud
is laid bare in the C source code:

  $ ./fakehalt2
  Got here so H_Hat(H_Hat) halted!
  H_Hat(H_Hat) doesn't halt!

Source:

#include <stdio.h>
#include <setjmp.h>
#include <stdlib.h>

typedef void (*fun_t)(void *data);
typedef int (*decider_t)(fun_t, void *data);

int Halts(fun_t, void *);

void H_Hat(void *data)
{
  if (Halts((fun_t) data, data)) {
    for (;;)
      fflush(stdout);
  } else {
    return;
  }
}

int Halts(fun_t fun, void *data)
{
  static int counter = 0;
  static jmp_buf jbuf;

  if (counter++ == 0) {
    if (setjmp(jbuf)) {
      return 0; // Caught exception in fun(data)
    } else {
      fun(data); // Just invoke the function on the input
      return 1;
    }
  }

  // Reset everything for next time.
  counter = 0;
  // Infinite execution is occurring: throw exception!
  longjmp(jbuf, 1);
}

int main(void)
{
  H_Hat((void *) H_Hat);

  puts("Got here so H_Hat(H_Hat) halted!");

  if (Halts(H_Hat, (void *) H_Hat))
    puts("H_Hat(H_Hat) halts!");
  else
    puts("H_Hat(H_Hat) doesn't halt!");

  return 0;
}


Subject: Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (deciders within infinite recursion)
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng
Date: Tue, 15 Dec 2020 18:13 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13
Path: i2pn2.org!i2pn.org!aioe.org!peer03.ams4!peer.am4.highwinds-media.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Tue, 15 Dec 2020 12:13:37 -0600
Subject: Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (deciders within
infinite recursion)
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng
References: <3JSdnRrpiNHInV3CnZ2dnUU7-YHNnZ2d@giganews.com>
<ZeqdndRFYfJ9LkrCnZ2dnUU7-KnNnZ2d@giganews.com> <rr8fqc$hq$1@dont-email.me>
<b8udnRE6dKfSQUrCnZ2dnUU7-U3NnZ2d@giganews.com> <rr8oug$1sm$1@dont-email.me>
<2tCdnYpd5begcErCnZ2dnUU7-cXNnZ2d@giganews.com> <rr9mqp$1h5$1@dont-email.me>
<3dadnQwwG--9VUXCnZ2dnUU7-U_NnZ2d@giganews.com> <rrajkc$551$1@dont-email.me>
<X5ydnW03xcIZSUXCnZ2dnUU7-KXNnZ2d@giganews.com> <rram8m$oep$1@dont-email.me>
<Mr2dnf4B2sjVeUXCnZ2dnUU7-a3NnZ2d@giganews.com> <rras9q$138o$1@news.muc.de>
From: NoO...@NoWhere.com (olcott)
Date: Tue, 15 Dec 2020 12:13:32 -0600
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.5.1
MIME-Version: 1.0
In-Reply-To: <rras9q$138o$1@news.muc.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <8eCdnUauuNBMYUXCnZ2dnUU7-Q_NnZ2d@giganews.com>
Lines: 41
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-4mBJtW9DWUDi9fNRxjeWOXIi8qWln84t64FmriYXWytp0bA/mhLV2L69ESNdVEXWSwx4gAf3ScuSAas!F/mp15O33Sp3apSYMFSofN8V0WrmJGj7botyB5Hp5iF2RMmGBML5ogT3gtOWv+Os98R+J0BtZnIN
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: 3444
X-Received-Bytes: 3687
View all headers
On 12/15/2020 11:38 AM, Alan Mackenzie wrote:
In comp.theory olcott <NoOne@nowhere.com> wrote:
On 12/15/2020 9:54 AM, André G. Isaak wrote:
On 2020-12-15 08:21, olcott wrote:

[ .... ]

Ah so you prove that you are ignorant of the common knowledge that
the simulation of the Turing machine description of a TM by a UTM is
equivalent to the direct execution of this TM.

You keep repeating this, but are failing to grasp the point: to be
blunt, I DON'T TRUST your simulator.

Neither do I, neither would anybody sensible.

I don't give a rats ass. (AKA this is moot). You don't even have to
trust it. You can determine that it would be correct even without
seeing its code.

Knowing that it decides correctly requires:
(a) An elementary understanding of software engineering, such things as
infinitely recursive invocations never return values to their caller.

If you had an elementary grasp of software engineering, you would know
that all software needs testing.  That includes your simulator.  What
needs testing is that it works, i.e. that its simulated results match the
real results.
My x86utm operating system entirely based on a world class x86 emulator that has been around for decades. All the x86 emulation is performed by this emulator.

The code emulated by this emulator is the COFF object file output generated by the Microsoft C compiler. All that I do to this COFF data is patch the relocation references to locations in the COFF object file.

--
Copyright 2020 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre minds." Einstein


Subject: Re: Refuting the {Linz, Sipser, Kozen} HP Proofs (Ben's example)
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.lang.c, comp.lang.c++
Followup: comp.theory
Date: Wed, 16 Dec 2020 00:23 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.snarked.org!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Tue, 15 Dec 2020 18:23:41 -0600
Subject: Re: Refuting the {Linz, Sipser, Kozen} HP Proofs (Ben's example)
Newsgroups: comp.theory,comp.ai.philosophy,comp.lang.c,comp.lang.c++
References: <3JSdnRrpiNHInV3CnZ2dnUU7-YHNnZ2d@giganews.com>
<HxSxH.34144$Oa.28187@fx16.iad>
<ZMOdncRH0J-RZVrCnZ2dnUU7-TudnZ2d@giganews.com>
<20201202130444.97@kylheku.com>
<4ISdnZjauficjlXCnZ2dnUU7-X3NnZ2d@giganews.com>
<20201202170501.883@kylheku.com> <rqbjrt$1s4o$1@gioia.aioe.org>
<20201207211640.ab3cf977e95bac160b406d58@gmail.com>
<87lfe9mat5.fsf@bsb.me.uk>
<20201209144312.3fa9e12d9eb9f6e65a6bf909@gmail.com>
<20201209144609.d72f65772754e159081986d3@gmail.com>
<rqqg0h$jn8$1@dont-email.me>
<cadb3cac-1359-4e7d-ad13-611e6c65199en@googlegroups.com>
<XPadnV3i4dHqeE3CnZ2dnUU7-VWdnZ2d@giganews.com>
<1702717b-0369-4388-99c5-765f9fedc54en@googlegroups.com>
<87o8j3djj9.fsf@bsb.me.uk> <8OGdnawuHrSQPEzCnZ2dnUU7-bXNnZ2d@giganews.com>
<87ft4a8vdr.fsf@bsb.me.uk> <oPOdnaQ4DramzkjCnZ2dnUU7-bmdnZ2d@giganews.com>
<87v9d57srg.fsf@bsb.me.uk> <yK2dnXzXs69GQkXCnZ2dnUU7-dvNnZ2d@giganews.com>
<875z5262oy.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Followup-To: comp.theory
Date: Tue, 15 Dec 2020 18:23:36 -0600
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.5.1
MIME-Version: 1.0
In-Reply-To: <875z5262oy.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Message-ID: <XKWdnc8Hn9oQzkTCnZ2dnUU7-RHNnZ2d@giganews.com>
Lines: 125
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-OFrevU+iXGa9SUBivkVy1120Zr8rckyxSb7cwuMA5NH1kg8KiLaUvtFaTlb1JSv6SjddZGJJ1c8l5+8!wLWxHzNyGNtnmzCezGXI1CnQ32nWa1jcG6nxx6Hvn9womOZ2+Js8TM/CgVomqtEToxzwOtonlFB/
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: 6824
View all headers
On 12/15/2020 5:59 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:

On 12/13/2020 7:14 AM, Ben Bacarisse wrote:
Code for contex:

bool Halts(u32 P, u32 I)
{
    bool Halted  = false;
    bool Aborted = false;
    while (!Halted && !Aborted)
    {
      Halted  = DebugStep(P, I);
      Aborted = Needs_To_Be_Aborted();
    }
    return !Aborted;

void Confound_Halts(u32 P) { if (Halts(P, P)) while (1); }

olcott <NoOne@NoWhere.com> writes:

On 12/12/2020 5:20 PM, Ben Bacarisse wrote:
<cut>
As far as my original point is  concerned you have already said that Halts
does not meet the challenge.  You've agreed that

(a) Halts(Confound_Halts, Confound_Halts) is false, and
(b) Confound_Halts(Confound_Halts) is a finite computation.

(b) Confound_Halts(Confound_Halts) IS NOT A FINITE COMPUTATION

I am aware that you have said both.  What you have not done is retract
what you said before*, namely that the input to halts is a finite
computation.  You can't expect to get away with saying both, you need to
say that you were wrong before.

This is the first point that needs to be resolved.  Were you wrong when
you described the computation passed to Halts as finite?  You qualified
it -- "it's only finite because...", but I'd still be dead even if I were
only dead because I jumped off a cliff.

Anyway, it seems you are now adamant that, despite what you said before,
Confound_Halts(Confound_Halts) is not a finite computation.  There are
only two ways that that can happen.  Reminder:

   void Confound_Halts(u32 P) { if (Halts(P, P)) while (1); }

(1) Halts(Confound_Halts, Confound_Halts) returns true when called in
     the above function; or

(2) Halts(Confound_Halts, Confound_Halts) does not return when called in
     the above function.

Either way, Halts does not meet the specification given in the
challenge.

The infinitely recursive invocation of Halts() by Confound_Halts()
never returns anything to Confound_Halts()

OK that's excellently clear.  Thank you.  So Halts fails to meet the
challenge because of (2) rather than (1)*.  Do you want to have another
go at meeting the challenge:

   Show a function F such that F(P, I) is true if, and only if, P(I) is a
   finite computation and false otherwise.

Unless it is not obvious, these words mean that any candidate function
must return in finite time no matter what arguments it is passed and
regardless of the context of the call.

* It occurs to me that you might think that a viable answer to this
   challenge might be a function that returns something in some contexts
   and does not return in others, even when given exactly the same
   arguments in both cases.  I'm discounting that because it's obviously
   not allowed by the challenge wording, and you confirmed that no such
   trickery is taking place long ago in the reply to, IIRC, Mike Terry.


Here is the architecture that I am working on physically implementing in the x86utm (x86 based universal Turing machine equivalent) operating system.

Whenever a function is called by Halts() and it would not halt Halts() returns 0. This is like wrapping a possible divide by zero error with a try-catch block, the otherwise abnormal termination is caught.

// This part is fully operational
int main()
{
   u32 Input_Halts = Halts((u32)Confound_Halts, (u32)Confound_Halts);
   Output("Input_Halts = ", Input_Halts);
}

Whenever a function is not called by Halts() and it would not halt the halt deciding operating system reports a "non-halting" error. This is like divide by zero error that is NOT wrapped with a try-catch block, the program abnormally terminates:

int main()
{
   HERE: goto HERE;
}

int main()
{
   Confound_Halts((u32)Confound_Halts);
}

This is the universal not-halting decision criteria:

On 11/27/2020 9:02 PM, Ben Bacarisse wrote:
 > A computation that would not halt if its simulation were not
 > halted is indeed a non-halting computation.

On Saturday, November 28, 2020 at 2:00:28 PM UTC-8, olcott wrote:
 > Every computation that would not halt if its simulation
 > were not halted is by logical necessity a non-halting computation.

The halting decision criteria is simply that the input has actually halted.

--
Copyright 2020 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre minds." Einstein


Subject: Re: Refuting the {Linz, Sipser, Kozen} HP Proofs (Ben's example)
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.lang.c, comp.lang.c++
Followup: comp.theory
Date: Wed, 16 Dec 2020 01:46 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!feeder1.feed.usenet.farm!feed.usenet.farm!feeder.usenetexpress.com!tr2.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Tue, 15 Dec 2020 19:46:14 -0600
Subject: Re: Refuting the {Linz, Sipser, Kozen} HP Proofs (Ben's example)
Newsgroups: comp.theory,comp.ai.philosophy,comp.lang.c,comp.lang.c++
References: <3JSdnRrpiNHInV3CnZ2dnUU7-YHNnZ2d@giganews.com> <20201202130444.97@kylheku.com> <4ISdnZjauficjlXCnZ2dnUU7-X3NnZ2d@giganews.com> <20201202170501.883@kylheku.com> <rqbjrt$1s4o$1@gioia.aioe.org> <20201207211640.ab3cf977e95bac160b406d58@gmail.com> <87lfe9mat5.fsf@bsb.me.uk> <20201209144312.3fa9e12d9eb9f6e65a6bf909@gmail.com> <20201209144609.d72f65772754e159081986d3@gmail.com> <rqqg0h$jn8$1@dont-email.me> <cadb3cac-1359-4e7d-ad13-611e6c65199en@googlegroups.com> <XPadnV3i4dHqeE3CnZ2dnUU7-VWdnZ2d@giganews.com> <1702717b-0369-4388-99c5-765f9fedc54en@googlegroups.com> <87o8j3djj9.fsf@bsb.me.uk> <8OGdnawuHrSQPEzCnZ2dnUU7-bXNnZ2d@giganews.com> <87ft4a8vdr.fsf@bsb.me.uk> <oPOdnaQ4DramzkjCnZ2dnUU7-bmdnZ2d@giganews.com> <87v9d57srg.fsf@bsb.me.uk> <yK2dnXzXs69GQkXCnZ2dnUU7-dvNnZ2d@giganews.com> <875z5262oy.fsf@bsb.me.uk> <XKWdnc8Hn9oQzkTCnZ2dnUU7-RHNnZ2d@giganews.com> <877dpi4ksa.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Followup-To: comp.theory
Date: Tue, 15 Dec 2020 19:46:08 -0600
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1
MIME-Version: 1.0
In-Reply-To: <877dpi4ksa.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Message-ID: <S7WdnVxdtqB7-0TCnZ2dnUU7-TPNnZ2d@giganews.com>
Lines: 107
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-D21uRswkybaErzFKAuyyVi0knwRRrVrTABAOZKUFN3eW5BXLV0QPHgHRiur/IHSIFZKMkusuS/Vr9XM!9mxdmXOfl0NPD0yL4yFkldirzDIQQIvaYSc0BWlt6mGy5e5fzysdJ19SRbBxiWHB4hikShss21Fr
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: 6490
View all headers
On 12/15/2020 7:11 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:

On 12/15/2020 5:59 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:

On 12/13/2020 7:14 AM, Ben Bacarisse wrote:
Code for contex:

bool Halts(u32 P, u32 I)
{
     bool Halted  = false;
     bool Aborted = false;
     while (!Halted && !Aborted)
     {
       Halted  = DebugStep(P, I);
       Aborted = Needs_To_Be_Aborted();
     }
     return !Aborted;

void Confound_Halts(u32 P) { if (Halts(P, P)) while (1); }

olcott <NoOne@NoWhere.com> writes:

On 12/12/2020 5:20 PM, Ben Bacarisse wrote:
<cut>
As far as my original point is  concerned you have already said that Halts
does not meet the challenge.  You've agreed that

(a) Halts(Confound_Halts, Confound_Halts) is false, and
(b) Confound_Halts(Confound_Halts) is a finite computation.

(b) Confound_Halts(Confound_Halts) IS NOT A FINITE COMPUTATION

I am aware that you have said both.  What you have not done is retract
what you said before*, namely that the input to halts is a finite
computation.  You can't expect to get away with saying both, you need to
say that you were wrong before.

This is the first point that needs to be resolved.  Were you wrong when
you described the computation passed to Halts as finite?  You qualified
it -- "it's only finite because...", but I'd still be dead even if I were
only dead because I jumped off a cliff.

Anyway, it seems you are now adamant that, despite what you said before,
Confound_Halts(Confound_Halts) is not a finite computation.  There are
only two ways that that can happen.  Reminder:

    void Confound_Halts(u32 P) { if (Halts(P, P)) while (1); }

(1) Halts(Confound_Halts, Confound_Halts) returns true when called in
      the above function; or

(2) Halts(Confound_Halts, Confound_Halts) does not return when called in
      the above function.


(3) When Halts(Confound_Halts, Confound_Halts) is called by main() this is similar to wrapping a divide by zero error with a try catch block. Halts() returns a value of 0 or 1.

When Confound_Halts(Confound_Halts) is called by main() this is similar to divide by zero error that has not been caught by a try-catch block. The operating system abnormally terminates the application with an [infinite execution] @ machine address fatal error.

Either way, Halts does not meet the specification given in the
challenge.

The infinitely recursive invocation of Halts() by Confound_Halts()
never returns anything to Confound_Halts()

OK that's excellently clear.  Thank you.  So Halts fails to meet the
challenge because of (2) rather than (1)*.  Do you want to have another
go at meeting the challenge:

    Show a function F such that F(P, I) is true if, and only if, P(I) is a
    finite computation and false otherwise.

Unless it is not obvious, these words mean that any candidate function
must return in finite time no matter what arguments it is passed and
regardless of the context of the call.

* It occurs to me that you might think that a viable answer to this
    challenge might be a function that returns something in some contexts
    and does not return in others, even when given exactly the same
    arguments in both cases.  I'm discounting that because it's obviously
    not allowed by the challenge wording, and you confirmed that no such
    trickery is taking place long ago in the reply to, IIRC, Mike Terry.


Here is the architecture that I am working on physically
implementing...

I'm not interested in that.  Can I take it that you agree you have not
met the challenge?  I'm sure everyone else will take your non-reply in
that way but I'd rather you were explicit about it.


Your challenge was a false dichotomy as pointed out above.


--
Copyright 2020 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre minds." Einstein


Subject: Re: Refuting the {Linz, Sipser, Kozen} HP Proofs (Ben's example)
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng
Date: Wed, 16 Dec 2020 19:23 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.snarked.org!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Wed, 16 Dec 2020 13:23:26 -0600
Subject: Re: Refuting the {Linz, Sipser, Kozen} HP Proofs (Ben's example)
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng
References: <3JSdnRrpiNHInV3CnZ2dnUU7-YHNnZ2d@giganews.com>
<4ISdnZjauficjlXCnZ2dnUU7-X3NnZ2d@giganews.com>
<20201202170501.883@kylheku.com> <rqbjrt$1s4o$1@gioia.aioe.org>
<20201207211640.ab3cf977e95bac160b406d58@gmail.com>
<87lfe9mat5.fsf@bsb.me.uk>
<20201209144312.3fa9e12d9eb9f6e65a6bf909@gmail.com>
<20201209144609.d72f65772754e159081986d3@gmail.com>
<rqqg0h$jn8$1@dont-email.me>
<cadb3cac-1359-4e7d-ad13-611e6c65199en@googlegroups.com>
<XPadnV3i4dHqeE3CnZ2dnUU7-VWdnZ2d@giganews.com>
<1702717b-0369-4388-99c5-765f9fedc54en@googlegroups.com>
<87o8j3djj9.fsf@bsb.me.uk> <8OGdnawuHrSQPEzCnZ2dnUU7-bXNnZ2d@giganews.com>
<87ft4a8vdr.fsf@bsb.me.uk> <oPOdnaQ4DramzkjCnZ2dnUU7-bmdnZ2d@giganews.com>
<87v9d57srg.fsf@bsb.me.uk> <yK2dnXzXs69GQkXCnZ2dnUU7-dvNnZ2d@giganews.com>
<875z5262oy.fsf@bsb.me.uk> <XKWdnc8Hn9oQzkTCnZ2dnUU7-RHNnZ2d@giganews.com>
<877dpi4ksa.fsf@bsb.me.uk> <S7WdnVxdtqB7-0TCnZ2dnUU7-TPNnZ2d@giganews.com>
<6b106784-3f6a-44c3-ad5b-646adba93fe6n@googlegroups.com>
From: NoO...@NoWhere.com (olcott)
Date: Wed, 16 Dec 2020 13:23:14 -0600
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.5.1
MIME-Version: 1.0
In-Reply-To: <6b106784-3f6a-44c3-ad5b-646adba93fe6n@googlegroups.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Message-ID: <IoGdndKfvMgzw0fCnZ2dnUU7-WvNnZ2d@giganews.com>
Lines: 124
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-7Eu6sCeuecZiyn4hGsaerZ0TO4nhyQdn2uV6Dln6lGRkxxuJvH4bFpXpdGt2dXwANw/G/3FVvKdu2vB!UDz7RNxQ9Rqij1894tUT2WMl6fYlrsS4AbyGM1MjmV/LnJDlqNKDRpzG5Huceelwo/F8xwVF5pBo
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: 7731
View all headers
On 12/16/2020 7:48 AM, Malcolm McLean wrote:
On Wednesday, 16 December 2020 at 01:46:22 UTC, olcott wrote:
On 12/15/2020 7:11 PM, Ben Bacarisse wrote:
olcott <No...@NoWhere.com> writes:

On 12/15/2020 5:59 PM, Ben Bacarisse wrote:
olcott <No...@NoWhere.com> writes:

On 12/13/2020 7:14 AM, Ben Bacarisse wrote:
Code for contex:

bool Halts(u32 P, u32 I)
{
bool Halted = false;
bool Aborted = false;
while (!Halted && !Aborted)
{
Halted = DebugStep(P, I);
Aborted = Needs_To_Be_Aborted();
}
return !Aborted;

void Confound_Halts(u32 P) { if (Halts(P, P)) while (1); }

olcott <No...@NoWhere.com> writes:

On 12/12/2020 5:20 PM, Ben Bacarisse wrote:
<cut>
As far as my original point is concerned you have already said that Halts
does not meet the challenge. You've agreed that

(a) Halts(Confound_Halts, Confound_Halts) is false, and
(b) Confound_Halts(Confound_Halts) is a finite computation.

(b) Confound_Halts(Confound_Halts) IS NOT A FINITE COMPUTATION

I am aware that you have said both. What you have not done is retract
what you said before*, namely that the input to halts is a finite
computation. You can't expect to get away with saying both, you need to
say that you were wrong before.

This is the first point that needs to be resolved. Were you wrong when
you described the computation passed to Halts as finite? You qualified
it -- "it's only finite because...", but I'd still be dead even if I were
only dead because I jumped off a cliff.

Anyway, it seems you are now adamant that, despite what you said before,
Confound_Halts(Confound_Halts) is not a finite computation. There are
only two ways that that can happen. Reminder:

void Confound_Halts(u32 P) { if (Halts(P, P)) while (1); }

(1) Halts(Confound_Halts, Confound_Halts) returns true when called in
the above function; or

(2) Halts(Confound_Halts, Confound_Halts) does not return when called in
the above function.

(3) When Halts(Confound_Halts, Confound_Halts) is called by main() this
is similar to wrapping a divide by zero error with a try catch block.
Halts() returns a value of 0 or 1.

When Confound_Halts(Confound_Halts) is called by main() this is similar
to divide by zero error that has not been caught by a try-catch block.
The operating system abnormally terminates the application with an
[infinite execution] @ machine address fatal error.

So this is reasonable. Everything is run under a supervisor which detects
non-stopping behaviour and aborts. Halts catches the detection when
called at top level. When not called at top level, the supervisor catches
the detection.

So it looks superficially as if Halts at top level is a pure function. That's as
much as anyone sane would expect or demand. Halts can't be really a
pure function because it changes its behaviour when called from Confound_
Halts() .

It must interact with the supervisor in some way. But that is quite well
hidden, and the supervisor set-up sounds innocuous enough at first sight.After
all, you need some framework for running Turing machines, and for stopping
them when they get caught in infinite loops (or exceed the patience of
the user).

You haven't met Ben's challenge because of this


Ben's challenge seemed to be self-contradictory adding the arbitrary requirement that a halt decider is either not allowed detect when another function is invoking it in infinite recursion

Halts-->H_Hat-->Halts  // second call to Halts

or whenever the halt decider does detect itself being invoked in infinite recursion this infinitely recursive invocation (the second one diagrammed above) must return a value to its caller even though no infinitely recursive invocations ever return values to their caller.

Since I have a complete execution trace of the halt decider deciding H_Hat correctly Ben's arbitrary requirement has no actual basis.

(Ben)
* It occurs to me that you might think that a viable answer to this
challenge might be a function that returns something in some contexts
and does not return in others, even when given exactly the same
arguments in both cases. I'm discounting that because it's obviously
not allowed by the challenge wording, and you confirmed that no such
trickery is taking place long ago in the reply to, IIRC, Mike Terry.

As the asterisk indicates, this is a post-hoc requirement. Ultimately if
you pile on control after control, it becomes impossibe even for the
most skilled magician to pull a rabbit out of a hat. You can demand
that you supply the the hat, and he can do it, you can demand that
the hat not be placed on a table, and he will do it, you can demand that he
wear short sleeves, and he will do it. But finally you demand a brown rabbit
instead of a white rabbit. That's a demand too far. It's no longer possible to
produce the rabbit from the hat.



--
Copyright 2020 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre minds." Einstein


Subject: Re: Refuting the {Linz, Sipser, Kozen} HP Proofs (Ben's example)
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng
Date: Wed, 16 Dec 2020 20:04 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
Path: i2pn2.org!i2pn.org!aioe.org!peer03.ams4!peer.am4.highwinds-media.com!news.highwinds-media.com!newsfeed.xs4all.nl!newsfeed7.news.xs4all.nl!tr2.eu1.usenetexpress.com!feeder.usenetexpress.com!tr1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Wed, 16 Dec 2020 14:04:42 -0600
Subject: Re: Refuting the {Linz, Sipser, Kozen} HP Proofs (Ben's example)
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng
References: <3JSdnRrpiNHInV3CnZ2dnUU7-YHNnZ2d@giganews.com> <rqbjrt$1s4o$1@gioia.aioe.org> <20201207211640.ab3cf977e95bac160b406d58@gmail.com> <87lfe9mat5.fsf@bsb.me.uk> <20201209144312.3fa9e12d9eb9f6e65a6bf909@gmail.com> <20201209144609.d72f65772754e159081986d3@gmail.com> <rqqg0h$jn8$1@dont-email.me> <cadb3cac-1359-4e7d-ad13-611e6c65199en@googlegroups.com> <XPadnV3i4dHqeE3CnZ2dnUU7-VWdnZ2d@giganews.com> <1702717b-0369-4388-99c5-765f9fedc54en@googlegroups.com> <87o8j3djj9.fsf@bsb.me.uk> <8OGdnawuHrSQPEzCnZ2dnUU7-bXNnZ2d@giganews.com> <87ft4a8vdr.fsf@bsb.me.uk> <oPOdnaQ4DramzkjCnZ2dnUU7-bmdnZ2d@giganews.com> <87v9d57srg.fsf@bsb.me.uk> <yK2dnXzXs69GQkXCnZ2dnUU7-dvNnZ2d@giganews.com> <875z5262oy.fsf@bsb.me.uk> <XKWdnc8Hn9oQzkTCnZ2dnUU7-RHNnZ2d@giganews.com> <877dpi4ksa.fsf@bsb.me.uk> <S7WdnVxdtqB7-0TCnZ2dnUU7-TPNnZ2d@giganews.com> <6b106784-3f6a-44c3-ad5b-646adba93fe6n@googlegroups.com> <IoGdndKfvMgzw0fCnZ2dnUU7-WvNnZ2d@giganews.com> <rrdomo$4ta$1@dont-email.me>
From: NoO...@NoWhere.com (olcott)
Date: Wed, 16 Dec 2020 14:04:41 -0600
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1
MIME-Version: 1.0
In-Reply-To: <rrdomo$4ta$1@dont-email.me>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <If6dnUUqRMbH9UfCnZ2dnUU7-e_NnZ2d@giganews.com>
Lines: 140
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-xCToM2411p0BZasbGnrSKznB717VuypJNnuMHWQLmM2q55FVjtlrE8+p28FkSJjX01L6FzUXHDQw7uh!/ja9rShlHwt7MugW7wRNZ5TXuqg4MZCYd8p4kzscW5+Wd+L6iS6Su+W0jRYZztGkT0HAPa6o3RqD
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: 7701
X-Received-Bytes: 7911
View all headers
On 12/16/2020 1:55 PM, André G. Isaak wrote:
On 2020-12-16 12:23, olcott wrote:
On 12/16/2020 7:48 AM, Malcolm McLean wrote:
On Wednesday, 16 December 2020 at 01:46:22 UTC, olcott wrote:
On 12/15/2020 7:11 PM, Ben Bacarisse wrote:
olcott <No...@NoWhere.com> writes:

On 12/15/2020 5:59 PM, Ben Bacarisse wrote:
olcott <No...@NoWhere.com> writes:

On 12/13/2020 7:14 AM, Ben Bacarisse wrote:
Code for contex:

bool Halts(u32 P, u32 I)
{
bool Halted = false;
bool Aborted = false;
while (!Halted && !Aborted)
{
Halted = DebugStep(P, I);
Aborted = Needs_To_Be_Aborted();
}
return !Aborted;

void Confound_Halts(u32 P) { if (Halts(P, P)) while (1); }

olcott <No...@NoWhere.com> writes:

On 12/12/2020 5:20 PM, Ben Bacarisse wrote:
<cut>
As far as my original point is concerned you have already said that Halts
does not meet the challenge. You've agreed that

(a) Halts(Confound_Halts, Confound_Halts) is false, and
(b) Confound_Halts(Confound_Halts) is a finite computation.

(b) Confound_Halts(Confound_Halts) IS NOT A FINITE COMPUTATION

I am aware that you have said both. What you have not done is retract
what you said before*, namely that the input to halts is a finite
computation. You can't expect to get away with saying both, you need to
say that you were wrong before.

This is the first point that needs to be resolved. Were you wrong when
you described the computation passed to Halts as finite? You qualified
it -- "it's only finite because...", but I'd still be dead even if I were
only dead because I jumped off a cliff.

Anyway, it seems you are now adamant that, despite what you said before,
Confound_Halts(Confound_Halts) is not a finite computation. There are
only two ways that that can happen. Reminder:

void Confound_Halts(u32 P) { if (Halts(P, P)) while (1); }

(1) Halts(Confound_Halts, Confound_Halts) returns true when called in
the above function; or

(2) Halts(Confound_Halts, Confound_Halts) does not return when called in
the above function.

(3) When Halts(Confound_Halts, Confound_Halts) is called by main() this
is similar to wrapping a divide by zero error with a try catch block.
Halts() returns a value of 0 or 1.

When Confound_Halts(Confound_Halts) is called by main() this is similar
to divide by zero error that has not been caught by a try-catch block.
The operating system abnormally terminates the application with an
[infinite execution] @ machine address fatal error.

So this is reasonable. Everything is run under a supervisor which detects
non-stopping behaviour and aborts. Halts catches the detection when
called at top level. When not called at top level, the supervisor catches
the detection.

So it looks superficially as if Halts at top level is a pure function. That's as
much as anyone sane would expect or demand. Halts can't be really a
pure function because it changes its behaviour when called from Confound_
Halts() .

It must interact with the supervisor in some way. But that is quite well
hidden, and the supervisor set-up sounds innocuous enough at first sight.After
all, you need some framework for running Turing machines, and for stopping
them when they get caught in infinite loops (or exceed the patience of
the user).

You haven't met Ben's challenge because of this


Ben's challenge seemed to be self-contradictory adding the arbitrary requirement that a halt decider is either not allowed detect when another function is invoking it in infinite recursion

Halts-->H_Hat-->Halts  // second call to Halts

or whenever the halt decider does detect itself being invoked in infinite recursion this infinitely recursive invocation (the second one diagrammed above) must return a value to its caller even though no infinitely recursive invocations ever return values to their caller.

Since I have a complete execution trace of the halt decider deciding H_Hat correctly Ben's arbitrary requirement has no actual basis.

There's nothing arbitrary here. The requirement is that Halts() must be *self-consistent*. That's a requirement which any solution to any problem has.

According to you:

(1) You call Halts(H_Hat, H_Hat)
(2) This in turn emulates H_Hat(H_Hat)
(3) This in turn emulates Halts(H_Hat, H_Hat)
(4) Your call in (1) aborts this as non-halting.

The problem is that the call in (1) and the call in (3) are *identical*

No they are not. Call (1) has a much longer execution trace to examine than call (3).  I have said this at least fifty times.


--
Copyright 2020 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre minds." Einstein


Subject: Re: Refuting the {Linz, Sipser, Kozen} HP Proofs (Ben's example)
From: Mr Flibble
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng
Organization: Jupiter Mining Corporation
Date: Wed, 16 Dec 2020 20:21 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
Path: i2pn2.org!i2pn.org!aioe.org!peer02.ams4!peer.am4.highwinds-media.com!news.highwinds-media.com!fx10.ams4.POSTED!not-for-mail
Subject: Re: Refuting the {Linz, Sipser, Kozen} HP Proofs (Ben's example)
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng
References: <3JSdnRrpiNHInV3CnZ2dnUU7-YHNnZ2d@giganews.com>
<20201207211640.ab3cf977e95bac160b406d58@gmail.com>
<87lfe9mat5.fsf@bsb.me.uk>
<20201209144312.3fa9e12d9eb9f6e65a6bf909@gmail.com>
<20201209144609.d72f65772754e159081986d3@gmail.com>
<rqqg0h$jn8$1@dont-email.me>
<cadb3cac-1359-4e7d-ad13-611e6c65199en@googlegroups.com>
<XPadnV3i4dHqeE3CnZ2dnUU7-VWdnZ2d@giganews.com>
<1702717b-0369-4388-99c5-765f9fedc54en@googlegroups.com>
<87o8j3djj9.fsf@bsb.me.uk> <8OGdnawuHrSQPEzCnZ2dnUU7-bXNnZ2d@giganews.com>
<87ft4a8vdr.fsf@bsb.me.uk> <oPOdnaQ4DramzkjCnZ2dnUU7-bmdnZ2d@giganews.com>
<87v9d57srg.fsf@bsb.me.uk> <yK2dnXzXs69GQkXCnZ2dnUU7-dvNnZ2d@giganews.com>
<875z5262oy.fsf@bsb.me.uk> <XKWdnc8Hn9oQzkTCnZ2dnUU7-RHNnZ2d@giganews.com>
<877dpi4ksa.fsf@bsb.me.uk> <S7WdnVxdtqB7-0TCnZ2dnUU7-TPNnZ2d@giganews.com>
<6b106784-3f6a-44c3-ad5b-646adba93fe6n@googlegroups.com>
<IoGdndKfvMgzw0fCnZ2dnUU7-WvNnZ2d@giganews.com> <rrdomo$4ta$1@dont-email.me>
<If6dnUUqRMbH9UfCnZ2dnUU7-e_NnZ2d@giganews.com>
From: flib...@i42.REMOVETHISBIT.co.uk (Mr Flibble)
Organization: Jupiter Mining Corporation
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.6.0
MIME-Version: 1.0
In-Reply-To: <If6dnUUqRMbH9UfCnZ2dnUU7-e_NnZ2d@giganews.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
Lines: 118
Message-ID: <8%tCH.414918$IbZ9.290031@fx10.ams4>
X-Complaints-To: abuse@eweka.nl
NNTP-Posting-Date: Wed, 16 Dec 2020 20:21:24 UTC
Date: Wed, 16 Dec 2020 20:21:25 +0000
X-Received-Bytes: 7306
View all headers
On 16/12/2020 20:04, olcott wrote:
On 12/16/2020 1:55 PM, André G. Isaak wrote:
On 2020-12-16 12:23, olcott wrote:
On 12/16/2020 7:48 AM, Malcolm McLean wrote:
On Wednesday, 16 December 2020 at 01:46:22 UTC, olcott wrote:
On 12/15/2020 7:11 PM, Ben Bacarisse wrote:
olcott <No...@NoWhere.com> writes:

On 12/15/2020 5:59 PM, Ben Bacarisse wrote:
olcott <No...@NoWhere.com> writes:

On 12/13/2020 7:14 AM, Ben Bacarisse wrote:
Code for contex:

bool Halts(u32 P, u32 I)
{
bool Halted = false;
bool Aborted = false;
while (!Halted && !Aborted)
{
Halted = DebugStep(P, I);
Aborted = Needs_To_Be_Aborted();
}
return !Aborted;

void Confound_Halts(u32 P) { if (Halts(P, P)) while (1); }

olcott <No...@NoWhere.com> writes:

On 12/12/2020 5:20 PM, Ben Bacarisse wrote:
<cut>
As far as my original point is concerned you have already said that Halts
does not meet the challenge. You've agreed that

(a) Halts(Confound_Halts, Confound_Halts) is false, and
(b) Confound_Halts(Confound_Halts) is a finite computation.

(b) Confound_Halts(Confound_Halts) IS NOT A FINITE COMPUTATION

I am aware that you have said both. What you have not done is retract
what you said before*, namely that the input to halts is a finite
computation. You can't expect to get away with saying both, you need to
say that you were wrong before.

This is the first point that needs to be resolved. Were you wrong when
you described the computation passed to Halts as finite? You qualified
it -- "it's only finite because...", but I'd still be dead even if I were
only dead because I jumped off a cliff.

Anyway, it seems you are now adamant that, despite what you said before,
Confound_Halts(Confound_Halts) is not a finite computation. There are
only two ways that that can happen. Reminder:

void Confound_Halts(u32 P) { if (Halts(P, P)) while (1); }

(1) Halts(Confound_Halts, Confound_Halts) returns true when called in
the above function; or

(2) Halts(Confound_Halts, Confound_Halts) does not return when called in
the above function.

(3) When Halts(Confound_Halts, Confound_Halts) is called by main() this
is similar to wrapping a divide by zero error with a try catch block.
Halts() returns a value of 0 or 1.

When Confound_Halts(Confound_Halts) is called by main() this is similar
to divide by zero error that has not been caught by a try-catch block.
The operating system abnormally terminates the application with an
[infinite execution] @ machine address fatal error.

So this is reasonable. Everything is run under a supervisor which detects
non-stopping behaviour and aborts. Halts catches the detection when
called at top level. When not called at top level, the supervisor catches
the detection.

So it looks superficially as if Halts at top level is a pure function. That's as
much as anyone sane would expect or demand. Halts can't be really a
pure function because it changes its behaviour when called from Confound_
Halts() .

It must interact with the supervisor in some way. But that is quite well
hidden, and the supervisor set-up sounds innocuous enough at first sight.After
all, you need some framework for running Turing machines, and for stopping
them when they get caught in infinite loops (or exceed the patience of
the user).

You haven't met Ben's challenge because of this


Ben's challenge seemed to be self-contradictory adding the arbitrary requirement that a halt decider is either not allowed detect when another function is invoking it in infinite recursion

Halts-->H_Hat-->Halts  // second call to Halts

or whenever the halt decider does detect itself being invoked in infinite recursion this infinitely recursive invocation (the second one diagrammed above) must return a value to its caller even though no infinitely recursive invocations ever return values to their caller.

Since I have a complete execution trace of the halt decider deciding H_Hat correctly Ben's arbitrary requirement has no actual basis.

There's nothing arbitrary here. The requirement is that Halts() must be *self-consistent*. That's a requirement which any solution to any problem has.

According to you:

(1) You call Halts(H_Hat, H_Hat)
(2) This in turn emulates H_Hat(H_Hat)
(3) This in turn emulates Halts(H_Hat, H_Hat)
(4) Your call in (1) aborts this as non-halting.

The problem is that the call in (1) and the call in (3) are *identical*

No they are not. Call (1) has a much longer execution trace to examine than call (3).  I have said this at least fifty times.

At least fifty-one times?

Soon to be fifty-two times, and fifty-three? Because you think you are right when EVERYBODY ELSE thinks you are wrong.

/Flibble

--
😎


Subject: Re: Refuting the {Linz, Sipser, Kozen} HP Proofs (Ben's example)
From: Jeff Barnett
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng
Organization: A noiseless patient Spider
Date: Wed, 16 Dec 2020 20:33 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: jbb...@notatt.com (Jeff Barnett)
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng
Subject: Re: Refuting the {Linz, Sipser, Kozen} HP Proofs (Ben's example)
Date: Wed, 16 Dec 2020 13:33:50 -0700
Organization: A noiseless patient Spider
Lines: 161
Message-ID: <rrdqvi$mh6$1@dont-email.me>
References: <3JSdnRrpiNHInV3CnZ2dnUU7-YHNnZ2d@giganews.com>
<20201207211640.ab3cf977e95bac160b406d58@gmail.com>
<87lfe9mat5.fsf@bsb.me.uk>
<20201209144312.3fa9e12d9eb9f6e65a6bf909@gmail.com>
<20201209144609.d72f65772754e159081986d3@gmail.com>
<rqqg0h$jn8$1@dont-email.me>
<cadb3cac-1359-4e7d-ad13-611e6c65199en@googlegroups.com>
<XPadnV3i4dHqeE3CnZ2dnUU7-VWdnZ2d@giganews.com>
<1702717b-0369-4388-99c5-765f9fedc54en@googlegroups.com>
<87o8j3djj9.fsf@bsb.me.uk> <8OGdnawuHrSQPEzCnZ2dnUU7-bXNnZ2d@giganews.com>
<87ft4a8vdr.fsf@bsb.me.uk> <oPOdnaQ4DramzkjCnZ2dnUU7-bmdnZ2d@giganews.com>
<87v9d57srg.fsf@bsb.me.uk> <yK2dnXzXs69GQkXCnZ2dnUU7-dvNnZ2d@giganews.com>
<875z5262oy.fsf@bsb.me.uk> <XKWdnc8Hn9oQzkTCnZ2dnUU7-RHNnZ2d@giganews.com>
<877dpi4ksa.fsf@bsb.me.uk> <S7WdnVxdtqB7-0TCnZ2dnUU7-TPNnZ2d@giganews.com>
<6b106784-3f6a-44c3-ad5b-646adba93fe6n@googlegroups.com>
<IoGdndKfvMgzw0fCnZ2dnUU7-WvNnZ2d@giganews.com> <rrdomo$4ta$1@dont-email.me>
<If6dnUUqRMbH9UfCnZ2dnUU7-e_NnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Injection-Date: Wed, 16 Dec 2020 20:33:54 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="a0d0ad17ead44f0733f7412467a5800e";
logging-data="23078"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19YurOpAB2LVf3jGRwIpY1yLhY0q/YvhsE="
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.5.1
Cancel-Lock: sha1:hidhhgoUym8/RxonwRkFU3sQoFA=
In-Reply-To: <If6dnUUqRMbH9UfCnZ2dnUU7-e_NnZ2d@giganews.com>
Content-Language: en-US
View all headers
On 12/16/2020 1:04 PM, olcott wrote:
On 12/16/2020 1:55 PM, André G. Isaak wrote:
On 2020-12-16 12:23, olcott wrote:
On 12/16/2020 7:48 AM, Malcolm McLean wrote:
On Wednesday, 16 December 2020 at 01:46:22 UTC, olcott wrote:
On 12/15/2020 7:11 PM, Ben Bacarisse wrote:
olcott <No...@NoWhere.com> writes:

On 12/15/2020 5:59 PM, Ben Bacarisse wrote:
olcott <No...@NoWhere.com> writes:

On 12/13/2020 7:14 AM, Ben Bacarisse wrote:
Code for contex:

bool Halts(u32 P, u32 I)
{
bool Halted = false;
bool Aborted = false;
while (!Halted && !Aborted)
{
Halted = DebugStep(P, I);
Aborted = Needs_To_Be_Aborted();
}
return !Aborted;

void Confound_Halts(u32 P) { if (Halts(P, P)) while (1); }

olcott <No...@NoWhere.com> writes:

On 12/12/2020 5:20 PM, Ben Bacarisse wrote:
<cut>
As far as my original point is concerned you have already said that Halts
does not meet the challenge. You've agreed that

(a) Halts(Confound_Halts, Confound_Halts) is false, and
(b) Confound_Halts(Confound_Halts) is a finite computation.

(b) Confound_Halts(Confound_Halts) IS NOT A FINITE COMPUTATION

I am aware that you have said both. What you have not done is retract
what you said before*, namely that the input to halts is a finite
computation. You can't expect to get away with saying both, you need to
say that you were wrong before.

This is the first point that needs to be resolved. Were you wrong when
you described the computation passed to Halts as finite? You qualified
it -- "it's only finite because...", but I'd still be dead even if I were
only dead because I jumped off a cliff.

Anyway, it seems you are now adamant that, despite what you said before,
Confound_Halts(Confound_Halts) is not a finite computation. There are
only two ways that that can happen. Reminder:

void Confound_Halts(u32 P) { if (Halts(P, P)) while (1); }

(1) Halts(Confound_Halts, Confound_Halts) returns true when called in
the above function; or

(2) Halts(Confound_Halts, Confound_Halts) does not return when called in
the above function.

(3) When Halts(Confound_Halts, Confound_Halts) is called by main() this
is similar to wrapping a divide by zero error with a try catch block.
Halts() returns a value of 0 or 1.

When Confound_Halts(Confound_Halts) is called by main() this is similar
to divide by zero error that has not been caught by a try-catch block.
The operating system abnormally terminates the application with an
[infinite execution] @ machine address fatal error.

So this is reasonable. Everything is run under a supervisor which detects
non-stopping behaviour and aborts. Halts catches the detection when
called at top level. When not called at top level, the supervisor catches
the detection.

So it looks superficially as if Halts at top level is a pure function. That's as
much as anyone sane would expect or demand. Halts can't be really a
pure function because it changes its behaviour when called from Confound_
Halts() .

It must interact with the supervisor in some way. But that is quite well
hidden, and the supervisor set-up sounds innocuous enough at first sight.After
all, you need some framework for running Turing machines, and for stopping
them when they get caught in infinite loops (or exceed the patience of
the user).

You haven't met Ben's challenge because of this


Ben's challenge seemed to be self-contradictory adding the arbitrary requirement that a halt decider is either not allowed detect when another function is invoking it in infinite recursion

Halts-->H_Hat-->Halts  // second call to Halts

or whenever the halt decider does detect itself being invoked in infinite recursion this infinitely recursive invocation (the second one diagrammed above) must return a value to its caller even though no infinitely recursive invocations ever return values to their caller.

Since I have a complete execution trace of the halt decider deciding H_Hat correctly Ben's arbitrary requirement has no actual basis.

There's nothing arbitrary here. The requirement is that Halts() must be *self-consistent*. That's a requirement which any solution to any problem has.

According to you:

(1) You call Halts(H_Hat, H_Hat)
(2) This in turn emulates H_Hat(H_Hat)
(3) This in turn emulates Halts(H_Hat, H_Hat)
(4) Your call in (1) aborts this as non-halting.

The problem is that the call in (1) and the call in (3) are *identical*

No they are not. Call (1) has a much longer execution trace to examine than call (3).  I have said this at least fifty times.

And you have been wrong 50 times in that case. The only explanation that seems to fit is that you don't know what "self-consistent" means. If you ask Andre, I sure he would explain it to you.
--
Jeff Barnett



Subject: Re: Refuting the {Linz, Sipser, Kozen} HP Proofs (Ben's example)
From: Kaz Kylheku
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng
Followup: comp.theory
Organization: Aioe.org NNTP Server
Date: Wed, 16 Dec 2020 20:44 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
Path: i2pn2.org!i2pn.org!usenet.goja.nl.eu.org!aioe.org!opIzC+UpU1FF0qsNaB+JHA.user.gioia.aioe.org.POSTED!not-for-mail
From: 563-365-...@kylheku.com (Kaz Kylheku)
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng
Subject: Re: Refuting the {Linz, Sipser, Kozen} HP Proofs (Ben's example)
Followup-To: comp.theory
Date: Wed, 16 Dec 2020 20:44:06 +0000 (UTC)
Organization: Aioe.org NNTP Server
Lines: 47
Message-ID: <20201216123021.901@kylheku.com>
References: <3JSdnRrpiNHInV3CnZ2dnUU7-YHNnZ2d@giganews.com>
<20201207211640.ab3cf977e95bac160b406d58@gmail.com>
<87lfe9mat5.fsf@bsb.me.uk>
<20201209144312.3fa9e12d9eb9f6e65a6bf909@gmail.com>
<20201209144609.d72f65772754e159081986d3@gmail.com>
<rqqg0h$jn8$1@dont-email.me>
<cadb3cac-1359-4e7d-ad13-611e6c65199en@googlegroups.com>
<XPadnV3i4dHqeE3CnZ2dnUU7-VWdnZ2d@giganews.com>
<1702717b-0369-4388-99c5-765f9fedc54en@googlegroups.com>
<87o8j3djj9.fsf@bsb.me.uk> <8OGdnawuHrSQPEzCnZ2dnUU7-bXNnZ2d@giganews.com>
<87ft4a8vdr.fsf@bsb.me.uk> <oPOdnaQ4DramzkjCnZ2dnUU7-bmdnZ2d@giganews.com>
<87v9d57srg.fsf@bsb.me.uk> <yK2dnXzXs69GQkXCnZ2dnUU7-dvNnZ2d@giganews.com>
<875z5262oy.fsf@bsb.me.uk> <XKWdnc8Hn9oQzkTCnZ2dnUU7-RHNnZ2d@giganews.com>
<877dpi4ksa.fsf@bsb.me.uk> <S7WdnVxdtqB7-0TCnZ2dnUU7-TPNnZ2d@giganews.com>
<6b106784-3f6a-44c3-ad5b-646adba93fe6n@googlegroups.com>
<IoGdndKfvMgzw0fCnZ2dnUU7-WvNnZ2d@giganews.com>
<rrdomo$4ta$1@dont-email.me>
<If6dnUUqRMbH9UfCnZ2dnUU7-e_NnZ2d@giganews.com>
NNTP-Posting-Host: opIzC+UpU1FF0qsNaB+JHA.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Complaints-To: abuse@aioe.org
User-Agent: slrn/1.0.3 (Linux)
X-Notice: Filtered by postfilter v. 0.9.2
View all headers
On 2020-12-16, olcott <NoOne@NoWhere.com> wrote:
On 12/16/2020 1:55 PM, André G. Isaak wrote:
According to you:

(1) You call Halts(H_Hat, H_Hat)
(2) This in turn emulates H_Hat(H_Hat)
(3) This in turn emulates Halts(H_Hat, H_Hat)
(4) Your call in (1) aborts this as non-halting.

The problem is that the call in (1) and the call in (3) are *identical*

No they are not. Call (1) has a much longer execution trace to examine
than call (3).  I have said this at least fifty times.

And that is invalid. Two instances of the same TM are effectively one
and the same object. Their executions are absolutely identical.

If we initialize a TM with the same initial tape contents, the steps it
produces will be absolutely the same.

What you have is that (1) and (3) are different TMs, which only look the
same at the source and machine code level.

What's making them different is the manipulation by the supervising
emulator. That emulator contains state, and it perturbs their execution
basedon that state.

By this dihonest (, perhaps better described as shockingly naive)
ruse, you are turning pure-looking functions into impure procedures in a
way that does not show up in their source or compiled code.

The presence of this interfering mechanism takes away our intellectual
right to consider those C functions to be pure functions of their
arguments, as required.

The proofs that you're trying to discredit use pseudo-coded functions
instead of tape-based Turing Machines. The equivalence between the two
depends on the assumption that those functions being pure: they cannot
be procedures which rely on mutable external state, such as a total
execution history of the system or whatever.

I guarantee you that nobody in CS academia at any post-undergraduate
level is going to fall for this lame nonsense.


--
TXR Programming Language: http://nongnu.org/txr


Subject: Re: Refuting the {Linz, Sipser, Kozen} HP Proofs (Ben's example)
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng
Date: Wed, 16 Dec 2020 21:00 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
Path: i2pn2.org!i2pn.org!aioe.org!peer01.ams4!peer.am4.highwinds-media.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Wed, 16 Dec 2020 15:00:52 -0600
Subject: Re: Refuting the {Linz, Sipser, Kozen} HP Proofs (Ben's example)
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng
References: <3JSdnRrpiNHInV3CnZ2dnUU7-YHNnZ2d@giganews.com>
<87lfe9mat5.fsf@bsb.me.uk>
<20201209144312.3fa9e12d9eb9f6e65a6bf909@gmail.com>
<20201209144609.d72f65772754e159081986d3@gmail.com>
<rqqg0h$jn8$1@dont-email.me>
<cadb3cac-1359-4e7d-ad13-611e6c65199en@googlegroups.com>
<XPadnV3i4dHqeE3CnZ2dnUU7-VWdnZ2d@giganews.com>
<1702717b-0369-4388-99c5-765f9fedc54en@googlegroups.com>
<87o8j3djj9.fsf@bsb.me.uk> <8OGdnawuHrSQPEzCnZ2dnUU7-bXNnZ2d@giganews.com>
<87ft4a8vdr.fsf@bsb.me.uk> <oPOdnaQ4DramzkjCnZ2dnUU7-bmdnZ2d@giganews.com>
<87v9d57srg.fsf@bsb.me.uk> <yK2dnXzXs69GQkXCnZ2dnUU7-dvNnZ2d@giganews.com>
<875z5262oy.fsf@bsb.me.uk> <XKWdnc8Hn9oQzkTCnZ2dnUU7-RHNnZ2d@giganews.com>
<877dpi4ksa.fsf@bsb.me.uk> <S7WdnVxdtqB7-0TCnZ2dnUU7-TPNnZ2d@giganews.com>
<6b106784-3f6a-44c3-ad5b-646adba93fe6n@googlegroups.com>
<IoGdndKfvMgzw0fCnZ2dnUU7-WvNnZ2d@giganews.com> <rrdomo$4ta$1@dont-email.me>
<If6dnUUqRMbH9UfCnZ2dnUU7-e_NnZ2d@giganews.com> <rrdqe4$i7d$1@dont-email.me>
From: NoO...@NoWhere.com (olcott)
Date: Wed, 16 Dec 2020 15:00:51 -0600
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.5.1
MIME-Version: 1.0
In-Reply-To: <rrdqe4$i7d$1@dont-email.me>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <kOydnRDlOZQZ6EfCnZ2dnUU7-XPNnZ2d@giganews.com>
Lines: 46
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-k9N8kWZqdaWYbi5BnK0cdRPPe0jcgbSEEaDwz38C66EG0nmOJ3x5J3ioxd7btWeazicv8eZJRwp+RjO!LNVtUm1lMamqC/64Ma6t77CibErrdXpCZb+QamPkcJb1HVk0sDCe/gJg+ZUjlROkoEldAFJQXrT1
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: 3851
X-Received-Bytes: 4063
View all headers
On 12/16/2020 2:24 PM, André G. Isaak wrote:
On 2020-12-16 13:04, olcott wrote:
On 12/16/2020 1:55 PM, André G. Isaak wrote:

<snippage>

There's nothing arbitrary here. The requirement is that Halts() must be *self-consistent*. That's a requirement which any solution to any problem has.

According to you:

(1) You call Halts(H_Hat, H_Hat)
(2) This in turn emulates H_Hat(H_Hat)
(3) This in turn emulates Halts(H_Hat, H_Hat)
(4) Your call in (1) aborts this as non-halting.

The problem is that the call in (1) and the call in (3) are *identical*

No they are not. Call (1) has a much longer execution trace to examine than call (3).  I have said this at least fifty times.

The above is entirely irrelevant.

In both cases, you are calling the *same* function with the *same* input.
It it not the same input.

In (1) Halts has seen H_Hat() call Halts() two times from the same machine address without any control flow instructions in between thus meeting the infinite recursion criteria.

In (3) Halts has not seen H_Hat() call Halts() two times from the same machine address without any control flow instructions in between thus NOT meeting the infinite recursion criteria.

If you would pay attention to what I actually say and not merely glance at a few words for the purpose of contriving a rebuttal that would fool others that are also not paying attention you would not make dumb mistakes like this one.

--
Copyright 2020 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre minds." Einstein


Subject: Re: Refuting the {Linz, Sipser, Kozen} HP Proofs (Ben's example)
From: Kaz Kylheku
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng
Followup: comp.theory
Organization: Aioe.org NNTP Server
Date: Wed, 16 Dec 2020 21:09 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
Path: i2pn2.org!i2pn.org!aioe.org!opIzC+UpU1FF0qsNaB+JHA.user.gioia.aioe.org.POSTED!not-for-mail
From: 563-365-...@kylheku.com (Kaz Kylheku)
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng
Subject: Re: Refuting the {Linz, Sipser, Kozen} HP Proofs (Ben's example)
Followup-To: comp.theory
Date: Wed, 16 Dec 2020 21:09:22 +0000 (UTC)
Organization: Aioe.org NNTP Server
Lines: 71
Message-ID: <20201216130303.17@kylheku.com>
References: <3JSdnRrpiNHInV3CnZ2dnUU7-YHNnZ2d@giganews.com>
<20201209144312.3fa9e12d9eb9f6e65a6bf909@gmail.com>
<20201209144609.d72f65772754e159081986d3@gmail.com>
<rqqg0h$jn8$1@dont-email.me>
<cadb3cac-1359-4e7d-ad13-611e6c65199en@googlegroups.com>
<XPadnV3i4dHqeE3CnZ2dnUU7-VWdnZ2d@giganews.com>
<1702717b-0369-4388-99c5-765f9fedc54en@googlegroups.com>
<87o8j3djj9.fsf@bsb.me.uk> <8OGdnawuHrSQPEzCnZ2dnUU7-bXNnZ2d@giganews.com>
<87ft4a8vdr.fsf@bsb.me.uk> <oPOdnaQ4DramzkjCnZ2dnUU7-bmdnZ2d@giganews.com>
<87v9d57srg.fsf@bsb.me.uk> <yK2dnXzXs69GQkXCnZ2dnUU7-dvNnZ2d@giganews.com>
<875z5262oy.fsf@bsb.me.uk> <XKWdnc8Hn9oQzkTCnZ2dnUU7-RHNnZ2d@giganews.com>
<877dpi4ksa.fsf@bsb.me.uk> <S7WdnVxdtqB7-0TCnZ2dnUU7-TPNnZ2d@giganews.com>
<6b106784-3f6a-44c3-ad5b-646adba93fe6n@googlegroups.com>
<IoGdndKfvMgzw0fCnZ2dnUU7-WvNnZ2d@giganews.com>
<rrdomo$4ta$1@dont-email.me>
<If6dnUUqRMbH9UfCnZ2dnUU7-e_NnZ2d@giganews.com>
<rrdqe4$i7d$1@dont-email.me>
<kOydnRDlOZQZ6EfCnZ2dnUU7-XPNnZ2d@giganews.com>
NNTP-Posting-Host: opIzC+UpU1FF0qsNaB+JHA.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Complaints-To: abuse@aioe.org
User-Agent: slrn/1.0.3 (Linux)
X-Notice: Filtered by postfilter v. 0.9.2
View all headers
["Followup-To:" header set to comp.theory.]
On 2020-12-16, olcott <NoOne@NoWhere.com> wrote:
On 12/16/2020 2:24 PM, André G. Isaak wrote:
On 2020-12-16 13:04, olcott wrote:
On 12/16/2020 1:55 PM, André G. Isaak wrote:

<snippage>

There's nothing arbitrary here. The requirement is that Halts() must
be *self-consistent*. That's a requirement which any solution to any
problem has.

According to you:

(1) You call Halts(H_Hat, H_Hat)
(2) This in turn emulates H_Hat(H_Hat)
(3) This in turn emulates Halts(H_Hat, H_Hat)
(4) Your call in (1) aborts this as non-halting.

The problem is that the call in (1) and the call in (3) are *identical*

No they are not. Call (1) has a much longer execution trace to examine
than call (3).  I have said this at least fifty times.

The above is entirely irrelevant.

In both cases, you are calling the *same* function with the *same*
input.
It it not the same input.

OK, at least you admit that.

But then, what is left of your argument?

You have, effectively, this:

void H_Hat(u32 P)
{
   if (Halts(P, P, EXTRA_INPUT_A))
     for (;;) { }
   else
     return;
}

int main(void)
{
   if (Halts((u32) H_Hat, (u32) H_Hat, EXTRA_INPUT_B))
     puts("H_Hat(H_Hat) halts!")
   else
     puts("H_Hat(H_Hat) doesn't halt!")
}


This is no longer the "attack template" used in the proofs.

  Halts(H_Hat, H_Hat, EXTRA_INPUT_A)

has nothing to do with:

  Halts(H_Hat, H_Hat, EXTRA_INPUT_B)

The third argument could be an opcode that turns it into a different
function.

  #define Bobs_Halt(P, I) Halts(P, I, EXTRA_INPUT_A);
  #define Dougs_Halt(P, I) Halts(P, I, EXTRA_INPUT_B);

Yes, H_Hat trying to behave opposite to what Bob's Halt decies is a
situation that can be decidable by Doug's Halt.

Nothing surprising or controversial there.


Subject: Re: Refuting the {Linz, Sipser, Kozen} HP Proofs (Ben's example)
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng
Date: Wed, 16 Dec 2020 22:37 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
Path: i2pn2.org!i2pn.org!paganini.bofh.team!news.dns-netz.com!news.freedyn.net!newsfeed.xs4all.nl!newsfeed7.news.xs4all.nl!tr3.eu1.usenetexpress.com!feeder.usenetexpress.com!tr1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Wed, 16 Dec 2020 16:37:44 -0600
Subject: Re: Refuting the {Linz, Sipser, Kozen} HP Proofs (Ben's example)
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng
References: <3JSdnRrpiNHInV3CnZ2dnUU7-YHNnZ2d@giganews.com> <20201209144609.d72f65772754e159081986d3@gmail.com> <rqqg0h$jn8$1@dont-email.me> <cadb3cac-1359-4e7d-ad13-611e6c65199en@googlegroups.com> <XPadnV3i4dHqeE3CnZ2dnUU7-VWdnZ2d@giganews.com> <1702717b-0369-4388-99c5-765f9fedc54en@googlegroups.com> <87o8j3djj9.fsf@bsb.me.uk> <8OGdnawuHrSQPEzCnZ2dnUU7-bXNnZ2d@giganews.com> <87ft4a8vdr.fsf@bsb.me.uk> <oPOdnaQ4DramzkjCnZ2dnUU7-bmdnZ2d@giganews.com> <87v9d57srg.fsf@bsb.me.uk> <yK2dnXzXs69GQkXCnZ2dnUU7-dvNnZ2d@giganews.com> <875z5262oy.fsf@bsb.me.uk> <XKWdnc8Hn9oQzkTCnZ2dnUU7-RHNnZ2d@giganews.com> <877dpi4ksa.fsf@bsb.me.uk> <S7WdnVxdtqB7-0TCnZ2dnUU7-TPNnZ2d@giganews.com> <6b106784-3f6a-44c3-ad5b-646adba93fe6n@googlegroups.com> <IoGdndKfvMgzw0fCnZ2dnUU7-WvNnZ2d@giganews.com> <rrdomo$4ta$1@dont-email.me> <If6dnUUqRMbH9UfCnZ2dnUU7-e_NnZ2d@giganews.com> <rrdqe4$i7d$1@dont-email.me> <kOydnRDlOZQZ6EfCnZ2dnUU7-XPNnZ2d@giganews.com> <rrdtd6$a4j$1@dont-email.me>
From: NoO...@NoWhere.com (olcott)
Date: Wed, 16 Dec 2020 16:37:43 -0600
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1
MIME-Version: 1.0
In-Reply-To: <rrdtd6$a4j$1@dont-email.me>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <DaGdnXUvT8KlEUfCnZ2dnUU7-VXNnZ2d@giganews.com>
Lines: 85
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-LzVJV0b3b6uo73+kuuMVoqBJM+evMvzUCP0fMbPKk6UL97FBYes3KQgy8Ic6GkvWvuGL0KZIK+9sJDY!8Q3MSbOB/L4Tv00Umg3kHnRPwEnfpn0FfOP1pZhQoI8LT/z08hUOVtQqfUe4j36Fc20iX4m8Iaih
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: 5245
View all headers
On 12/16/2020 3:15 PM, André G. Isaak wrote:
On 2020-12-16 14:00, olcott wrote:
On 12/16/2020 2:24 PM, André G. Isaak wrote:
On 2020-12-16 13:04, olcott wrote:
On 12/16/2020 1:55 PM, André G. Isaak wrote:

<snippage>

There's nothing arbitrary here. The requirement is that Halts() must be *self-consistent*. That's a requirement which any solution to any problem has.

According to you:

(1) You call Halts(H_Hat, H_Hat)
(2) This in turn emulates H_Hat(H_Hat)
(3) This in turn emulates Halts(H_Hat, H_Hat)
(4) Your call in (1) aborts this as non-halting.

The problem is that the call in (1) and the call in (3) are *identical*

No they are not. Call (1) has a much longer execution trace to examine than call (3).  I have said this at least fifty times.

The above is entirely irrelevant.

In both cases, you are calling the *same* function with the *same* input.
It it not the same input.

In (1) you have Halts(H_Hat, H_Hat)
In (3) you have Halts(H_Hat, H_Hat)

That stuff between the parentheses is called "the input". In what possible sense can you claim that Halts(H_Hat, H_Hat) and Halts(H_Hat, H_Hat) have different inputs?


Each invocation of Halts() only examines the x86 instructions that have been invoked since its own invocation.

It is just like a hierarchy of UTMs executing other UTMs. Each UTM can look downward in the hierarchy from where it is in this hierarchy.

(1) Halts() can see the whole hierarchy.
(3) Can only see the UTMs that it has invoked.

In (1) Halts has seen H_Hat() call Halts() two times from the same machine address without any control flow instructions in between thus meeting the infinite recursion criteria.

In (3) Halts has not seen H_Hat() call Halts() two times from the same machine address without any control flow instructions in between thus NOT meeting the infinite recursion criteria.

None of that has anything to do with what the *input* is. What this does amount to is the claim that Halts() behaves differently when being emulated within Halts() than it does otherwise, which means your emulation is broken.


(see what I said above).

If you would pay attention to what I actually say and not merely glance at a few words for the purpose of contriving a rebuttal that would fool others that are also not paying attention you would not make dumb mistakes like this one.

I have made no mistake. You keep raising points intended to rationalize your mistakes, but they are not legitimate, as is clear to everyone on this group who actually understands what the halting problem is.

André


It is more diffcult than I thought so neither of us made any actual mistake.


--
Copyright 2020 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre minds." Einstein


Subject: Re: Refuting the {Linz, Sipser, Kozen} HP Proofs (Ben's example)
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng
Date: Wed, 16 Dec 2020 22:49 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!tr1.eu1.usenetexpress.com!feeder.usenetexpress.com!tr3.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Wed, 16 Dec 2020 16:49:01 -0600
Subject: Re: Refuting the {Linz, Sipser, Kozen} HP Proofs (Ben's example)
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng
References: <3JSdnRrpiNHInV3CnZ2dnUU7-YHNnZ2d@giganews.com> <20201209144609.d72f65772754e159081986d3@gmail.com> <rqqg0h$jn8$1@dont-email.me> <cadb3cac-1359-4e7d-ad13-611e6c65199en@googlegroups.com> <XPadnV3i4dHqeE3CnZ2dnUU7-VWdnZ2d@giganews.com> <1702717b-0369-4388-99c5-765f9fedc54en@googlegroups.com> <87o8j3djj9.fsf@bsb.me.uk> <8OGdnawuHrSQPEzCnZ2dnUU7-bXNnZ2d@giganews.com> <87ft4a8vdr.fsf@bsb.me.uk> <oPOdnaQ4DramzkjCnZ2dnUU7-bmdnZ2d@giganews.com> <87v9d57srg.fsf@bsb.me.uk> <yK2dnXzXs69GQkXCnZ2dnUU7-dvNnZ2d@giganews.com> <875z5262oy.fsf@bsb.me.uk> <XKWdnc8Hn9oQzkTCnZ2dnUU7-RHNnZ2d@giganews.com> <877dpi4ksa.fsf@bsb.me.uk> <S7WdnVxdtqB7-0TCnZ2dnUU7-TPNnZ2d@giganews.com> <6b106784-3f6a-44c3-ad5b-646adba93fe6n@googlegroups.com> <IoGdndKfvMgzw0fCnZ2dnUU7-WvNnZ2d@giganews.com> <rrdomo$4ta$1@dont-email.me> <If6dnUUqRMbH9UfCnZ2dnUU7-e_NnZ2d@giganews.com> <rrdqe4$i7d$1@dont-email.me> <kOydnRDlOZQZ6EfCnZ2dnUU7-XPNnZ2d@giganews.com> <20201216130303.17@kylheku.com>
From: NoO...@NoWhere.com (olcott)
Date: Wed, 16 Dec 2020 16:49:00 -0600
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1
MIME-Version: 1.0
In-Reply-To: <20201216130303.17@kylheku.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <28ydnaYJM_5AE0fCnZ2dnUU7-QfNnZ2d@giganews.com>
Lines: 50
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-IRwCskGLRUYQhXxsJ706L0ZYHX6Y67jBYqGhaZn7W1opTBKgxIxQbPuOwm3P/AQLCgGETf2XG7b4DuV!uh5WI/vvHSQ5i1G3fD9D7mlV2dYXDSnPSfZvet1hTH+HypgwRjkbOQutYtUkK0TDxvaTRxGM39DD
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: 3947
View all headers
On 12/16/2020 3:09 PM, Kaz Kylheku wrote:
["Followup-To:" header set to comp.theory.]
On 2020-12-16, olcott <NoOne@NoWhere.com> wrote:
On 12/16/2020 2:24 PM, André G. Isaak wrote:
On 2020-12-16 13:04, olcott wrote:
On 12/16/2020 1:55 PM, André G. Isaak wrote:

<snippage>

There's nothing arbitrary here. The requirement is that Halts() must
be *self-consistent*. That's a requirement which any solution to any
problem has.

According to you:

(1) You call Halts(H_Hat, H_Hat)
(2) This in turn emulates H_Hat(H_Hat)
(3) This in turn emulates Halts(H_Hat, H_Hat)
(4) Your call in (1) aborts this as non-halting.

The problem is that the call in (1) and the call in (3) are *identical*

No they are not. Call (1) has a much longer execution trace to examine
than call (3).  I have said this at least fifty times.

The above is entirely irrelevant.

In both cases, you are calling the *same* function with the *same*
input.
It it not the same input.

This is no longer the "attack template" used in the proofs.

I waited to respond to your posts until I developed this:

[Debug trace of Halts() deciding halting on H_Hat() ---Halts returns a value to main()]

The x86utm operating system as applied to the halting problem is best thought of as a hierarchy of UTMs executing other UTMs. Each UTM can look downward in the hierarchy from where it is in this hierarchy.

(1) Halts() can see the whole hierarchy.
(3) Can only see the UTMs that it has invoked.

--
Copyright 2020 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre minds." Einstein


Subject: Re: Refuting the {Linz, Sipser, Kozen} HP Proofs (Ben's example)
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng
Date: Wed, 16 Dec 2020 23:43 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.snarked.org!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: Wed, 16 Dec 2020 17:43:52 -0600
Subject: Re: Refuting the {Linz, Sipser, Kozen} HP Proofs (Ben's example)
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng
References: <3JSdnRrpiNHInV3CnZ2dnUU7-YHNnZ2d@giganews.com>
<rqqg0h$jn8$1@dont-email.me>
<cadb3cac-1359-4e7d-ad13-611e6c65199en@googlegroups.com>
<XPadnV3i4dHqeE3CnZ2dnUU7-VWdnZ2d@giganews.com>
<1702717b-0369-4388-99c5-765f9fedc54en@googlegroups.com>
<87o8j3djj9.fsf@bsb.me.uk> <8OGdnawuHrSQPEzCnZ2dnUU7-bXNnZ2d@giganews.com>
<87ft4a8vdr.fsf@bsb.me.uk> <oPOdnaQ4DramzkjCnZ2dnUU7-bmdnZ2d@giganews.com>
<87v9d57srg.fsf@bsb.me.uk> <yK2dnXzXs69GQkXCnZ2dnUU7-dvNnZ2d@giganews.com>
<875z5262oy.fsf@bsb.me.uk> <XKWdnc8Hn9oQzkTCnZ2dnUU7-RHNnZ2d@giganews.com>
<877dpi4ksa.fsf@bsb.me.uk> <S7WdnVxdtqB7-0TCnZ2dnUU7-TPNnZ2d@giganews.com>
<6b106784-3f6a-44c3-ad5b-646adba93fe6n@googlegroups.com>
<IoGdndKfvMgzw0fCnZ2dnUU7-WvNnZ2d@giganews.com> <rrdomo$4ta$1@dont-email.me>
<If6dnUUqRMbH9UfCnZ2dnUU7-e_NnZ2d@giganews.com> <rrdqe4$i7d$1@dont-email.me>
<kOydnRDlOZQZ6EfCnZ2dnUU7-XPNnZ2d@giganews.com> <rrdtd6$a4j$1@dont-email.me>
<DaGdnXUvT8KlEUfCnZ2dnUU7-VXNnZ2d@giganews.com> <rre588$gv5$1@dont-email.me>
From: NoO...@NoWhere.com (olcott)
Date: Wed, 16 Dec 2020 17:43:51 -0600
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.5.1
MIME-Version: 1.0
In-Reply-To: <rre588$gv5$1@dont-email.me>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <N8KdnVLL45clBkfCnZ2dnUU7-e3NnZ2d@giganews.com>
Lines: 92
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-iRcYQH4JRX5QsSrjtPWpu9KyC7CWNFKHGA8rFoQ7JpEsqUF4Jw5tT54pSxxrhFAyOVjCwGnVehbf6QA!htGLn6WLrzdTP/akywSnhed2T/viEsKkPauDFbnmaRU5YdMU4BHvZr9KNDVJWWjimc+3bPLGVRxW
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: 5574
View all headers
On 12/16/2020 5:29 PM, André G. Isaak wrote:
On 2020-12-16 15:37, olcott wrote:
On 12/16/2020 3:15 PM, André G. Isaak wrote:
On 2020-12-16 14:00, olcott wrote:
On 12/16/2020 2:24 PM, André G. Isaak wrote:
On 2020-12-16 13:04, olcott wrote:
On 12/16/2020 1:55 PM, André G. Isaak wrote:

<snippage>

There's nothing arbitrary here. The requirement is that Halts() must be *self-consistent*. That's a requirement which any solution to any problem has.

According to you:

(1) You call Halts(H_Hat, H_Hat)
(2) This in turn emulates H_Hat(H_Hat)
(3) This in turn emulates Halts(H_Hat, H_Hat)
(4) Your call in (1) aborts this as non-halting.

The problem is that the call in (1) and the call in (3) are *identical*

No they are not. Call (1) has a much longer execution trace to examine than call (3).  I have said this at least fifty times.

The above is entirely irrelevant.

In both cases, you are calling the *same* function with the *same* input.
It it not the same input.

In (1) you have Halts(H_Hat, H_Hat)
In (3) you have Halts(H_Hat, H_Hat)

That stuff between the parentheses is called "the input". In what possible sense can you claim that Halts(H_Hat, H_Hat) and Halts(H_Hat, H_Hat) have different inputs?


Each invocation of Halts() only examines the x86 instructions that have been invoked since its own invocation.

It is just like a hierarchy of UTMs executing other UTMs. Each UTM can look downward in the hierarchy from where it is in this hierarchy.

(1) Halts() can see the whole hierarchy.
(3) Can only see the UTMs that it has invoked.

In (1) Halts has seen H_Hat() call Halts() two times from the same machine address without any control flow instructions in between thus meeting the infinite recursion criteria.

In (3) Halts has not seen H_Hat() call Halts() two times from the same machine address without any control flow instructions in between thus NOT meeting the infinite recursion criteria.

None of that has anything to do with what the *input* is. What this does amount to is the claim that Halts() behaves differently when being emulated within Halts() than it does otherwise, which means your emulation is broken.


(see what I said above).

That doesn't address the point about the *input*.


Yes it does.

You claim that your upper Halts(H_Hat, H_Hat) *must* abort the inner one or it would not halt. But the inner one is the exact same function call with the exact same arguments as the outer one.

The first Halts is a UTM that simulates H_Hat that simulates Halts.
Each UTM in the UTM hierarchy can only see the hierarchy beginning with its only slave.

If I actually was incorrect you could point to a specific mistake in this: https://groups.google.com/g/comp.theory/c/P5xftn9F0no

The above proves that every hunch and intuition that I am incorrect is mistaken.



--
Copyright 2020 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre minds." Einstein


Subject: Re: Refuting the {Linz, Sipser, Kozen} HP Proofs (Ben's example)
From: Kaz Kylheku
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng
Followup: comp.theory
Organization: Aioe.org NNTP Server
Date: Thu, 17 Dec 2020 00:21 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
Path: i2pn2.org!i2pn.org!aioe.org!opIzC+UpU1FF0qsNaB+JHA.user.gioia.aioe.org.POSTED!not-for-mail
From: 563-365-...@kylheku.com (Kaz Kylheku)
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng
Subject: Re: Refuting the {Linz, Sipser, Kozen} HP Proofs (Ben's example)
Followup-To: comp.theory
Date: Thu, 17 Dec 2020 00:21:57 +0000 (UTC)
Organization: Aioe.org NNTP Server
Lines: 75
Message-ID: <20201216161232.867@kylheku.com>
References: <3JSdnRrpiNHInV3CnZ2dnUU7-YHNnZ2d@giganews.com>
<rqqg0h$jn8$1@dont-email.me>
<cadb3cac-1359-4e7d-ad13-611e6c65199en@googlegroups.com>
<XPadnV3i4dHqeE3CnZ2dnUU7-VWdnZ2d@giganews.com>
<1702717b-0369-4388-99c5-765f9fedc54en@googlegroups.com>
<87o8j3djj9.fsf@bsb.me.uk> <8OGdnawuHrSQPEzCnZ2dnUU7-bXNnZ2d@giganews.com>
<87ft4a8vdr.fsf@bsb.me.uk> <oPOdnaQ4DramzkjCnZ2dnUU7-bmdnZ2d@giganews.com>
<87v9d57srg.fsf@bsb.me.uk> <yK2dnXzXs69GQkXCnZ2dnUU7-dvNnZ2d@giganews.com>
<875z5262oy.fsf@bsb.me.uk> <XKWdnc8Hn9oQzkTCnZ2dnUU7-RHNnZ2d@giganews.com>
<877dpi4ksa.fsf@bsb.me.uk> <S7WdnVxdtqB7-0TCnZ2dnUU7-TPNnZ2d@giganews.com>
<6b106784-3f6a-44c3-ad5b-646adba93fe6n@googlegroups.com>
<IoGdndKfvMgzw0fCnZ2dnUU7-WvNnZ2d@giganews.com>
<rrdomo$4ta$1@dont-email.me>
<If6dnUUqRMbH9UfCnZ2dnUU7-e_NnZ2d@giganews.com>
<rrdqe4$i7d$1@dont-email.me>
<kOydnRDlOZQZ6EfCnZ2dnUU7-XPNnZ2d@giganews.com>
<20201216130303.17@kylheku.com>
<28ydnaYJM_5AE0fCnZ2dnUU7-QfNnZ2d@giganews.com>
NNTP-Posting-Host: opIzC+UpU1FF0qsNaB+JHA.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Complaints-To: abuse@aioe.org
User-Agent: slrn/1.0.3 (Linux)
X-Notice: Filtered by postfilter v. 0.9.2
View all headers
["Followup-To:" header set to comp.theory.]
On 2020-12-16, olcott <NoOne@NoWhere.com> wrote:
On 12/16/2020 3:09 PM, Kaz Kylheku wrote:
["Followup-To:" header set to comp.theory.]
On 2020-12-16, olcott <NoOne@NoWhere.com> wrote:
On 12/16/2020 2:24 PM, André G. Isaak wrote:
On 2020-12-16 13:04, olcott wrote:
On 12/16/2020 1:55 PM, André G. Isaak wrote:

<snippage>

There's nothing arbitrary here. The requirement is that Halts() must
be *self-consistent*. That's a requirement which any solution to any
problem has.

According to you:

(1) You call Halts(H_Hat, H_Hat)
(2) This in turn emulates H_Hat(H_Hat)
(3) This in turn emulates Halts(H_Hat, H_Hat)
(4) Your call in (1) aborts this as non-halting.

The problem is that the call in (1) and the call in (3) are *identical*

No they are not. Call (1) has a much longer execution trace to examine
than call (3).  I have said this at least fifty times.

The above is entirely irrelevant.

In both cases, you are calling the *same* function with the *same*
input.
It it not the same input.

This is no longer the "attack template" used in the proofs.

I waited to respond to your posts until I developed this:

[Debug trace of Halts() deciding halting on H_Hat() ---Halts returns a
value to main()]

The x86utm operating system as applied to the halting problem is best
thought of as a hierarchy of UTMs executing other UTMs. Each UTM can
look downward in the hierarchy from where it is in this hierarchy.

(1) Halts() can see the whole hierarchy.
(3) Can only see the UTMs that it has invoked.

If Halts is really a pure function of two arguments, and it generates a
hierarchy of UTMs, then every call to Halts with the same two arguments
must generate exactly the same hierarchy of UTMs, and come to exactly
the same conclusion when it examines that hierarchy.

This is true even if one call is nested in the other. If Halts is a pure
function and invoked as Halts(P, I), which generates some structure of
computation, then if that compuation makes a recursive Halts(P, I) call,
that call will generate exactly the same structure of computation (and
so the recursion runs away, generating infinite nestings of that
identical structure).

If some hack is introduced into he execution model such that a nested
Halts(P, I) is distinguishable, then that I'm afraid is invalid.
Halts canno be called a pure function of those two arguments.

At this point, I have repeated the same point more than several times.

You already seem to agree that the two function invocations operate on
some different datum related to the execution sequence, which
constitutes an input that is not reflected in argument list.

This amounts to barking up completely the wrong tree in trying to refute
some class of halting proofs which are expressly rooted in pure
functions, of the arguments beween their parentheses.

--
TXR Programming Language: http://nongnu.org/txr


Subject: Re: Refuting the {Linz, Sipser, Kozen} HP Proofs (Ben's example)
From: Kaz Kylheku
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng
Followup: comp.theory
Organization: Aioe.org NNTP Server
Date: Thu, 17 Dec 2020 00:28 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
Path: i2pn2.org!i2pn.org!aioe.org!opIzC+UpU1FF0qsNaB+JHA.user.gioia.aioe.org.POSTED!not-for-mail
From: 563-365-...@kylheku.com (Kaz Kylheku)
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng
Subject: Re: Refuting the {Linz, Sipser, Kozen} HP Proofs (Ben's example)
Followup-To: comp.theory
Date: Thu, 17 Dec 2020 00:28:51 +0000 (UTC)
Organization: Aioe.org NNTP Server
Lines: 106
Message-ID: <20201216162234.114@kylheku.com>
References: <3JSdnRrpiNHInV3CnZ2dnUU7-YHNnZ2d@giganews.com>
<XPadnV3i4dHqeE3CnZ2dnUU7-VWdnZ2d@giganews.com>
<1702717b-0369-4388-99c5-765f9fedc54en@googlegroups.com>
<87o8j3djj9.fsf@bsb.me.uk> <8OGdnawuHrSQPEzCnZ2dnUU7-bXNnZ2d@giganews.com>
<87ft4a8vdr.fsf@bsb.me.uk> <oPOdnaQ4DramzkjCnZ2dnUU7-bmdnZ2d@giganews.com>
<87v9d57srg.fsf@bsb.me.uk> <yK2dnXzXs69GQkXCnZ2dnUU7-dvNnZ2d@giganews.com>
<875z5262oy.fsf@bsb.me.uk> <XKWdnc8Hn9oQzkTCnZ2dnUU7-RHNnZ2d@giganews.com>
<877dpi4ksa.fsf@bsb.me.uk> <S7WdnVxdtqB7-0TCnZ2dnUU7-TPNnZ2d@giganews.com>
<6b106784-3f6a-44c3-ad5b-646adba93fe6n@googlegroups.com>
<IoGdndKfvMgzw0fCnZ2dnUU7-WvNnZ2d@giganews.com>
<rrdomo$4ta$1@dont-email.me>
<If6dnUUqRMbH9UfCnZ2dnUU7-e_NnZ2d@giganews.com>
<rrdqe4$i7d$1@dont-email.me>
<kOydnRDlOZQZ6EfCnZ2dnUU7-XPNnZ2d@giganews.com>
<rrdtd6$a4j$1@dont-email.me>
<DaGdnXUvT8KlEUfCnZ2dnUU7-VXNnZ2d@giganews.com>
<rre588$gv5$1@dont-email.me>
<N8KdnVLL45clBkfCnZ2dnUU7-e3NnZ2d@giganews.com>
NNTP-Posting-Host: opIzC+UpU1FF0qsNaB+JHA.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Complaints-To: abuse@aioe.org
User-Agent: slrn/1.0.3 (Linux)
X-Notice: Filtered by postfilter v. 0.9.2
View all headers
["Followup-To:" header set to comp.theory.]
On 2020-12-16, olcott <NoOne@NoWhere.com> wrote:
On 12/16/2020 5:29 PM, André G. Isaak wrote:
On 2020-12-16 15:37, olcott wrote:
On 12/16/2020 3:15 PM, André G. Isaak wrote:
On 2020-12-16 14:00, olcott wrote:
On 12/16/2020 2:24 PM, André G. Isaak wrote:
On 2020-12-16 13:04, olcott wrote:
On 12/16/2020 1:55 PM, André G. Isaak wrote:

<snippage>

There's nothing arbitrary here. The requirement is that Halts()
must be *self-consistent*. That's a requirement which any
solution to any problem has.

According to you:

(1) You call Halts(H_Hat, H_Hat)
(2) This in turn emulates H_Hat(H_Hat)
(3) This in turn emulates Halts(H_Hat, H_Hat)
(4) Your call in (1) aborts this as non-halting.

The problem is that the call in (1) and the call in (3) are
*identical*

No they are not. Call (1) has a much longer execution trace to
examine than call (3).  I have said this at least fifty times.

The above is entirely irrelevant.

In both cases, you are calling the *same* function with the *same*
input.
It it not the same input.

In (1) you have Halts(H_Hat, H_Hat)
In (3) you have Halts(H_Hat, H_Hat)

That stuff between the parentheses is called "the input". In what
possible sense can you claim that Halts(H_Hat, H_Hat) and
Halts(H_Hat, H_Hat) have different inputs?


Each invocation of Halts() only examines the x86 instructions that
have been invoked since its own invocation.

It is just like a hierarchy of UTMs executing other UTMs. Each UTM can
look downward in the hierarchy from where it is in this hierarchy.

(1) Halts() can see the whole hierarchy.
(3) Can only see the UTMs that it has invoked.

In (1) Halts has seen H_Hat() call Halts() two times from the same
machine address without any control flow instructions in between
thus meeting the infinite recursion criteria.

In (3) Halts has not seen H_Hat() call Halts() two times from the
same machine address without any control flow instructions in
between thus NOT meeting the infinite recursion criteria.

None of that has anything to do with what the *input* is. What this
does amount to is the claim that Halts() behaves differently when
being emulated within Halts() than it does otherwise, which means
your emulation is broken.


(see what I said above).

That doesn't address the point about the *input*.


Yes it does.

You claim that your upper Halts(H_Hat, H_Hat) *must* abort the inner one
or it would not halt. But the inner one is the exact same function call
with the exact same arguments as the outer one.

The first Halts is a UTM that simulates H_Hat that simulates Halts.

Thus, if Halts is properly a pure funcion, as required, then *every*
halts is a UTM that simulates H_Hat that simulates Halts, and they
are all identical down to infinity.

Each UTM in the UTM hierarchy can only see the hierarchy beginning with
its only slave.

You don't realize that these hierarchies must be identical, in spite
of the nesting. Just like when we zoom in on a fractal, and keep seeing
the same structures. (And other analogies.)

If they are not identical, there is a problem: Halts has a hidden input
not appearing in the arguments, or some other meddling is going on
from the supervising "global" simulator.

Nested hierarchies can have levels that are identical to each other.

If I have an infinite list of identical ducks X, and then I prepend
another identical duck to it to make a list Y, then X and Y are the same
list of ducks.  It's not the case that when I'm looking at Y, I see a
different, longer list of ducks compared to X.

If the lists look different, then it cannot be that what I prepended
is a duck that is identical to the others.

--
TXR Programming Language: http://nongnu.org/txr


Pages:123456789101112131415161718
rocksolid light 0.7.2
clearneti2ptor