Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.theory > #22099 > unrolled thread
| Started by | olcott <NoOne@NoWhere.com> |
|---|---|
| First post | 2020-08-03 13:17 -0500 |
| Last post | 2020-08-07 10:54 -0600 |
| Articles | 20 on this page of 677 — 15 participants |
Back to article view | Back to comp.theory
Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-03 13:17 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-04 01:57 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-03 20:07 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-04 02:45 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-03 21:00 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-04 04:05 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-03 23:29 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) André G. Isaak <agisaak@gm.invalid> - 2020-08-04 00:11 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-04 01:26 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) André G. Isaak <agisaak@gm.invalid> - 2020-08-04 01:01 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-04 09:52 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) André G. Isaak <agisaak@gm.invalid> - 2020-08-04 09:30 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-04 11:23 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) André G. Isaak <agisaak@gm.invalid> - 2020-08-04 19:35 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-04 23:30 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) André G. Isaak <agisaak@gm.invalid> - 2020-08-04 23:10 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-05 00:59 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) André G. Isaak <agisaak@gm.invalid> - 2020-08-05 00:44 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-05 13:04 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) André G. Isaak <agisaak@gm.invalid> - 2020-08-05 19:57 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-05 21:12 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) André G. Isaak <agisaak@gm.invalid> - 2020-08-05 20:27 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-05 22:32 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) André G. Isaak <agisaak@gm.invalid> - 2020-08-05 21:37 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-05 22:34 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-04 15:47 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-04 09:54 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-04 20:44 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-04 14:58 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-05 01:40 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-04 19:46 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-05 02:06 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-04 23:25 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-05 12:49 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-05 13:12 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-05 21:32 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-05 16:18 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-05 23:48 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-05 20:09 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-06 03:13 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-05 22:31 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-06 11:48 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-06 10:47 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-06 20:04 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-06 15:09 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-06 23:03 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-06 18:08 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-07 02:51 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-07 10:25 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-07 17:12 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-07 11:48 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) Kaz Kylheku <793-849-0957@kylheku.com> - 2020-08-07 16:55 +0000
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-07 12:34 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) André G. Isaak <agisaak@gm.invalid> - 2020-08-07 11:13 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-07 12:40 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) André G. Isaak <agisaak@gm.invalid> - 2020-08-07 12:24 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-07 14:46 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) André G. Isaak <agisaak@gm.invalid> - 2020-08-07 20:06 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-07 23:46 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-08 01:01 -0700
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-07 11:29 -0700
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-07 14:58 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-07 13:24 -0700
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-07 16:58 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-07 17:11 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-07 17:40 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-07 15:43 -0700
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) Andy Walker <anw@cuboid.co.uk> - 2020-08-08 11:04 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-08 12:10 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-07 23:41 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-07 18:03 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-08 00:20 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-07 19:11 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-08 01:50 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-07 20:06 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) André G. Isaak <agisaak@gm.invalid> - 2020-08-07 20:21 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-08 03:53 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-08 13:58 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-08 23:06 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-08 00:01 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) André G. Isaak <agisaak@gm.invalid> - 2020-08-08 00:03 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-08 14:18 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) André G. Isaak <agisaak@gm.invalid> - 2020-08-08 13:42 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-08 03:30 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) Jeff Barnett <jbb@notatt.com> - 2020-08-07 23:12 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-08 13:27 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-08 20:17 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-08 14:36 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-08 23:17 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) André G. Isaak <agisaak@gm.invalid> - 2020-08-08 13:38 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-08 15:05 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-08 19:16 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-09 01:32 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-08 19:49 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-09 02:25 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-08 21:41 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) Jeff Barnett <jbb@notatt.com> - 2020-08-08 23:13 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-09 17:27 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-09 12:06 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-09 21:57 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-09 16:30 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-09 14:44 -0700
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-09 17:17 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-10 00:16 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-09 20:27 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-10 03:08 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-09 21:35 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-10 15:02 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-10 10:19 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-10 16:42 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V36 (x86 based Turing machine) olcott <NoOne@NoWhere.com> - 2020-08-10 11:49 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V36 (x86 based Turing machine) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-11 00:35 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-10 18:49 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-10 18:52 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-10 18:58 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-11 03:49 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-11 15:31 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-11 22:16 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-11 16:32 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-11 14:53 -0700
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-11 17:50 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-12 00:53 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-11 20:04 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) Jeff Barnett <jbb@notatt.com> - 2020-08-11 21:25 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-11 22:56 -0700
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-12 13:40 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-12 09:49 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) Kaz Kylheku <793-849-0957@kylheku.com> - 2020-08-12 16:47 +0000
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-12 12:26 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) Kaz Kylheku <793-849-0957@kylheku.com> - 2020-08-12 18:25 +0000
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-12 14:45 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (x86 based UTM) olcott <NoOne@NoWhere.com> - 2020-08-12 15:26 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (x86 based UTM) olcott <NoOne@NoWhere.com> - 2020-08-12 17:23 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-12 21:36 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-12 15:55 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-12 23:00 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-12 17:40 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-13 01:21 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-12 19:54 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-12 18:36 -0700
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-12 21:01 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-13 04:25 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-12 22:39 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) André G. Isaak <agisaak@gm.invalid> - 2020-08-13 02:56 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-13 10:48 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) André G. Isaak <agisaak@gm.invalid> - 2020-08-13 10:51 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-13 12:12 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) André G. Isaak <agisaak@gm.invalid> - 2020-08-13 12:03 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-13 14:17 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) André G. Isaak <agisaak@gm.invalid> - 2020-08-13 22:02 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-13 11:50 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-13 10:40 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-13 20:38 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-13 14:55 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-13 23:17 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-14 09:55 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-14 22:23 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Decidability) olcott <NoOne@NoWhere.com> - 2020-08-14 15:56 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Decidability) David Kleinecke <dkleinecke@gmail.com> - 2020-08-14 14:28 -0700
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Decidability) olcott <NoOne@NoWhere.com> - 2020-08-14 17:08 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Decidability) David Kleinecke <dkleinecke@gmail.com> - 2020-08-14 17:58 -0700
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Decidability) olcott <NoOne@NoWhere.com> - 2020-08-14 20:14 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Decidability) David Kleinecke <dkleinecke@gmail.com> - 2020-08-14 21:03 -0700
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Decidability) olcott <NoOne@NoWhere.com> - 2020-08-14 23:31 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Decidability) olcott <NoOne@NoWhere.com> - 2020-08-15 00:17 -0500
Re: Simply defining G"odel Incompleteness and Tarski Undefinability away V37 (Decidability) R Kym Horsell <kym@kymhorsell.com> - 2020-08-14 23:35 +0000
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Decidability) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-14 22:56 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Decidability) olcott <NoOne@NoWhere.com> - 2020-08-14 18:34 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-13 16:47 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-13 15:02 -0700
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-13 17:18 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-14 00:13 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-14 10:06 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-14 22:33 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-14 00:01 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-13 22:41 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-14 13:50 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) André G. Isaak <agisaak@gm.invalid> - 2020-08-13 03:00 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35? (Gödel) olcott <NoOne@NoWhere.com> - 2020-08-13 10:56 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) André G. Isaak <agisaak@gm.invalid> - 2020-08-11 20:48 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-11 22:37 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) André G. Isaak <agisaak@gm.invalid> - 2020-08-11 22:48 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-12 00:28 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-11 23:14 -0700
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-12 08:23 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) André G. Isaak <agisaak@gm.invalid> - 2020-08-12 01:35 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-12 09:28 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) André G. Isaak <agisaak@gm.invalid> - 2020-08-12 08:40 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-12 09:55 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) André G. Isaak <agisaak@gm.invalid> - 2020-08-12 09:00 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-12 10:24 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) André G. Isaak <agisaak@gm.invalid> - 2020-08-12 09:46 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-12 11:38 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-12 16:04 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-12 10:30 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-12 22:51 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-12 17:08 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-13 00:39 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-12 19:12 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-13 04:11 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-12 22:26 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-13 00:17 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-13 11:16 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V36 (x86 based UTM) olcott <NoOne@NoWhere.com> - 2020-08-13 10:44 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-13 11:34 -0700
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) André G. Isaak <agisaak@gm.invalid> - 2020-08-13 12:46 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-13 14:09 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-13 20:46 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-13 15:29 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-13 23:41 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-13 21:00 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-14 11:05 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V36 (x86 based UTM) olcott <NoOne@NoWhere.com> - 2020-08-13 14:50 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V36 (x86 based UTM) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-13 22:47 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V36 (x86 based UTM) olcott <NoOne@NoWhere.com> - 2020-08-13 16:54 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V36 (x86 based UTM) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-13 23:44 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V36 (x86 based UTM) olcott <NoOne@NoWhere.com> - 2020-08-13 21:11 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V36 (x86 based UTM) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-14 11:29 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V36 (x86 based UTM) Andy Walker <anw@cuboid.co.uk> - 2020-08-14 12:34 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V36 (x86 based UTM) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-14 13:59 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V36 (x86 based UTM) Andy Walker <anw@cuboid.co.uk> - 2020-08-14 16:41 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V38 (x86 is Turing Complete) olcott <NoOne@NoWhere.com> - 2020-08-14 12:10 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V38 (x86 is Turing Complete) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-15 00:48 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V38 (x86 is Turing Complete) olcott <NoOne@NoWhere.com> - 2020-08-14 19:34 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V38 (x86 is Turing Complete) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-15 02:13 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V38 (x86 is Turing Complete) olcott <NoOne@NoWhere.com> - 2020-08-14 23:29 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V38 (x86 is Turing Complete) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-15 17:49 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V38 (x86 is Turing Complete) olcott <NoOne@NoWhere.com> - 2020-08-15 14:31 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V38 (x86 is Turing Complete) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-15 22:34 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V38 (x86 is Turing Complete) olcott <NoOne@NoWhere.com> - 2020-08-15 16:49 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V38 (x86 is Turing Complete) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-15 23:40 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V36 (x86 based UTM) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-14 21:27 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V36 (x86 based UTM) Andy Walker <anw@cuboid.co.uk> - 2020-08-15 12:13 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V36 (X86 is Turing Complete) olcott <NoOne@NoWhere.com> - 2020-08-15 09:13 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V36 (x86 based UTM) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-15 17:25 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V36 (x86 based UTM) olcott <NoOne@NoWhere.com> - 2020-08-15 12:07 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V36 (x86 based UTM) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-15 20:31 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V36 (x86 based UTM) Jeff Barnett <jbb@notatt.com> - 2020-08-15 13:38 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V36 (x86 based UTM) olcott <NoOne@NoWhere.com> - 2020-08-15 14:52 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V36 (x86 based UTM) Andy Walker <anw@cuboid.co.uk> - 2020-08-15 21:23 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V36 (x86 based UTM) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-15 22:05 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V36 (x86 based UTM) Andy Walker <anw@cuboid.co.uk> - 2020-08-16 00:33 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V36 (x86 based UTM) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-16 02:07 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V36 (x86 based UTM) Jeff Barnett <jbb@notatt.com> - 2020-08-15 16:04 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V39 (x86 is Turing Complete) olcott <NoOne@NoWhere.com> - 2020-08-14 13:28 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V36 (x86 based UTM) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-13 15:14 -0700
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V36 (x86 based UTM) olcott <NoOne@NoWhere.com> - 2020-08-13 18:23 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V36 (x86 based UTM) David Kleinecke <dkleinecke@gmail.com> - 2020-08-13 16:26 -0700
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V36 (x86 based UTM) olcott <NoOne@NoWhere.com> - 2020-08-13 18:44 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-14 17:54 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-15 01:05 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-15 00:29 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-15 20:22 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-15 16:06 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-15 22:59 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-15 17:45 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-16 02:36 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-15 21:07 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-16 13:23 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-16 10:46 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-16 17:41 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-16 12:55 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-16 20:13 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-16 14:33 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-16 20:52 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V40 (x86 is Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-16 15:29 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V40 (x86 is Turing complete) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-16 22:23 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V42 [x86 is Turing complete] olcott <NoOne@NoWhere.com> - 2020-08-16 16:44 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V42 [x86 is Turing complete] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-17 00:07 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V42 [x86 is Turing complete] olcott <NoOne@NoWhere.com> - 2020-08-16 18:17 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V42 [x86 is Turing complete] André G. Isaak <agisaak@gm.invalid> - 2020-08-17 00:44 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V42 [x86 is Turing complete] olcott <NoOne@NoWhere.com> - 2020-08-17 10:20 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V42 [x86 is Turing complete] André G. Isaak <agisaak@gm.invalid> - 2020-08-17 09:35 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V42 [x86 is Turing complete] olcott <NoOne@NoWhere.com> - 2020-08-17 12:16 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V42 [x86 is Turing complete] Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-17 10:53 -0700
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V42 [x86 is Turing complete] olcott <NoOne@NoWhere.com> - 2020-08-17 13:21 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V42 [x86 is Turing complete] Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-17 12:19 -0700
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V42 [x86 is Turing complete] olcott <NoOne@NoWhere.com> - 2020-08-17 16:41 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V42 [x86 is Turing complete] Kaz Kylheku <793-849-0957@kylheku.com> - 2020-08-17 18:12 +0000
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V42 [x86 is Turing complete] olcott <NoOne@NoWhere.com> - 2020-08-17 13:43 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V42 [x86 is Turing complete] olcott <NoOne@NoWhere.com> - 2020-08-17 16:58 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V42 [x86 is Turing complete] olcott <NoOne@NoWhere.com> - 2020-08-21 00:06 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V42 [x86 is Turing complete] ROOKIE MISTAKE olcott <NoOne@NoWhere.com> - 2020-08-23 16:29 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V42 [x86 is Turing complete] ROOKIE MISTAKE Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-23 14:49 -0700
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V42 [x86 is Turing complete] ROOKIE MISTAKE olcott <NoOne@NoWhere.com> - 2020-08-23 17:40 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V42 [x86 is Turing complete] ROOKIE MISTAKE Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-23 17:08 -0700
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V42 [x86 is Turing complete] ROOKIE MISTAKE olcott <NoOne@NoWhere.com> - 2020-08-23 20:19 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V42 [x86 is Turing complete] ROOKIE MISTAKE Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-23 20:47 -0700
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V42 [x86 is Turing complete] ROOKIE MISTAKE olcott <NoOne@NoWhere.com> - 2020-08-23 23:34 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V42 [x86 is Turing complete] ROOKIE MISTAKE Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-23 22:47 -0700
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V42 [x86 is Turing complete] ROOKIE MISTAKE olcott <NoOne@NoWhere.com> - 2020-08-24 01:52 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V42 [x86 is Turing complete] ROOKIE MISTAKE Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-24 00:30 -0700
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V42 [x86 is Turing complete] ROOKIE MISTAKE olcott <NoOne@NoWhere.com> - 2020-08-24 10:55 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V42 [x86 is Turing complete] ROOKIE MISTAKE André G. Isaak <agisaak@gm.invalid> - 2020-08-24 11:40 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V42 [x86 is Turing complete] ROOKIE MISTAKE olcott <NoOne@NoWhere.com> - 2020-08-24 13:26 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V42 [x86 is Turing complete] ROOKIE MISTAKE André G. Isaak <agisaak@gm.invalid> - 2020-08-24 13:23 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V42 [x86 is Turing complete] ROOKIE MISTAKE olcott <NoOne@NoWhere.com> - 2020-08-24 16:02 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V42 [x86 is Turing complete] ROOKIE MISTAKE André G. Isaak <agisaak@gm.invalid> - 2020-08-24 20:30 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V42 [x86 is Turing complete] ROOKIE MISTAKE olcott <NoOne@NoWhere.com> - 2020-08-25 09:34 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V42 [x86 is Turing complete] ROOKIE MISTAKE André G. Isaak <agisaak@gm.invalid> - 2020-08-25 08:56 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V42 [x86 is Turing complete] ROOKIE MISTAKE olcott <NoOne@NoWhere.com> - 2020-08-25 10:34 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V42 [x86 is Turing complete] ROOKIE MISTAKE André G. Isaak <agisaak@gm.invalid> - 2020-08-25 09:59 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V42 [x86 is Turing complete] ROOKIE MISTAKE olcott <NoOne@NoWhere.com> - 2020-08-25 12:00 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V42 [x86 is Turing complete] ROOKIE MISTAKE André G. Isaak <agisaak@gm.invalid> - 2020-08-25 12:39 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V42 [x86 is Turing complete] ROOKIE MISTAKE olcott <NoOne@NoWhere.com> - 2020-08-25 14:37 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V42 [x86 is Turing complete] olcott <NoOne@NoWhere.com> - 2020-08-17 20:17 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-16 16:01 -0700
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-16 18:13 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V46 (x86 is Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-20 19:58 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-21 00:17 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-21 11:20 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V46 (x86 Turing is complete) olcott <NoOne@NoWhere.com> - 2020-08-21 09:31 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V46 (x86 Turing is complete) André G. Isaak <agisaak@gm.invalid> - 2020-08-21 12:17 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V46 (x86 Turing is complete) olcott <NoOne@NoWhere.com> - 2020-08-21 13:46 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V46 (x86 Turing is complete) André G. Isaak <agisaak@gm.invalid> - 2020-08-21 14:14 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V46 (x86 Turing is complete) olcott <NoOne@NoWhere.com> - 2020-08-21 16:27 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V46 (x86 Turing is complete) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-22 01:10 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-21 19:31 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-22 03:06 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-21 21:19 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-21 19:47 -0700
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-21 22:00 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-21 20:12 -0700
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-21 22:22 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-21 22:19 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-22 11:28 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-22 10:31 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-22 22:24 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-22 17:26 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-22 23:36 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-22 18:32 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-23 02:04 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-22 22:42 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-23 00:03 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-23 13:00 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-23 08:51 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-23 16:42 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-23 11:33 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-23 22:14 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-23 16:47 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-24 01:38 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-23 21:27 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-23 21:22 -0700
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-23 23:54 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-24 00:05 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-24 18:18 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-25 01:59 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-24 20:21 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-24 21:29 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-25 03:54 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-25 01:38 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-25 03:37 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-25 09:55 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-25 08:34 -0700
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-25 11:06 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-25 10:28 -0700
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-25 12:51 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) André G. Isaak <agisaak@gm.invalid> - 2020-08-25 12:30 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-25 13:50 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-25 12:50 -0700
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-25 15:14 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-25 12:29 -0700
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-25 14:41 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-25 12:54 -0700
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-25 15:27 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-25 13:38 -0700
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-25 16:36 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-25 23:35 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-25 18:01 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-25 17:07 -0700
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-25 20:07 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-26 16:32 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-26 15:40 -0700
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-26 18:12 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-26 17:31 -0700
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-26 19:52 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-26 03:37 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-25 22:12 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-26 12:58 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-26 09:38 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-26 17:36 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-26 12:26 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-26 20:43 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-26 15:12 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-26 22:40 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) Alan Smaill <smaill@SPAMinf.ed.ac.uk> - 2020-08-26 18:28 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-26 12:36 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-26 19:41 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-26 14:03 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-26 21:17 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-26 15:42 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-26 22:37 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-26 16:47 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-26 15:41 -0700
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-26 18:15 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-26 17:32 -0700
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-26 19:59 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (Chris Rock Speaks for God) olcott <NoOne@NoWhere.com> - 2020-08-26 20:18 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-28 10:12 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-28 10:20 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-28 10:25 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) André G. Isaak <agisaak@gm.invalid> - 2020-08-28 09:39 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-28 11:25 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) André G. Isaak <agisaak@gm.invalid> - 2020-08-28 10:42 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-28 11:59 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-28 11:45 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-28 17:52 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-28 12:08 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) André G. Isaak <agisaak@gm.invalid> - 2020-08-28 11:19 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-28 12:50 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) André G. Isaak <agisaak@gm.invalid> - 2020-08-28 22:34 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) Jeff Barnett <jbb@notatt.com> - 2020-08-29 03:06 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-29 08:27 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) André G. Isaak <agisaak@gm.invalid> - 2020-08-29 07:44 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-29 09:26 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) André G. Isaak <agisaak@gm.invalid> - 2020-08-29 08:58 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-29 10:12 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) André G. Isaak <agisaak@gm.invalid> - 2020-08-30 07:38 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V51 (Turing Equivalent) olcott <NoOne@NoWhere.com> - 2020-08-30 11:11 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-29 10:29 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-29 17:47 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V50 (Can "C" be made Turing complete?) olcott <NoOne@NoWhere.com> - 2020-08-29 12:32 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V50 (Can "C" be made Turing complete?) olcott <NoOne@NoWhere.com> - 2020-08-29 14:01 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V50 (Can "C" be made Turing complete?) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-29 20:03 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V50 (Can "C" be made Turing complete?) olcott <NoOne@NoWhere.com> - 2020-08-29 14:48 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V50 (Can "C" be made Turing complete?) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-29 21:35 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V50 (Can "C" be made Turing complete?) olcott <NoOne@NoWhere.com> - 2020-08-29 16:00 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V50 (Can "C" be made Turing complete?) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-29 23:32 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V50 (Can "C" be made Turing complete?) olcott <NoOne@NoWhere.com> - 2020-08-29 18:20 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V50 (Can "C" be made Turing complete?) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-30 02:24 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V50 (Can "C" be made Turing complete?) olcott <NoOne@NoWhere.com> - 2020-08-29 21:17 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V50 (Can "C" be made Turing complete?) Jeff Barnett <jbb@notatt.com> - 2020-08-29 23:15 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V50 (Can "C" be made Turing complete?) Jeff Barnett <jbb@notatt.com> - 2020-08-29 22:57 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V50 (Can "C" be made Turing complete?) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-29 22:13 -0700
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V50 (Can "C" be made Turing complete?) Jeff Barnett <jbb@notatt.com> - 2020-08-29 23:27 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V50 (Can "C" be made Turing complete?) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-30 03:27 -0700
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V50 (Can "C" be made Turing complete?) olcott <NoOne@NoWhere.com> - 2020-08-29 16:26 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V50 (Can "C" be made Turing complete?) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-29 23:53 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V50 (Can "C" be made Turing complete?) olcott <NoOne@NoWhere.com> - 2020-08-29 18:33 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V50 (Can "C" be made Turing complete?) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-30 02:35 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V50 (Can "C" be made Turing complete?) olcott <NoOne@NoWhere.com> - 2020-08-29 21:36 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V50 (Can "C" be made Turing complete?) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-30 15:38 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V51 (Making "C" Turing equivalent) olcott <NoOne@NoWhere.com> - 2020-08-30 11:42 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V51 (Making "C" Turing equivalent) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-30 20:05 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V51 (Making "C" Turing equivalent) olcott <NoOne@NoWhere.com> - 2020-08-30 14:17 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (Machine equivalence) olcott <NoOne@NoWhere.com> - 2020-08-30 14:37 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (Machine equivalence) David Kleinecke <dkleinecke@gmail.com> - 2020-08-30 13:10 -0700
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (Machine equivalence) olcott <NoOne@NoWhere.com> - 2020-08-30 15:19 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (Machine equivalence) David Kleinecke <dkleinecke@gmail.com> - 2020-08-30 14:22 -0700
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (Machine equivalence) olcott <NoOne@NoWhere.com> - 2020-08-30 16:58 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (Machine equivalence) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-31 02:48 +0100
Re: Simply defining G"odel Incompleteness and Tarski Undefinability away V52 (Machine equivalence) R Kym Horsell <kym@kymhorsell.com> - 2020-08-31 02:08 +0000
Re: Simply defining G"odel Incompleteness and Tarski Undefinability away V52 (Machine equivalence) Andy Walker <anw@cuboid.co.uk> - 2020-08-31 09:49 +0100
Re: Simply defining G"odel Incompleteness and Tarski Undefinability away V52 (Machine equivalence) R Kym Horsell <kym@kymhorsell.com> - 2020-08-31 13:59 +0000
Re: Simply defining G"odel Incompleteness and Tarski Undefinability away V52 (Machine equivalence) Andy Walker <anw@cuboid.co.uk> - 2020-08-31 16:13 +0100
Re: Simply defining G"odel Incompleteness and Tarski Undefinability away V52 (Machine equivalence) R Kym Horsell <kym@kymhorsell.com> - 2020-08-31 15:24 +0000
Re: Simply defining G"odel Incompleteness and Tarski Undefinability away V52 (Machine equivalence) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-31 19:26 +0100
Re: Simply defining G"odel Incompleteness and Tarski Undefinability away V52 (Machine equivalence) R Kym Horsell <kym@kymhorsell.com> - 2020-08-31 21:37 +0000
Re: Simply defining G"odel Incompleteness and Tarski Undefinability away V52 (Machine equivalence) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-31 23:56 +0100
Re: Simply defining G"odel Incompleteness and Tarski Undefinability away V52 (Machine equivalence) R Kym Horsell <kym@kymhorsell.com> - 2020-08-31 23:10 +0000
Re: Simply defining G"odel Incompleteness and Tarski Undefinability away V52 (Machine equivalence) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-09-01 02:28 +0100
Re: Simply defining G"odel Incompleteness and Tarski Undefinability away V52 (Machine equivalence) R Kym Horsell <kym@kymhorsell.com> - 2020-09-01 02:02 +0000
Re: Simply defining G"odel Incompleteness and Tarski Undefinability away V52 (Machine equivalence) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-09-01 03:16 +0100
Re: Simply defining G"odel Incompleteness and Tarski Undefinability away V52 (Machine equivalence) R Kym Horsell <kym@kymhorsell.com> - 2020-09-01 02:29 +0000
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (Machine equivalence) olcott <NoOne@NoWhere.com> - 2020-08-31 08:58 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (Machine equivalence) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-09-01 00:04 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation) olcott <NoOne@NoWhere.com> - 2020-09-02 09:55 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation) olcott <NoOne@NoWhere.com> - 2020-09-02 12:03 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation) André G. Isaak <agisaak@gm.invalid> - 2020-09-03 06:12 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation) olcott <NoOne@NoWhere.com> - 2020-09-03 09:46 -0500
Re: Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation) kegs@provalid.com (Kent Dickey) - 2020-09-03 14:23 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation) Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2020-09-03 21:28 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation) olcott <NoOne@NoWhere.com> - 2020-09-03 16:51 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation) Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2020-09-03 23:20 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation) olcott <NoOne@NoWhere.com> - 2020-09-03 17:31 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation) Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2020-09-04 01:56 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation) olcott <NoOne@NoWhere.com> - 2020-09-03 20:15 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation) olcott <NoOne@NoWhere.com> - 2020-09-03 20:29 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation) Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2020-09-04 02:47 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation) olcott <NoOne@NoWhere.com> - 2020-09-03 21:08 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-09-04 03:52 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency specs) olcott <NoOne@NoWhere.com> - 2020-09-03 22:15 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation) olcott <NoOne@NoWhere.com> - 2020-09-03 22:41 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-09-04 05:14 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation) olcott <NoOne@NoWhere.com> - 2020-09-03 23:37 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation) olcott <NoOne@NoWhere.com> - 2020-09-03 15:28 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation) olcott <NoOne@NoWhere.com> - 2020-09-03 16:16 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-09-03 16:13 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation) olcott <NoOne@NoWhere.com> - 2020-09-03 12:05 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-09-04 02:50 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) olcott <NoOne@NoWhere.com> - 2020-09-03 22:02 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-09-04 05:05 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) olcott <NoOne@NoWhere.com> - 2020-09-03 23:42 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-09-04 11:48 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) olcott <NoOne@NoWhere.com> - 2020-09-04 08:41 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-09-04 17:04 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) olcott <NoOne@NoWhere.com> - 2020-09-04 11:36 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-09-04 22:29 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-09-04 14:42 -0700
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-09-04 22:53 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) olcott <NoOne@NoWhere.com> - 2020-09-04 17:51 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-09-05 02:25 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) olcott <NoOne@NoWhere.com> - 2020-09-04 20:34 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-09-05 23:58 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) Jeff Barnett <jbb@notatt.com> - 2020-09-05 17:59 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) olcott <NoOne@NoWhere.com> - 2020-09-04 20:58 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) André G. Isaak <agisaak@gm.invalid> - 2020-09-04 22:50 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) olcott <NoOne@NoWhere.com> - 2020-09-05 00:21 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) Richard Damon <Richard@Damon-Family.org> - 2020-09-05 09:49 -0400
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) olcott <NoOne@NoWhere.com> - 2020-09-05 09:34 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) Richard Damon <Richard@Damon-Family.org> - 2020-09-05 11:03 -0400
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) olcott <NoOne@NoWhere.com> - 2020-09-05 11:20 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) André G. Isaak <agisaak@gm.invalid> - 2020-09-05 10:40 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) olcott <NoOne@NoWhere.com> - 2020-09-05 12:12 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) André G. Isaak <agisaak@gm.invalid> - 2020-09-05 11:42 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) olcott <NoOne@NoWhere.com> - 2020-09-05 13:17 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) André G. Isaak <agisaak@gm.invalid> - 2020-09-05 12:33 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) olcott <NoOne@NoWhere.com> - 2020-09-05 14:16 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) Richard Damon <Richard@Damon-Family.org> - 2020-09-05 16:19 -0400
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) olcott <NoOne@NoWhere.com> - 2020-09-05 15:31 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) Richard Damon <Richard@Damon-Family.org> - 2020-09-05 17:19 -0400
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2020-09-05 23:01 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) Jeff Barnett <jbb@notatt.com> - 2020-09-05 17:52 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) Richard Damon <Richard@Damon-Family.org> - 2020-09-05 21:12 -0400
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-09-06 02:32 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) olcott <NoOne@NoWhere.com> - 2020-09-06 13:08 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) olcott <NoOne@NoWhere.com> - 2020-09-05 21:49 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2020-09-06 04:35 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) olcott <NoOne@NoWhere.com> - 2020-09-05 22:50 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) olcott <NoOne@NoWhere.com> - 2020-09-05 22:58 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) Richard Damon <Richard@Damon-Family.org> - 2020-09-06 08:47 -0400
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) olcott <NoOne@NoWhere.com> - 2020-09-06 11:42 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) André G. Isaak <agisaak@gm.invalid> - 2020-09-06 11:43 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) olcott <NoOne@NoWhere.com> - 2020-09-06 13:04 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) Richard Damon <Richard@Damon-Family.org> - 2020-09-06 16:07 -0400
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) olcott <NoOne@NoWhere.com> - 2020-09-06 15:14 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-09-06 21:42 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) olcott <NoOne@NoWhere.com> - 2020-09-06 16:16 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) Richard Damon <Richard@Damon-Family.org> - 2020-09-06 14:18 -0400
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) olcott <NoOne@NoWhere.com> - 2020-09-06 13:32 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) André G. Isaak <agisaak@gm.invalid> - 2020-09-06 12:59 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) olcott <NoOne@NoWhere.com> - 2020-09-06 14:18 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) André G. Isaak <agisaak@gm.invalid> - 2020-09-06 13:37 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) olcott <NoOne@NoWhere.com> - 2020-09-06 14:44 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) André G. Isaak <agisaak@gm.invalid> - 2020-09-06 14:02 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) olcott <NoOne@NoWhere.com> - 2020-09-06 15:22 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) Richard Damon <Richard@Damon-Family.org> - 2020-09-06 17:02 -0400
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) olcott <NoOne@NoWhere.com> - 2020-09-06 16:22 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) Richard Damon <Richard@Damon-Family.org> - 2020-09-06 18:19 -0400
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) olcott <NoOne@NoWhere.com> - 2020-09-06 17:39 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) Richard Damon <Richard@Damon-Family.org> - 2020-09-06 20:23 -0400
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) olcott <NoOne@NoWhere.com> - 2020-09-06 20:23 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) Richard Damon <Richard@Damon-Family.org> - 2020-09-06 21:51 -0400
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) olcott <NoOne@NoWhere.com> - 2020-09-06 21:10 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-09-07 00:59 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) olcott <NoOne@NoWhere.com> - 2020-09-06 21:02 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) Richard Damon <Richard@Damon-Family.org> - 2020-09-06 22:51 -0400
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) olcott <NoOne@NoWhere.com> - 2020-09-06 22:10 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) André G. Isaak <agisaak@gm.invalid> - 2020-09-05 15:29 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) André G. Isaak <agisaak@gm.invalid> - 2020-09-05 15:52 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-09-06 00:05 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) André G. Isaak <agisaak@gm.invalid> - 2020-09-05 15:28 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-09-05 23:09 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) olcott <NoOne@NoWhere.com> - 2020-09-05 00:40 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-09-06 02:25 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) André G. Isaak <agisaak@gm.invalid> - 2020-09-04 22:45 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) olcott <NoOne@NoWhere.com> - 2020-09-05 00:06 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) André G. Isaak <agisaak@gm.invalid> - 2020-09-05 00:03 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) olcott <NoOne@NoWhere.com> - 2020-09-05 09:20 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) André G. Isaak <agisaak@gm.invalid> - 2020-09-05 09:34 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) olcott <NoOne@NoWhere.com> - 2020-09-05 11:32 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) André G. Isaak <agisaak@gm.invalid> - 2020-09-05 10:48 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) olcott <NoOne@NoWhere.com> - 2020-09-05 12:21 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-09-05 23:18 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) olcott <NoOne@NoWhere.com> - 2020-09-04 12:47 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) olcott <NoOne@NoWhere.com> - 2020-09-04 08:51 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-09-04 17:11 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) olcott <NoOne@NoWhere.com> - 2020-09-04 11:39 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) Jeff Barnett <jbb@notatt.com> - 2020-09-03 22:44 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) red floyd <no.spam.here@its.invalid> - 2020-09-04 11:09 -0700
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) olcott <NoOne@NoWhere.com> - 2020-09-04 13:34 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (Machine equivalence) Andy Walker <anw@cuboid.co.uk> - 2020-08-31 00:23 +0100
Transforming "C" into a Turing equivalent language 001 [Providing unlimited memory access to C] olcott <NoOne@NoWhere.com> - 2020-08-30 19:17 -0500
Re: Transforming "C" into a Turing equivalent language 001 [Providing unlimited memory access to C] Andy Walker <anw@cuboid.co.uk> - 2020-08-31 09:59 +0100
Re: Transforming "C" into a Turing equivalent language 001 [Providing unlimited memory access to C] olcott <NoOne@NoWhere.com> - 2020-08-31 08:47 -0500
Re: Transforming "C" into a Turing equivalent language 001 [Providing unlimited memory access to C] olcott <NoOne@NoWhere.com> - 2020-09-02 09:58 -0500
Re: Transforming "C" into a Turing equivalent language 001 [Providing unlimited memory access to C] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-09-03 03:37 +0100
Re: Transforming "C" into a Turing equivalent language 001 [Providing unlimited memory access to C] olcott <NoOne@NoWhere.com> - 2020-09-02 21:50 -0500
Re: Transforming "C" into a Turing equivalent language 001 [Providing unlimited memory access to C] olcott <NoOne@NoWhere.com> - 2020-09-02 22:04 -0500
Re: Transforming "C" into a Turing equivalent language 007 [Mapping x86 to Turing Equivalent] olcott <NoOne@NoWhere.com> - 2020-09-02 22:30 -0500
Re: Simply defining G"odel Incompleteness and Tarski Undefinability away V52 (Machine equivalence) R Kym Horsell <kym@kymhorsell.com> - 2020-08-31 02:16 +0000
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (Machine equivalence) Richard Damon <Richard@Damon-Family.org> - 2020-08-30 20:43 -0400
Transforming "C" into a Turing equivalent language 001 [Providing unlimited memory access to C] olcott <NoOne@NoWhere.com> - 2020-08-30 20:21 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) André G. Isaak <agisaak@gm.invalid> - 2020-08-30 07:27 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V51 (Making "C" Turing equivalent) olcott <NoOne@NoWhere.com> - 2020-08-30 10:21 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-29 01:24 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V50 (Making "C" Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-25 14:51 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-23 10:18 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-23 17:51 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-23 12:29 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-23 22:12 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-23 16:23 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-22 16:19 -0700
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V46 (Honest dialogue?) olcott <NoOne@NoWhere.com> - 2020-08-22 18:46 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V46 (Honest dialogue?) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-22 17:55 -0700
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V46 (Honest dialogue?) olcott <NoOne@NoWhere.com> - 2020-08-22 20:14 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) Kaz Kylheku <793-849-0957@kylheku.com> - 2020-08-13 07:45 +0000
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V37 (Turing complete) olcott <NoOne@NoWhere.com> - 2020-08-13 10:32 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-09 22:32 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) André G. Isaak <agisaak@gm.invalid> - 2020-08-09 22:26 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V36 (x86 based Turing Machines) olcott <NoOne@NoWhere.com> - 2020-08-09 23:40 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V36 (x86 based Turing Machines) André G. Isaak <agisaak@gm.invalid> - 2020-08-09 23:28 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V36 (x86 based Turing Machines) olcott <NoOne@NoWhere.com> - 2020-08-10 00:43 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V36 (x86 based Turing Machines) André G. Isaak <agisaak@gm.invalid> - 2020-08-10 00:19 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V36 (x86 based Turing Machines) olcott <NoOne@NoWhere.com> - 2020-08-10 09:08 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V36 (x86 based Turing Machines) André G. Isaak <agisaak@gm.invalid> - 2020-08-10 08:34 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V36 (x86 based Turing Machines) olcott <NoOne@NoWhere.com> - 2020-08-10 10:27 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V36 (x86 based Turing Machines) André G. Isaak <agisaak@gm.invalid> - 2020-08-10 09:31 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V36 (x86 based Turing Machines) olcott <NoOne@NoWhere.com> - 2020-08-10 10:56 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V36 (x86 based Turing Machines) André G. Isaak <agisaak@gm.invalid> - 2020-08-10 10:31 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V36 (x86 based Turing Machines) olcott <NoOne@NoWhere.com> - 2020-08-10 12:03 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V36 (x86 based Turing Machines) André G. Isaak <agisaak@gm.invalid> - 2020-08-10 11:06 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V36 (x86 based Turing Machines) olcott <NoOne@NoWhere.com> - 2020-08-10 12:13 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-10 12:27 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-09 18:37 -0700
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-09 21:33 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-09 20:41 -0700
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-09 22:46 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-09 21:36 -0700
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-09 23:44 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-09 22:22 -0700
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-10 00:41 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-09 22:56 -0700
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-10 01:06 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-09 23:20 -0700
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-10 09:25 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-10 10:55 -0700
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-10 13:14 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-10 18:39 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) Wasell <usenet2020.1@wasell.eu> - 2020-08-10 16:01 +0200
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V36 (x86 based Turing Machine) olcott <NoOne@NoWhere.com> - 2020-08-10 09:58 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-09 21:01 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-10 12:24 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V36 (x86 based Turing Machine) olcott <NoOne@NoWhere.com> - 2020-08-10 09:35 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V36 (x86 based Turing Machine) Andy Walker <anw@cuboid.co.uk> - 2020-08-10 16:12 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V36 (x86 based Turing Machine) olcott <NoOne@NoWhere.com> - 2020-08-10 10:26 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) Andy Walker <anw@cuboid.co.uk> - 2020-08-08 11:54 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-08 12:27 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-06 18:25 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-06 18:28 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) David Kleinecke <dkleinecke@gmail.com> - 2020-08-06 16:45 -0700
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-06 18:59 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-07 02:26 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-06 20:46 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-07 03:05 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-07 10:43 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-07 11:23 -0700
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-07 23:41 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-07 18:28 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-08 01:20 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-07 19:58 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-08 03:09 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-08 00:14 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-08 17:52 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-08 14:05 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-08 21:23 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-07 19:16 -0700
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) André G. Isaak <agisaak@gm.invalid> - 2020-08-07 00:53 -0600
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-07 10:01 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-07 16:38 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-07 10:48 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-07 11:10 -0700
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-07 14:41 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-07 13:11 -0700
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) olcott <NoOne@NoWhere.com> - 2020-08-07 16:52 -0500
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-08 00:02 +0100
Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined) André G. Isaak <agisaak@gm.invalid> - 2020-08-07 10:54 -0600
Page 32 of 34 — ← Prev page 1 … 30 31 [32] 33 34 Next page →
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2020-08-10 12:03 -0500 |
| Subject | Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V36 (x86 based Turing Machines) |
| Message-ID | <QvWdnedc_IF_4KzCnZ2dnUU7-K_NnZ2d@giganews.com> |
| In reply to | #22272 |
On 8/10/2020 11:31 AM, André G. Isaak wrote: > On 2020-08-10 09:56, olcott wrote: >> On 8/10/2020 10:31 AM, André G. Isaak wrote: >>> On 2020-08-10 09:27, olcott wrote: >>>> On 8/10/2020 9:34 AM, André G. Isaak wrote: >>>>> On 2020-08-10 08:08, olcott wrote: >>>>>> On 8/10/2020 1:19 AM, André G. Isaak wrote: >>>>>>> On 2020-08-09 23:43, olcott wrote: >>>>>>>> On 8/10/2020 12:28 AM, André G. Isaak wrote: >>>>>>>>> On 2020-08-09 22:40, olcott wrote: >>>>>>>>>> On 8/9/2020 11:26 PM, André G. Isaak wrote: >>>>>>>>>>> On 2020-08-09 21:32, olcott wrote: >>>>>>>>>>>> On 8/9/2020 9:08 PM, Ben Bacarisse wrote: >>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes: >>>>>>>>>>>>> >>>>>>>>>>>>>> On 8/9/2020 6:16 PM, Ben Bacarisse wrote: >>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 8/9/2020 4:44 PM, Keith Thompson wrote: >>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes: >>>>>>>>>>>>>>>>>> On 8/9/2020 3:57 PM, Ben Bacarisse wrote: >>>>>>>>>>>>>>>>> [...] >>>>>>>>>>>>>>>>>>> You don't have, and have never had, a Turing machine >>>>>>>>>>>>>>>>>>> with the properties >>>>>>>>>>>>>>>>>>> you claim. It would be good if you admitted that and >>>>>>>>>>>>>>>>>>> moved on because >>>>>>>>>>>>>>>>>>> attempting to defend the indefensible is taking up a >>>>>>>>>>>>>>>>>>> lot of your time. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I have a finite state machine >>>>>>>>>>>>>> >>>>>>>>>>>>>>> How many states does it have? What are the domain and >>>>>>>>>>>>>>> co-domain of the >>>>>>>>>>>>>>> state transition function? >>>>>>>>>>>>>> >>>>>>>>>>>>>> That depends on how the states are counted. >>>>>>>>>>>>>> Every time that memory changes can be counted as a state >>>>>>>>>>>>>> change. >>>>>>>>>>>>> >>>>>>>>>>>>> Ah, so you don't have a state machine either. You have >>>>>>>>>>>>> real trouble >>>>>>>>>>>>> with the names of things. What /do/ you have, and what did >>>>>>>>>>>>> you have in >>>>>>>>>>>>> Dec 2018? I'd like conventional descriptions if possible. >>>>>>>>>>>>> If it's a C >>>>>>>>>>>>> program, don't call it Pascal because they are >>>>>>>>>>>>> "computationally >>>>>>>>>>>>> equivalent". >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> It is just about the closest thing to a UTM that anyone >>>>>>>>>>>> could ever create where the Turing machine Description >>>>>>>>>>>> language is x86 machine language. >>>>>>>>>>> >>>>>>>>>>> x86 machine language is not a 'Turing Machine Description >>>>>>>>>>> Language'. >>>>>>>>>>> >>>>>>>>>>> Do you actually understand what a UTM is? >>>>>>>>>> >>>>>>>>>> Do you understand what a UTM would be if it had x86 as its >>>>>>>>>> Turing Machine Description language? >>>>>>>>> >>>>>>>>> That's not an answer to my question. Do you understand what a >>>>>>>>> UTM is? Can you explain what you think a UTM is in simple >>>>>>>>> English without any links to webpages? >>>>>>>>> >>>>>>>> >>>>>>>> Yes I can. >>>>>>> >>>>>>> Normally, such an answer would be followed by such an >>>>>>> explanation. You really should read up on Grice's Maxims of >>>>>>> cooperative conversation. >>>>>>> >>>>>>> A UTM is... >>>>>> >>>>>> I can but refuse to do so the question was disrespectful. >>>>>> >>>>>>> >>>>>>>>>>> >>>>>>>>>>> What is the actual expected input for your program? >>>>>>>>> >>>>>>>>> And again, none of what you write below is an answer to this >>>>>>>>> question. What is the *input* which your program expects? >>>>>>>>> >>>>>>>> >>>>>>>> I already answered that in great depth. >>>>>>>> The input of my x86 version of the Peter Linz H_Hat is its own >>>>>>>> x86 code. >>>>>>> >>>>>>> That is entirely unclear. >>>>>>> >>>>>>> Does this mean that the input is x86 code? >>>>>> >>>>>> I just said that the input in this specific case is x86 code. >>>>>> More specifically it is the input of a specific x86 program. >>>>>> More specifically it is the program at the bottom of page 319. >>>>>> http://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf >>>>>> >>>>>> The UTM can handle input of any 32-bit memory block up to 4GB and >>>>>> it can address elements in this block as 32-bit, 16-bit and 8-bit >>>>>> signed or unsigned integers. >>>>>> >>>>>>> Or does it mean that it is specifically its own x86 code and that >>>>>>> it will refuse to run given any other input? >>>>>> >>>>>> The UTM is in every way a generic x86 based operating system and >>>>>> can run any x86 software that does not need I/O. >>>>> >>>>> That is not even remotely what a UTM is, which is why I asked you >>>>> above to define what you mean by UTM. It is clear you mean >>>>> something entirely different from the standard meaning of UTM, but >>>>> without knowing your private definition of UTM, nothing you write >>>>> is even interpretable. >>>>> >>>>> André >>>>> >>>> >>>> I mean the standard conventional idea of a UTM that had been adapted >>>> such that the x86 language is its Turing Machine description language. >>> >>> And what exactly do you mean by the 'standard conventional idea of a >>> UTM'? >>> >>> Again, can you explain this in your own words without simply copying >>> a web address. >> >> Yes I can. >> >>> I do not believe that what you mean is actually the conventional >>> meaning of the term. >>> >>> André >>> >>> >> >> I really don't care what you believe. > > Clearly, then, you have absolutely no interest in communicating whatever > it is that you are trying to claim. > All beliefs are distractions away from Truth. > What you describe above is not even remotely a UTM according to the > 'standard conventional idea of a UTM', so unless you actually explain > what *you* mean by a UTM you have no hope of being understood. > > Since x86 assembly language is also not even remotely a "Turing Machine > description language", the phrase "a UTM that had been adapted such that > the x86 language is its Turing Machine description language" is an > entirely meaningless phrase without clarification on your part. > > I am not the only one who has asked for your definition of "(Universal) > Turing Machine" so clearly I am not the only one who wants to know what > exactly it is that you mean by this. If you were using this term as it > is conventionally understood, no one would be asking this question. > > André > My master UTM can execute a chain of UTM's of arbitrary depth. It executes H_Hat that executes itself as H_Hat's basis for deciding halting on itself. All of the memory is a single contiguous block that can be dynamically extended during run-time again and again. -- Copyright 2020 Pete Olcott
[toc] | [prev] | [next] | [standalone]
| From | André G. Isaak <agisaak@gm.invalid> |
|---|---|
| Date | 2020-08-10 11:06 -0600 |
| Subject | Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V36 (x86 based Turing Machines) |
| Message-ID | <rgrupp$57q$1@dont-email.me> |
| In reply to | #22274 |
On 2020-08-10 11:03, olcott wrote: > On 8/10/2020 11:31 AM, André G. Isaak wrote: >> On 2020-08-10 09:56, olcott wrote: >>> On 8/10/2020 10:31 AM, André G. Isaak wrote: >>>> On 2020-08-10 09:27, olcott wrote: >>>>> On 8/10/2020 9:34 AM, André G. Isaak wrote: >>>>>> On 2020-08-10 08:08, olcott wrote: >>>>>>> On 8/10/2020 1:19 AM, André G. Isaak wrote: >>>>>>>> On 2020-08-09 23:43, olcott wrote: >>>>>>>>> On 8/10/2020 12:28 AM, André G. Isaak wrote: >>>>>>>>>> On 2020-08-09 22:40, olcott wrote: >>>>>>>>>>> On 8/9/2020 11:26 PM, André G. Isaak wrote: >>>>>>>>>>>> On 2020-08-09 21:32, olcott wrote: >>>>>>>>>>>>> On 8/9/2020 9:08 PM, Ben Bacarisse wrote: >>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 8/9/2020 6:16 PM, Ben Bacarisse wrote: >>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 8/9/2020 4:44 PM, Keith Thompson wrote: >>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes: >>>>>>>>>>>>>>>>>>> On 8/9/2020 3:57 PM, Ben Bacarisse wrote: >>>>>>>>>>>>>>>>>> [...] >>>>>>>>>>>>>>>>>>>> You don't have, and have never had, a Turing machine >>>>>>>>>>>>>>>>>>>> with the properties >>>>>>>>>>>>>>>>>>>> you claim. It would be good if you admitted that >>>>>>>>>>>>>>>>>>>> and moved on because >>>>>>>>>>>>>>>>>>>> attempting to defend the indefensible is taking up a >>>>>>>>>>>>>>>>>>>> lot of your time. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I have a finite state machine >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> How many states does it have? What are the domain and >>>>>>>>>>>>>>>> co-domain of the >>>>>>>>>>>>>>>> state transition function? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> That depends on how the states are counted. >>>>>>>>>>>>>>> Every time that memory changes can be counted as a state >>>>>>>>>>>>>>> change. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Ah, so you don't have a state machine either. You have >>>>>>>>>>>>>> real trouble >>>>>>>>>>>>>> with the names of things. What /do/ you have, and what >>>>>>>>>>>>>> did you have in >>>>>>>>>>>>>> Dec 2018? I'd like conventional descriptions if possible. >>>>>>>>>>>>>> If it's a C >>>>>>>>>>>>>> program, don't call it Pascal because they are >>>>>>>>>>>>>> "computationally >>>>>>>>>>>>>> equivalent". >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> It is just about the closest thing to a UTM that anyone >>>>>>>>>>>>> could ever create where the Turing machine Description >>>>>>>>>>>>> language is x86 machine language. >>>>>>>>>>>> >>>>>>>>>>>> x86 machine language is not a 'Turing Machine Description >>>>>>>>>>>> Language'. >>>>>>>>>>>> >>>>>>>>>>>> Do you actually understand what a UTM is? >>>>>>>>>>> >>>>>>>>>>> Do you understand what a UTM would be if it had x86 as its >>>>>>>>>>> Turing Machine Description language? >>>>>>>>>> >>>>>>>>>> That's not an answer to my question. Do you understand what a >>>>>>>>>> UTM is? Can you explain what you think a UTM is in simple >>>>>>>>>> English without any links to webpages? >>>>>>>>>> >>>>>>>>> >>>>>>>>> Yes I can. >>>>>>>> >>>>>>>> Normally, such an answer would be followed by such an >>>>>>>> explanation. You really should read up on Grice's Maxims of >>>>>>>> cooperative conversation. >>>>>>>> >>>>>>>> A UTM is... >>>>>>> >>>>>>> I can but refuse to do so the question was disrespectful. >>>>>>> >>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> What is the actual expected input for your program? >>>>>>>>>> >>>>>>>>>> And again, none of what you write below is an answer to this >>>>>>>>>> question. What is the *input* which your program expects? >>>>>>>>>> >>>>>>>>> >>>>>>>>> I already answered that in great depth. >>>>>>>>> The input of my x86 version of the Peter Linz H_Hat is its own >>>>>>>>> x86 code. >>>>>>>> >>>>>>>> That is entirely unclear. >>>>>>>> >>>>>>>> Does this mean that the input is x86 code? >>>>>>> >>>>>>> I just said that the input in this specific case is x86 code. >>>>>>> More specifically it is the input of a specific x86 program. >>>>>>> More specifically it is the program at the bottom of page 319. >>>>>>> http://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf >>>>>>> >>>>>>> The UTM can handle input of any 32-bit memory block up to 4GB and >>>>>>> it can address elements in this block as 32-bit, 16-bit and 8-bit >>>>>>> signed or unsigned integers. >>>>>>> >>>>>>>> Or does it mean that it is specifically its own x86 code and >>>>>>>> that it will refuse to run given any other input? >>>>>>> >>>>>>> The UTM is in every way a generic x86 based operating system and >>>>>>> can run any x86 software that does not need I/O. >>>>>> >>>>>> That is not even remotely what a UTM is, which is why I asked you >>>>>> above to define what you mean by UTM. It is clear you mean >>>>>> something entirely different from the standard meaning of UTM, but >>>>>> without knowing your private definition of UTM, nothing you write >>>>>> is even interpretable. >>>>>> >>>>>> André >>>>>> >>>>> >>>>> I mean the standard conventional idea of a UTM that had been >>>>> adapted such that the x86 language is its Turing Machine >>>>> description language. >>>> >>>> And what exactly do you mean by the 'standard conventional idea of a >>>> UTM'? >>>> >>>> Again, can you explain this in your own words without simply copying >>>> a web address. >>> >>> Yes I can. >>> >>>> I do not believe that what you mean is actually the conventional >>>> meaning of the term. >>>> >>>> André >>>> >>>> >>> >>> I really don't care what you believe. >> >> Clearly, then, you have absolutely no interest in communicating >> whatever it is that you are trying to claim. >> > > All beliefs are distractions away from Truth. > >> What you describe above is not even remotely a UTM according to the >> 'standard conventional idea of a UTM', so unless you actually explain >> what *you* mean by a UTM you have no hope of being understood. >> >> Since x86 assembly language is also not even remotely a "Turing >> Machine description language", the phrase "a UTM that had been adapted >> such that the x86 language is its Turing Machine description language" >> is an entirely meaningless phrase without clarification on your part. >> >> I am not the only one who has asked for your definition of >> "(Universal) Turing Machine" so clearly I am not the only one who >> wants to know what exactly it is that you mean by this. If you were >> using this term as it is conventionally understood, no one would be >> asking this question. >> >> André >> > > My master UTM can execute a chain of UTM's of arbitrary depth. It > executes H_Hat that executes itself as H_Hat's basis for deciding > halting on itself. All of the memory is a single contiguous block that > can be dynamically extended during run-time again and again. > None of that addresses my question. I am asking you to provide *your* definition of UTM. Not what your UTM does, but what you think a UTM actually is. André -- To email remove 'invalid' & replace 'gm' with well known Google mail service.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2020-08-10 12:13 -0500 |
| Subject | Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V36 (x86 based Turing Machines) |
| Message-ID | <XpOdnTQfAs21HazCnZ2dnUU7-audnZ2d@giganews.com> |
| In reply to | #22275 |
On 8/10/2020 12:06 PM, André G. Isaak wrote: > On 2020-08-10 11:03, olcott wrote: >> On 8/10/2020 11:31 AM, André G. Isaak wrote: >>> On 2020-08-10 09:56, olcott wrote: >>>> On 8/10/2020 10:31 AM, André G. Isaak wrote: >>>>> On 2020-08-10 09:27, olcott wrote: >>>>>> On 8/10/2020 9:34 AM, André G. Isaak wrote: >>>>>>> On 2020-08-10 08:08, olcott wrote: >>>>>>>> On 8/10/2020 1:19 AM, André G. Isaak wrote: >>>>>>>>> On 2020-08-09 23:43, olcott wrote: >>>>>>>>>> On 8/10/2020 12:28 AM, André G. Isaak wrote: >>>>>>>>>>> On 2020-08-09 22:40, olcott wrote: >>>>>>>>>>>> On 8/9/2020 11:26 PM, André G. Isaak wrote: >>>>>>>>>>>>> On 2020-08-09 21:32, olcott wrote: >>>>>>>>>>>>>> On 8/9/2020 9:08 PM, Ben Bacarisse wrote: >>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 8/9/2020 6:16 PM, Ben Bacarisse wrote: >>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 8/9/2020 4:44 PM, Keith Thompson wrote: >>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes: >>>>>>>>>>>>>>>>>>>> On 8/9/2020 3:57 PM, Ben Bacarisse wrote: >>>>>>>>>>>>>>>>>>> [...] >>>>>>>>>>>>>>>>>>>>> You don't have, and have never had, a Turing >>>>>>>>>>>>>>>>>>>>> machine with the properties >>>>>>>>>>>>>>>>>>>>> you claim. It would be good if you admitted that >>>>>>>>>>>>>>>>>>>>> and moved on because >>>>>>>>>>>>>>>>>>>>> attempting to defend the indefensible is taking up >>>>>>>>>>>>>>>>>>>>> a lot of your time. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I have a finite state machine >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> How many states does it have? What are the domain and >>>>>>>>>>>>>>>>> co-domain of the >>>>>>>>>>>>>>>>> state transition function? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> That depends on how the states are counted. >>>>>>>>>>>>>>>> Every time that memory changes can be counted as a state >>>>>>>>>>>>>>>> change. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Ah, so you don't have a state machine either. You have >>>>>>>>>>>>>>> real trouble >>>>>>>>>>>>>>> with the names of things. What /do/ you have, and what >>>>>>>>>>>>>>> did you have in >>>>>>>>>>>>>>> Dec 2018? I'd like conventional descriptions if >>>>>>>>>>>>>>> possible. If it's a C >>>>>>>>>>>>>>> program, don't call it Pascal because they are >>>>>>>>>>>>>>> "computationally >>>>>>>>>>>>>>> equivalent". >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> It is just about the closest thing to a UTM that anyone >>>>>>>>>>>>>> could ever create where the Turing machine Description >>>>>>>>>>>>>> language is x86 machine language. >>>>>>>>>>>>> >>>>>>>>>>>>> x86 machine language is not a 'Turing Machine Description >>>>>>>>>>>>> Language'. >>>>>>>>>>>>> >>>>>>>>>>>>> Do you actually understand what a UTM is? >>>>>>>>>>>> >>>>>>>>>>>> Do you understand what a UTM would be if it had x86 as its >>>>>>>>>>>> Turing Machine Description language? >>>>>>>>>>> >>>>>>>>>>> That's not an answer to my question. Do you understand what a >>>>>>>>>>> UTM is? Can you explain what you think a UTM is in simple >>>>>>>>>>> English without any links to webpages? >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Yes I can. >>>>>>>>> >>>>>>>>> Normally, such an answer would be followed by such an >>>>>>>>> explanation. You really should read up on Grice's Maxims of >>>>>>>>> cooperative conversation. >>>>>>>>> >>>>>>>>> A UTM is... >>>>>>>> >>>>>>>> I can but refuse to do so the question was disrespectful. >>>>>>>> >>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> What is the actual expected input for your program? >>>>>>>>>>> >>>>>>>>>>> And again, none of what you write below is an answer to this >>>>>>>>>>> question. What is the *input* which your program expects? >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I already answered that in great depth. >>>>>>>>>> The input of my x86 version of the Peter Linz H_Hat is its own >>>>>>>>>> x86 code. >>>>>>>>> >>>>>>>>> That is entirely unclear. >>>>>>>>> >>>>>>>>> Does this mean that the input is x86 code? >>>>>>>> >>>>>>>> I just said that the input in this specific case is x86 code. >>>>>>>> More specifically it is the input of a specific x86 program. >>>>>>>> More specifically it is the program at the bottom of page 319. >>>>>>>> http://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf >>>>>>>> >>>>>>>> The UTM can handle input of any 32-bit memory block up to 4GB >>>>>>>> and it can address elements in this block as 32-bit, 16-bit and >>>>>>>> 8-bit signed or unsigned integers. >>>>>>>> >>>>>>>>> Or does it mean that it is specifically its own x86 code and >>>>>>>>> that it will refuse to run given any other input? >>>>>>>> >>>>>>>> The UTM is in every way a generic x86 based operating system and >>>>>>>> can run any x86 software that does not need I/O. >>>>>>> >>>>>>> That is not even remotely what a UTM is, which is why I asked you >>>>>>> above to define what you mean by UTM. It is clear you mean >>>>>>> something entirely different from the standard meaning of UTM, >>>>>>> but without knowing your private definition of UTM, nothing you >>>>>>> write is even interpretable. >>>>>>> >>>>>>> André >>>>>>> >>>>>> >>>>>> I mean the standard conventional idea of a UTM that had been >>>>>> adapted such that the x86 language is its Turing Machine >>>>>> description language. >>>>> >>>>> And what exactly do you mean by the 'standard conventional idea of >>>>> a UTM'? >>>>> >>>>> Again, can you explain this in your own words without simply >>>>> copying a web address. >>>> >>>> Yes I can. >>>> >>>>> I do not believe that what you mean is actually the conventional >>>>> meaning of the term. >>>>> >>>>> André >>>>> >>>>> >>>> >>>> I really don't care what you believe. >>> >>> Clearly, then, you have absolutely no interest in communicating >>> whatever it is that you are trying to claim. >>> >> >> All beliefs are distractions away from Truth. >> >>> What you describe above is not even remotely a UTM according to the >>> 'standard conventional idea of a UTM', so unless you actually explain >>> what *you* mean by a UTM you have no hope of being understood. >>> >>> Since x86 assembly language is also not even remotely a "Turing >>> Machine description language", the phrase "a UTM that had been >>> adapted such that the x86 language is its Turing Machine description >>> language" is an entirely meaningless phrase without clarification on >>> your part. >>> >>> I am not the only one who has asked for your definition of >>> "(Universal) Turing Machine" so clearly I am not the only one who >>> wants to know what exactly it is that you mean by this. If you were >>> using this term as it is conventionally understood, no one would be >>> asking this question. >>> >>> André >>> >> >> My master UTM can execute a chain of UTM's of arbitrary depth. It >> executes H_Hat that executes itself as H_Hat's basis for deciding >> halting on itself. All of the memory is a single contiguous block that >> can be dynamically extended during run-time again and again. >> > > None of that addresses my question. I am asking you to provide *your* > definition of UTM. Not what your UTM does, but what you think a UTM > actually is. > > André > How many times do I have to tell you that this question is disrespectful and will not be answered? -- Copyright 2020 Pete Olcott
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2020-08-10 12:27 +0100 |
| Message-ID | <87imdqd9lo.fsf@bsb.me.uk> |
| In reply to | #22241 |
olcott <NoOne@NoWhere.com> writes: > On 8/9/2020 9:08 PM, Ben Bacarisse wrote: >> olcott <NoOne@NoWhere.com> writes: >> >>> On 8/9/2020 6:16 PM, Ben Bacarisse wrote: >>>> olcott <NoOne@NoWhere.com> writes: >>>> >>>>> On 8/9/2020 4:44 PM, Keith Thompson wrote: >>>>>> olcott <NoOne@NoWhere.com> writes: >>>>>>> On 8/9/2020 3:57 PM, Ben Bacarisse wrote: >>>>>> [...] >>>>>>>> You don't have, and have never had, a Turing machine with the properties >>>>>>>> you claim. It would be good if you admitted that and moved on because >>>>>>>> attempting to defend the indefensible is taking up a lot of your time. >>>>>>> >>>>>>> I have a finite state machine >>> >>>> How many states does it have? What are the domain and co-domain of the >>>> state transition function? >>> >>> That depends on how the states are counted. >>> Every time that memory changes can be counted as a state change. >> >> Ah, so you don't have a state machine either. You have real trouble >> with the names of things. What /do/ you have, and what did you have in >> Dec 2018? I'd like conventional descriptions if possible. If it's a C >> program, don't call it Pascal because they are "computationally >> equivalent". > > It is just about the closest thing to a UTM that anyone could ever > create where the Turing machine Description language is x86 machine > language. So nothing of any interest then? How odd. You once claimed something extraordinary. You were provably wrong, of course, but the claim was at least interesting. Now all you have is this? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-08-09 18:37 -0700 |
| Message-ID | <878sen5lij.fsf@nosuchdomain.example.com> |
| In reply to | #22233 |
olcott <NoOne@NoWhere.com> writes:
> On 8/9/2020 4:44 PM, Keith Thompson wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>> On 8/9/2020 3:57 PM, Ben Bacarisse wrote:
>> [...]
>>>> You don't have, and have never had, a Turing machine with the properties
>>>> you claim. It would be good if you admitted that and moved on because
>>>> attempting to defend the indefensible is taking up a lot of your time.
>>>
>>> I have a finite state machine that implements computationally
>>> equivalent code to the Peter Linz H_Hat such that this computational
>>> equivalent correctly decides halting on itself showing exactly how the
>>> standard self-referential halting problem counter-example can be
>>> defeated.
>>
>> As I recall, you've claimed to have pseudocode that you were going
>> to translate into working software. Did you ever actually get it
>> written and running?
>>
>> Do you have a finite state machine, or do you merely have an *idea*
>> for a finite state machine?
>
> I translated the finite state equivalent of the same self-referential
> counter-example that all the Halting Problem proofs are based on into
> "C". I am using a very excellent x86 interpreter to run the machine
> code of this "C" function. It turns out that Visual "C++" generates
> machine code that is easier to understand than g++.
So now you have a "C" function.
The quotation marks around C seem odd. Are they significant, and if
so, what's the difference between a "C" function and a C function?
I presume you're referring to the C programming language.
How many lines of C code are in this function? I presume posting
that number wouldn't harm its "trade secret" status. (I'm not
interested in any answer to this question that isn't a specific
positive integer.)
Does this function conform to the C language standard? Which edition
(C90, C99, C11, ...)?
Does this "C" function exist in the context of a C program that
you can compile, link, and execute? Have you done so?
Why do you need an x86 interpreter to "run the machine code of this
"C" function"? Why can't you just compile it with an ordinary C
compiler and execute it? I understand that the goal is to feed
your program its own machine code as input (correct?), but are you
able to create an executable that can be run with, for example,
empty input? (I understand that it might fail with empty input,
but the ability to run the program *at all* is a significant step.)
> The machine code examines itself and decides halting on itself.
> The key part that I have been working on for the last week is building
> the context switching aspect of the master UTM such that one UTM can
> execute another UTM and this can be to arbitrary depth. I am guessing
> that this will be done very soon. Although this is the most difficult
> part that remains it is standard operating system software
> engineering.
>
> Converting an x86 interpreter into a UTM that can execute a chain of
> UTMs of arbitrary depth has taken most of my time. Half of this time
> was learning the internals of the x86 interpreter well enough that I
> can make the changes needed. Less that 10% of my time was spent on
> anything directly related to halt deciding.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2020-08-09 21:33 -0500 |
| Message-ID | <TJadne_yf4WVL63CnZ2dnUU7-TnNnZ2d@giganews.com> |
| In reply to | #22236 |
On 8/9/2020 8:37 PM, Keith Thompson wrote: > olcott <NoOne@NoWhere.com> writes: >> On 8/9/2020 4:44 PM, Keith Thompson wrote: >>> olcott <NoOne@NoWhere.com> writes: >>>> On 8/9/2020 3:57 PM, Ben Bacarisse wrote: >>> [...] >>>>> You don't have, and have never had, a Turing machine with the properties >>>>> you claim. It would be good if you admitted that and moved on because >>>>> attempting to defend the indefensible is taking up a lot of your time. >>>> >>>> I have a finite state machine that implements computationally >>>> equivalent code to the Peter Linz H_Hat such that this computational >>>> equivalent correctly decides halting on itself showing exactly how the >>>> standard self-referential halting problem counter-example can be >>>> defeated. >>> >>> As I recall, you've claimed to have pseudocode that you were going >>> to translate into working software. Did you ever actually get it >>> written and running? >>> >>> Do you have a finite state machine, or do you merely have an *idea* >>> for a finite state machine? >> >> I translated the finite state equivalent of the same self-referential >> counter-example that all the Halting Problem proofs are based on into >> "C". I am using a very excellent x86 interpreter to run the machine >> code of this "C" function. It turns out that Visual "C++" generates >> machine code that is easier to understand than g++. > > So now you have a "C" function. > > The quotation marks around C seem odd. Are they significant, and if > so, what's the difference between a "C" function and a C function? > I presume you're referring to the C programming language. > > How many lines of C code are in this function? I presume posting > that number wouldn't harm its "trade secret" status. (I'm not > interested in any answer to this question that isn't a specific > positive integer.) > I can't finish the halt decider until its master UTM is complete. The details of the greatly enhanced halt decider have been designed for many months. > Does this function conform to the C language standard? Which edition > (C90, C99, C11, ...)? > > Does this "C" function exist in the context of a C program that > you can compile, link, and execute? Have you done so? > It can only be correctly executed inside the master UTM and this is not quite built yet. > Why do you need an x86 interpreter to "run the machine code of this > "C" function"? Why can't you just compile it with an ordinary C I need to function to examine its own machine code because the control flow of machine code is straight forward. I need an x86 interpreter as the basis of the master UTM. > compiler and execute it? I understand that the goal is to feed > your program its own machine code as input (correct?), but are you > able to create an executable that can be run with, for example, > empty input? (I understand that it might fail with empty input, > but the ability to run the program *at all* is a significant step.) > >> The machine code examines itself and decides halting on itself. >> The key part that I have been working on for the last week is building >> the context switching aspect of the master UTM such that one UTM can >> execute another UTM and this can be to arbitrary depth. I am guessing >> that this will be done very soon. Although this is the most difficult >> part that remains it is standard operating system software >> engineering. >> >> Converting an x86 interpreter into a UTM that can execute a chain of >> UTMs of arbitrary depth has taken most of my time. Half of this time >> was learning the internals of the x86 interpreter well enough that I >> can make the changes needed. Less that 10% of my time was spent on >> anything directly related to halt deciding. > -- Copyright 2020 Pete Olcott
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-08-09 20:41 -0700 |
| Message-ID | <87y2mn417q.fsf@nosuchdomain.example.com> |
| In reply to | #22239 |
olcott <NoOne@NoWhere.com> writes:
> On 8/9/2020 8:37 PM, Keith Thompson wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>> On 8/9/2020 4:44 PM, Keith Thompson wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>> On 8/9/2020 3:57 PM, Ben Bacarisse wrote:
>>>> [...]
>>>>>> You don't have, and have never had, a Turing machine with the properties
>>>>>> you claim. It would be good if you admitted that and moved on because
>>>>>> attempting to defend the indefensible is taking up a lot of your time.
>>>>>
>>>>> I have a finite state machine that implements computationally
>>>>> equivalent code to the Peter Linz H_Hat such that this computational
>>>>> equivalent correctly decides halting on itself showing exactly how the
>>>>> standard self-referential halting problem counter-example can be
>>>>> defeated.
>>>>
>>>> As I recall, you've claimed to have pseudocode that you were going
>>>> to translate into working software. Did you ever actually get it
>>>> written and running?
>>>>
>>>> Do you have a finite state machine, or do you merely have an *idea*
>>>> for a finite state machine?
>>>
>>> I translated the finite state equivalent of the same self-referential
>>> counter-example that all the Halting Problem proofs are based on into
>>> "C". I am using a very excellent x86 interpreter to run the machine
>>> code of this "C" function. It turns out that Visual "C++" generates
>>> machine code that is easier to understand than g++.
>>
>> So now you have a "C" function.
>>
>> The quotation marks around C seem odd. Are they significant, and if
>> so, what's the difference between a "C" function and a C function?
>> I presume you're referring to the C programming language.
>>
>> How many lines of C code are in this function? I presume posting
>> that number wouldn't harm its "trade secret" status. (I'm not
>> interested in any answer to this question that isn't a specific
>> positive integer.)
>
> I can't finish the halt decider until its master UTM is complete.
> The details of the greatly enhanced halt decider have been designed
> for many months.
>
>> Does this function conform to the C language standard? Which edition
>> (C90, C99, C11, ...)?
>>
>> Does this "C" function exist in the context of a C program that
>> you can compile, link, and execute? Have you done so?
>
> It can only be correctly executed inside the master UTM and this is
> not quite built yet.
>
>> Why do you need an x86 interpreter to "run the machine code of this
>> "C" function"? Why can't you just compile it with an ordinary C
>
> I need to function to examine its own machine code because the control
> flow of machine code is straight forward. I need an x86 interpreter as
> the basis of the master UTM.
>
>> compiler and execute it? I understand that the goal is to feed
>> your program its own machine code as input (correct?), but are you
>> able to create an executable that can be run with, for example,
>> empty input? (I understand that it might fail with empty input,
>> but the ability to run the program *at all* is a significant step.)
>>
>>> The machine code examines itself and decides halting on itself.
>>> The key part that I have been working on for the last week is building
>>> the context switching aspect of the master UTM such that one UTM can
>>> execute another UTM and this can be to arbitrary depth. I am guessing
>>> that this will be done very soon. Although this is the most difficult
>>> part that remains it is standard operating system software
>>> engineering.
>>>
>>> Converting an x86 interpreter into a UTM that can execute a chain of
>>> UTMs of arbitrary depth has taken most of my time. Half of this time
>>> was learning the internals of the x86 interpreter well enough that I
>>> can make the changes needed. Less that 10% of my time was spent on
>>> anything directly related to halt deciding.
Nothing you've written actually responds to anything I asked.
I'll just conclude that you have a vague "design" for some code that
you eventually intend to write, and that you haven't yet written
an actual C function of any kind.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2020-08-09 22:46 -0500 |
| Message-ID | <PfGdnRcLR7edXq3CnZ2dnUU7-L_NnZ2d@giganews.com> |
| In reply to | #22242 |
On 8/9/2020 10:41 PM, Keith Thompson wrote: > olcott <NoOne@NoWhere.com> writes: >> On 8/9/2020 8:37 PM, Keith Thompson wrote: >>> olcott <NoOne@NoWhere.com> writes: >>>> On 8/9/2020 4:44 PM, Keith Thompson wrote: >>>>> olcott <NoOne@NoWhere.com> writes: >>>>>> On 8/9/2020 3:57 PM, Ben Bacarisse wrote: >>>>> [...] >>>>>>> You don't have, and have never had, a Turing machine with the properties >>>>>>> you claim. It would be good if you admitted that and moved on because >>>>>>> attempting to defend the indefensible is taking up a lot of your time. >>>>>> >>>>>> I have a finite state machine that implements computationally >>>>>> equivalent code to the Peter Linz H_Hat such that this computational >>>>>> equivalent correctly decides halting on itself showing exactly how the >>>>>> standard self-referential halting problem counter-example can be >>>>>> defeated. >>>>> >>>>> As I recall, you've claimed to have pseudocode that you were going >>>>> to translate into working software. Did you ever actually get it >>>>> written and running? >>>>> >>>>> Do you have a finite state machine, or do you merely have an *idea* >>>>> for a finite state machine? >>>> >>>> I translated the finite state equivalent of the same self-referential >>>> counter-example that all the Halting Problem proofs are based on into >>>> "C". I am using a very excellent x86 interpreter to run the machine >>>> code of this "C" function. It turns out that Visual "C++" generates >>>> machine code that is easier to understand than g++. >>> >>> So now you have a "C" function. >>> >>> The quotation marks around C seem odd. Are they significant, and if >>> so, what's the difference between a "C" function and a C function? >>> I presume you're referring to the C programming language. >>> >>> How many lines of C code are in this function? I presume posting >>> that number wouldn't harm its "trade secret" status. (I'm not >>> interested in any answer to this question that isn't a specific >>> positive integer.) >> >> I can't finish the halt decider until its master UTM is complete. >> The details of the greatly enhanced halt decider have been designed >> for many months. >> >>> Does this function conform to the C language standard? Which edition >>> (C90, C99, C11, ...)? >>> >>> Does this "C" function exist in the context of a C program that >>> you can compile, link, and execute? Have you done so? >> >> It can only be correctly executed inside the master UTM and this is >> not quite built yet. >> >>> Why do you need an x86 interpreter to "run the machine code of this >>> "C" function"? Why can't you just compile it with an ordinary C >> >> I need to function to examine its own machine code because the control >> flow of machine code is straight forward. I need an x86 interpreter as >> the basis of the master UTM. >> >>> compiler and execute it? I understand that the goal is to feed >>> your program its own machine code as input (correct?), but are you >>> able to create an executable that can be run with, for example, >>> empty input? (I understand that it might fail with empty input, >>> but the ability to run the program *at all* is a significant step.) >>> >>>> The machine code examines itself and decides halting on itself. >>>> The key part that I have been working on for the last week is building >>>> the context switching aspect of the master UTM such that one UTM can >>>> execute another UTM and this can be to arbitrary depth. I am guessing >>>> that this will be done very soon. Although this is the most difficult >>>> part that remains it is standard operating system software >>>> engineering. >>>> >>>> Converting an x86 interpreter into a UTM that can execute a chain of >>>> UTMs of arbitrary depth has taken most of my time. Half of this time >>>> was learning the internals of the x86 interpreter well enough that I >>>> can make the changes needed. Less that 10% of my time was spent on >>>> anything directly related to halt deciding. > > Nothing you've written actually responds to anything I asked. > > I'll just conclude that you have a vague "design" for some code that > you eventually intend to write, and that you haven't yet written > an actual C function of any kind. > If you understand what the x86 language is and you understand what a UTM is then you can put them together and know what I have. If you don't understand what these are then you cannot begin to understand what I have. -- Copyright 2020 Pete Olcott
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-08-09 21:36 -0700 |
| Message-ID | <87tuxb3yng.fsf@nosuchdomain.example.com> |
| In reply to | #22243 |
olcott <NoOne@NoWhere.com> writes:
> On 8/9/2020 10:41 PM, Keith Thompson wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>> On 8/9/2020 8:37 PM, Keith Thompson wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>> On 8/9/2020 4:44 PM, Keith Thompson wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>> On 8/9/2020 3:57 PM, Ben Bacarisse wrote:
>>>>>> [...]
>>>>>>>> You don't have, and have never had, a Turing machine with the properties
>>>>>>>> you claim. It would be good if you admitted that and moved on because
>>>>>>>> attempting to defend the indefensible is taking up a lot of your time.
>>>>>>>
>>>>>>> I have a finite state machine that implements computationally
>>>>>>> equivalent code to the Peter Linz H_Hat such that this computational
>>>>>>> equivalent correctly decides halting on itself showing exactly how the
>>>>>>> standard self-referential halting problem counter-example can be
>>>>>>> defeated.
>>>>>>
>>>>>> As I recall, you've claimed to have pseudocode that you were going
>>>>>> to translate into working software. Did you ever actually get it
>>>>>> written and running?
>>>>>>
>>>>>> Do you have a finite state machine, or do you merely have an *idea*
>>>>>> for a finite state machine?
>>>>>
>>>>> I translated the finite state equivalent of the same self-referential
>>>>> counter-example that all the Halting Problem proofs are based on into
>>>>> "C". I am using a very excellent x86 interpreter to run the machine
>>>>> code of this "C" function. It turns out that Visual "C++" generates
>>>>> machine code that is easier to understand than g++.
>>>>
>>>> So now you have a "C" function.
>>>>
>>>> The quotation marks around C seem odd. Are they significant, and if
>>>> so, what's the difference between a "C" function and a C function?
>>>> I presume you're referring to the C programming language.
>>>>
>>>> How many lines of C code are in this function? I presume posting
>>>> that number wouldn't harm its "trade secret" status. (I'm not
>>>> interested in any answer to this question that isn't a specific
>>>> positive integer.)
>>>
>>> I can't finish the halt decider until its master UTM is complete.
>>> The details of the greatly enhanced halt decider have been designed
>>> for many months.
>>>
>>>> Does this function conform to the C language standard? Which edition
>>>> (C90, C99, C11, ...)?
>>>>
>>>> Does this "C" function exist in the context of a C program that
>>>> you can compile, link, and execute? Have you done so?
>>>
>>> It can only be correctly executed inside the master UTM and this is
>>> not quite built yet.
>>>
>>>> Why do you need an x86 interpreter to "run the machine code of this
>>>> "C" function"? Why can't you just compile it with an ordinary C
>>>
>>> I need to function to examine its own machine code because the control
>>> flow of machine code is straight forward. I need an x86 interpreter as
>>> the basis of the master UTM.
>>>
>>>> compiler and execute it? I understand that the goal is to feed
>>>> your program its own machine code as input (correct?), but are you
>>>> able to create an executable that can be run with, for example,
>>>> empty input? (I understand that it might fail with empty input,
>>>> but the ability to run the program *at all* is a significant step.)
>>>>
>>>>> The machine code examines itself and decides halting on itself.
>>>>> The key part that I have been working on for the last week is building
>>>>> the context switching aspect of the master UTM such that one UTM can
>>>>> execute another UTM and this can be to arbitrary depth. I am guessing
>>>>> that this will be done very soon. Although this is the most difficult
>>>>> part that remains it is standard operating system software
>>>>> engineering.
>>>>>
>>>>> Converting an x86 interpreter into a UTM that can execute a chain of
>>>>> UTMs of arbitrary depth has taken most of my time. Half of this time
>>>>> was learning the internals of the x86 interpreter well enough that I
>>>>> can make the changes needed. Less that 10% of my time was spent on
>>>>> anything directly related to halt deciding.
>>
>> Nothing you've written actually responds to anything I asked.
>>
>> I'll just conclude that you have a vague "design" for some code that
>> you eventually intend to write, and that you haven't yet written
>> an actual C function of any kind.
>
> If you understand what the x86 language is and you understand what a
> UTM is then you can put them together and know what I have. If you
> don't understand what these are then you cannot begin to understand
> what I have.
Nonsense.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2020-08-09 23:44 -0500 |
| Message-ID | <d62dnasNw5xcTa3CnZ2dnUU7-IXNnZ2d@giganews.com> |
| In reply to | #22245 |
On 8/9/2020 11:36 PM, Keith Thompson wrote: > olcott <NoOne@NoWhere.com> writes: >> On 8/9/2020 10:41 PM, Keith Thompson wrote: >>> olcott <NoOne@NoWhere.com> writes: >>>> On 8/9/2020 8:37 PM, Keith Thompson wrote: >>>>> olcott <NoOne@NoWhere.com> writes: >>>>>> On 8/9/2020 4:44 PM, Keith Thompson wrote: >>>>>>> olcott <NoOne@NoWhere.com> writes: >>>>>>>> On 8/9/2020 3:57 PM, Ben Bacarisse wrote: >>>>>>> [...] >>>>>>>>> You don't have, and have never had, a Turing machine with the properties >>>>>>>>> you claim. It would be good if you admitted that and moved on because >>>>>>>>> attempting to defend the indefensible is taking up a lot of your time. >>>>>>>> >>>>>>>> I have a finite state machine that implements computationally >>>>>>>> equivalent code to the Peter Linz H_Hat such that this computational >>>>>>>> equivalent correctly decides halting on itself showing exactly how the >>>>>>>> standard self-referential halting problem counter-example can be >>>>>>>> defeated. >>>>>>> >>>>>>> As I recall, you've claimed to have pseudocode that you were going >>>>>>> to translate into working software. Did you ever actually get it >>>>>>> written and running? >>>>>>> >>>>>>> Do you have a finite state machine, or do you merely have an *idea* >>>>>>> for a finite state machine? >>>>>> >>>>>> I translated the finite state equivalent of the same self-referential >>>>>> counter-example that all the Halting Problem proofs are based on into >>>>>> "C". I am using a very excellent x86 interpreter to run the machine >>>>>> code of this "C" function. It turns out that Visual "C++" generates >>>>>> machine code that is easier to understand than g++. >>>>> >>>>> So now you have a "C" function. >>>>> >>>>> The quotation marks around C seem odd. Are they significant, and if >>>>> so, what's the difference between a "C" function and a C function? >>>>> I presume you're referring to the C programming language. >>>>> >>>>> How many lines of C code are in this function? I presume posting >>>>> that number wouldn't harm its "trade secret" status. (I'm not >>>>> interested in any answer to this question that isn't a specific >>>>> positive integer.) >>>> >>>> I can't finish the halt decider until its master UTM is complete. >>>> The details of the greatly enhanced halt decider have been designed >>>> for many months. >>>> >>>>> Does this function conform to the C language standard? Which edition >>>>> (C90, C99, C11, ...)? >>>>> >>>>> Does this "C" function exist in the context of a C program that >>>>> you can compile, link, and execute? Have you done so? >>>> >>>> It can only be correctly executed inside the master UTM and this is >>>> not quite built yet. >>>> >>>>> Why do you need an x86 interpreter to "run the machine code of this >>>>> "C" function"? Why can't you just compile it with an ordinary C >>>> >>>> I need to function to examine its own machine code because the control >>>> flow of machine code is straight forward. I need an x86 interpreter as >>>> the basis of the master UTM. >>>> >>>>> compiler and execute it? I understand that the goal is to feed >>>>> your program its own machine code as input (correct?), but are you >>>>> able to create an executable that can be run with, for example, >>>>> empty input? (I understand that it might fail with empty input, >>>>> but the ability to run the program *at all* is a significant step.) >>>>> >>>>>> The machine code examines itself and decides halting on itself. >>>>>> The key part that I have been working on for the last week is building >>>>>> the context switching aspect of the master UTM such that one UTM can >>>>>> execute another UTM and this can be to arbitrary depth. I am guessing >>>>>> that this will be done very soon. Although this is the most difficult >>>>>> part that remains it is standard operating system software >>>>>> engineering. >>>>>> >>>>>> Converting an x86 interpreter into a UTM that can execute a chain of >>>>>> UTMs of arbitrary depth has taken most of my time. Half of this time >>>>>> was learning the internals of the x86 interpreter well enough that I >>>>>> can make the changes needed. Less that 10% of my time was spent on >>>>>> anything directly related to halt deciding. >>> >>> Nothing you've written actually responds to anything I asked. >>> >>> I'll just conclude that you have a vague "design" for some code that >>> you eventually intend to write, and that you haven't yet written >>> an actual C function of any kind. >> >> If you understand what the x86 language is and you understand what a >> UTM is then you can put them together and know what I have. If you >> don't understand what these are then you cannot begin to understand >> what I have. > > Nonsense. > That is exactly the answer that would be expected from someone that does not know the underlying subject matter. I have been working with the x86 language since the early 1980's. This was back when 64K was the maximum segment size. Boy is it a relief to have 4 GB segments, switching between 64K segments was so tedious. -- Copyright 2020 Pete Olcott
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-08-09 22:22 -0700 |
| Message-ID | <87pn7z3wjg.fsf@nosuchdomain.example.com> |
| In reply to | #22247 |
olcott <NoOne@NoWhere.com> writes:
> On 8/9/2020 11:36 PM, Keith Thompson wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>> On 8/9/2020 10:41 PM, Keith Thompson wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>> On 8/9/2020 8:37 PM, Keith Thompson wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>> On 8/9/2020 4:44 PM, Keith Thompson wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>> On 8/9/2020 3:57 PM, Ben Bacarisse wrote:
>>>>>>>> [...]
>>>>>>>>>> You don't have, and have never had, a Turing machine with the properties
>>>>>>>>>> you claim. It would be good if you admitted that and moved on because
>>>>>>>>>> attempting to defend the indefensible is taking up a lot of your time.
>>>>>>>>>
>>>>>>>>> I have a finite state machine that implements computationally
>>>>>>>>> equivalent code to the Peter Linz H_Hat such that this computational
>>>>>>>>> equivalent correctly decides halting on itself showing exactly how the
>>>>>>>>> standard self-referential halting problem counter-example can be
>>>>>>>>> defeated.
>>>>>>>>
>>>>>>>> As I recall, you've claimed to have pseudocode that you were going
>>>>>>>> to translate into working software. Did you ever actually get it
>>>>>>>> written and running?
>>>>>>>>
>>>>>>>> Do you have a finite state machine, or do you merely have an *idea*
>>>>>>>> for a finite state machine?
>>>>>>>
>>>>>>> I translated the finite state equivalent of the same self-referential
>>>>>>> counter-example that all the Halting Problem proofs are based on into
>>>>>>> "C". I am using a very excellent x86 interpreter to run the machine
>>>>>>> code of this "C" function. It turns out that Visual "C++" generates
>>>>>>> machine code that is easier to understand than g++.
>>>>>>
>>>>>> So now you have a "C" function.
>>>>>>
>>>>>> The quotation marks around C seem odd. Are they significant, and if
>>>>>> so, what's the difference between a "C" function and a C function?
>>>>>> I presume you're referring to the C programming language.
>>>>>>
>>>>>> How many lines of C code are in this function? I presume posting
>>>>>> that number wouldn't harm its "trade secret" status. (I'm not
>>>>>> interested in any answer to this question that isn't a specific
>>>>>> positive integer.)
>>>>>
>>>>> I can't finish the halt decider until its master UTM is complete.
>>>>> The details of the greatly enhanced halt decider have been designed
>>>>> for many months.
>>>>>
>>>>>> Does this function conform to the C language standard? Which edition
>>>>>> (C90, C99, C11, ...)?
>>>>>>
>>>>>> Does this "C" function exist in the context of a C program that
>>>>>> you can compile, link, and execute? Have you done so?
>>>>>
>>>>> It can only be correctly executed inside the master UTM and this is
>>>>> not quite built yet.
>>>>>
>>>>>> Why do you need an x86 interpreter to "run the machine code of this
>>>>>> "C" function"? Why can't you just compile it with an ordinary C
>>>>>
>>>>> I need to function to examine its own machine code because the control
>>>>> flow of machine code is straight forward. I need an x86 interpreter as
>>>>> the basis of the master UTM.
>>>>>
>>>>>> compiler and execute it? I understand that the goal is to feed
>>>>>> your program its own machine code as input (correct?), but are you
>>>>>> able to create an executable that can be run with, for example,
>>>>>> empty input? (I understand that it might fail with empty input,
>>>>>> but the ability to run the program *at all* is a significant step.)
>>>>>>
>>>>>>> The machine code examines itself and decides halting on itself.
>>>>>>> The key part that I have been working on for the last week is building
>>>>>>> the context switching aspect of the master UTM such that one UTM can
>>>>>>> execute another UTM and this can be to arbitrary depth. I am guessing
>>>>>>> that this will be done very soon. Although this is the most difficult
>>>>>>> part that remains it is standard operating system software
>>>>>>> engineering.
>>>>>>>
>>>>>>> Converting an x86 interpreter into a UTM that can execute a chain of
>>>>>>> UTMs of arbitrary depth has taken most of my time. Half of this time
>>>>>>> was learning the internals of the x86 interpreter well enough that I
>>>>>>> can make the changes needed. Less that 10% of my time was spent on
>>>>>>> anything directly related to halt deciding.
>>>>
>>>> Nothing you've written actually responds to anything I asked.
>>>>
>>>> I'll just conclude that you have a vague "design" for some code that
>>>> you eventually intend to write, and that you haven't yet written
>>>> an actual C function of any kind.
>>>
>>> If you understand what the x86 language is and you understand what a
>>> UTM is then you can put them together and know what I have. If you
>>> don't understand what these are then you cannot begin to understand
>>> what I have.
>>
>> Nonsense.
>
> That is exactly the answer that would be expected from someone that
> does not know the underlying subject matter. I have been working with
> the x86 language since the early 1980's. This was back when 64K was
> the maximum segment size. Boy is it a relief to have 4 GB segments,
> switching between 64K segments was so tedious.
Resorting to insults means you don't have to explain anything, right?
I've noticed you tend to do that when someone pushes you to answer a
simple question.
Here's an easy one. You've used the phrase
a "C" function
Is there any significant difference in meaning between that and
a C function
?
I'm just asking you to explain the quotation marks. If they don't
mean anything, that's fine.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2020-08-10 00:41 -0500 |
| Message-ID | <NfudndclNaOVQ63CnZ2dnUU7-XWdnZ2d@giganews.com> |
| In reply to | #22248 |
On 8/10/2020 12:22 AM, Keith Thompson wrote: > olcott <NoOne@NoWhere.com> writes: >> On 8/9/2020 11:36 PM, Keith Thompson wrote: >>> olcott <NoOne@NoWhere.com> writes: >>>> On 8/9/2020 10:41 PM, Keith Thompson wrote: >>>>> olcott <NoOne@NoWhere.com> writes: >>>>>> On 8/9/2020 8:37 PM, Keith Thompson wrote: >>>>>>> olcott <NoOne@NoWhere.com> writes: >>>>>>>> On 8/9/2020 4:44 PM, Keith Thompson wrote: >>>>>>>>> olcott <NoOne@NoWhere.com> writes: >>>>>>>>>> On 8/9/2020 3:57 PM, Ben Bacarisse wrote: >>>>>>>>> [...] >>>>>>>>>>> You don't have, and have never had, a Turing machine with the properties >>>>>>>>>>> you claim. It would be good if you admitted that and moved on because >>>>>>>>>>> attempting to defend the indefensible is taking up a lot of your time. >>>>>>>>>> >>>>>>>>>> I have a finite state machine that implements computationally >>>>>>>>>> equivalent code to the Peter Linz H_Hat such that this computational >>>>>>>>>> equivalent correctly decides halting on itself showing exactly how the >>>>>>>>>> standard self-referential halting problem counter-example can be >>>>>>>>>> defeated. >>>>>>>>> >>>>>>>>> As I recall, you've claimed to have pseudocode that you were going >>>>>>>>> to translate into working software. Did you ever actually get it >>>>>>>>> written and running? >>>>>>>>> >>>>>>>>> Do you have a finite state machine, or do you merely have an *idea* >>>>>>>>> for a finite state machine? >>>>>>>> >>>>>>>> I translated the finite state equivalent of the same self-referential >>>>>>>> counter-example that all the Halting Problem proofs are based on into >>>>>>>> "C". I am using a very excellent x86 interpreter to run the machine >>>>>>>> code of this "C" function. It turns out that Visual "C++" generates >>>>>>>> machine code that is easier to understand than g++. >>>>>>> >>>>>>> So now you have a "C" function. >>>>>>> >>>>>>> The quotation marks around C seem odd. Are they significant, and if >>>>>>> so, what's the difference between a "C" function and a C function? >>>>>>> I presume you're referring to the C programming language. >>>>>>> >>>>>>> How many lines of C code are in this function? I presume posting >>>>>>> that number wouldn't harm its "trade secret" status. (I'm not >>>>>>> interested in any answer to this question that isn't a specific >>>>>>> positive integer.) >>>>>> >>>>>> I can't finish the halt decider until its master UTM is complete. >>>>>> The details of the greatly enhanced halt decider have been designed >>>>>> for many months. >>>>>> >>>>>>> Does this function conform to the C language standard? Which edition >>>>>>> (C90, C99, C11, ...)? >>>>>>> >>>>>>> Does this "C" function exist in the context of a C program that >>>>>>> you can compile, link, and execute? Have you done so? >>>>>> >>>>>> It can only be correctly executed inside the master UTM and this is >>>>>> not quite built yet. >>>>>> >>>>>>> Why do you need an x86 interpreter to "run the machine code of this >>>>>>> "C" function"? Why can't you just compile it with an ordinary C >>>>>> >>>>>> I need to function to examine its own machine code because the control >>>>>> flow of machine code is straight forward. I need an x86 interpreter as >>>>>> the basis of the master UTM. >>>>>> >>>>>>> compiler and execute it? I understand that the goal is to feed >>>>>>> your program its own machine code as input (correct?), but are you >>>>>>> able to create an executable that can be run with, for example, >>>>>>> empty input? (I understand that it might fail with empty input, >>>>>>> but the ability to run the program *at all* is a significant step.) >>>>>>> >>>>>>>> The machine code examines itself and decides halting on itself. >>>>>>>> The key part that I have been working on for the last week is building >>>>>>>> the context switching aspect of the master UTM such that one UTM can >>>>>>>> execute another UTM and this can be to arbitrary depth. I am guessing >>>>>>>> that this will be done very soon. Although this is the most difficult >>>>>>>> part that remains it is standard operating system software >>>>>>>> engineering. >>>>>>>> >>>>>>>> Converting an x86 interpreter into a UTM that can execute a chain of >>>>>>>> UTMs of arbitrary depth has taken most of my time. Half of this time >>>>>>>> was learning the internals of the x86 interpreter well enough that I >>>>>>>> can make the changes needed. Less that 10% of my time was spent on >>>>>>>> anything directly related to halt deciding. >>>>> >>>>> Nothing you've written actually responds to anything I asked. >>>>> >>>>> I'll just conclude that you have a vague "design" for some code that >>>>> you eventually intend to write, and that you haven't yet written >>>>> an actual C function of any kind. >>>> >>>> If you understand what the x86 language is and you understand what a >>>> UTM is then you can put them together and know what I have. If you >>>> don't understand what these are then you cannot begin to understand >>>> what I have. >>> >>> Nonsense. >> >> That is exactly the answer that would be expected from someone that >> does not know the underlying subject matter. I have been working with >> the x86 language since the early 1980's. This was back when 64K was >> the maximum segment size. Boy is it a relief to have 4 GB segments, >> switching between 64K segments was so tedious. > > Resorting to insults means you don't have to explain anything, right? > Merely an objective assessment. > I've noticed you tend to do that when someone pushes you to answer a > simple question. > > Here's an easy one. You've used the phrase > a "C" function > Is there any significant difference in meaning between that and > a C function > ? No, it is merely easier to read. > > I'm just asking you to explain the quotation marks. If they don't > mean anything, that's fine. > -- Copyright 2020 Pete Olcott
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-08-09 22:56 -0700 |
| Message-ID | <87lfin3uy8.fsf@nosuchdomain.example.com> |
| In reply to | #22250 |
olcott <NoOne@NoWhere.com> writes:
> On 8/10/2020 12:22 AM, Keith Thompson wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>> On 8/9/2020 11:36 PM, Keith Thompson wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>> On 8/9/2020 10:41 PM, Keith Thompson wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>> On 8/9/2020 8:37 PM, Keith Thompson wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>> On 8/9/2020 4:44 PM, Keith Thompson wrote:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>> On 8/9/2020 3:57 PM, Ben Bacarisse wrote:
>>>>>>>>>> [...]
>>>>>>>>>>>> You don't have, and have never had, a Turing machine with the properties
>>>>>>>>>>>> you claim. It would be good if you admitted that and moved on because
>>>>>>>>>>>> attempting to defend the indefensible is taking up a lot of your time.
>>>>>>>>>>>
>>>>>>>>>>> I have a finite state machine that implements computationally
>>>>>>>>>>> equivalent code to the Peter Linz H_Hat such that this computational
>>>>>>>>>>> equivalent correctly decides halting on itself showing exactly how the
>>>>>>>>>>> standard self-referential halting problem counter-example can be
>>>>>>>>>>> defeated.
>>>>>>>>>>
>>>>>>>>>> As I recall, you've claimed to have pseudocode that you were going
>>>>>>>>>> to translate into working software. Did you ever actually get it
>>>>>>>>>> written and running?
>>>>>>>>>>
>>>>>>>>>> Do you have a finite state machine, or do you merely have an *idea*
>>>>>>>>>> for a finite state machine?
>>>>>>>>>
>>>>>>>>> I translated the finite state equivalent of the same self-referential
>>>>>>>>> counter-example that all the Halting Problem proofs are based on into
>>>>>>>>> "C". I am using a very excellent x86 interpreter to run the machine
>>>>>>>>> code of this "C" function. It turns out that Visual "C++" generates
>>>>>>>>> machine code that is easier to understand than g++.
>>>>>>>>
>>>>>>>> So now you have a "C" function.
>>>>>>>>
>>>>>>>> The quotation marks around C seem odd. Are they significant, and if
>>>>>>>> so, what's the difference between a "C" function and a C function?
>>>>>>>> I presume you're referring to the C programming language.
>>>>>>>>
>>>>>>>> How many lines of C code are in this function? I presume posting
>>>>>>>> that number wouldn't harm its "trade secret" status. (I'm not
>>>>>>>> interested in any answer to this question that isn't a specific
>>>>>>>> positive integer.)
>>>>>>>
>>>>>>> I can't finish the halt decider until its master UTM is complete.
>>>>>>> The details of the greatly enhanced halt decider have been designed
>>>>>>> for many months.
>>>>>>>
>>>>>>>> Does this function conform to the C language standard? Which edition
>>>>>>>> (C90, C99, C11, ...)?
>>>>>>>>
>>>>>>>> Does this "C" function exist in the context of a C program that
>>>>>>>> you can compile, link, and execute? Have you done so?
>>>>>>>
>>>>>>> It can only be correctly executed inside the master UTM and this is
>>>>>>> not quite built yet.
>>>>>>>
>>>>>>>> Why do you need an x86 interpreter to "run the machine code of this
>>>>>>>> "C" function"? Why can't you just compile it with an ordinary C
>>>>>>>
>>>>>>> I need to function to examine its own machine code because the control
>>>>>>> flow of machine code is straight forward. I need an x86 interpreter as
>>>>>>> the basis of the master UTM.
>>>>>>>
>>>>>>>> compiler and execute it? I understand that the goal is to feed
>>>>>>>> your program its own machine code as input (correct?), but are you
>>>>>>>> able to create an executable that can be run with, for example,
>>>>>>>> empty input? (I understand that it might fail with empty input,
>>>>>>>> but the ability to run the program *at all* is a significant step.)
>>>>>>>>
>>>>>>>>> The machine code examines itself and decides halting on itself.
>>>>>>>>> The key part that I have been working on for the last week is building
>>>>>>>>> the context switching aspect of the master UTM such that one UTM can
>>>>>>>>> execute another UTM and this can be to arbitrary depth. I am guessing
>>>>>>>>> that this will be done very soon. Although this is the most difficult
>>>>>>>>> part that remains it is standard operating system software
>>>>>>>>> engineering.
>>>>>>>>>
>>>>>>>>> Converting an x86 interpreter into a UTM that can execute a chain of
>>>>>>>>> UTMs of arbitrary depth has taken most of my time. Half of this time
>>>>>>>>> was learning the internals of the x86 interpreter well enough that I
>>>>>>>>> can make the changes needed. Less that 10% of my time was spent on
>>>>>>>>> anything directly related to halt deciding.
>>>>>>
>>>>>> Nothing you've written actually responds to anything I asked.
>>>>>>
>>>>>> I'll just conclude that you have a vague "design" for some code that
>>>>>> you eventually intend to write, and that you haven't yet written
>>>>>> an actual C function of any kind.
>>>>>
>>>>> If you understand what the x86 language is and you understand what a
>>>>> UTM is then you can put them together and know what I have. If you
>>>>> don't understand what these are then you cannot begin to understand
>>>>> what I have.
>>>>
>>>> Nonsense.
>>>
>>> That is exactly the answer that would be expected from someone that
>>> does not know the underlying subject matter. I have been working with
>>> the x86 language since the early 1980's. This was back when 64K was
>>> the maximum segment size. Boy is it a relief to have 4 GB segments,
>>> switching between 64K segments was so tedious.
>>
>> Resorting to insults means you don't have to explain anything, right?
>
> Merely an objective assessment.
Whatever. I'm not going to follow that particular digression any further.
>> I've noticed you tend to do that when someone pushes you to answer a
>> simple question.
>>
>> Here's an easy one. You've used the phrase
>> a "C" function
>> Is there any significant difference in meaning between that and
>> a C function
>> ?
>
> No, it is merely easier to read.
Great.
Is there a number of times I have to ask a straightforward question
before you'll answer it? Would it help if I just ask it that
many times in a single post? (This doesn't imply I'd be willing
to do that.) Yes, I'm being a bit sarcastic, but if you'll read
the quoted material in this post, I think you'll see that you've
been extraordinarily unwilling to answer simple questions (and
that has led me to make certain inferences that I won't get into
for the moment).
FWIW, putting quotation marks around C does not make it easier
to read. As you can see my my response, all it does is make me
think that there's some significance to them. But now that I know
that there isn't:
You've referred to a C function. Have you written this C function?
Is it, or is it intended to be, in standard C? Which edition of the
standard does it attempt to conform to? How many lines long is it?
(If you were willing to share the function itself that would be
great, but I presume you won't do that.)
I'll leave questions about what the function is supposed to do
for later.
I've already asked you these questions, and you ignored them.
I presume that it's important *to you* to communicate something
about what you're working on. It's less important to me. So I'm
not going to be as persistent about getting you to answer these
simple questions.
>> I'm just asking you to explain the quotation marks. If they don't
>> mean anything, that's fine.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2020-08-10 01:06 -0500 |
| Message-ID | <9YudnWkJupFsfq3CnZ2dnUU7-K_NnZ2d@giganews.com> |
| In reply to | #22252 |
On 8/10/2020 12:56 AM, Keith Thompson wrote: > olcott <NoOne@NoWhere.com> writes: >> On 8/10/2020 12:22 AM, Keith Thompson wrote: >>> olcott <NoOne@NoWhere.com> writes: >>>> On 8/9/2020 11:36 PM, Keith Thompson wrote: >>>>> olcott <NoOne@NoWhere.com> writes: >>>>>> On 8/9/2020 10:41 PM, Keith Thompson wrote: >>>>>>> olcott <NoOne@NoWhere.com> writes: >>>>>>>> On 8/9/2020 8:37 PM, Keith Thompson wrote: >>>>>>>>> olcott <NoOne@NoWhere.com> writes: >>>>>>>>>> On 8/9/2020 4:44 PM, Keith Thompson wrote: >>>>>>>>>>> olcott <NoOne@NoWhere.com> writes: >>>>>>>>>>>> On 8/9/2020 3:57 PM, Ben Bacarisse wrote: >>>>>>>>>>> [...] >>>>>>>>>>>>> You don't have, and have never had, a Turing machine with the properties >>>>>>>>>>>>> you claim. It would be good if you admitted that and moved on because >>>>>>>>>>>>> attempting to defend the indefensible is taking up a lot of your time. >>>>>>>>>>>> >>>>>>>>>>>> I have a finite state machine that implements computationally >>>>>>>>>>>> equivalent code to the Peter Linz H_Hat such that this computational >>>>>>>>>>>> equivalent correctly decides halting on itself showing exactly how the >>>>>>>>>>>> standard self-referential halting problem counter-example can be >>>>>>>>>>>> defeated. >>>>>>>>>>> >>>>>>>>>>> As I recall, you've claimed to have pseudocode that you were going >>>>>>>>>>> to translate into working software. Did you ever actually get it >>>>>>>>>>> written and running? >>>>>>>>>>> >>>>>>>>>>> Do you have a finite state machine, or do you merely have an *idea* >>>>>>>>>>> for a finite state machine? >>>>>>>>>> >>>>>>>>>> I translated the finite state equivalent of the same self-referential >>>>>>>>>> counter-example that all the Halting Problem proofs are based on into >>>>>>>>>> "C". I am using a very excellent x86 interpreter to run the machine >>>>>>>>>> code of this "C" function. It turns out that Visual "C++" generates >>>>>>>>>> machine code that is easier to understand than g++. >>>>>>>>> >>>>>>>>> So now you have a "C" function. >>>>>>>>> >>>>>>>>> The quotation marks around C seem odd. Are they significant, and if >>>>>>>>> so, what's the difference between a "C" function and a C function? >>>>>>>>> I presume you're referring to the C programming language. >>>>>>>>> >>>>>>>>> How many lines of C code are in this function? I presume posting >>>>>>>>> that number wouldn't harm its "trade secret" status. (I'm not >>>>>>>>> interested in any answer to this question that isn't a specific >>>>>>>>> positive integer.) >>>>>>>> >>>>>>>> I can't finish the halt decider until its master UTM is complete. >>>>>>>> The details of the greatly enhanced halt decider have been designed >>>>>>>> for many months. >>>>>>>> >>>>>>>>> Does this function conform to the C language standard? Which edition >>>>>>>>> (C90, C99, C11, ...)? >>>>>>>>> >>>>>>>>> Does this "C" function exist in the context of a C program that >>>>>>>>> you can compile, link, and execute? Have you done so? >>>>>>>> >>>>>>>> It can only be correctly executed inside the master UTM and this is >>>>>>>> not quite built yet. >>>>>>>> >>>>>>>>> Why do you need an x86 interpreter to "run the machine code of this >>>>>>>>> "C" function"? Why can't you just compile it with an ordinary C >>>>>>>> >>>>>>>> I need to function to examine its own machine code because the control >>>>>>>> flow of machine code is straight forward. I need an x86 interpreter as >>>>>>>> the basis of the master UTM. >>>>>>>> >>>>>>>>> compiler and execute it? I understand that the goal is to feed >>>>>>>>> your program its own machine code as input (correct?), but are you >>>>>>>>> able to create an executable that can be run with, for example, >>>>>>>>> empty input? (I understand that it might fail with empty input, >>>>>>>>> but the ability to run the program *at all* is a significant step.) >>>>>>>>> >>>>>>>>>> The machine code examines itself and decides halting on itself. >>>>>>>>>> The key part that I have been working on for the last week is building >>>>>>>>>> the context switching aspect of the master UTM such that one UTM can >>>>>>>>>> execute another UTM and this can be to arbitrary depth. I am guessing >>>>>>>>>> that this will be done very soon. Although this is the most difficult >>>>>>>>>> part that remains it is standard operating system software >>>>>>>>>> engineering. >>>>>>>>>> >>>>>>>>>> Converting an x86 interpreter into a UTM that can execute a chain of >>>>>>>>>> UTMs of arbitrary depth has taken most of my time. Half of this time >>>>>>>>>> was learning the internals of the x86 interpreter well enough that I >>>>>>>>>> can make the changes needed. Less that 10% of my time was spent on >>>>>>>>>> anything directly related to halt deciding. >>>>>>> >>>>>>> Nothing you've written actually responds to anything I asked. >>>>>>> >>>>>>> I'll just conclude that you have a vague "design" for some code that >>>>>>> you eventually intend to write, and that you haven't yet written >>>>>>> an actual C function of any kind. >>>>>> >>>>>> If you understand what the x86 language is and you understand what a >>>>>> UTM is then you can put them together and know what I have. If you >>>>>> don't understand what these are then you cannot begin to understand >>>>>> what I have. >>>>> >>>>> Nonsense. >>>> >>>> That is exactly the answer that would be expected from someone that >>>> does not know the underlying subject matter. I have been working with >>>> the x86 language since the early 1980's. This was back when 64K was >>>> the maximum segment size. Boy is it a relief to have 4 GB segments, >>>> switching between 64K segments was so tedious. >>> >>> Resorting to insults means you don't have to explain anything, right? >> >> Merely an objective assessment. > > Whatever. I'm not going to follow that particular digression any further. > >>> I've noticed you tend to do that when someone pushes you to answer a >>> simple question. >>> >>> Here's an easy one. You've used the phrase >>> a "C" function >>> Is there any significant difference in meaning between that and >>> a C function >>> ? >> >> No, it is merely easier to read. > > Great. > > Is there a number of times I have to ask a straightforward question > before you'll answer it? Would it help if I just ask it that > many times in a single post? (This doesn't imply I'd be willing > to do that.) Yes, I'm being a bit sarcastic, but if you'll read > the quoted material in this post, I think you'll see that you've > been extraordinarily unwilling to answer simple questions (and > that has led me to make certain inferences that I won't get into > for the moment). > > FWIW, putting quotation marks around C does not make it easier > to read. As you can see my my response, all it does is make me > think that there's some significance to them. But now that I know > that there isn't: > > You've referred to a C function. Have you written this C function? > Is it, or is it intended to be, in standard C? Which edition of the > standard does it attempt to conform to? How many lines long is it? > (If you were willing to share the function itself that would be > great, but I presume you won't do that.) > > I'll leave questions about what the function is supposed to do > for later. I can't write the function yet because its operating system is not finished. The function itself is in very standard very simple c. It is the same c since the first ansi c. I began writing c back when it was K&R c. > > I've already asked you these questions, and you ignored them. > I presume that it's important *to you* to communicate something > about what you're working on. It's less important to me. So I'm > not going to be as persistent about getting you to answer these > simple questions. > I told you that I can't write the function because its operating system is not finished. >>> I'm just asking you to explain the quotation marks. If they don't >>> mean anything, that's fine. > -- Copyright 2020 Pete Olcott
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-08-09 23:20 -0700 |
| Message-ID | <87h7tb3ttk.fsf@nosuchdomain.example.com> |
| In reply to | #22253 |
olcott <NoOne@NoWhere.com> writes:
> On 8/10/2020 12:56 AM, Keith Thompson wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>> On 8/10/2020 12:22 AM, Keith Thompson wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>> On 8/9/2020 11:36 PM, Keith Thompson wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>> On 8/9/2020 10:41 PM, Keith Thompson wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>> On 8/9/2020 8:37 PM, Keith Thompson wrote:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>> On 8/9/2020 4:44 PM, Keith Thompson wrote:
>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>> On 8/9/2020 3:57 PM, Ben Bacarisse wrote:
>>>>>>>>>>>> [...]
>>>>>>>>>>>>>> You don't have, and have never had, a Turing machine with the properties
>>>>>>>>>>>>>> you claim. It would be good if you admitted that and moved on because
>>>>>>>>>>>>>> attempting to defend the indefensible is taking up a lot of your time.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I have a finite state machine that implements computationally
>>>>>>>>>>>>> equivalent code to the Peter Linz H_Hat such that this computational
>>>>>>>>>>>>> equivalent correctly decides halting on itself showing exactly how the
>>>>>>>>>>>>> standard self-referential halting problem counter-example can be
>>>>>>>>>>>>> defeated.
>>>>>>>>>>>>
>>>>>>>>>>>> As I recall, you've claimed to have pseudocode that you were going
>>>>>>>>>>>> to translate into working software. Did you ever actually get it
>>>>>>>>>>>> written and running?
>>>>>>>>>>>>
>>>>>>>>>>>> Do you have a finite state machine, or do you merely have an *idea*
>>>>>>>>>>>> for a finite state machine?
>>>>>>>>>>>
>>>>>>>>>>> I translated the finite state equivalent of the same self-referential
>>>>>>>>>>> counter-example that all the Halting Problem proofs are based on into
>>>>>>>>>>> "C". I am using a very excellent x86 interpreter to run the machine
>>>>>>>>>>> code of this "C" function. It turns out that Visual "C++" generates
>>>>>>>>>>> machine code that is easier to understand than g++.
>>>>>>>>>>
>>>>>>>>>> So now you have a "C" function.
>>>>>>>>>>
>>>>>>>>>> The quotation marks around C seem odd. Are they significant, and if
>>>>>>>>>> so, what's the difference between a "C" function and a C function?
>>>>>>>>>> I presume you're referring to the C programming language.
>>>>>>>>>>
>>>>>>>>>> How many lines of C code are in this function? I presume posting
>>>>>>>>>> that number wouldn't harm its "trade secret" status. (I'm not
>>>>>>>>>> interested in any answer to this question that isn't a specific
>>>>>>>>>> positive integer.)
>>>>>>>>>
>>>>>>>>> I can't finish the halt decider until its master UTM is complete.
>>>>>>>>> The details of the greatly enhanced halt decider have been designed
>>>>>>>>> for many months.
>>>>>>>>>
>>>>>>>>>> Does this function conform to the C language standard? Which edition
>>>>>>>>>> (C90, C99, C11, ...)?
>>>>>>>>>>
>>>>>>>>>> Does this "C" function exist in the context of a C program that
>>>>>>>>>> you can compile, link, and execute? Have you done so?
>>>>>>>>>
>>>>>>>>> It can only be correctly executed inside the master UTM and this is
>>>>>>>>> not quite built yet.
>>>>>>>>>
>>>>>>>>>> Why do you need an x86 interpreter to "run the machine code of this
>>>>>>>>>> "C" function"? Why can't you just compile it with an ordinary C
>>>>>>>>>
>>>>>>>>> I need to function to examine its own machine code because the control
>>>>>>>>> flow of machine code is straight forward. I need an x86 interpreter as
>>>>>>>>> the basis of the master UTM.
>>>>>>>>>
>>>>>>>>>> compiler and execute it? I understand that the goal is to feed
>>>>>>>>>> your program its own machine code as input (correct?), but are you
>>>>>>>>>> able to create an executable that can be run with, for example,
>>>>>>>>>> empty input? (I understand that it might fail with empty input,
>>>>>>>>>> but the ability to run the program *at all* is a significant step.)
>>>>>>>>>>
>>>>>>>>>>> The machine code examines itself and decides halting on itself.
>>>>>>>>>>> The key part that I have been working on for the last week is building
>>>>>>>>>>> the context switching aspect of the master UTM such that one UTM can
>>>>>>>>>>> execute another UTM and this can be to arbitrary depth. I am guessing
>>>>>>>>>>> that this will be done very soon. Although this is the most difficult
>>>>>>>>>>> part that remains it is standard operating system software
>>>>>>>>>>> engineering.
>>>>>>>>>>>
>>>>>>>>>>> Converting an x86 interpreter into a UTM that can execute a chain of
>>>>>>>>>>> UTMs of arbitrary depth has taken most of my time. Half of this time
>>>>>>>>>>> was learning the internals of the x86 interpreter well enough that I
>>>>>>>>>>> can make the changes needed. Less that 10% of my time was spent on
>>>>>>>>>>> anything directly related to halt deciding.
>>>>>>>>
>>>>>>>> Nothing you've written actually responds to anything I asked.
>>>>>>>>
>>>>>>>> I'll just conclude that you have a vague "design" for some code that
>>>>>>>> you eventually intend to write, and that you haven't yet written
>>>>>>>> an actual C function of any kind.
>>>>>>>
>>>>>>> If you understand what the x86 language is and you understand what a
>>>>>>> UTM is then you can put them together and know what I have. If you
>>>>>>> don't understand what these are then you cannot begin to understand
>>>>>>> what I have.
>>>>>>
>>>>>> Nonsense.
>>>>>
>>>>> That is exactly the answer that would be expected from someone that
>>>>> does not know the underlying subject matter. I have been working with
>>>>> the x86 language since the early 1980's. This was back when 64K was
>>>>> the maximum segment size. Boy is it a relief to have 4 GB segments,
>>>>> switching between 64K segments was so tedious.
>>>>
>>>> Resorting to insults means you don't have to explain anything, right?
>>>
>>> Merely an objective assessment.
>>
>> Whatever. I'm not going to follow that particular digression any further.
>>
>>>> I've noticed you tend to do that when someone pushes you to answer a
>>>> simple question.
>>>>
>>>> Here's an easy one. You've used the phrase
>>>> a "C" function
>>>> Is there any significant difference in meaning between that and
>>>> a C function
>>>> ?
>>>
>>> No, it is merely easier to read.
>>
>> Great.
>>
>> Is there a number of times I have to ask a straightforward question
>> before you'll answer it? Would it help if I just ask it that
>> many times in a single post? (This doesn't imply I'd be willing
>> to do that.) Yes, I'm being a bit sarcastic, but if you'll read
>> the quoted material in this post, I think you'll see that you've
>> been extraordinarily unwilling to answer simple questions (and
>> that has led me to make certain inferences that I won't get into
>> for the moment).
>>
>> FWIW, putting quotation marks around C does not make it easier
>> to read. As you can see my my response, all it does is make me
>> think that there's some significance to them. But now that I know
>> that there isn't:
>>
>> You've referred to a C function. Have you written this C function?
>> Is it, or is it intended to be, in standard C? Which edition of the
>> standard does it attempt to conform to? How many lines long is it?
>> (If you were willing to share the function itself that would be
>> great, but I presume you won't do that.)
>>
>> I'll leave questions about what the function is supposed to do
>> for later.
>
> I can't write the function yet because its operating system is not
> finished.
So you have no C function. Got it.
> The function itself is in very standard very simple c.
You mean it *will be* in very standard very simple C.
> It is the same c since the first ansi c. I began writing c back when
> it was K&R c.
Great, so did I. I'm not sure what you mean by "the same c".
If you mean that this C function that you haven't written yet will
be compatible with the first ANSI C standard and with all later
standards, that's fine. If you mean that the language itself hasn't
changed, that's simply incorrect. I'll explain further if and only
if you ask me to.
>> I've already asked you these questions, and you ignored them.
>> I presume that it's important *to you* to communicate something
>> about what you're working on. It's less important to me. So I'm
>> not going to be as persistent about getting you to answer these
>> simple questions.
>
> I told you that I can't write the function because its operating
> system is not finished.
>
>>>> I'm just asking you to explain the quotation marks. If they don't
>>>> mean anything, that's fine.
You claimed to have a C function. You don't. You acknowledge that
you haven't written it. No doubt you have some design or idea, or
perhaps something written down in some kind of pseudocode, and
we could discuss that if you like, but you don't have a C function.
I *think* you've said or implied that this C function is the same
thing as the "fully encoded Turing Machine" you've been making
claims about (because C is Turing-complete, and you therefore think
you can call any chunk of C code a "fully encoded Turing machine").
Is that correct? So you never had your Turing machine either.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2020-08-10 09:25 -0500 |
| Message-ID | <ldSdnZfQed9ExazCnZ2dnUU7-XvNnZ2d@giganews.com> |
| In reply to | #22255 |
On 8/10/2020 1:20 AM, Keith Thompson wrote: > olcott <NoOne@NoWhere.com> writes: >> On 8/10/2020 12:56 AM, Keith Thompson wrote: >>> olcott <NoOne@NoWhere.com> writes: >>>> On 8/10/2020 12:22 AM, Keith Thompson wrote: >>>>> olcott <NoOne@NoWhere.com> writes: >>>>>> On 8/9/2020 11:36 PM, Keith Thompson wrote: >>>>>>> olcott <NoOne@NoWhere.com> writes: >>>>>>>> On 8/9/2020 10:41 PM, Keith Thompson wrote: >>>>>>>>> olcott <NoOne@NoWhere.com> writes: >>>>>>>>>> On 8/9/2020 8:37 PM, Keith Thompson wrote: >>>>>>>>>>> olcott <NoOne@NoWhere.com> writes: >>>>>>>>>>>> On 8/9/2020 4:44 PM, Keith Thompson wrote: >>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes: >>>>>>>>>>>>>> On 8/9/2020 3:57 PM, Ben Bacarisse wrote: >>>>>>>>>>>>> [...] >>>>>>>>>>>>>>> You don't have, and have never had, a Turing machine with the properties >>>>>>>>>>>>>>> you claim. It would be good if you admitted that and moved on because >>>>>>>>>>>>>>> attempting to defend the indefensible is taking up a lot of your time. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I have a finite state machine that implements computationally >>>>>>>>>>>>>> equivalent code to the Peter Linz H_Hat such that this computational >>>>>>>>>>>>>> equivalent correctly decides halting on itself showing exactly how the >>>>>>>>>>>>>> standard self-referential halting problem counter-example can be >>>>>>>>>>>>>> defeated. >>>>>>>>>>>>> >>>>>>>>>>>>> As I recall, you've claimed to have pseudocode that you were going >>>>>>>>>>>>> to translate into working software. Did you ever actually get it >>>>>>>>>>>>> written and running? >>>>>>>>>>>>> >>>>>>>>>>>>> Do you have a finite state machine, or do you merely have an *idea* >>>>>>>>>>>>> for a finite state machine? >>>>>>>>>>>> >>>>>>>>>>>> I translated the finite state equivalent of the same self-referential >>>>>>>>>>>> counter-example that all the Halting Problem proofs are based on into >>>>>>>>>>>> "C". I am using a very excellent x86 interpreter to run the machine >>>>>>>>>>>> code of this "C" function. It turns out that Visual "C++" generates >>>>>>>>>>>> machine code that is easier to understand than g++. >>>>>>>>>>> >>>>>>>>>>> So now you have a "C" function. >>>>>>>>>>> >>>>>>>>>>> The quotation marks around C seem odd. Are they significant, and if >>>>>>>>>>> so, what's the difference between a "C" function and a C function? >>>>>>>>>>> I presume you're referring to the C programming language. >>>>>>>>>>> >>>>>>>>>>> How many lines of C code are in this function? I presume posting >>>>>>>>>>> that number wouldn't harm its "trade secret" status. (I'm not >>>>>>>>>>> interested in any answer to this question that isn't a specific >>>>>>>>>>> positive integer.) >>>>>>>>>> >>>>>>>>>> I can't finish the halt decider until its master UTM is complete. >>>>>>>>>> The details of the greatly enhanced halt decider have been designed >>>>>>>>>> for many months. >>>>>>>>>> >>>>>>>>>>> Does this function conform to the C language standard? Which edition >>>>>>>>>>> (C90, C99, C11, ...)? >>>>>>>>>>> >>>>>>>>>>> Does this "C" function exist in the context of a C program that >>>>>>>>>>> you can compile, link, and execute? Have you done so? >>>>>>>>>> >>>>>>>>>> It can only be correctly executed inside the master UTM and this is >>>>>>>>>> not quite built yet. >>>>>>>>>> >>>>>>>>>>> Why do you need an x86 interpreter to "run the machine code of this >>>>>>>>>>> "C" function"? Why can't you just compile it with an ordinary C >>>>>>>>>> >>>>>>>>>> I need to function to examine its own machine code because the control >>>>>>>>>> flow of machine code is straight forward. I need an x86 interpreter as >>>>>>>>>> the basis of the master UTM. >>>>>>>>>> >>>>>>>>>>> compiler and execute it? I understand that the goal is to feed >>>>>>>>>>> your program its own machine code as input (correct?), but are you >>>>>>>>>>> able to create an executable that can be run with, for example, >>>>>>>>>>> empty input? (I understand that it might fail with empty input, >>>>>>>>>>> but the ability to run the program *at all* is a significant step.) >>>>>>>>>>> >>>>>>>>>>>> The machine code examines itself and decides halting on itself. >>>>>>>>>>>> The key part that I have been working on for the last week is building >>>>>>>>>>>> the context switching aspect of the master UTM such that one UTM can >>>>>>>>>>>> execute another UTM and this can be to arbitrary depth. I am guessing >>>>>>>>>>>> that this will be done very soon. Although this is the most difficult >>>>>>>>>>>> part that remains it is standard operating system software >>>>>>>>>>>> engineering. >>>>>>>>>>>> >>>>>>>>>>>> Converting an x86 interpreter into a UTM that can execute a chain of >>>>>>>>>>>> UTMs of arbitrary depth has taken most of my time. Half of this time >>>>>>>>>>>> was learning the internals of the x86 interpreter well enough that I >>>>>>>>>>>> can make the changes needed. Less that 10% of my time was spent on >>>>>>>>>>>> anything directly related to halt deciding. >>>>>>>>> >>>>>>>>> Nothing you've written actually responds to anything I asked. >>>>>>>>> >>>>>>>>> I'll just conclude that you have a vague "design" for some code that >>>>>>>>> you eventually intend to write, and that you haven't yet written >>>>>>>>> an actual C function of any kind. >>>>>>>> >>>>>>>> If you understand what the x86 language is and you understand what a >>>>>>>> UTM is then you can put them together and know what I have. If you >>>>>>>> don't understand what these are then you cannot begin to understand >>>>>>>> what I have. >>>>>>> >>>>>>> Nonsense. >>>>>> >>>>>> That is exactly the answer that would be expected from someone that >>>>>> does not know the underlying subject matter. I have been working with >>>>>> the x86 language since the early 1980's. This was back when 64K was >>>>>> the maximum segment size. Boy is it a relief to have 4 GB segments, >>>>>> switching between 64K segments was so tedious. >>>>> >>>>> Resorting to insults means you don't have to explain anything, right? >>>> >>>> Merely an objective assessment. >>> >>> Whatever. I'm not going to follow that particular digression any further. >>> >>>>> I've noticed you tend to do that when someone pushes you to answer a >>>>> simple question. >>>>> >>>>> Here's an easy one. You've used the phrase >>>>> a "C" function >>>>> Is there any significant difference in meaning between that and >>>>> a C function >>>>> ? >>>> >>>> No, it is merely easier to read. >>> >>> Great. >>> >>> Is there a number of times I have to ask a straightforward question >>> before you'll answer it? Would it help if I just ask it that >>> many times in a single post? (This doesn't imply I'd be willing >>> to do that.) Yes, I'm being a bit sarcastic, but if you'll read >>> the quoted material in this post, I think you'll see that you've >>> been extraordinarily unwilling to answer simple questions (and >>> that has led me to make certain inferences that I won't get into >>> for the moment). >>> >>> FWIW, putting quotation marks around C does not make it easier >>> to read. As you can see my my response, all it does is make me >>> think that there's some significance to them. But now that I know >>> that there isn't: >>> >>> You've referred to a C function. Have you written this C function? >>> Is it, or is it intended to be, in standard C? Which edition of the >>> standard does it attempt to conform to? How many lines long is it? >>> (If you were willing to share the function itself that would be >>> great, but I presume you won't do that.) >>> >>> I'll leave questions about what the function is supposed to do >>> for later. >> >> I can't write the function yet because its operating system is not >> finished. > > So you have no C function. Got it. > >> The function itself is in very standard very simple c. > > You mean it *will be* in very standard very simple C. Some of the code is written and executing. >> It is the same c since the first ansi c. I began writing c back when >> it was K&R c. > > Great, so did I. I'm not sure what you mean by "the same c". > If you mean that this C function that you haven't written yet will > be compatible with the first ANSI C standard and with all later > standards, that's fine. I can't write the halt deciding aspects of the code until after I have added heap allocation and process context switching support. Their detailed design has been complete for many months. This has been very significanlty augmented from the 2018_12_13 initial specification. > If you mean that the language itself hasn't > changed, that's simply incorrect. I'll explain further if and only > if you ask me to. It is and has been the x86 language for many months. When I finish adding minimal operating system support it will be a UTM having the x86 language as its Turing Machine Description language. with at least two (build from scratch) operating system functions that can be invoked from this language: (1) Allocation for the heap (2) Process context switching from one UTM to another. >>> I've already asked you these questions, and you ignored them. >>> I presume that it's important *to you* to communicate something >>> about what you're working on. It's less important to me. So I'm >>> not going to be as persistent about getting you to answer these >>> simple questions. >> >> I told you that I can't write the function because its operating >> system is not finished. >> >>>>> I'm just asking you to explain the quotation marks. If they don't >>>>> mean anything, that's fine. > > You claimed to have a C function. You don't. You acknowledge that > you haven't written it. No doubt you have some design or idea, or > perhaps something written down in some kind of pseudocode, and > we could discuss that if you like, but you don't have a C function. I have a c function that is fully executable except for those aspects that depends on operating system support. > I *think* you've said or implied that this C function is the same > thing as the "fully encoded Turing Machine" you've been making > claims about (because C is Turing-complete, and you therefore think > you can call any chunk of C code a "fully encoded Turing machine"). > Is that correct? So you never had your Turing machine either. All c code is Turing complete except for processes such as counting to infinity and storing the result. If a machine had x-bit relative addressing and no direct memory addressing then c could be easily mapped to an actual Turing machine. -- Copyright 2020 Pete Olcott
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-08-10 10:55 -0700 |
| Message-ID | <87d03y4c86.fsf@nosuchdomain.example.com> |
| In reply to | #22261 |
olcott <NoOne@NoWhere.com> writes:
> On 8/10/2020 1:20 AM, Keith Thompson wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>> On 8/10/2020 12:56 AM, Keith Thompson wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>> On 8/10/2020 12:22 AM, Keith Thompson wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>> On 8/9/2020 11:36 PM, Keith Thompson wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>> On 8/9/2020 10:41 PM, Keith Thompson wrote:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>> On 8/9/2020 8:37 PM, Keith Thompson wrote:
>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>> On 8/9/2020 4:44 PM, Keith Thompson wrote:
>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>>> On 8/9/2020 3:57 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>>> [...]
>>>>>>>>>>>>>>>> You don't have, and have never had, a Turing machine with the properties
>>>>>>>>>>>>>>>> you claim. It would be good if you admitted that and moved on because
>>>>>>>>>>>>>>>> attempting to defend the indefensible is taking up a lot of your time.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I have a finite state machine that implements computationally
>>>>>>>>>>>>>>> equivalent code to the Peter Linz H_Hat such that this computational
>>>>>>>>>>>>>>> equivalent correctly decides halting on itself showing exactly how the
>>>>>>>>>>>>>>> standard self-referential halting problem counter-example can be
>>>>>>>>>>>>>>> defeated.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> As I recall, you've claimed to have pseudocode that you were going
>>>>>>>>>>>>>> to translate into working software. Did you ever actually get it
>>>>>>>>>>>>>> written and running?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Do you have a finite state machine, or do you merely have an *idea*
>>>>>>>>>>>>>> for a finite state machine?
>>>>>>>>>>>>>
>>>>>>>>>>>>> I translated the finite state equivalent of the same self-referential
>>>>>>>>>>>>> counter-example that all the Halting Problem proofs are based on into
>>>>>>>>>>>>> "C". I am using a very excellent x86 interpreter to run the machine
>>>>>>>>>>>>> code of this "C" function. It turns out that Visual "C++" generates
>>>>>>>>>>>>> machine code that is easier to understand than g++.
>>>>>>>>>>>>
>>>>>>>>>>>> So now you have a "C" function.
>>>>>>>>>>>>
>>>>>>>>>>>> The quotation marks around C seem odd. Are they significant, and if
>>>>>>>>>>>> so, what's the difference between a "C" function and a C function?
>>>>>>>>>>>> I presume you're referring to the C programming language.
>>>>>>>>>>>>
>>>>>>>>>>>> How many lines of C code are in this function? I presume posting
>>>>>>>>>>>> that number wouldn't harm its "trade secret" status. (I'm not
>>>>>>>>>>>> interested in any answer to this question that isn't a specific
>>>>>>>>>>>> positive integer.)
>>>>>>>>>>>
>>>>>>>>>>> I can't finish the halt decider until its master UTM is complete.
>>>>>>>>>>> The details of the greatly enhanced halt decider have been designed
>>>>>>>>>>> for many months.
>>>>>>>>>>>
>>>>>>>>>>>> Does this function conform to the C language standard? Which edition
>>>>>>>>>>>> (C90, C99, C11, ...)?
>>>>>>>>>>>>
>>>>>>>>>>>> Does this "C" function exist in the context of a C program that
>>>>>>>>>>>> you can compile, link, and execute? Have you done so?
>>>>>>>>>>>
>>>>>>>>>>> It can only be correctly executed inside the master UTM and this is
>>>>>>>>>>> not quite built yet.
>>>>>>>>>>>
>>>>>>>>>>>> Why do you need an x86 interpreter to "run the machine code of this
>>>>>>>>>>>> "C" function"? Why can't you just compile it with an ordinary C
>>>>>>>>>>>
>>>>>>>>>>> I need to function to examine its own machine code because the control
>>>>>>>>>>> flow of machine code is straight forward. I need an x86 interpreter as
>>>>>>>>>>> the basis of the master UTM.
>>>>>>>>>>>
>>>>>>>>>>>> compiler and execute it? I understand that the goal is to feed
>>>>>>>>>>>> your program its own machine code as input (correct?), but are you
>>>>>>>>>>>> able to create an executable that can be run with, for example,
>>>>>>>>>>>> empty input? (I understand that it might fail with empty input,
>>>>>>>>>>>> but the ability to run the program *at all* is a significant step.)
>>>>>>>>>>>>
>>>>>>>>>>>>> The machine code examines itself and decides halting on itself.
>>>>>>>>>>>>> The key part that I have been working on for the last week is building
>>>>>>>>>>>>> the context switching aspect of the master UTM such that one UTM can
>>>>>>>>>>>>> execute another UTM and this can be to arbitrary depth. I am guessing
>>>>>>>>>>>>> that this will be done very soon. Although this is the most difficult
>>>>>>>>>>>>> part that remains it is standard operating system software
>>>>>>>>>>>>> engineering.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Converting an x86 interpreter into a UTM that can execute a chain of
>>>>>>>>>>>>> UTMs of arbitrary depth has taken most of my time. Half of this time
>>>>>>>>>>>>> was learning the internals of the x86 interpreter well enough that I
>>>>>>>>>>>>> can make the changes needed. Less that 10% of my time was spent on
>>>>>>>>>>>>> anything directly related to halt deciding.
>>>>>>>>>>
>>>>>>>>>> Nothing you've written actually responds to anything I asked.
>>>>>>>>>>
>>>>>>>>>> I'll just conclude that you have a vague "design" for some code that
>>>>>>>>>> you eventually intend to write, and that you haven't yet written
>>>>>>>>>> an actual C function of any kind.
>>>>>>>>>
>>>>>>>>> If you understand what the x86 language is and you understand what a
>>>>>>>>> UTM is then you can put them together and know what I have. If you
>>>>>>>>> don't understand what these are then you cannot begin to understand
>>>>>>>>> what I have.
>>>>>>>>
>>>>>>>> Nonsense.
>>>>>>>
>>>>>>> That is exactly the answer that would be expected from someone that
>>>>>>> does not know the underlying subject matter. I have been working with
>>>>>>> the x86 language since the early 1980's. This was back when 64K was
>>>>>>> the maximum segment size. Boy is it a relief to have 4 GB segments,
>>>>>>> switching between 64K segments was so tedious.
>>>>>>
>>>>>> Resorting to insults means you don't have to explain anything, right?
>>>>>
>>>>> Merely an objective assessment.
>>>>
>>>> Whatever. I'm not going to follow that particular digression any further.
>>>>
>>>>>> I've noticed you tend to do that when someone pushes you to answer a
>>>>>> simple question.
>>>>>>
>>>>>> Here's an easy one. You've used the phrase
>>>>>> a "C" function
>>>>>> Is there any significant difference in meaning between that and
>>>>>> a C function
>>>>>> ?
>>>>>
>>>>> No, it is merely easier to read.
>>>>
>>>> Great.
>>>>
>>>> Is there a number of times I have to ask a straightforward question
>>>> before you'll answer it? Would it help if I just ask it that
>>>> many times in a single post? (This doesn't imply I'd be willing
>>>> to do that.) Yes, I'm being a bit sarcastic, but if you'll read
>>>> the quoted material in this post, I think you'll see that you've
>>>> been extraordinarily unwilling to answer simple questions (and
>>>> that has led me to make certain inferences that I won't get into
>>>> for the moment).
>>>>
>>>> FWIW, putting quotation marks around C does not make it easier
>>>> to read. As you can see my my response, all it does is make me
>>>> think that there's some significance to them. But now that I know
>>>> that there isn't:
>>>>
>>>> You've referred to a C function. Have you written this C function?
>>>> Is it, or is it intended to be, in standard C? Which edition of the
>>>> standard does it attempt to conform to? How many lines long is it?
>>>> (If you were willing to share the function itself that would be
>>>> great, but I presume you won't do that.)
>>>>
>>>> I'll leave questions about what the function is supposed to do
>>>> for later.
>>>
>>> I can't write the function yet because its operating system is not
>>> finished.
>>
>> So you have no C function. Got it.
>>
>>> The function itself is in very standard very simple c.
>>
>> You mean it *will be* in very standard very simple C.
>
> Some of the code is written and executing.
You said "I can't write the function yet". "Some of the code" could
mean anything. You don't have a C function.
> >> It is the same c since the first ansi c. I began writing c back when
>>> it was K&R c.
>>
>> Great, so did I. I'm not sure what you mean by "the same c".
>> If you mean that this C function that you haven't written yet will
>> be compatible with the first ANSI C standard and with all later
>> standards, that's fine.
>
> I can't write the halt deciding aspects of the code until after I have
> added heap allocation and process context switching support. Their
> detailed design has been complete for many months. This has been very
> significanlty augmented from the 2018_12_13 initial specification.
>
>> If you mean that the language itself hasn't
>> changed, that's simply incorrect. I'll explain further if and only
>> if you ask me to.
>
> It is and has been the x86 language for many months. When I finish
> adding minimal operating system support it will be a UTM having the
> x86 language as its Turing Machine Description language. with at least
> two (build from scratch) operating system functions that can be
> invoked from this language: (1) Allocation for the heap (2) Process
> context switching from one UTM to another.
You were talking about C. I responded with more information about C.
In response, you talk about "the x86 language".
What exactly do you mean by "the x86 language"? Please don't assume
I'm ignorant (I'm not), merely that I don't know just what you mean
by the phrase.
>>>> I've already asked you these questions, and you ignored them.
>>>> I presume that it's important *to you* to communicate something
>>>> about what you're working on. It's less important to me. So I'm
>>>> not going to be as persistent about getting you to answer these
>>>> simple questions.
>>>
>>> I told you that I can't write the function because its operating
>>> system is not finished.
>>>
>>>>>> I'm just asking you to explain the quotation marks. If they don't
>>>>>> mean anything, that's fine.
>>
>> You claimed to have a C function. You don't. You acknowledge that
>> you haven't written it. No doubt you have some design or idea, or
>> perhaps something written down in some kind of pseudocode, and
>> we could discuss that if you like, but you don't have a C function.
>
> I have a c function that is fully executable except for those aspects
> that depends on operating system support.
In other words you don't have an executable C function.
Your goal is to solve the halting problem, right? *Almost* solving the
halting problem is easy (and uninteresting).
>> I *think* you've said or implied that this C function is the same
>> thing as the "fully encoded Turing Machine" you've been making
>> claims about (because C is Turing-complete, and you therefore think
>> you can call any chunk of C code a "fully encoded Turing machine").
>> Is that correct? So you never had your Turing machine either.
>
> All c code is Turing complete except for processes such as counting to
> infinity and storing the result. If a machine had x-bit relative
> addressing and no direct memory addressing then c could be easily
> mapped to an actual Turing machine.
I think you mean the C language, not "All c code".
This is C code:
int main(void) { }
As you know, it is not Turing complete. My point is that precision is
important, and if you write "All c code" when you really mean "The C
programming language", it's impossible to to know what else you've
written that means something else.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2020-08-10 13:14 -0500 |
| Message-ID | <45SdnYdoycXzE6zCnZ2dnUU7-f3NnZ2d@giganews.com> |
| In reply to | #22277 |
On 8/10/2020 12:55 PM, Keith Thompson wrote:
> olcott <NoOne@NoWhere.com> writes:
>> On 8/10/2020 1:20 AM, Keith Thompson wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>> On 8/10/2020 12:56 AM, Keith Thompson wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>> On 8/10/2020 12:22 AM, Keith Thompson wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>> On 8/9/2020 11:36 PM, Keith Thompson wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>> On 8/9/2020 10:41 PM, Keith Thompson wrote:
>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>> On 8/9/2020 8:37 PM, Keith Thompson wrote:
>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>> On 8/9/2020 4:44 PM, Keith Thompson wrote:
>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>>>> On 8/9/2020 3:57 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>> [...]
>>>>>>>>>>>>>>>>> You don't have, and have never had, a Turing machine with the properties
>>>>>>>>>>>>>>>>> you claim. It would be good if you admitted that and moved on because
>>>>>>>>>>>>>>>>> attempting to defend the indefensible is taking up a lot of your time.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I have a finite state machine that implements computationally
>>>>>>>>>>>>>>>> equivalent code to the Peter Linz H_Hat such that this computational
>>>>>>>>>>>>>>>> equivalent correctly decides halting on itself showing exactly how the
>>>>>>>>>>>>>>>> standard self-referential halting problem counter-example can be
>>>>>>>>>>>>>>>> defeated.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> As I recall, you've claimed to have pseudocode that you were going
>>>>>>>>>>>>>>> to translate into working software. Did you ever actually get it
>>>>>>>>>>>>>>> written and running?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Do you have a finite state machine, or do you merely have an *idea*
>>>>>>>>>>>>>>> for a finite state machine?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I translated the finite state equivalent of the same self-referential
>>>>>>>>>>>>>> counter-example that all the Halting Problem proofs are based on into
>>>>>>>>>>>>>> "C". I am using a very excellent x86 interpreter to run the machine
>>>>>>>>>>>>>> code of this "C" function. It turns out that Visual "C++" generates
>>>>>>>>>>>>>> machine code that is easier to understand than g++.
>>>>>>>>>>>>>
>>>>>>>>>>>>> So now you have a "C" function.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The quotation marks around C seem odd. Are they significant, and if
>>>>>>>>>>>>> so, what's the difference between a "C" function and a C function?
>>>>>>>>>>>>> I presume you're referring to the C programming language.
>>>>>>>>>>>>>
>>>>>>>>>>>>> How many lines of C code are in this function? I presume posting
>>>>>>>>>>>>> that number wouldn't harm its "trade secret" status. (I'm not
>>>>>>>>>>>>> interested in any answer to this question that isn't a specific
>>>>>>>>>>>>> positive integer.)
>>>>>>>>>>>>
>>>>>>>>>>>> I can't finish the halt decider until its master UTM is complete.
>>>>>>>>>>>> The details of the greatly enhanced halt decider have been designed
>>>>>>>>>>>> for many months.
>>>>>>>>>>>>
>>>>>>>>>>>>> Does this function conform to the C language standard? Which edition
>>>>>>>>>>>>> (C90, C99, C11, ...)?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Does this "C" function exist in the context of a C program that
>>>>>>>>>>>>> you can compile, link, and execute? Have you done so?
>>>>>>>>>>>>
>>>>>>>>>>>> It can only be correctly executed inside the master UTM and this is
>>>>>>>>>>>> not quite built yet.
>>>>>>>>>>>>
>>>>>>>>>>>>> Why do you need an x86 interpreter to "run the machine code of this
>>>>>>>>>>>>> "C" function"? Why can't you just compile it with an ordinary C
>>>>>>>>>>>>
>>>>>>>>>>>> I need to function to examine its own machine code because the control
>>>>>>>>>>>> flow of machine code is straight forward. I need an x86 interpreter as
>>>>>>>>>>>> the basis of the master UTM.
>>>>>>>>>>>>
>>>>>>>>>>>>> compiler and execute it? I understand that the goal is to feed
>>>>>>>>>>>>> your program its own machine code as input (correct?), but are you
>>>>>>>>>>>>> able to create an executable that can be run with, for example,
>>>>>>>>>>>>> empty input? (I understand that it might fail with empty input,
>>>>>>>>>>>>> but the ability to run the program *at all* is a significant step.)
>>>>>>>>>>>>>
>>>>>>>>>>>>>> The machine code examines itself and decides halting on itself.
>>>>>>>>>>>>>> The key part that I have been working on for the last week is building
>>>>>>>>>>>>>> the context switching aspect of the master UTM such that one UTM can
>>>>>>>>>>>>>> execute another UTM and this can be to arbitrary depth. I am guessing
>>>>>>>>>>>>>> that this will be done very soon. Although this is the most difficult
>>>>>>>>>>>>>> part that remains it is standard operating system software
>>>>>>>>>>>>>> engineering.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Converting an x86 interpreter into a UTM that can execute a chain of
>>>>>>>>>>>>>> UTMs of arbitrary depth has taken most of my time. Half of this time
>>>>>>>>>>>>>> was learning the internals of the x86 interpreter well enough that I
>>>>>>>>>>>>>> can make the changes needed. Less that 10% of my time was spent on
>>>>>>>>>>>>>> anything directly related to halt deciding.
>>>>>>>>>>>
>>>>>>>>>>> Nothing you've written actually responds to anything I asked.
>>>>>>>>>>>
>>>>>>>>>>> I'll just conclude that you have a vague "design" for some code that
>>>>>>>>>>> you eventually intend to write, and that you haven't yet written
>>>>>>>>>>> an actual C function of any kind.
>>>>>>>>>>
>>>>>>>>>> If you understand what the x86 language is and you understand what a
>>>>>>>>>> UTM is then you can put them together and know what I have. If you
>>>>>>>>>> don't understand what these are then you cannot begin to understand
>>>>>>>>>> what I have.
>>>>>>>>>
>>>>>>>>> Nonsense.
>>>>>>>>
>>>>>>>> That is exactly the answer that would be expected from someone that
>>>>>>>> does not know the underlying subject matter. I have been working with
>>>>>>>> the x86 language since the early 1980's. This was back when 64K was
>>>>>>>> the maximum segment size. Boy is it a relief to have 4 GB segments,
>>>>>>>> switching between 64K segments was so tedious.
>>>>>>>
>>>>>>> Resorting to insults means you don't have to explain anything, right?
>>>>>>
>>>>>> Merely an objective assessment.
>>>>>
>>>>> Whatever. I'm not going to follow that particular digression any further.
>>>>>
>>>>>>> I've noticed you tend to do that when someone pushes you to answer a
>>>>>>> simple question.
>>>>>>>
>>>>>>> Here's an easy one. You've used the phrase
>>>>>>> a "C" function
>>>>>>> Is there any significant difference in meaning between that and
>>>>>>> a C function
>>>>>>> ?
>>>>>>
>>>>>> No, it is merely easier to read.
>>>>>
>>>>> Great.
>>>>>
>>>>> Is there a number of times I have to ask a straightforward question
>>>>> before you'll answer it? Would it help if I just ask it that
>>>>> many times in a single post? (This doesn't imply I'd be willing
>>>>> to do that.) Yes, I'm being a bit sarcastic, but if you'll read
>>>>> the quoted material in this post, I think you'll see that you've
>>>>> been extraordinarily unwilling to answer simple questions (and
>>>>> that has led me to make certain inferences that I won't get into
>>>>> for the moment).
>>>>>
>>>>> FWIW, putting quotation marks around C does not make it easier
>>>>> to read. As you can see my my response, all it does is make me
>>>>> think that there's some significance to them. But now that I know
>>>>> that there isn't:
>>>>>
>>>>> You've referred to a C function. Have you written this C function?
>>>>> Is it, or is it intended to be, in standard C? Which edition of the
>>>>> standard does it attempt to conform to? How many lines long is it?
>>>>> (If you were willing to share the function itself that would be
>>>>> great, but I presume you won't do that.)
>>>>>
>>>>> I'll leave questions about what the function is supposed to do
>>>>> for later.
>>>>
>>>> I can't write the function yet because its operating system is not
>>>> finished.
>>>
>>> So you have no C function. Got it.
>>>
>>>> The function itself is in very standard very simple c.
>>>
>>> You mean it *will be* in very standard very simple C.
>>
>> Some of the code is written and executing.
>
> You said "I can't write the function yet". "Some of the code" could
> mean anything. You don't have a C function.
I have to break what I say down into simpler steps or you get confused.
>
>> >> It is the same c since the first ansi c. I began writing c back when
>>>> it was K&R c.
>>>
>>> Great, so did I. I'm not sure what you mean by "the same c".
>>> If you mean that this C function that you haven't written yet will
>>> be compatible with the first ANSI C standard and with all later
>>> standards, that's fine.
>>
>> I can't write the halt deciding aspects of the code until after I have
>> added heap allocation and process context switching support. Their
>> detailed design has been complete for many months. This has been very
>> significanlty augmented from the 2018_12_13 initial specification.
>>
>>> If you mean that the language itself hasn't
>>> changed, that's simply incorrect. I'll explain further if and only
>>> if you ask me to.
>>
>> It is and has been the x86 language for many months. When I finish
>> adding minimal operating system support it will be a UTM having the
>> x86 language as its Turing Machine Description language. with at least
>> two (build from scratch) operating system functions that can be
>> invoked from this language: (1) Allocation for the heap (2) Process
>> context switching from one UTM to another.
>
> You were talking about C. I responded with more information about C.
> In response, you talk about "the x86 language".
>
> What exactly do you mean by "the x86 language"? Please don't assume
> I'm ignorant (I'm not), merely that I don't know just what you mean
> by the phrase.
In this particular case I mean every single detail of the actual x86
language. The x86 language is the machine language of most desktop
computers. https://www.cs.virginia.edu/~evans/cs216/guides/x86.html
The x86 emulator fully implements that whole set.
>>>>> I've already asked you these questions, and you ignored them.
>>>>> I presume that it's important *to you* to communicate something
>>>>> about what you're working on. It's less important to me. So I'm
>>>>> not going to be as persistent about getting you to answer these
>>>>> simple questions.
>>>>
>>>> I told you that I can't write the function because its operating
>>>> system is not finished.
>>>>
>>>>>>> I'm just asking you to explain the quotation marks. If they don't
>>>>>>> mean anything, that's fine.
>>>
>>> You claimed to have a C function. You don't. You acknowledge that
>>> you haven't written it. No doubt you have some design or idea, or
>>> perhaps something written down in some kind of pseudocode, and
>>> we could discuss that if you like, but you don't have a C function.
>>
>> I have a c function that is fully executable except for those aspects
>> that depends on operating system support.
>
> In other words you don't have an executable C function.
>
> Your goal is to solve the halting problem, right? *Almost* solving the
> halting problem is easy (and uninteresting).
I refuted all of the conventional halting problem counter-examples ever
since 2018-12-13. In previous years I called this goal solving the
halting problem. It is not. Solving the halting problem would require
having a halt decider for every program of the set of all programs.
>>> I *think* you've said or implied that this C function is the same
>>> thing as the "fully encoded Turing Machine" you've been making
>>> claims about (because C is Turing-complete, and you therefore think
>>> you can call any chunk of C code a "fully encoded Turing machine").
>>> Is that correct? So you never had your Turing machine either.
>>
>> All c code is Turing complete except for processes such as counting to
>> infinity and storing the result. If a machine had x-bit relative
>> addressing and no direct memory addressing then c could be easily
>> mapped to an actual Turing machine.
>
> I think you mean the C language, not "All c code".
Yes that way of saying it is more correct.
>
> This is C code:
>
> int main(void) { }
>
> As you know, it is not Turing complete. My point is that precision is
> important, and if you write "All c code" when you really mean "The C
> programming language", it's impossible to to know what else you've
> written that means something else.
>
Science has shown that analytical abilitlity and communication ability
are significantly mutually exclusive.
The creator of the Snobol programming language wrote a text book about
his language. Key elements of chapter one could not be understood until
after reading chapter three. The same gestalt "everything at once"
mindset that is great for designing programming languages is not very
good as exaplaining things as one logical step at a time.
--
Copyright 2020 Pete Olcott
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2020-08-10 18:39 -0500 |
| Message-ID | <RIqdnYkwht9WR6zCnZ2dnUU7-dOdnZ2d@giganews.com> |
| In reply to | #22277 |
On 8/10/2020 12:55 PM, Keith Thompson wrote:
> olcott <NoOne@NoWhere.com> writes:
>> On 8/10/2020 1:20 AM, Keith Thompson wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>> On 8/10/2020 12:56 AM, Keith Thompson wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>> On 8/10/2020 12:22 AM, Keith Thompson wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>> On 8/9/2020 11:36 PM, Keith Thompson wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>> On 8/9/2020 10:41 PM, Keith Thompson wrote:
>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>> On 8/9/2020 8:37 PM, Keith Thompson wrote:
>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>> On 8/9/2020 4:44 PM, Keith Thompson wrote:
>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>>>> On 8/9/2020 3:57 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>> [...]
>>>>>>>>>>>>>>>>> You don't have, and have never had, a Turing machine with the properties
>>>>>>>>>>>>>>>>> you claim. It would be good if you admitted that and moved on because
>>>>>>>>>>>>>>>>> attempting to defend the indefensible is taking up a lot of your time.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I have a finite state machine that implements computationally
>>>>>>>>>>>>>>>> equivalent code to the Peter Linz H_Hat such that this computational
>>>>>>>>>>>>>>>> equivalent correctly decides halting on itself showing exactly how the
>>>>>>>>>>>>>>>> standard self-referential halting problem counter-example can be
>>>>>>>>>>>>>>>> defeated.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> As I recall, you've claimed to have pseudocode that you were going
>>>>>>>>>>>>>>> to translate into working software. Did you ever actually get it
>>>>>>>>>>>>>>> written and running?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Do you have a finite state machine, or do you merely have an *idea*
>>>>>>>>>>>>>>> for a finite state machine?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I translated the finite state equivalent of the same self-referential
>>>>>>>>>>>>>> counter-example that all the Halting Problem proofs are based on into
>>>>>>>>>>>>>> "C". I am using a very excellent x86 interpreter to run the machine
>>>>>>>>>>>>>> code of this "C" function. It turns out that Visual "C++" generates
>>>>>>>>>>>>>> machine code that is easier to understand than g++.
>>>>>>>>>>>>>
>>>>>>>>>>>>> So now you have a "C" function.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The quotation marks around C seem odd. Are they significant, and if
>>>>>>>>>>>>> so, what's the difference between a "C" function and a C function?
>>>>>>>>>>>>> I presume you're referring to the C programming language.
>>>>>>>>>>>>>
>>>>>>>>>>>>> How many lines of C code are in this function? I presume posting
>>>>>>>>>>>>> that number wouldn't harm its "trade secret" status. (I'm not
>>>>>>>>>>>>> interested in any answer to this question that isn't a specific
>>>>>>>>>>>>> positive integer.)
>>>>>>>>>>>>
>>>>>>>>>>>> I can't finish the halt decider until its master UTM is complete.
>>>>>>>>>>>> The details of the greatly enhanced halt decider have been designed
>>>>>>>>>>>> for many months.
>>>>>>>>>>>>
>>>>>>>>>>>>> Does this function conform to the C language standard? Which edition
>>>>>>>>>>>>> (C90, C99, C11, ...)?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Does this "C" function exist in the context of a C program that
>>>>>>>>>>>>> you can compile, link, and execute? Have you done so?
>>>>>>>>>>>>
>>>>>>>>>>>> It can only be correctly executed inside the master UTM and this is
>>>>>>>>>>>> not quite built yet.
>>>>>>>>>>>>
>>>>>>>>>>>>> Why do you need an x86 interpreter to "run the machine code of this
>>>>>>>>>>>>> "C" function"? Why can't you just compile it with an ordinary C
>>>>>>>>>>>>
>>>>>>>>>>>> I need to function to examine its own machine code because the control
>>>>>>>>>>>> flow of machine code is straight forward. I need an x86 interpreter as
>>>>>>>>>>>> the basis of the master UTM.
>>>>>>>>>>>>
>>>>>>>>>>>>> compiler and execute it? I understand that the goal is to feed
>>>>>>>>>>>>> your program its own machine code as input (correct?), but are you
>>>>>>>>>>>>> able to create an executable that can be run with, for example,
>>>>>>>>>>>>> empty input? (I understand that it might fail with empty input,
>>>>>>>>>>>>> but the ability to run the program *at all* is a significant step.)
>>>>>>>>>>>>>
>>>>>>>>>>>>>> The machine code examines itself and decides halting on itself.
>>>>>>>>>>>>>> The key part that I have been working on for the last week is building
>>>>>>>>>>>>>> the context switching aspect of the master UTM such that one UTM can
>>>>>>>>>>>>>> execute another UTM and this can be to arbitrary depth. I am guessing
>>>>>>>>>>>>>> that this will be done very soon. Although this is the most difficult
>>>>>>>>>>>>>> part that remains it is standard operating system software
>>>>>>>>>>>>>> engineering.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Converting an x86 interpreter into a UTM that can execute a chain of
>>>>>>>>>>>>>> UTMs of arbitrary depth has taken most of my time. Half of this time
>>>>>>>>>>>>>> was learning the internals of the x86 interpreter well enough that I
>>>>>>>>>>>>>> can make the changes needed. Less that 10% of my time was spent on
>>>>>>>>>>>>>> anything directly related to halt deciding.
>>>>>>>>>>>
>>>>>>>>>>> Nothing you've written actually responds to anything I asked.
>>>>>>>>>>>
>>>>>>>>>>> I'll just conclude that you have a vague "design" for some code that
>>>>>>>>>>> you eventually intend to write, and that you haven't yet written
>>>>>>>>>>> an actual C function of any kind.
>>>>>>>>>>
>>>>>>>>>> If you understand what the x86 language is and you understand what a
>>>>>>>>>> UTM is then you can put them together and know what I have. If you
>>>>>>>>>> don't understand what these are then you cannot begin to understand
>>>>>>>>>> what I have.
>>>>>>>>>
>>>>>>>>> Nonsense.
>>>>>>>>
>>>>>>>> That is exactly the answer that would be expected from someone that
>>>>>>>> does not know the underlying subject matter. I have been working with
>>>>>>>> the x86 language since the early 1980's. This was back when 64K was
>>>>>>>> the maximum segment size. Boy is it a relief to have 4 GB segments,
>>>>>>>> switching between 64K segments was so tedious.
>>>>>>>
>>>>>>> Resorting to insults means you don't have to explain anything, right?
>>>>>>
>>>>>> Merely an objective assessment.
>>>>>
>>>>> Whatever. I'm not going to follow that particular digression any further.
>>>>>
>>>>>>> I've noticed you tend to do that when someone pushes you to answer a
>>>>>>> simple question.
>>>>>>>
>>>>>>> Here's an easy one. You've used the phrase
>>>>>>> a "C" function
>>>>>>> Is there any significant difference in meaning between that and
>>>>>>> a C function
>>>>>>> ?
>>>>>>
>>>>>> No, it is merely easier to read.
>>>>>
>>>>> Great.
>>>>>
>>>>> Is there a number of times I have to ask a straightforward question
>>>>> before you'll answer it? Would it help if I just ask it that
>>>>> many times in a single post? (This doesn't imply I'd be willing
>>>>> to do that.) Yes, I'm being a bit sarcastic, but if you'll read
>>>>> the quoted material in this post, I think you'll see that you've
>>>>> been extraordinarily unwilling to answer simple questions (and
>>>>> that has led me to make certain inferences that I won't get into
>>>>> for the moment).
>>>>>
>>>>> FWIW, putting quotation marks around C does not make it easier
>>>>> to read. As you can see my my response, all it does is make me
>>>>> think that there's some significance to them. But now that I know
>>>>> that there isn't:
>>>>>
>>>>> You've referred to a C function. Have you written this C function?
>>>>> Is it, or is it intended to be, in standard C? Which edition of the
>>>>> standard does it attempt to conform to? How many lines long is it?
>>>>> (If you were willing to share the function itself that would be
>>>>> great, but I presume you won't do that.)
>>>>>
>>>>> I'll leave questions about what the function is supposed to do
>>>>> for later.
>>>>
>>>> I can't write the function yet because its operating system is not
>>>> finished.
>>>
>>> So you have no C function. Got it.
>>>
>>>> The function itself is in very standard very simple c.
>>>
>>> You mean it *will be* in very standard very simple C.
>>
>> Some of the code is written and executing.
>
> You said "I can't write the function yet". "Some of the code" could
> mean anything. You don't have a C function.
>
>> >> It is the same c since the first ansi c. I began writing c back when
>>>> it was K&R c.
>>>
>>> Great, so did I. I'm not sure what you mean by "the same c".
>>> If you mean that this C function that you haven't written yet will
>>> be compatible with the first ANSI C standard and with all later
>>> standards, that's fine.
>>
>> I can't write the halt deciding aspects of the code until after I have
>> added heap allocation and process context switching support. Their
>> detailed design has been complete for many months. This has been very
>> significanlty augmented from the 2018_12_13 initial specification.
>>
>>> If you mean that the language itself hasn't
>>> changed, that's simply incorrect. I'll explain further if and only
>>> if you ask me to.
>>
>> It is and has been the x86 language for many months. When I finish
>> adding minimal operating system support it will be a UTM having the
>> x86 language as its Turing Machine Description language. with at least
>> two (build from scratch) operating system functions that can be
>> invoked from this language: (1) Allocation for the heap (2) Process
>> context switching from one UTM to another.
>
> You were talking about C. I responded with more information about C.
> In response, you talk about "the x86 language".
>
> What exactly do you mean by "the x86 language"? Please don't assume
> I'm ignorant (I'm not), merely that I don't know just what you mean
> by the phrase.
>
>>>>> I've already asked you these questions, and you ignored them.
>>>>> I presume that it's important *to you* to communicate something
>>>>> about what you're working on. It's less important to me. So I'm
>>>>> not going to be as persistent about getting you to answer these
>>>>> simple questions.
>>>>
>>>> I told you that I can't write the function because its operating
>>>> system is not finished.
>>>>
>>>>>>> I'm just asking you to explain the quotation marks. If they don't
>>>>>>> mean anything, that's fine.
>>>
>>> You claimed to have a C function. You don't. You acknowledge that
>>> you haven't written it. No doubt you have some design or idea, or
>>> perhaps something written down in some kind of pseudocode, and
>>> we could discuss that if you like, but you don't have a C function.
>>
>> I have a c function that is fully executable except for those aspects
>> that depends on operating system support.
>
> In other words you don't have an executable C function.
>
> Your goal is to solve the halting problem, right? *Almost* solving the
> halting problem is easy (and uninteresting).
>
>>> I *think* you've said or implied that this C function is the same
>>> thing as the "fully encoded Turing Machine" you've been making
>>> claims about (because C is Turing-complete, and you therefore think
>>> you can call any chunk of C code a "fully encoded Turing machine").
>>> Is that correct? So you never had your Turing machine either.
>>
>> All c code is Turing complete except for processes such as counting to
>> infinity and storing the result. If a machine had x-bit relative
>> addressing and no direct memory addressing then c could be easily
>> mapped to an actual Turing machine.
>
> I think you mean the C language, not "All c code".
Yes I was very sloppy in my wording.
>
> This is C code:
>
> int main(void) { }
>
> As you know, it is not Turing complete. My point is that precision is
> important, and if you write "All c code" when you really mean "The C
> programming language", it's impossible to to know what else you've
> written that means something else.
>
--
Copyright 2020 Pete Olcott
[toc] | [prev] | [next] | [standalone]
| From | Wasell <usenet2020.1@wasell.eu> |
|---|---|
| Date | 2020-08-10 16:01 +0200 |
| Message-ID | <MPG.399b706f94d11f1f9896dd@reader.eternal-september.org> |
| In reply to | #22231 |
On Sun, 9 Aug 2020 16:30:58 -0500, in article <woGdnUPdH5WK9q3CnZ2dnUU7- V3NnZ2d@giganews.com>, olcott wrote: [snip] > I have a finite state machine that implements computationally equivalent > code to the Peter Linz H_Hat such that this computational equivalent > correctly decides halting on itself showing exactly how the standard > self-referential halting problem counter-example can be defeated. You are, I hope, aware of the fact that Finite State Machines are (in general) much, *much* weaker than Turing Machines. Actually, FSMs are exactly those TMs that have a transition function that *always* move to the right. This means that an FSM can never refer to "earlier" (i.e. leftward) parts of the "tape". This, in turn, means that anything you prove about FSMs doesn't *necessarily* carry over to TMs. Therefore, if you want to prove something about TMs, and you manages to prove that something about FSMs, you still need to provide a proof that it carries over to TMs. You having "a finite state machine that implements computationally equivalent code <blargh>" is entirely pointless, unless you supply an actual *proof* that the relevant properties of your FSM carries over to *all* TMs. (Also, if you want to claim "computational equivalence", you need to supply an actual *proof* of that. Otherwise it's just impotent posturing.)
[toc] | [prev] | [next] | [standalone]
Page 32 of 34 — ← Prev page 1 … 30 31 [32] 33 34 Next page →
Back to top | Article view | comp.theory
csiph-web