Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.theory > #103977 > unrolled thread
| Started by | olcott <polcott333@gmail.com> |
|---|---|
| First post | 2024-04-27 19:17 -0500 |
| Last post | 2024-04-29 09:10 -0500 |
| Articles | 20 on this page of 353 — 9 participants |
Back to article view | Back to comp.theory
Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-27 19:17 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-04-27 20:49 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-27 19:58 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-04-27 21:39 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-27 20:54 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-04-27 22:09 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-27 21:33 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-04-27 23:31 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-27 22:45 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-04-28 09:13 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-28 08:45 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-04-28 10:00 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-28 09:15 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-04-28 13:34 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-28 12:55 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-04-28 14:18 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-28 13:23 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-04-28 14:42 -0400
Re: Can D simulated by H terminate normally? POE olcott <polcott333@gmail.com> - 2024-04-28 14:06 -0500
Re: Can D simulated by H terminate normally? POE Richard Damon <richard@damon-family.org> - 2024-04-28 15:29 -0400
Re: Can D simulated by H terminate normally? POE olcott <polcott333@gmail.com> - 2024-04-28 14:43 -0500
Re: Can D simulated by H terminate normally? POE Richard Damon <richard@damon-family.org> - 2024-04-28 19:07 -0400
Re: Can D simulated by H terminate normally? POE olcott <polcott333@gmail.com> - 2024-04-28 17:28 -0500
Re: Can D simulated by H terminate normally? POE Richard Damon <richard@damon-family.org> - 2024-04-28 19:01 -0400
Re: Can D simulated by H terminate normally? POE olcott <polcott333@gmail.com> - 2024-04-28 23:07 -0500
Re: Can D simulated by H terminate normally? POE Richard Damon <richard@damon-family.org> - 2024-04-29 07:25 -0400
Re: Can D simulated by H terminate normally? POE olcott <polcott333@gmail.com> - 2024-04-29 09:47 -0500
Re: Can D simulated by H terminate normally? POE Richard Damon <richard@damon-family.org> - 2024-04-29 19:19 -0400
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-04-28 14:25 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-28 13:33 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-04-28 14:44 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-28 14:00 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-04-28 15:14 -0400
Re: Can D simulated by H terminate normally? Mikko <mikko.levanto@iki.fi> - 2024-04-28 11:30 +0300
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-28 08:06 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-04-28 09:14 -0400
Re: Can D simulated by H terminate normally? Mikko <mikko.levanto@iki.fi> - 2024-04-28 11:23 +0300
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-28 07:56 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-04-28 09:19 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-28 08:52 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-04-28 11:08 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-28 10:33 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-04-28 12:08 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-28 12:50 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-04-28 14:06 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-28 13:19 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-04-28 14:39 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-28 13:52 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-04-28 15:18 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-28 14:26 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-04-28 15:36 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-28 14:48 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-04-28 19:05 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-28 22:48 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-04-29 07:25 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-29 09:51 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-04-29 19:19 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-30 01:07 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-04-30 07:33 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-30 10:55 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-04-30 18:46 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-30 22:56 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-05-01 07:23 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-01 11:11 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-05-01 20:10 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-01 21:59 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-05-01 23:50 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-01 23:02 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-05-02 00:06 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-01 23:13 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-05-02 00:17 -0400
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-05-18 09:11 -0400
Re: Can D simulated by H terminate normally? --- Message-ID provided olcott <polcott333@gmail.com> - 2024-05-18 11:24 -0500
Re: Can D simulated by H terminate normally? --- Message-ID provided Richard Damon <richard@damon-family.org> - 2024-05-18 12:49 -0400
Re: Can D simulated by H terminate normally? --- Message-ID provided olcott <polcott333@gmail.com> - 2024-05-18 12:20 -0500
Re: Can D simulated by H terminate normally? --- Message-ID provided Richard Damon <richard@damon-family.org> - 2024-05-18 13:40 -0400
Re: Can D simulated by H terminate normally? --- Message_ID Provided olcott <polcott333@gmail.com> - 2024-05-18 13:54 -0500
Re: Can D simulated by H terminate normally? --- Message_ID Provided Richard Damon <richard@damon-family.org> - 2024-05-18 15:15 -0400
Re: Can D simulated by H terminate normally? --- Message_ID Provided olcott <polcott333@gmail.com> - 2024-05-18 14:24 -0500
Re: Can D simulated by H terminate normally? --- Message_ID Provided Richard Damon <richard@damon-family.org> - 2024-05-18 15:42 -0400
Re: Can D simulated by H terminate normally? --- Message_ID Provided Richard Damon <richard@damon-family.org> - 2024-05-18 15:18 -0400
Re: Can D simulated by H terminate normally? --- Message_ID Provided olcott <polcott333@gmail.com> - 2024-05-18 14:28 -0500
Re: Can D simulated by H terminate normally? --- Message_ID Provided Richard Damon <richard@damon-family.org> - 2024-05-18 15:42 -0400
Re: Can D simulated by H terminate normally? --- Message_ID Provided olcott <polcott333@gmail.com> - 2024-05-18 14:57 -0500
Re: Can D simulated by H terminate normally? --- Message_ID Provided Richard Damon <richard@damon-family.org> - 2024-05-18 16:02 -0400
Re: Can D simulated by H terminate normally? --- Message_ID Provided olcott <polcott333@gmail.com> - 2024-05-18 16:00 -0500
Re: Can D simulated by H terminate normally? --- Message_ID Provided Richard Damon <richard@damon-family.org> - 2024-05-18 18:22 -0400
Re: Can D simulated by H terminate normally? --- Message_ID Provided olcott <polcott333@gmail.com> - 2024-05-18 17:44 -0500
Re: Can D simulated by H terminate normally? --- Message_ID Provided Richard Damon <richard@damon-family.org> - 2024-05-18 19:06 -0400
Re: Can D simulated by H terminate normally? --- Message_ID Provided olcott <polcott333@gmail.com> - 2024-05-18 18:24 -0500
Re: Can D simulated by H terminate normally? --- Message_ID Provided Richard Damon <richard@damon-family.org> - 2024-05-18 19:38 -0400
Re: Can D simulated by H terminate normally? --- Message_ID Provided olcott <polcott333@gmail.com> - 2024-05-18 22:59 -0500
Re: Can D simulated by H terminate normally? --- Message_ID Provided immibis <news@immibis.com> - 2024-05-19 14:16 +0200
Re: Can D simulated by H terminate normally? --- Message_ID Provided olcott <polcott333@gmail.com> - 2024-05-19 08:06 -0500
Re: Can D simulated by H terminate normally? --- Message_ID Provided immibis <news@immibis.com> - 2024-05-20 06:37 +0200
Re: Can D simulated by H terminate normally? --- Message_ID Provided olcott <polcott333@gmail.com> - 2024-05-20 00:17 -0500
Re: Can D simulated by H terminate normally? --- Message_ID Provided immibis <news@immibis.com> - 2024-05-20 10:37 +0200
Re: Can D simulated by H terminate normally? --- Message_ID Provided olcott <polcott333@gmail.com> - 2024-05-20 10:32 -0500
Re: Can D simulated by H terminate normally? --- Message_ID Provided Richard Damon <richard@damon-family.org> - 2024-05-20 20:57 -0400
Re: Can D simulated by H terminate normally? --- Message_ID Provided Richard Damon <richard@damon-family.org> - 2024-05-20 07:24 -0400
Re: Can D simulated by H terminate normally? --- Message_ID Provided olcott <polcott333@gmail.com> - 2024-05-20 13:17 -0500
Re: Can D simulated by H terminate normally? --- Message_ID Provided Richard Damon <richard@damon-family.org> - 2024-05-20 20:57 -0400
Re: Can D simulated by H terminate normally? --- Message_ID Provided olcott <polcott333@gmail.com> - 2024-05-19 08:14 -0500
Re: Can D simulated by H terminate normally? --- Message_ID Provided Richard Damon <richard@damon-family.org> - 2024-05-19 13:17 -0400
Re: Can D simulated by H terminate normally? --- Message_ID Provided immibis <news@immibis.com> - 2024-05-20 11:01 +0200
Re: Can D simulated by H terminate normally? --- Message_ID Provided olcott <polcott333@gmail.com> - 2024-05-20 10:18 -0500
Re: Can D simulated by H terminate normally? --- Message_ID Provided Richard Damon <richard@damon-family.org> - 2024-05-20 20:57 -0400
Re: Can D simulated by H terminate normally? --- Message_ID Provided Richard Damon <richard@damon-family.org> - 2024-05-19 13:17 -0400
Re: Can D simulated by H terminate normally? --- Message_ID Provided olcott <polcott333@gmail.com> - 2024-05-19 14:46 -0500
Re: Can D simulated by H terminate normally? --- Message_ID Provided Richard Damon <richard@damon-family.org> - 2024-05-19 19:31 -0400
Re: Can D simulated by H terminate normally? --- Message_ID Provided olcott <polcott333@gmail.com> - 2024-05-20 13:28 -0500
Re: Can D simulated by H terminate normally? --- Message_ID Provided Richard Damon <richard@damon-family.org> - 2024-05-20 20:57 -0400
Re: Can D simulated by H terminate normally? --- Message_ID Provided immibis <news@immibis.com> - 2024-05-21 06:50 +0200
Re: Can D simulated by H terminate normally? --- Message_ID Provided olcott <polcott333@gmail.com> - 2024-05-21 00:05 -0500
Re: Can D simulated by H terminate normally? Message_ID Provided V2 olcott <polcott333@gmail.com> - 2024-05-19 19:06 -0500
Re: Can D simulated by H terminate normally? Message_ID Provided V2 Richard Damon <richard@damon-family.org> - 2024-05-19 21:10 -0400
Re: Can D simulated by H terminate normally? Message_ID Provided V2 olcott <polcott333@gmail.com> - 2024-05-19 21:52 -0500
Re: Can D simulated by H terminate normally? Message_ID Provided V2 Richard Damon <richard@damon-family.org> - 2024-05-19 23:11 -0400
Every D correctly simulated by H cannot possible reach its own line 06 and halt olcott <polcott333@gmail.com> - 2024-05-19 22:22 -0500
Re: Every D correctly simulated by H cannot possible reach its own line 06 and halt Richard Damon <richard@damon-family.org> - 2024-05-20 07:24 -0400
Re: Every D correctly simulated by H cannot possible reach its own line 06 and halt olcott <polcott333@gmail.com> - 2024-05-20 13:03 -0500
Re: Every D correctly simulated by H cannot possible reach its own line 06 and halt Richard Damon <richard@damon-family.org> - 2024-05-20 20:57 -0400
Re: Every D correctly simulated by H cannot possibly reach its own line 06 and halt olcott <polcott333@gmail.com> - 2024-05-20 21:25 -0500
Re: Every D correctly simulated by H cannot possibly reach its own line 06 and halt Richard Damon <richard@damon-family.org> - 2024-05-20 22:39 -0400
Re: Every D correctly simulated by H cannot possibly reach its own line 06 and halt olcott <polcott333@gmail.com> - 2024-05-21 00:18 -0500
Re: Every D correctly simulated by H cannot possibly reach its own line 06 and halt Richard Damon <richard@damon-family.org> - 2024-05-21 08:03 -0400
Re: Every D correctly simulated by H cannot possibly reach its own line 06 and halt olcott <polcott333@gmail.com> - 2024-05-21 09:22 -0500
Re: Every D correctly simulated by H cannot possibly reach its own line 06 and halt Richard Damon <richard@damon-family.org> - 2024-05-21 21:46 -0400
Re: Every D correctly simulated by H cannot possibly reach its own line 06 and halt olcott <polcott333@gmail.com> - 2024-05-21 21:05 -0500
Re: Every D correctly simulated by H cannot possibly reach its own line 06 and halt Richard Damon <richard@damon-family.org> - 2024-05-21 23:09 -0400
Re: Every D correctly simulated by H cannot possibly reach its own line 06 and halt olcott <polcott333@gmail.com> - 2024-05-21 22:52 -0500
Re: Every D correctly simulated by H cannot possibly reach its own line 06 and halt Richard Damon <richard@damon-family.org> - 2024-05-22 07:48 -0400
Every D correctly simulated by H remains stuck in recursive simulation olcott <polcott333@gmail.com> - 2024-05-22 10:41 -0500
Re: Every D correctly simulated by H remains stuck in recursive simulation Richard Damon <richard@damon-family.org> - 2024-05-22 19:01 -0400
Re: Every D correctly simulated by H remains stuck in recursive simulation olcott <polcott333@gmail.com> - 2024-05-22 21:15 -0500
Re: Every D correctly simulated by H remains stuck in recursive simulation Richard Damon <richard@damon-family.org> - 2024-05-22 22:36 -0400
Re: Every D correctly simulated by H cannot possibly reach its own line 06 and halt "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-05-22 09:52 +0200
Re: Every D correctly simulated by H cannot possibly reach its own line 06 and halt joes <noreply@example.com> - 2024-05-22 10:26 +0000
Re: Can D simulated by H terminate normally? Message_ID Provided V2 immibis <news@immibis.com> - 2024-05-20 13:31 +0200
Re: Can D simulated by H terminate normally? Message_ID Provided V2 olcott <polcott333@gmail.com> - 2024-05-20 10:23 -0500
Re: Can D simulated by H terminate normally? Message_ID Provided V2 Richard Damon <richard@damon-family.org> - 2024-05-20 20:57 -0400
Every D correctly simulated by H cannot possible reach its own line 06 and halt olcott <polcott333@gmail.com> - 2024-05-19 22:09 -0500
Re: Every D correctly simulated by H cannot possible reach its own line 06 and halt Richard Damon <richard@damon-family.org> - 2024-05-19 23:24 -0400
Re: Every D correctly simulated by H cannot possible reach its own line 06 and halt olcott <polcott333@gmail.com> - 2024-05-19 22:32 -0500
Re: Every D correctly simulated by H cannot possible reach its own line 06 and halt Richard Damon <richard@damon-family.org> - 2024-05-20 07:24 -0400
Re: Every D correctly simulated by H cannot possible reach its own line 06 and halt olcott <polcott333@gmail.com> - 2024-05-20 13:01 -0500
Re: Every D correctly simulated by H cannot possible reach its own line 06 and halt Richard Damon <richard@damon-family.org> - 2024-05-20 20:57 -0400
Re: Can D simulated by H terminate normally? Mikko <mikko.levanto@iki.fi> - 2024-04-29 16:44 +0300
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-29 09:20 -0500
Re: Can D simulated by H terminate normally? Mikko <mikko.levanto@iki.fi> - 2024-04-30 13:27 +0300
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-30 10:50 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-04-30 18:46 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-30 23:19 -0500
Re: Can D simulated by H terminate normally? Alan Mackenzie <acm@muc.de> - 2024-05-01 09:42 +0000
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-01 10:26 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-05-01 20:16 -0400
Re: Can D simulated by H terminate normally? André G. Isaak <agisaak@gm.invalid> - 2024-05-01 18:44 -0600
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-05-01 21:13 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-01 20:44 -0500
Re: Can D simulated by H terminate normally? André G. Isaak <agisaak@gm.invalid> - 2024-05-01 20:30 -0600
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-01 22:55 -0500
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-01 22:03 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-05-01 23:54 -0400
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-05-01 07:23 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-01 11:26 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-05-01 20:25 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-01 22:12 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-05-01 23:54 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-01 23:08 -0500
Re: Can D simulated by H terminate normally? Mikko <mikko.levanto@iki.fi> - 2024-05-01 12:51 +0300
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-01 10:51 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-05-01 20:28 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-01 22:16 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-05-01 23:50 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-01 23:04 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-05-02 00:10 -0400
Re: Can D simulated by H terminate normally? --- olcott <polcott333@gmail.com> - 2024-05-01 23:24 -0500
Re: Can D simulated by H terminate normally? --- Richard Damon <richard@damon-family.org> - 2024-05-02 07:04 -0400
Re: Can D simulated by H terminate normally? --- olcott <polcott333@gmail.com> - 2024-05-02 13:48 -0500
Re: Can D simulated by H terminate normally? --- Richard Damon <richard@damon-family.org> - 2024-05-02 21:48 -0400
Re: Can D simulated by H terminate normally? --- olcott <polcott333@gmail.com> - 2024-05-03 07:17 -0500
Re: Can D simulated by H terminate normally? --- Richard Damon <richard@damon-family.org> - 2024-05-03 22:12 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-01 23:21 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-05-02 07:03 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-02 13:46 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-05-02 21:48 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-03 07:22 -0500
Re: Can D simulated by H terminate normally? Richard Damon <Richard@Damon-Family.org> - 2024-05-03 18:15 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-01 23:23 -0500
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-01 23:27 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-05-02 07:04 -0400
Is Richard a Liar? olcott <polcott333@gmail.com> - 2024-05-14 10:42 -0500
Re: Olcott is a Liar! Richard Damon <richard@damon-family.org> - 2024-05-14 22:15 -0400
Re: Can D simulated by H terminate normally? Alan Mackenzie <acm@muc.de> - 2024-04-29 14:37 +0000
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-29 09:56 -0500
Re: Can D simulated by H terminate normally? Alan Mackenzie <acm@muc.de> - 2024-04-29 15:23 +0000
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-29 10:50 -0500
Re: Can D simulated by H terminate normally? Alan Mackenzie <acm@muc.de> - 2024-04-29 16:17 +0000
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-29 12:31 -0500
Re: Can D simulated by H terminate normally? Alan Mackenzie <acm@muc.de> - 2024-04-29 18:19 +0000
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-29 14:04 -0500
Re: Can D simulated by H terminate normally? "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-04-30 10:46 +0200
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-30 10:18 -0500
Re: Can D simulated by H terminate normally? "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-04-30 17:37 +0200
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-30 11:10 -0500
Re: Can D simulated by H terminate normally? "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-04-30 18:24 +0200
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-30 11:27 -0500
Re: Can D simulated by H terminate normally? "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-04-30 19:38 +0200
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-30 13:26 -0500
Re: Can D simulated by H terminate normally? "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-05-01 11:02 +0200
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-01 10:20 -0500
Re: Can D simulated by H terminate normally? "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-05-02 17:10 +0200
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-02 13:42 -0500
Re: Can D simulated by H terminate normally? Alan Mackenzie <acm@muc.de> - 2024-04-30 15:44 +0000
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-30 11:15 -0500
Re: Can D simulated by H terminate normally? Alan Mackenzie <acm@muc.de> - 2024-04-30 16:46 +0000
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-30 13:24 -0500
Re: Can D simulated by H terminate normally? Alan Mackenzie <acm@muc.de> - 2024-05-01 10:01 +0000
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-01 10:34 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-05-01 20:31 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-01 22:22 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-05-01 23:53 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-01 23:07 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-05-02 00:13 -0400
Re: Can D simulated by H terminate normally? Mikko <mikko.levanto@iki.fi> - 2024-05-02 12:16 +0300
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-02 09:50 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-05-02 21:48 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-03 07:36 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-05-03 22:09 -0400
Re: Can D simulated by H terminate normally? Mikko <mikko.levanto@iki.fi> - 2024-05-04 12:23 +0300
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-04 08:49 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-05-04 13:50 -0400
Re: Can D simulated by H terminate normally? Mikko <mikko.levanto@iki.fi> - 2024-05-05 11:01 +0300
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-05 09:28 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-05-05 12:55 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-05 12:38 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-05-05 14:15 -0400
Re: Can D simulated by H terminate normally? Mikko <mikko.levanto@iki.fi> - 2024-05-06 18:05 +0300
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-06 11:02 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-05-06 22:20 -0400
Re: Can D simulated by H terminate normally? Mikko <mikko.levanto@iki.fi> - 2024-05-03 12:17 +0300
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-03 06:40 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-05-03 22:10 -0400
Re: Can D simulated by H terminate normally? Mikko <mikko.levanto@iki.fi> - 2024-05-04 12:26 +0300
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-04 08:51 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-05-04 12:00 -0400
Re: Can D simulated by H terminate normally? Mikko <mikko.levanto@iki.fi> - 2024-05-05 11:08 +0300
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-05 09:32 -0500
Re: Can D simulated by H terminate normally? Mikko <mikko.levanto@iki.fi> - 2024-05-06 18:08 +0300
Re: Can D simulated by H terminate normally? Alan Mackenzie <acm@muc.de> - 2024-05-02 09:29 +0000
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-02 13:05 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-05-02 21:49 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-03 07:40 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-05-03 23:33 -0400
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-05-02 21:49 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-03 07:52 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-05-03 22:19 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-02 14:52 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-04-30 18:46 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-30 23:28 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-05-01 07:23 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-01 11:32 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-05-01 20:36 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-01 22:26 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-05-01 23:56 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-01 22:59 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-05-02 00:08 -0400
Re: Can D simulated by H terminate normally? Alan Mackenzie <acm@muc.de> - 2024-05-02 09:39 +0000
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-02 13:35 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-05-02 21:48 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-03 07:25 -0500
Re: Can D simulated by H terminate normally? joes <noreply@example.com> - 2024-05-03 19:30 +0000
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-03 16:26 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-05-03 22:35 -0400
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-05-03 22:29 -0400
Re: Can D simulated by H terminate normally? Mikko <mikko.levanto@iki.fi> - 2024-05-03 12:33 +0300
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-03 06:55 -0500
Re: Can D simulated by H terminate normally? joes <noreply@example.com> - 2024-05-03 13:40 +0000
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-03 08:47 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-05-03 22:41 -0400
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-05-03 22:38 -0400
Re: Can D simulated by H terminate normally? Mikko <mikko.levanto@iki.fi> - 2024-05-04 12:47 +0300
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-04 08:56 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-05-04 12:07 -0400
Re: Can D simulated by H terminate normally? Mikko <mikko.levanto@iki.fi> - 2024-05-05 11:14 +0300
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-05 09:38 -0500
Re: Can D simulated by H terminate normally? joes <noreply@example.com> - 2024-05-05 17:07 +0000
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-05 12:43 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-05-05 14:20 -0400
Re: Can D simulated by H terminate normally? Mikko <mikko.levanto@iki.fi> - 2024-05-06 18:16 +0300
Re: Can D simulated by H terminate normally? immibis <news@immibis.com> - 2024-05-07 03:37 +0200
Re: Can D simulated by H terminate normally? Alan Mackenzie <acm@muc.de> - 2024-05-02 09:07 +0000
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-02 12:45 -0500
Re: Can D simulated by H terminate normally? joes <noreply@example.com> - 2024-05-02 21:51 +0000
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-02 16:55 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-05-02 21:48 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-03 07:27 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-05-03 22:42 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-02 17:10 -0500
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-29 14:31 -0500
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-28 13:54 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-04-28 15:23 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-28 13:58 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-04-28 15:25 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-28 14:35 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-04-28 15:45 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-28 14:51 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-04-28 19:07 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-28 22:58 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-04-29 07:24 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-29 09:43 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-04-29 19:19 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-30 00:54 -0500
Re: Can D simulated by H terminate normally? Mikko <mikko.levanto@iki.fi> - 2024-04-30 13:22 +0300
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-30 10:45 -0500
Re: Can D simulated by H terminate normally? Mikko <mikko.levanto@iki.fi> - 2024-05-01 13:03 +0300
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-01 11:00 -0500
Re: Can D simulated by H terminate normally? Mikko <mikko.levanto@iki.fi> - 2024-05-02 12:00 +0300
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-02 09:43 -0500
Re: Can D simulated by H terminate normally? Mikko <mikko.levanto@iki.fi> - 2024-05-03 12:43 +0300
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-03 07:13 -0500
Re: Can D simulated by H terminate normally? Alan Mackenzie <acm@muc.de> - 2024-05-03 14:08 +0000
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-03 09:34 -0500
Re: Can D simulated by H terminate normally? Alan Mackenzie <acm@muc.de> - 2024-05-03 19:33 +0000
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-03 14:43 -0500
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-03 15:08 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-05-03 23:09 -0400
Re: Can D simulated by H terminate normally? joes <noreply@example.com> - 2024-05-03 19:10 +0000
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-03 16:22 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-05-04 08:43 -0400
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-05-03 23:07 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-03 23:20 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-05-04 08:53 -0400
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-05-03 22:54 -0400
Re: Can D simulated by H terminate normally? Mikko <mikko.levanto@iki.fi> - 2024-05-04 13:10 +0300
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-04 08:59 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-05-04 13:51 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-02 15:13 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-04-30 07:40 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-30 10:58 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-04-30 18:46 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-30 23:11 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-05-01 07:23 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-01 11:06 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-05-01 20:41 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-01 22:29 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-05-01 23:59 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-01 23:09 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-05-02 00:15 -0400
Re: Can D simulated by H terminate normally? Mikko <mikko.levanto@iki.fi> - 2024-04-29 15:27 +0300
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-29 09:14 -0500
Re: Can D simulated by H terminate normally? Mikko <mikko.levanto@iki.fi> - 2024-04-29 15:22 +0300
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-29 09:10 -0500
Page 7 of 18 — ← Prev page 1 … 5 6 [7] 8 9 … 18 Next page →
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-05-20 13:03 -0500 |
| Subject | Re: Every D correctly simulated by H cannot possible reach its own line 06 and halt |
| Message-ID | <v2g390$3ugq$6@dont-email.me> |
| In reply to | #105283 |
On 5/20/2024 6:24 AM, Richard Damon wrote:
> On 5/19/24 11:22 PM, olcott wrote:
>> On 5/19/2024 10:11 PM, Richard Damon wrote:
>>> On 5/19/24 10:52 PM, olcott wrote:
>>>> On 5/19/2024 8:10 PM, Richard Damon wrote:
>>>>> On 5/19/24 8:06 PM, olcott wrote:
>>>>>> On 5/1/2024 7:10 PM, Richard Damon wrote:
>>>>>>
>>>>>> typedef int (*ptr)(); // ptr is pointer to int function
>>>>>> 00 int H(ptr p, ptr i);
>>>>>> 01 int D(ptr p)
>>>>>> 02 {
>>>>>> 03 int Halt_Status = H(p, p);
>>>>>> 04 if (Halt_Status)
>>>>>> 05 HERE: goto HERE;
>>>>>> 06 return Halt_Status;
>>>>>> 07 }
>>>>>> 08
>>>>>> 09 int main()
>>>>>> 10 {
>>>>>> 11 H(D,D);
>>>>>> 12 return 0;
>>>>>> 13 }
>>>>>>
>>>>>> In the above case a simulator is an x86 emulator that correctly
>>>>>> emulates at least one of the x86 instructions of D in the order
>>>>>> specified by the x86 instructions of D.
>>>>>>
>>>>>> This may include correctly emulating the x86 instructions of H in
>>>>>> the order specified by the x86 instructions of H thus calling
>>>>>> H(D,D) in recursive simulation.
>>>>>>
>>>>>> For every H/D pair of the above template D correctly simulated by
>>>>>> *pure function* H cannot possibly reach its own final state at
>>>>>> line 06 and halt.
>>>>>>
>>>>>
>>>>> Ok, so adding that H is a pure function, that means that since your
>>>>> outer H(D,D) is going to return 0, all logic must be compatible
>>>>> with the fact that EVERY call to H(D,D) will also eventually return 0.
>>>>>
>>>>>
>>>>> Remember also, THIS D is defined to call THIS H, that does exactly
>>>>> the same as the H that is deciding it.
>>>>>
>>>>
>>>> OK, good.
>>>
>>> Right, so it doesn't matter what any other D does, it matters what
>>> THIS D does, and this D calls aths H.
>>>
>>> Remember, you reinstated the Computation model by enforcing Pure
>>> Functions.
>>>
>>>>
>>>>>>
>>>>>> <snip so that Message ID links to whole message>
>>>>>> We can use my unique time/date stamp as an alternative.
>>>>>>
>>>>>>> Remember, YOU are the one saying you are needing to change the
>>>>>>> definition from the classical theory, where we have things well
>>>>>>> defined.
>>>>>>>
>>>>>>> YOU have decider that H is just whatever C code you want to write
>>>>>>> for it, and D is the input proved. (which doesn't actually match
>>>>>>> the Linz or Sipser proof, but fairly close).
>>>>>>>
>>>>>>> With THAT set of definitions we have a lot of options that break
>>>>>>> your incorrectly assumed results.
>>>>>>>
>>>>>>> The first method has been discussed here by Flibble. While the
>>>>>>> final answer he got to doesn't fit the requirements, the first
>>>>>>> part of the method DOES show that it is possible for an H to
>>>>>>> simulate to past line 3.
>>>>>>>
>>>>>>> THe basic idea is that if H(M,d) finds that its simulation of
>>>>>>> M(d) get to a call to H(M,d) then rather that your idea of just
>>>>>>> saying it will get stuck and declair the input invalid, since
>>>>>>> there ARE a number of possible inputs that there is a "correct"
>>>>>>> answer that H can give to
>>>>>>
>>>>>> That D is calling H does not prove recursive simulation.
>>>>>> That D is calling H with its same parameters does seem
>>>>>> to prove non-halting recursive simulation.
>>>>>
>>>>> Nope. Try to actuall PROVE it.
>>>>>
>>>>
>>>> That is off-topic for this post.
>>>> All that we need know is that no D simulated by any H
>>>> ever reaches its own line 06 and halts.
>>>
>>> Nope. Make a claim, you need to prove it.
>>>
>>
>> *In other different post not this one*
>>
>> I am using categorically exhaustive reasoning that can work
>> through every possibility that can possibly exist in a feasible
>> amount of time as long as the category is very very narrow.
>
> But you can't PRECISELY define the category, or what you want to reason
> about, so your logic is worthless as it is baseless.
>
*POINT TO ANY ACTUAL MISTAKE OR AMBIGUITY WITH THIS VERSION*
typedef int (*ptr)(); // ptr is pointer to int function
00 int H(ptr p, ptr i);
01 int D(ptr p)
02 {
03 int Halt_Status = H(p, p);
04 if (Halt_Status)
05 HERE: goto HERE;
06 return Halt_Status;
07 }
08
09 int main()
10 {
11 H(D,D);
12 return 0;
13 }
In the above case a simulator is an x86 emulator that correctly emulates
at least one of the x86 instructions of D in the order specified by the
x86 instructions of D.
This may include correctly emulating the x86 instructions of H in the
order specified by the x86 instructions of H thus calling H(D,D) in
recursive simulation.
Execution Trace
Line 11: main() invokes H(D,D);
keeps repeating (unless aborted)
Line 01:
Line 02:
Line 03: simulated D(D) invokes simulated H(D,D) that simulates D(D)
Simulation invariant:
D correctly simulated by H cannot possibly reach past its own line 03.
For every H/D pair of the above template D correctly simulated by pure
function (thus computable function) H cannot possibly reach its own
final state at line 06 and halt.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-05-20 20:57 -0400 |
| Subject | Re: Every D correctly simulated by H cannot possible reach its own line 06 and halt |
| Message-ID | <v2grhq$1kiah$6@i2pn2.org> |
| In reply to | #105299 |
On 5/20/24 2:03 PM, olcott wrote:
> On 5/20/2024 6:24 AM, Richard Damon wrote:
>> On 5/19/24 11:22 PM, olcott wrote:
>>> On 5/19/2024 10:11 PM, Richard Damon wrote:
>>>> On 5/19/24 10:52 PM, olcott wrote:
>>>>> On 5/19/2024 8:10 PM, Richard Damon wrote:
>>>>>> On 5/19/24 8:06 PM, olcott wrote:
>>>>>>> On 5/1/2024 7:10 PM, Richard Damon wrote:
>>>>>>>
>>>>>>> typedef int (*ptr)(); // ptr is pointer to int function
>>>>>>> 00 int H(ptr p, ptr i);
>>>>>>> 01 int D(ptr p)
>>>>>>> 02 {
>>>>>>> 03 int Halt_Status = H(p, p);
>>>>>>> 04 if (Halt_Status)
>>>>>>> 05 HERE: goto HERE;
>>>>>>> 06 return Halt_Status;
>>>>>>> 07 }
>>>>>>> 08
>>>>>>> 09 int main()
>>>>>>> 10 {
>>>>>>> 11 H(D,D);
>>>>>>> 12 return 0;
>>>>>>> 13 }
>>>>>>>
>>>>>>> In the above case a simulator is an x86 emulator that correctly
>>>>>>> emulates at least one of the x86 instructions of D in the order
>>>>>>> specified by the x86 instructions of D.
>>>>>>>
>>>>>>> This may include correctly emulating the x86 instructions of H in
>>>>>>> the order specified by the x86 instructions of H thus calling
>>>>>>> H(D,D) in recursive simulation.
>>>>>>>
>>>>>>> For every H/D pair of the above template D correctly simulated by
>>>>>>> *pure function* H cannot possibly reach its own final state at
>>>>>>> line 06 and halt.
>>>>>>>
>>>>>>
>>>>>> Ok, so adding that H is a pure function, that means that since
>>>>>> your outer H(D,D) is going to return 0, all logic must be
>>>>>> compatible with the fact that EVERY call to H(D,D) will also
>>>>>> eventually return 0.
>>>>>>
>>>>>>
>>>>>> Remember also, THIS D is defined to call THIS H, that does exactly
>>>>>> the same as the H that is deciding it.
>>>>>>
>>>>>
>>>>> OK, good.
>>>>
>>>> Right, so it doesn't matter what any other D does, it matters what
>>>> THIS D does, and this D calls aths H.
>>>>
>>>> Remember, you reinstated the Computation model by enforcing Pure
>>>> Functions.
>>>>
>>>>>
>>>>>>>
>>>>>>> <snip so that Message ID links to whole message>
>>>>>>> We can use my unique time/date stamp as an alternative.
>>>>>>>
>>>>>>>> Remember, YOU are the one saying you are needing to change the
>>>>>>>> definition from the classical theory, where we have things well
>>>>>>>> defined.
>>>>>>>>
>>>>>>>> YOU have decider that H is just whatever C code you want to
>>>>>>>> write for it, and D is the input proved. (which doesn't actually
>>>>>>>> match the Linz or Sipser proof, but fairly close).
>>>>>>>>
>>>>>>>> With THAT set of definitions we have a lot of options that break
>>>>>>>> your incorrectly assumed results.
>>>>>>>>
>>>>>>>> The first method has been discussed here by Flibble. While the
>>>>>>>> final answer he got to doesn't fit the requirements, the first
>>>>>>>> part of the method DOES show that it is possible for an H to
>>>>>>>> simulate to past line 3.
>>>>>>>>
>>>>>>>> THe basic idea is that if H(M,d) finds that its simulation of
>>>>>>>> M(d) get to a call to H(M,d) then rather that your idea of just
>>>>>>>> saying it will get stuck and declair the input invalid, since
>>>>>>>> there ARE a number of possible inputs that there is a "correct"
>>>>>>>> answer that H can give to
>>>>>>>
>>>>>>> That D is calling H does not prove recursive simulation.
>>>>>>> That D is calling H with its same parameters does seem
>>>>>>> to prove non-halting recursive simulation.
>>>>>>
>>>>>> Nope. Try to actuall PROVE it.
>>>>>>
>>>>>
>>>>> That is off-topic for this post.
>>>>> All that we need know is that no D simulated by any H
>>>>> ever reaches its own line 06 and halts.
>>>>
>>>> Nope. Make a claim, you need to prove it.
>>>>
>>>
>>> *In other different post not this one*
>>>
>>> I am using categorically exhaustive reasoning that can work
>>> through every possibility that can possibly exist in a feasible
>>> amount of time as long as the category is very very narrow.
>>
>> But you can't PRECISELY define the category, or what you want to
>> reason about, so your logic is worthless as it is baseless.
>>
>
> *POINT TO ANY ACTUAL MISTAKE OR AMBIGUITY WITH THIS VERSION*
>
> typedef int (*ptr)(); // ptr is pointer to int function
> 00 int H(ptr p, ptr i);
> 01 int D(ptr p)
> 02 {
> 03 int Halt_Status = H(p, p);
> 04 if (Halt_Status)
> 05 HERE: goto HERE;
> 06 return Halt_Status;
> 07 }
> 08
> 09 int main()
> 10 {
> 11 H(D,D);
> 12 return 0;
> 13 }
>
> In the above case a simulator is an x86 emulator that correctly emulates
> at least one of the x86 instructions of D in the order specified by the
> x86 instructions of D.
>
> This may include correctly emulating the x86 instructions of H in the
> order specified by the x86 instructions of H thus calling H(D,D) in
> recursive simulation.
>
> Execution Trace
> Line 11: main() invokes H(D,D);
>
> keeps repeating (unless aborted)
> Line 01:
> Line 02:
> Line 03: simulated D(D) invokes simulated H(D,D) that simulates D(D)
>
> Simulation invariant:
> D correctly simulated by H cannot possibly reach past its own line 03.
>
> For every H/D pair of the above template D correctly simulated by pure
> function (thus computable function) H cannot possibly reach its own
> final state at line 06 and halt.
>
Which thus doesn't correct simulate the call to H (since H proves that a
call to itself as H(D,D) WILL return the value 0)
Since you have an incorrect step in your simulation, you arguement is
just unsound.
Note, a correct simulation of a call to H(D,D) is NOT another simulation
of D(D), as H SIMULATES its input, not run it, and even if the
"simulation" is "debug stepping", the H still retains control, so if H
will abort its simulation at some point, such simulation is not
"infinite", even if the out H gives up before it gets to that point.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-05-20 21:25 -0500 |
| Subject | Re: Every D correctly simulated by H cannot possibly reach its own line 06 and halt |
| Message-ID | <v2h0nm$d87m$1@dont-email.me> |
| In reply to | #105316 |
On 5/20/2024 7:57 PM, Richard Damon wrote:
> On 5/20/24 2:03 PM, olcott wrote:
>> On 5/20/2024 6:24 AM, Richard Damon wrote:
>>> On 5/19/24 11:22 PM, olcott wrote:
>>>> On 5/19/2024 10:11 PM, Richard Damon wrote:
>>>>> On 5/19/24 10:52 PM, olcott wrote:
>>>>>> On 5/19/2024 8:10 PM, Richard Damon wrote:
>>>>>>> On 5/19/24 8:06 PM, olcott wrote:
>>>>>>>> On 5/1/2024 7:10 PM, Richard Damon wrote:
>>>>>>>>
>>>>>>>> typedef int (*ptr)(); // ptr is pointer to int function
>>>>>>>> 00 int H(ptr p, ptr i);
>>>>>>>> 01 int D(ptr p)
>>>>>>>> 02 {
>>>>>>>> 03 int Halt_Status = H(p, p);
>>>>>>>> 04 if (Halt_Status)
>>>>>>>> 05 HERE: goto HERE;
>>>>>>>> 06 return Halt_Status;
>>>>>>>> 07 }
>>>>>>>> 08
>>>>>>>> 09 int main()
>>>>>>>> 10 {
>>>>>>>> 11 H(D,D);
>>>>>>>> 12 return 0;
>>>>>>>> 13 }
>>>>>>>>
>>>>>>>> In the above case a simulator is an x86 emulator that correctly
>>>>>>>> emulates at least one of the x86 instructions of D in the order
>>>>>>>> specified by the x86 instructions of D.
>>>>>>>>
>>>>>>>> This may include correctly emulating the x86 instructions of H
>>>>>>>> in the order specified by the x86 instructions of H thus calling
>>>>>>>> H(D,D) in recursive simulation.
>>>>>>>>
>>>>>>>> For every H/D pair of the above template D correctly simulated by
>>>>>>>> *pure function* H cannot possibly reach its own final state at
>>>>>>>> line 06 and halt.
>>>>>>>>
>>>>>>>
>>>>>>> Ok, so adding that H is a pure function, that means that since
>>>>>>> your outer H(D,D) is going to return 0, all logic must be
>>>>>>> compatible with the fact that EVERY call to H(D,D) will also
>>>>>>> eventually return 0.
>>>>>>>
>>>>>>>
>>>>>>> Remember also, THIS D is defined to call THIS H, that does
>>>>>>> exactly the same as the H that is deciding it.
>>>>>>>
>>>>>>
>>>>>> OK, good.
>>>>>
>>>>> Right, so it doesn't matter what any other D does, it matters what
>>>>> THIS D does, and this D calls aths H.
>>>>>
>>>>> Remember, you reinstated the Computation model by enforcing Pure
>>>>> Functions.
>>>>>
>>>>>>
>>>>>>>>
>>>>>>>> <snip so that Message ID links to whole message>
>>>>>>>> We can use my unique time/date stamp as an alternative.
>>>>>>>>
>>>>>>>>> Remember, YOU are the one saying you are needing to change the
>>>>>>>>> definition from the classical theory, where we have things well
>>>>>>>>> defined.
>>>>>>>>>
>>>>>>>>> YOU have decider that H is just whatever C code you want to
>>>>>>>>> write for it, and D is the input proved. (which doesn't
>>>>>>>>> actually match the Linz or Sipser proof, but fairly close).
>>>>>>>>>
>>>>>>>>> With THAT set of definitions we have a lot of options that
>>>>>>>>> break your incorrectly assumed results.
>>>>>>>>>
>>>>>>>>> The first method has been discussed here by Flibble. While the
>>>>>>>>> final answer he got to doesn't fit the requirements, the first
>>>>>>>>> part of the method DOES show that it is possible for an H to
>>>>>>>>> simulate to past line 3.
>>>>>>>>>
>>>>>>>>> THe basic idea is that if H(M,d) finds that its simulation of
>>>>>>>>> M(d) get to a call to H(M,d) then rather that your idea of just
>>>>>>>>> saying it will get stuck and declair the input invalid, since
>>>>>>>>> there ARE a number of possible inputs that there is a "correct"
>>>>>>>>> answer that H can give to
>>>>>>>>
>>>>>>>> That D is calling H does not prove recursive simulation.
>>>>>>>> That D is calling H with its same parameters does seem
>>>>>>>> to prove non-halting recursive simulation.
>>>>>>>
>>>>>>> Nope. Try to actuall PROVE it.
>>>>>>>
>>>>>>
>>>>>> That is off-topic for this post.
>>>>>> All that we need know is that no D simulated by any H
>>>>>> ever reaches its own line 06 and halts.
>>>>>
>>>>> Nope. Make a claim, you need to prove it.
>>>>>
>>>>
>>>> *In other different post not this one*
>>>>
>>>> I am using categorically exhaustive reasoning that can work
>>>> through every possibility that can possibly exist in a feasible
>>>> amount of time as long as the category is very very narrow.
>>>
>>> But you can't PRECISELY define the category, or what you want to
>>> reason about, so your logic is worthless as it is baseless.
>>>
>>
>> *POINT TO ANY ACTUAL MISTAKE OR AMBIGUITY WITH THIS VERSION*
>>
>> typedef int (*ptr)(); // ptr is pointer to int function
>> 00 int H(ptr p, ptr i);
>> 01 int D(ptr p)
>> 02 {
>> 03 int Halt_Status = H(p, p);
>> 04 if (Halt_Status)
>> 05 HERE: goto HERE;
>> 06 return Halt_Status;
>> 07 }
>> 08
>> 09 int main()
>> 10 {
>> 11 H(D,D);
>> 12 return 0;
>> 13 }
>>
>> In the above case a simulator is an x86 emulator that correctly
>> emulates at least one of the x86 instructions of D in the order
>> specified by the x86 instructions of D.
>>
>> This may include correctly emulating the x86 instructions of H in the
>> order specified by the x86 instructions of H thus calling H(D,D) in
>> recursive simulation.
>>
>> Execution Trace
>> Line 11: main() invokes H(D,D);
>>
>> keeps repeating (unless aborted)
>> Line 01:
>> Line 02:
>> Line 03: simulated D(D) invokes simulated H(D,D) that simulates D(D)
>>
>> Simulation invariant:
>> D correctly simulated by H cannot possibly reach past its own line 03.
>>
>> For every H/D pair of the above template D correctly simulated by pure
>> function (thus computable function) H cannot possibly reach its own
>> final state at line 06 and halt.
>>
>
> Which thus doesn't correct simulate the call to H
*Counter-factual, try again*
We are not talking about any of your misconceptions the term:
"simulate" is expressly defined.
This is the only post about this subject that I will respond
to from you. I have to paint half of my house and empty my
garage within about a week.
If you can find some source that conclusively proves that
not all pure functions are computable functions I would like
to see it. All of the experts that I could find seem to agree
that all pure functions in C would be computable functions
by a Turing machine.
I skimmed the rest of your posts and they were mostly
trying to get away with changing the subject to divert
attention away from the point at hand in this subject line.
I will not discuss and theory of computation stuff with you
until after you quit playing head games with the subject
of this post.
*THINKING THE WRONG ANSWERS ARE ALLOWED IS A HEAD GAME*
*THINKING THE WRONG ANSWERS ARE ALLOWED IS A HEAD GAME*
*THINKING THE WRONG ANSWERS ARE ALLOWED IS A HEAD GAME*
On 5/19/2024 12:17 PM, Richard Damon wrote:
> On 5/19/24 9:59 AM, olcott wrote:
>> Richard has stated that he thinks that an example of
>> {D never simulated by H} ∈ {every D simulated by H}
>
> No, the H that didn't simulate its input shows that
> *once you allow H to not be required to be correct*,
> that we can then have a trivial function that is
> "just as correct" (since wrong answers were allowed).
I am glad to see that it turned out that you were not a liar.
That was very reassuring. Seems to be a liar to me until I see
proof otherwise is not the same thing as calling you a liar.
If you think it is fun to endlessly talk in circles then
you will get very little dialogue with me.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-05-20 22:39 -0400 |
| Subject | Re: Every D correctly simulated by H cannot possibly reach its own line 06 and halt |
| Message-ID | <v2h1gp$1kiah$14@i2pn2.org> |
| In reply to | #105325 |
On 5/20/24 10:25 PM, olcott wrote:
> On 5/20/2024 7:57 PM, Richard Damon wrote:
>> On 5/20/24 2:03 PM, olcott wrote:
>>> On 5/20/2024 6:24 AM, Richard Damon wrote:
>>>> On 5/19/24 11:22 PM, olcott wrote:
>>>>> On 5/19/2024 10:11 PM, Richard Damon wrote:
>>>>>> On 5/19/24 10:52 PM, olcott wrote:
>>>>>>> On 5/19/2024 8:10 PM, Richard Damon wrote:
>>>>>>>> On 5/19/24 8:06 PM, olcott wrote:
>>>>>>>>> On 5/1/2024 7:10 PM, Richard Damon wrote:
>>>>>>>>>
>>>>>>>>> typedef int (*ptr)(); // ptr is pointer to int function
>>>>>>>>> 00 int H(ptr p, ptr i);
>>>>>>>>> 01 int D(ptr p)
>>>>>>>>> 02 {
>>>>>>>>> 03 int Halt_Status = H(p, p);
>>>>>>>>> 04 if (Halt_Status)
>>>>>>>>> 05 HERE: goto HERE;
>>>>>>>>> 06 return Halt_Status;
>>>>>>>>> 07 }
>>>>>>>>> 08
>>>>>>>>> 09 int main()
>>>>>>>>> 10 {
>>>>>>>>> 11 H(D,D);
>>>>>>>>> 12 return 0;
>>>>>>>>> 13 }
>>>>>>>>>
>>>>>>>>> In the above case a simulator is an x86 emulator that correctly
>>>>>>>>> emulates at least one of the x86 instructions of D in the order
>>>>>>>>> specified by the x86 instructions of D.
>>>>>>>>>
>>>>>>>>> This may include correctly emulating the x86 instructions of H
>>>>>>>>> in the order specified by the x86 instructions of H thus
>>>>>>>>> calling H(D,D) in recursive simulation.
>>>>>>>>>
>>>>>>>>> For every H/D pair of the above template D correctly simulated by
>>>>>>>>> *pure function* H cannot possibly reach its own final state at
>>>>>>>>> line 06 and halt.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Ok, so adding that H is a pure function, that means that since
>>>>>>>> your outer H(D,D) is going to return 0, all logic must be
>>>>>>>> compatible with the fact that EVERY call to H(D,D) will also
>>>>>>>> eventually return 0.
>>>>>>>>
>>>>>>>>
>>>>>>>> Remember also, THIS D is defined to call THIS H, that does
>>>>>>>> exactly the same as the H that is deciding it.
>>>>>>>>
>>>>>>>
>>>>>>> OK, good.
>>>>>>
>>>>>> Right, so it doesn't matter what any other D does, it matters what
>>>>>> THIS D does, and this D calls aths H.
>>>>>>
>>>>>> Remember, you reinstated the Computation model by enforcing Pure
>>>>>> Functions.
>>>>>>
>>>>>>>
>>>>>>>>>
>>>>>>>>> <snip so that Message ID links to whole message>
>>>>>>>>> We can use my unique time/date stamp as an alternative.
>>>>>>>>>
>>>>>>>>>> Remember, YOU are the one saying you are needing to change the
>>>>>>>>>> definition from the classical theory, where we have things
>>>>>>>>>> well defined.
>>>>>>>>>>
>>>>>>>>>> YOU have decider that H is just whatever C code you want to
>>>>>>>>>> write for it, and D is the input proved. (which doesn't
>>>>>>>>>> actually match the Linz or Sipser proof, but fairly close).
>>>>>>>>>>
>>>>>>>>>> With THAT set of definitions we have a lot of options that
>>>>>>>>>> break your incorrectly assumed results.
>>>>>>>>>>
>>>>>>>>>> The first method has been discussed here by Flibble. While the
>>>>>>>>>> final answer he got to doesn't fit the requirements, the first
>>>>>>>>>> part of the method DOES show that it is possible for an H to
>>>>>>>>>> simulate to past line 3.
>>>>>>>>>>
>>>>>>>>>> THe basic idea is that if H(M,d) finds that its simulation of
>>>>>>>>>> M(d) get to a call to H(M,d) then rather that your idea of
>>>>>>>>>> just saying it will get stuck and declair the input invalid,
>>>>>>>>>> since there ARE a number of possible inputs that there is a
>>>>>>>>>> "correct" answer that H can give to
>>>>>>>>>
>>>>>>>>> That D is calling H does not prove recursive simulation.
>>>>>>>>> That D is calling H with its same parameters does seem
>>>>>>>>> to prove non-halting recursive simulation.
>>>>>>>>
>>>>>>>> Nope. Try to actuall PROVE it.
>>>>>>>>
>>>>>>>
>>>>>>> That is off-topic for this post.
>>>>>>> All that we need know is that no D simulated by any H
>>>>>>> ever reaches its own line 06 and halts.
>>>>>>
>>>>>> Nope. Make a claim, you need to prove it.
>>>>>>
>>>>>
>>>>> *In other different post not this one*
>>>>>
>>>>> I am using categorically exhaustive reasoning that can work
>>>>> through every possibility that can possibly exist in a feasible
>>>>> amount of time as long as the category is very very narrow.
>>>>
>>>> But you can't PRECISELY define the category, or what you want to
>>>> reason about, so your logic is worthless as it is baseless.
>>>>
>>>
>>> *POINT TO ANY ACTUAL MISTAKE OR AMBIGUITY WITH THIS VERSION*
>>>
>>> typedef int (*ptr)(); // ptr is pointer to int function
>>> 00 int H(ptr p, ptr i);
>>> 01 int D(ptr p)
>>> 02 {
>>> 03 int Halt_Status = H(p, p);
>>> 04 if (Halt_Status)
>>> 05 HERE: goto HERE;
>>> 06 return Halt_Status;
>>> 07 }
>>> 08
>>> 09 int main()
>>> 10 {
>>> 11 H(D,D);
>>> 12 return 0;
>>> 13 }
>>>
>>> In the above case a simulator is an x86 emulator that correctly
>>> emulates at least one of the x86 instructions of D in the order
>>> specified by the x86 instructions of D.
>>>
>>> This may include correctly emulating the x86 instructions of H in the
>>> order specified by the x86 instructions of H thus calling H(D,D) in
>>> recursive simulation.
>>>
>>> Execution Trace
>>> Line 11: main() invokes H(D,D);
>>>
>>> keeps repeating (unless aborted)
>>> Line 01:
>>> Line 02:
>>> Line 03: simulated D(D) invokes simulated H(D,D) that simulates D(D)
>>>
>>> Simulation invariant:
>>> D correctly simulated by H cannot possibly reach past its own line 03.
>>>
>>> For every H/D pair of the above template D correctly simulated by
>>> pure function (thus computable function) H cannot possibly reach its
>>> own final state at line 06 and halt.
>>>
>>
>> Which thus doesn't correct simulate the call to H
>
> *Counter-factual, try again*
> We are not talking about any of your misconceptions the term:
> "simulate" is expressly defined.
And how did your H "Correctly" simulate the call to H?
>
> This is the only post about this subject that I will respond
> to from you. I have to paint half of my house and empty my
> garage within about a week.
>
> If you can find some source that conclusively proves that
> not all pure functions are computable functions I would like
> to see it. All of the experts that I could find seem to agree
> that all pure functions in C would be computable functions
> by a Turing machine.
So, you just don't understand that "Computable Function" is a
Term-of-the-art to talk about the mathematical mapping, an NOT the
algorithm that shows the mapping is computable.
One key point that make "Pure Functions" not necessarily equivalent to a
Turing Machine is the ability to get "hidden inputs" from things like
their own program address, something a Turing Machine doesn't have.
This is what made your H and H1, even though "exact copies" of each
other (by using x86 instructions that access this otherwise hidden
information in a way that make it not obvious), act differently, when
two identical copies of Turing Machines ALWAYS act the same for the same
input.
So, YOU YOURSELF have provided the counter-example, but were too stupid
to understand it.
>
> I skimmed the rest of your posts and they were mostly
> trying to get away with changing the subject to divert
> attention away from the point at hand in this subject line.
>
> I will not discuss and theory of computation stuff with you
> until after you quit playing head games with the subject
> of this post.
>
> *THINKING THE WRONG ANSWERS ARE ALLOWED IS A HEAD GAME*
> *THINKING THE WRONG ANSWERS ARE ALLOWED IS A HEAD GAME*
> *THINKING THE WRONG ANSWERS ARE ALLOWED IS A HEAD GAME*
>
> On 5/19/2024 12:17 PM, Richard Damon wrote:
> > On 5/19/24 9:59 AM, olcott wrote:
> >> Richard has stated that he thinks that an example of
> >> {D never simulated by H} ∈ {every D simulated by H}
> >
> > No, the H that didn't simulate its input shows that
> > *once you allow H to not be required to be correct*,
> > that we can then have a trivial function that is
> > "just as correct" (since wrong answers were allowed).
>
> I am glad to see that it turned out that you were not a liar.
> That was very reassuring. Seems to be a liar to me until I see
> proof otherwise is not the same thing as calling you a liar.
Which just makes you a pathological liar, because you have a reckless
disregard for the truth, PRESUMING without the need of evidence.
Note, you positively claimed for two weeks that I did not say what I
claimed to. Since I showed that I did, that you PROVES you LIED for
those two weeks, and you just admitted that you were doing so.
Note, "Honest Mistake" does not ignore what someone says.
>
> If you think it is fun to endlessly talk in circles then
> you will get very little dialogue with me.
>
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-05-21 00:18 -0500 |
| Subject | Re: Every D correctly simulated by H cannot possibly reach its own line 06 and halt |
| Message-ID | <v2harp$ehmg$5@dont-email.me> |
| In reply to | #105326 |
On 5/20/2024 9:39 PM, Richard Damon wrote:
> On 5/20/24 10:25 PM, olcott wrote:
>> On 5/20/2024 7:57 PM, Richard Damon wrote:
>>> On 5/20/24 2:03 PM, olcott wrote:
>>>> On 5/20/2024 6:24 AM, Richard Damon wrote:
>>>>> On 5/19/24 11:22 PM, olcott wrote:
>>>>>> On 5/19/2024 10:11 PM, Richard Damon wrote:
>>>>>>> On 5/19/24 10:52 PM, olcott wrote:
>>>>>>>> On 5/19/2024 8:10 PM, Richard Damon wrote:
>>>>>>>>> On 5/19/24 8:06 PM, olcott wrote:
>>>>>>>>>> On 5/1/2024 7:10 PM, Richard Damon wrote:
>>>>>>>>>>
>>>>>>>>>> typedef int (*ptr)(); // ptr is pointer to int function
>>>>>>>>>> 00 int H(ptr p, ptr i);
>>>>>>>>>> 01 int D(ptr p)
>>>>>>>>>> 02 {
>>>>>>>>>> 03 int Halt_Status = H(p, p);
>>>>>>>>>> 04 if (Halt_Status)
>>>>>>>>>> 05 HERE: goto HERE;
>>>>>>>>>> 06 return Halt_Status;
>>>>>>>>>> 07 }
>>>>>>>>>> 08
>>>>>>>>>> 09 int main()
>>>>>>>>>> 10 {
>>>>>>>>>> 11 H(D,D);
>>>>>>>>>> 12 return 0;
>>>>>>>>>> 13 }
>>>>>>>>>>
>>>>>>>>>> In the above case a simulator is an x86 emulator that
>>>>>>>>>> correctly emulates at least one of the x86 instructions of D
>>>>>>>>>> in the order specified by the x86 instructions of D.
>>>>>>>>>>
>>>>>>>>>> This may include correctly emulating the x86 instructions of H
>>>>>>>>>> in the order specified by the x86 instructions of H thus
>>>>>>>>>> calling H(D,D) in recursive simulation.
>>>>>>>>>>
>>>>>>>>>> For every H/D pair of the above template D correctly simulated by
>>>>>>>>>> *pure function* H cannot possibly reach its own final state at
>>>>>>>>>> line 06 and halt.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Ok, so adding that H is a pure function, that means that since
>>>>>>>>> your outer H(D,D) is going to return 0, all logic must be
>>>>>>>>> compatible with the fact that EVERY call to H(D,D) will also
>>>>>>>>> eventually return 0.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Remember also, THIS D is defined to call THIS H, that does
>>>>>>>>> exactly the same as the H that is deciding it.
>>>>>>>>>
>>>>>>>>
>>>>>>>> OK, good.
>>>>>>>
>>>>>>> Right, so it doesn't matter what any other D does, it matters
>>>>>>> what THIS D does, and this D calls aths H.
>>>>>>>
>>>>>>> Remember, you reinstated the Computation model by enforcing Pure
>>>>>>> Functions.
>>>>>>>
>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> <snip so that Message ID links to whole message>
>>>>>>>>>> We can use my unique time/date stamp as an alternative.
>>>>>>>>>>
>>>>>>>>>>> Remember, YOU are the one saying you are needing to change
>>>>>>>>>>> the definition from the classical theory, where we have
>>>>>>>>>>> things well defined.
>>>>>>>>>>>
>>>>>>>>>>> YOU have decider that H is just whatever C code you want to
>>>>>>>>>>> write for it, and D is the input proved. (which doesn't
>>>>>>>>>>> actually match the Linz or Sipser proof, but fairly close).
>>>>>>>>>>>
>>>>>>>>>>> With THAT set of definitions we have a lot of options that
>>>>>>>>>>> break your incorrectly assumed results.
>>>>>>>>>>>
>>>>>>>>>>> The first method has been discussed here by Flibble. While
>>>>>>>>>>> the final answer he got to doesn't fit the requirements, the
>>>>>>>>>>> first part of the method DOES show that it is possible for an
>>>>>>>>>>> H to simulate to past line 3.
>>>>>>>>>>>
>>>>>>>>>>> THe basic idea is that if H(M,d) finds that its simulation of
>>>>>>>>>>> M(d) get to a call to H(M,d) then rather that your idea of
>>>>>>>>>>> just saying it will get stuck and declair the input invalid,
>>>>>>>>>>> since there ARE a number of possible inputs that there is a
>>>>>>>>>>> "correct" answer that H can give to
>>>>>>>>>>
>>>>>>>>>> That D is calling H does not prove recursive simulation.
>>>>>>>>>> That D is calling H with its same parameters does seem
>>>>>>>>>> to prove non-halting recursive simulation.
>>>>>>>>>
>>>>>>>>> Nope. Try to actuall PROVE it.
>>>>>>>>>
>>>>>>>>
>>>>>>>> That is off-topic for this post.
>>>>>>>> All that we need know is that no D simulated by any H
>>>>>>>> ever reaches its own line 06 and halts.
>>>>>>>
>>>>>>> Nope. Make a claim, you need to prove it.
>>>>>>>
>>>>>>
>>>>>> *In other different post not this one*
>>>>>>
>>>>>> I am using categorically exhaustive reasoning that can work
>>>>>> through every possibility that can possibly exist in a feasible
>>>>>> amount of time as long as the category is very very narrow.
>>>>>
>>>>> But you can't PRECISELY define the category, or what you want to
>>>>> reason about, so your logic is worthless as it is baseless.
>>>>>
>>>>
>>>> *POINT TO ANY ACTUAL MISTAKE OR AMBIGUITY WITH THIS VERSION*
>>>>
>>>> typedef int (*ptr)(); // ptr is pointer to int function
>>>> 00 int H(ptr p, ptr i);
>>>> 01 int D(ptr p)
>>>> 02 {
>>>> 03 int Halt_Status = H(p, p);
>>>> 04 if (Halt_Status)
>>>> 05 HERE: goto HERE;
>>>> 06 return Halt_Status;
>>>> 07 }
>>>> 08
>>>> 09 int main()
>>>> 10 {
>>>> 11 H(D,D);
>>>> 12 return 0;
>>>> 13 }
>>>>
>>>> In the above case a simulator is an x86 emulator that correctly
>>>> emulates at least one of the x86 instructions of D in the order
>>>> specified by the x86 instructions of D.
>>>>
>>>> This may include correctly emulating the x86 instructions of H in
>>>> the order specified by the x86 instructions of H thus calling H(D,D)
>>>> in recursive simulation.
>>>>
>>>> Execution Trace
>>>> Line 11: main() invokes H(D,D);
>>>>
>>>> keeps repeating (unless aborted)
>>>> Line 01:
>>>> Line 02:
>>>> Line 03: simulated D(D) invokes simulated H(D,D) that simulates D(D)
>>>>
>>>> Simulation invariant:
>>>> D correctly simulated by H cannot possibly reach past its own line 03.
>>>>
>>>> For every H/D pair of the above template D correctly simulated by
>>>> pure function (thus computable function) H cannot possibly reach its
>>>> own final state at line 06 and halt.
>>>>
>>>
>>> Which thus doesn't correct simulate the call to H
>>
>> *Counter-factual, try again*
>> We are not talking about any of your misconceptions the term:
>> "simulate" is expressly defined.
>
> And how did your H "Correctly" simulate the call to H?
>
That does not matter as long as it is not impossible.
>>
>> This is the only post about this subject that I will respond
>> to from you. I have to paint half of my house and empty my
>> garage within about a week.
>>
>> If you can find some source that conclusively proves that
>> not all pure functions are computable functions I would like
>> to see it. All of the experts that I could find seem to agree
>> that all pure functions in C would be computable functions
>> by a Turing machine.
>
> So, you just don't understand that "Computable Function" is a
> Term-of-the-art to talk about the mathematical mapping, an NOT the
> algorithm that shows the mapping is computable.
>
Pure functions <are> Turing computable functions until you
conclusively prove otherwise.
> One key point that make "Pure Functions" not necessarily equivalent to a
> Turing Machine is the ability to get "hidden inputs" from things like
> their own program address, something a Turing Machine doesn't have.
>
*That is irrelevant to the current post*
*You can always look at the title and see if you went off topic*
*This boiler plate will be the only reply*
I am using categorically exhaustive reasoning that can work
through every possibility that can possibly exist in a feasible
amount of time as long as the category is very very narrow.
Enlarge the category a tiny little bit and then the time
becomes infeasible.
The tiniest little divergence from the title of this
thread and I totally ignore and erase everything else
that you say.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-05-21 08:03 -0400 |
| Subject | Re: Every D correctly simulated by H cannot possibly reach its own line 06 and halt |
| Message-ID | <v2i2it$1kiag$2@i2pn2.org> |
| In reply to | #105336 |
On 5/21/24 1:18 AM, olcott wrote:
> On 5/20/2024 9:39 PM, Richard Damon wrote:
>> On 5/20/24 10:25 PM, olcott wrote:
>>> On 5/20/2024 7:57 PM, Richard Damon wrote:
>>>> On 5/20/24 2:03 PM, olcott wrote:
>>>>> On 5/20/2024 6:24 AM, Richard Damon wrote:
>>>>>> On 5/19/24 11:22 PM, olcott wrote:
>>>>>>> On 5/19/2024 10:11 PM, Richard Damon wrote:
>>>>>>>> On 5/19/24 10:52 PM, olcott wrote:
>>>>>>>>> On 5/19/2024 8:10 PM, Richard Damon wrote:
>>>>>>>>>> On 5/19/24 8:06 PM, olcott wrote:
>>>>>>>>>>> On 5/1/2024 7:10 PM, Richard Damon wrote:
>>>>>>>>>>>
>>>>>>>>>>> typedef int (*ptr)(); // ptr is pointer to int function
>>>>>>>>>>> 00 int H(ptr p, ptr i);
>>>>>>>>>>> 01 int D(ptr p)
>>>>>>>>>>> 02 {
>>>>>>>>>>> 03 int Halt_Status = H(p, p);
>>>>>>>>>>> 04 if (Halt_Status)
>>>>>>>>>>> 05 HERE: goto HERE;
>>>>>>>>>>> 06 return Halt_Status;
>>>>>>>>>>> 07 }
>>>>>>>>>>> 08
>>>>>>>>>>> 09 int main()
>>>>>>>>>>> 10 {
>>>>>>>>>>> 11 H(D,D);
>>>>>>>>>>> 12 return 0;
>>>>>>>>>>> 13 }
>>>>>>>>>>>
>>>>>>>>>>> In the above case a simulator is an x86 emulator that
>>>>>>>>>>> correctly emulates at least one of the x86 instructions of D
>>>>>>>>>>> in the order specified by the x86 instructions of D.
>>>>>>>>>>>
>>>>>>>>>>> This may include correctly emulating the x86 instructions of
>>>>>>>>>>> H in the order specified by the x86 instructions of H thus
>>>>>>>>>>> calling H(D,D) in recursive simulation.
>>>>>>>>>>>
>>>>>>>>>>> For every H/D pair of the above template D correctly
>>>>>>>>>>> simulated by
>>>>>>>>>>> *pure function* H cannot possibly reach its own final state at
>>>>>>>>>>> line 06 and halt.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Ok, so adding that H is a pure function, that means that since
>>>>>>>>>> your outer H(D,D) is going to return 0, all logic must be
>>>>>>>>>> compatible with the fact that EVERY call to H(D,D) will also
>>>>>>>>>> eventually return 0.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Remember also, THIS D is defined to call THIS H, that does
>>>>>>>>>> exactly the same as the H that is deciding it.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> OK, good.
>>>>>>>>
>>>>>>>> Right, so it doesn't matter what any other D does, it matters
>>>>>>>> what THIS D does, and this D calls aths H.
>>>>>>>>
>>>>>>>> Remember, you reinstated the Computation model by enforcing Pure
>>>>>>>> Functions.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> <snip so that Message ID links to whole message>
>>>>>>>>>>> We can use my unique time/date stamp as an alternative.
>>>>>>>>>>>
>>>>>>>>>>>> Remember, YOU are the one saying you are needing to change
>>>>>>>>>>>> the definition from the classical theory, where we have
>>>>>>>>>>>> things well defined.
>>>>>>>>>>>>
>>>>>>>>>>>> YOU have decider that H is just whatever C code you want to
>>>>>>>>>>>> write for it, and D is the input proved. (which doesn't
>>>>>>>>>>>> actually match the Linz or Sipser proof, but fairly close).
>>>>>>>>>>>>
>>>>>>>>>>>> With THAT set of definitions we have a lot of options that
>>>>>>>>>>>> break your incorrectly assumed results.
>>>>>>>>>>>>
>>>>>>>>>>>> The first method has been discussed here by Flibble. While
>>>>>>>>>>>> the final answer he got to doesn't fit the requirements, the
>>>>>>>>>>>> first part of the method DOES show that it is possible for
>>>>>>>>>>>> an H to simulate to past line 3.
>>>>>>>>>>>>
>>>>>>>>>>>> THe basic idea is that if H(M,d) finds that its simulation
>>>>>>>>>>>> of M(d) get to a call to H(M,d) then rather that your idea
>>>>>>>>>>>> of just saying it will get stuck and declair the input
>>>>>>>>>>>> invalid, since there ARE a number of possible inputs that
>>>>>>>>>>>> there is a "correct" answer that H can give to
>>>>>>>>>>>
>>>>>>>>>>> That D is calling H does not prove recursive simulation.
>>>>>>>>>>> That D is calling H with its same parameters does seem
>>>>>>>>>>> to prove non-halting recursive simulation.
>>>>>>>>>>
>>>>>>>>>> Nope. Try to actuall PROVE it.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> That is off-topic for this post.
>>>>>>>>> All that we need know is that no D simulated by any H
>>>>>>>>> ever reaches its own line 06 and halts.
>>>>>>>>
>>>>>>>> Nope. Make a claim, you need to prove it.
>>>>>>>>
>>>>>>>
>>>>>>> *In other different post not this one*
>>>>>>>
>>>>>>> I am using categorically exhaustive reasoning that can work
>>>>>>> through every possibility that can possibly exist in a feasible
>>>>>>> amount of time as long as the category is very very narrow.
>>>>>>
>>>>>> But you can't PRECISELY define the category, or what you want to
>>>>>> reason about, so your logic is worthless as it is baseless.
>>>>>>
>>>>>
>>>>> *POINT TO ANY ACTUAL MISTAKE OR AMBIGUITY WITH THIS VERSION*
>>>>>
>>>>> typedef int (*ptr)(); // ptr is pointer to int function
>>>>> 00 int H(ptr p, ptr i);
>>>>> 01 int D(ptr p)
>>>>> 02 {
>>>>> 03 int Halt_Status = H(p, p);
>>>>> 04 if (Halt_Status)
>>>>> 05 HERE: goto HERE;
>>>>> 06 return Halt_Status;
>>>>> 07 }
>>>>> 08
>>>>> 09 int main()
>>>>> 10 {
>>>>> 11 H(D,D);
>>>>> 12 return 0;
>>>>> 13 }
>>>>>
>>>>> In the above case a simulator is an x86 emulator that correctly
>>>>> emulates at least one of the x86 instructions of D in the order
>>>>> specified by the x86 instructions of D.
>>>>>
>>>>> This may include correctly emulating the x86 instructions of H in
>>>>> the order specified by the x86 instructions of H thus calling
>>>>> H(D,D) in recursive simulation.
>>>>>
>>>>> Execution Trace
>>>>> Line 11: main() invokes H(D,D);
>>>>>
>>>>> keeps repeating (unless aborted)
>>>>> Line 01:
>>>>> Line 02:
>>>>> Line 03: simulated D(D) invokes simulated H(D,D) that simulates D(D)
>>>>>
>>>>> Simulation invariant:
>>>>> D correctly simulated by H cannot possibly reach past its own line 03.
>>>>>
>>>>> For every H/D pair of the above template D correctly simulated by
>>>>> pure function (thus computable function) H cannot possibly reach
>>>>> its own final state at line 06 and halt.
>>>>>
>>>>
>>>> Which thus doesn't correct simulate the call to H
>>>
>>> *Counter-factual, try again*
>>> We are not talking about any of your misconceptions the term:
>>> "simulate" is expressly defined.
>>
>> And how did your H "Correctly" simulate the call to H?
>>
>
> That does not matter as long as it is not impossible.
But since you claim you did it, you need to show what you did.
The problem is you don't seem to understand that somethings ARE impossible.
Like building a Turing Machine that always correctly determines if
another Turing Machine/Input combination will halt.
Your claims that you make one that answers the proof case, is just
proven to be a lie, and your proof is based on first assuming it is
possible and then using that "fact" to try to prove your answer, which
is just the thing you claim you are not allowed to do.
Thus, it is proven that you whole concept is just built on inconsistant
lies.
>
>>>
>>> This is the only post about this subject that I will respond
>>> to from you. I have to paint half of my house and empty my
>>> garage within about a week.
>>>
>>> If you can find some source that conclusively proves that
>>> not all pure functions are computable functions I would like
>>> to see it. All of the experts that I could find seem to agree
>>> that all pure functions in C would be computable functions
>>> by a Turing machine.
>>
>> So, you just don't understand that "Computable Function" is a
>> Term-of-the-art to talk about the mathematical mapping, an NOT the
>> algorithm that shows the mapping is computable.
>>
>
> Pure functions <are> Turing computable functions until you
> conclusively prove otherwise.
So, you still don't understand the meaning of the words.
Your claim is like saying that cats are 10 story office building.
>
>> One key point that make "Pure Functions" not necessarily equivalent to
>> a Turing Machine is the ability to get "hidden inputs" from things
>> like their own program address, something a Turing Machine doesn't have.
>>
>
> *That is irrelevant to the current post*
> *You can always look at the title and see if you went off topic*
No, you keep making the error, and thus destroy your arguement.
>
>
> *This boiler plate will be the only reply*
> I am using categorically exhaustive reasoning that can work
> through every possibility that can possibly exist in a feasible
> amount of time as long as the category is very very narrow.
>
> Enlarge the category a tiny little bit and then the time
> becomes infeasible.
>
> The tiniest little divergence from the title of this
> thread and I totally ignore and erase everything else
> that you say.
>
>
And if you can't actually define your category or the thing to be
analyzied you are just wasting your time, as if you don't know where you
are going, it is hard to find the path.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-05-21 09:22 -0500 |
| Subject | Re: Every D correctly simulated by H cannot possibly reach its own line 06 and halt |
| Message-ID | <v2ian9$ko3b$1@dont-email.me> |
| In reply to | #105351 |
On 5/21/2024 7:03 AM, Richard Damon wrote:
> On 5/21/24 1:18 AM, olcott wrote:
>> On 5/20/2024 9:39 PM, Richard Damon wrote:
>>> On 5/20/24 10:25 PM, olcott wrote:
>>>> On 5/20/2024 7:57 PM, Richard Damon wrote:
>>>>> On 5/20/24 2:03 PM, olcott wrote:
>>>>>> On 5/20/2024 6:24 AM, Richard Damon wrote:
>>>>>>> On 5/19/24 11:22 PM, olcott wrote:
>>>>>>>> On 5/19/2024 10:11 PM, Richard Damon wrote:
>>>>>>>>> On 5/19/24 10:52 PM, olcott wrote:
>>>>>>>>>> On 5/19/2024 8:10 PM, Richard Damon wrote:
>>>>>>>>>>> On 5/19/24 8:06 PM, olcott wrote:
>>>>>>>>>>>> On 5/1/2024 7:10 PM, Richard Damon wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> typedef int (*ptr)(); // ptr is pointer to int function
>>>>>>>>>>>> 00 int H(ptr p, ptr i);
>>>>>>>>>>>> 01 int D(ptr p)
>>>>>>>>>>>> 02 {
>>>>>>>>>>>> 03 int Halt_Status = H(p, p);
>>>>>>>>>>>> 04 if (Halt_Status)
>>>>>>>>>>>> 05 HERE: goto HERE;
>>>>>>>>>>>> 06 return Halt_Status;
>>>>>>>>>>>> 07 }
>>>>>>>>>>>> 08
>>>>>>>>>>>> 09 int main()
>>>>>>>>>>>> 10 {
>>>>>>>>>>>> 11 H(D,D);
>>>>>>>>>>>> 12 return 0;
>>>>>>>>>>>> 13 }
>>>>>>>>>>>>
>>>>>>>>>>>> In the above case a simulator is an x86 emulator that
>>>>>>>>>>>> correctly emulates at least one of the x86 instructions of D
>>>>>>>>>>>> in the order specified by the x86 instructions of D.
>>>>>>>>>>>>
>>>>>>>>>>>> This may include correctly emulating the x86 instructions of
>>>>>>>>>>>> H in the order specified by the x86 instructions of H thus
>>>>>>>>>>>> calling H(D,D) in recursive simulation.
>>>>>>>>>>>>
>>>>>>>>>>>> For every H/D pair of the above template D correctly
>>>>>>>>>>>> simulated by
>>>>>>>>>>>> *pure function* H cannot possibly reach its own final state at
>>>>>>>>>>>> line 06 and halt.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Ok, so adding that H is a pure function, that means that
>>>>>>>>>>> since your outer H(D,D) is going to return 0, all logic must
>>>>>>>>>>> be compatible with the fact that EVERY call to H(D,D) will
>>>>>>>>>>> also eventually return 0.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Remember also, THIS D is defined to call THIS H, that does
>>>>>>>>>>> exactly the same as the H that is deciding it.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> OK, good.
>>>>>>>>>
>>>>>>>>> Right, so it doesn't matter what any other D does, it matters
>>>>>>>>> what THIS D does, and this D calls aths H.
>>>>>>>>>
>>>>>>>>> Remember, you reinstated the Computation model by enforcing
>>>>>>>>> Pure Functions.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> <snip so that Message ID links to whole message>
>>>>>>>>>>>> We can use my unique time/date stamp as an alternative.
>>>>>>>>>>>>
>>>>>>>>>>>>> Remember, YOU are the one saying you are needing to change
>>>>>>>>>>>>> the definition from the classical theory, where we have
>>>>>>>>>>>>> things well defined.
>>>>>>>>>>>>>
>>>>>>>>>>>>> YOU have decider that H is just whatever C code you want to
>>>>>>>>>>>>> write for it, and D is the input proved. (which doesn't
>>>>>>>>>>>>> actually match the Linz or Sipser proof, but fairly close).
>>>>>>>>>>>>>
>>>>>>>>>>>>> With THAT set of definitions we have a lot of options that
>>>>>>>>>>>>> break your incorrectly assumed results.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The first method has been discussed here by Flibble. While
>>>>>>>>>>>>> the final answer he got to doesn't fit the requirements,
>>>>>>>>>>>>> the first part of the method DOES show that it is possible
>>>>>>>>>>>>> for an H to simulate to past line 3.
>>>>>>>>>>>>>
>>>>>>>>>>>>> THe basic idea is that if H(M,d) finds that its simulation
>>>>>>>>>>>>> of M(d) get to a call to H(M,d) then rather that your idea
>>>>>>>>>>>>> of just saying it will get stuck and declair the input
>>>>>>>>>>>>> invalid, since there ARE a number of possible inputs that
>>>>>>>>>>>>> there is a "correct" answer that H can give to
>>>>>>>>>>>>
>>>>>>>>>>>> That D is calling H does not prove recursive simulation.
>>>>>>>>>>>> That D is calling H with its same parameters does seem
>>>>>>>>>>>> to prove non-halting recursive simulation.
>>>>>>>>>>>
>>>>>>>>>>> Nope. Try to actuall PROVE it.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> That is off-topic for this post.
>>>>>>>>>> All that we need know is that no D simulated by any H
>>>>>>>>>> ever reaches its own line 06 and halts.
>>>>>>>>>
>>>>>>>>> Nope. Make a claim, you need to prove it.
>>>>>>>>>
>>>>>>>>
>>>>>>>> *In other different post not this one*
>>>>>>>>
>>>>>>>> I am using categorically exhaustive reasoning that can work
>>>>>>>> through every possibility that can possibly exist in a feasible
>>>>>>>> amount of time as long as the category is very very narrow.
>>>>>>>
>>>>>>> But you can't PRECISELY define the category, or what you want to
>>>>>>> reason about, so your logic is worthless as it is baseless.
>>>>>>>
>>>>>>
>>>>>> *POINT TO ANY ACTUAL MISTAKE OR AMBIGUITY WITH THIS VERSION*
>>>>>>
>>>>>> typedef int (*ptr)(); // ptr is pointer to int function
>>>>>> 00 int H(ptr p, ptr i);
>>>>>> 01 int D(ptr p)
>>>>>> 02 {
>>>>>> 03 int Halt_Status = H(p, p);
>>>>>> 04 if (Halt_Status)
>>>>>> 05 HERE: goto HERE;
>>>>>> 06 return Halt_Status;
>>>>>> 07 }
>>>>>> 08
>>>>>> 09 int main()
>>>>>> 10 {
>>>>>> 11 H(D,D);
>>>>>> 12 return 0;
>>>>>> 13 }
>>>>>>
>>>>>> In the above case a simulator is an x86 emulator that correctly
>>>>>> emulates at least one of the x86 instructions of D in the order
>>>>>> specified by the x86 instructions of D.
>>>>>>
>>>>>> This may include correctly emulating the x86 instructions of H in
>>>>>> the order specified by the x86 instructions of H thus calling
>>>>>> H(D,D) in recursive simulation.
>>>>>>
>>>>>> Execution Trace
>>>>>> Line 11: main() invokes H(D,D);
>>>>>>
>>>>>> keeps repeating (unless aborted)
>>>>>> Line 01:
>>>>>> Line 02:
>>>>>> Line 03: simulated D(D) invokes simulated H(D,D) that simulates D(D)
>>>>>>
>>>>>> Simulation invariant:
>>>>>> D correctly simulated by H cannot possibly reach past its own line
>>>>>> 03.
>>>>>>
>>>>>> For every H/D pair of the above template D correctly simulated by
>>>>>> pure function (thus computable function) H cannot possibly reach
>>>>>> its own final state at line 06 and halt.
>>>>>>
>>>>>
>>>>> Which thus doesn't correct simulate the call to H
>>>>
>>>> *Counter-factual, try again*
>>>> We are not talking about any of your misconceptions the term:
>>>> "simulate" is expressly defined.
>>>
>>> And how did your H "Correctly" simulate the call to H?
>>>
>>
>> That does not matter as long as it is not impossible.
>
> But since you claim you did it, you need to show what you did.
>
I cannot show the behavior of every element of an infinite set
a c function pairs.
> The problem is you don't seem to understand that somethings ARE impossible.
>
It is certainly not impossible for pure function H to correctly
simulate D.
> Like building a Turing Machine that always correctly determines if
> another Turing Machine/Input combination will halt.
>
> Your claims that you make one that answers the proof case, is just
> proven to be a lie, and your proof is based on first assuming it is
> possible and then using that "fact" to try to prove your answer, which
> is just the thing you claim you are not allowed to do.
>
In the last two years I have not even exaggerated.
Lets call a truce on accusations of lying you eventually
proved that you were not lying about this key point and I
updated my spec to address the issue that you raised.
I made sure to not call you a liar on this. I said that until
proved otherwise I will assume that you are a liar and then
you proved otherwise.
> Thus, it is proven that you whole concept is just built on inconsistant
> lies.
>
>>
>>>>
>>>> This is the only post about this subject that I will respond
>>>> to from you. I have to paint half of my house and empty my
>>>> garage within about a week.
>>>>
>>>> If you can find some source that conclusively proves that
>>>> not all pure functions are computable functions I would like
>>>> to see it. All of the experts that I could find seem to agree
>>>> that all pure functions in C would be computable functions
>>>> by a Turing machine.
>>>
>>> So, you just don't understand that "Computable Function" is a
>>> Term-of-the-art to talk about the mathematical mapping, an NOT the
>>> algorithm that shows the mapping is computable.
>>>
>>
>> Pure functions <are> Turing computable functions until you
>> conclusively prove otherwise.
>
> So, you still don't understand the meaning of the words.
>
Try and point out the specific error and I will correct any
mistake that you find. Until you provide a basis I will assume
that your claim is baseless.
> Your claim is like saying that cats are 10 story office building.
>
>>
>>> One key point that make "Pure Functions" not necessarily equivalent
>>> to a Turing Machine is the ability to get "hidden inputs" from things
>>> like their own program address, something a Turing Machine doesn't have.
>>>
>>
>> *That is irrelevant to the current post*
>> *You can always look at the title and see if you went off topic*
>
> No, you keep making the error, and thus destroy your arguement.
>
Since I am only responding to you via this single thread I
don't have to cut off the first divergence from the title.
>>
>>
>> *This boiler plate will be the only reply*
>> I am using categorically exhaustive reasoning that can work
>> through every possibility that can possibly exist in a feasible
>> amount of time as long as the category is very very narrow.
>>
>> Enlarge the category a tiny little bit and then the time
>> becomes infeasible.
>>
>> The tiniest little divergence from the title of this
>> thread and I totally ignore and erase everything else
>> that you say.
>>
>>
>
> And if you can't actually define your category or the thing to be
> analyzied you are just wasting your time, as if you don't know where you
> are going, it is hard to find the path.
>
The way I see it I defined it correctly and completely and you
are simply pretending otherwise. Until you prove otherwise I
will continue to assume this.
You seem to favor baseless rhetoric because you know that baseless
rhetoric with ad hominem mixed in is very convincing for gullible fools.
Gullible fools are outside of my target audience.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-05-21 21:46 -0400 |
| Subject | Re: Every D correctly simulated by H cannot possibly reach its own line 06 and halt |
| Message-ID | <v2jiop$1no6v$1@i2pn2.org> |
| In reply to | #105355 |
On 5/21/24 10:22 AM, olcott wrote:
> On 5/21/2024 7:03 AM, Richard Damon wrote:
>> On 5/21/24 1:18 AM, olcott wrote:
>>> On 5/20/2024 9:39 PM, Richard Damon wrote:
>>>> On 5/20/24 10:25 PM, olcott wrote:
>>>>> On 5/20/2024 7:57 PM, Richard Damon wrote:
>>>>>> On 5/20/24 2:03 PM, olcott wrote:
>>>>>>> On 5/20/2024 6:24 AM, Richard Damon wrote:
>>>>>>>> On 5/19/24 11:22 PM, olcott wrote:
>>>>>>>>> On 5/19/2024 10:11 PM, Richard Damon wrote:
>>>>>>>>>> On 5/19/24 10:52 PM, olcott wrote:
>>>>>>>>>>> On 5/19/2024 8:10 PM, Richard Damon wrote:
>>>>>>>>>>>> On 5/19/24 8:06 PM, olcott wrote:
>>>>>>>>>>>>> On 5/1/2024 7:10 PM, Richard Damon wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> typedef int (*ptr)(); // ptr is pointer to int function
>>>>>>>>>>>>> 00 int H(ptr p, ptr i);
>>>>>>>>>>>>> 01 int D(ptr p)
>>>>>>>>>>>>> 02 {
>>>>>>>>>>>>> 03 int Halt_Status = H(p, p);
>>>>>>>>>>>>> 04 if (Halt_Status)
>>>>>>>>>>>>> 05 HERE: goto HERE;
>>>>>>>>>>>>> 06 return Halt_Status;
>>>>>>>>>>>>> 07 }
>>>>>>>>>>>>> 08
>>>>>>>>>>>>> 09 int main()
>>>>>>>>>>>>> 10 {
>>>>>>>>>>>>> 11 H(D,D);
>>>>>>>>>>>>> 12 return 0;
>>>>>>>>>>>>> 13 }
>>>>>>>>>>>>>
>>>>>>>>>>>>> In the above case a simulator is an x86 emulator that
>>>>>>>>>>>>> correctly emulates at least one of the x86 instructions of
>>>>>>>>>>>>> D in the order specified by the x86 instructions of D.
>>>>>>>>>>>>>
>>>>>>>>>>>>> This may include correctly emulating the x86 instructions
>>>>>>>>>>>>> of H in the order specified by the x86 instructions of H
>>>>>>>>>>>>> thus calling H(D,D) in recursive simulation.
>>>>>>>>>>>>>
>>>>>>>>>>>>> For every H/D pair of the above template D correctly
>>>>>>>>>>>>> simulated by
>>>>>>>>>>>>> *pure function* H cannot possibly reach its own final state at
>>>>>>>>>>>>> line 06 and halt.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Ok, so adding that H is a pure function, that means that
>>>>>>>>>>>> since your outer H(D,D) is going to return 0, all logic must
>>>>>>>>>>>> be compatible with the fact that EVERY call to H(D,D) will
>>>>>>>>>>>> also eventually return 0.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Remember also, THIS D is defined to call THIS H, that does
>>>>>>>>>>>> exactly the same as the H that is deciding it.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> OK, good.
>>>>>>>>>>
>>>>>>>>>> Right, so it doesn't matter what any other D does, it matters
>>>>>>>>>> what THIS D does, and this D calls aths H.
>>>>>>>>>>
>>>>>>>>>> Remember, you reinstated the Computation model by enforcing
>>>>>>>>>> Pure Functions.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> <snip so that Message ID links to whole message>
>>>>>>>>>>>>> We can use my unique time/date stamp as an alternative.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Remember, YOU are the one saying you are needing to change
>>>>>>>>>>>>>> the definition from the classical theory, where we have
>>>>>>>>>>>>>> things well defined.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> YOU have decider that H is just whatever C code you want
>>>>>>>>>>>>>> to write for it, and D is the input proved. (which doesn't
>>>>>>>>>>>>>> actually match the Linz or Sipser proof, but fairly close).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> With THAT set of definitions we have a lot of options that
>>>>>>>>>>>>>> break your incorrectly assumed results.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The first method has been discussed here by Flibble. While
>>>>>>>>>>>>>> the final answer he got to doesn't fit the requirements,
>>>>>>>>>>>>>> the first part of the method DOES show that it is possible
>>>>>>>>>>>>>> for an H to simulate to past line 3.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> THe basic idea is that if H(M,d) finds that its simulation
>>>>>>>>>>>>>> of M(d) get to a call to H(M,d) then rather that your idea
>>>>>>>>>>>>>> of just saying it will get stuck and declair the input
>>>>>>>>>>>>>> invalid, since there ARE a number of possible inputs that
>>>>>>>>>>>>>> there is a "correct" answer that H can give to
>>>>>>>>>>>>>
>>>>>>>>>>>>> That D is calling H does not prove recursive simulation.
>>>>>>>>>>>>> That D is calling H with its same parameters does seem
>>>>>>>>>>>>> to prove non-halting recursive simulation.
>>>>>>>>>>>>
>>>>>>>>>>>> Nope. Try to actuall PROVE it.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> That is off-topic for this post.
>>>>>>>>>>> All that we need know is that no D simulated by any H
>>>>>>>>>>> ever reaches its own line 06 and halts.
>>>>>>>>>>
>>>>>>>>>> Nope. Make a claim, you need to prove it.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> *In other different post not this one*
>>>>>>>>>
>>>>>>>>> I am using categorically exhaustive reasoning that can work
>>>>>>>>> through every possibility that can possibly exist in a feasible
>>>>>>>>> amount of time as long as the category is very very narrow.
>>>>>>>>
>>>>>>>> But you can't PRECISELY define the category, or what you want to
>>>>>>>> reason about, so your logic is worthless as it is baseless.
>>>>>>>>
>>>>>>>
>>>>>>> *POINT TO ANY ACTUAL MISTAKE OR AMBIGUITY WITH THIS VERSION*
>>>>>>>
>>>>>>> typedef int (*ptr)(); // ptr is pointer to int function
>>>>>>> 00 int H(ptr p, ptr i);
>>>>>>> 01 int D(ptr p)
>>>>>>> 02 {
>>>>>>> 03 int Halt_Status = H(p, p);
>>>>>>> 04 if (Halt_Status)
>>>>>>> 05 HERE: goto HERE;
>>>>>>> 06 return Halt_Status;
>>>>>>> 07 }
>>>>>>> 08
>>>>>>> 09 int main()
>>>>>>> 10 {
>>>>>>> 11 H(D,D);
>>>>>>> 12 return 0;
>>>>>>> 13 }
>>>>>>>
>>>>>>> In the above case a simulator is an x86 emulator that correctly
>>>>>>> emulates at least one of the x86 instructions of D in the order
>>>>>>> specified by the x86 instructions of D.
>>>>>>>
>>>>>>> This may include correctly emulating the x86 instructions of H in
>>>>>>> the order specified by the x86 instructions of H thus calling
>>>>>>> H(D,D) in recursive simulation.
>>>>>>>
>>>>>>> Execution Trace
>>>>>>> Line 11: main() invokes H(D,D);
>>>>>>>
>>>>>>> keeps repeating (unless aborted)
>>>>>>> Line 01:
>>>>>>> Line 02:
>>>>>>> Line 03: simulated D(D) invokes simulated H(D,D) that simulates D(D)
>>>>>>>
>>>>>>> Simulation invariant:
>>>>>>> D correctly simulated by H cannot possibly reach past its own
>>>>>>> line 03.
>>>>>>>
>>>>>>> For every H/D pair of the above template D correctly simulated by
>>>>>>> pure function (thus computable function) H cannot possibly reach
>>>>>>> its own final state at line 06 and halt.
>>>>>>>
>>>>>>
>>>>>> Which thus doesn't correct simulate the call to H
>>>>>
>>>>> *Counter-factual, try again*
>>>>> We are not talking about any of your misconceptions the term:
>>>>> "simulate" is expressly defined.
>>>>
>>>> And how did your H "Correctly" simulate the call to H?
>>>>
>>>
>>> That does not matter as long as it is not impossible.
>>
>> But since you claim you did it, you need to show what you did.
>>
>
> I cannot show the behavior of every element of an infinite set
> a c function pairs.
So, didn't you say that needing infinite operations to evaluate made
something not a truth beared?
>
>> The problem is you don't seem to understand that somethings ARE
>> impossible.
>>
>
> It is certainly not impossible for pure function H to correctly
> simulate D.
No, but it is impossible for a pure function H to correctly simulate
this D built on that H by the definition of Computation Theory AND
provide an answer.
>
>> Like building a Turing Machine that always correctly determines if
>> another Turing Machine/Input combination will halt.
>>
>> Your claims that you make one that answers the proof case, is just
>> proven to be a lie, and your proof is based on first assuming it is
>> possible and then using that "fact" to try to prove your answer, which
>> is just the thing you claim you are not allowed to do.
>>
>
> In the last two years I have not even exaggerated.
> Lets call a truce on accusations of lying you eventually
> proved that you were not lying about this key point and I
> updated my spec to address the issue that you raised.
Really, how many times did you say that I did not provide a counter example?
>
> I made sure to not call you a liar on this. I said that until
> proved otherwise I will assume that you are a liar and then
> you proved otherwise.
But you continued to assert a statement that was untrue, even though it
was proved incorrect, you LATER changed your definition to try to get
around my answer,
You still haven't refuted the first method.
>
>> Thus, it is proven that you whole concept is just built on
>> inconsistant lies.
>>
>>>
>>>>>
>>>>> This is the only post about this subject that I will respond
>>>>> to from you. I have to paint half of my house and empty my
>>>>> garage within about a week.
>>>>>
>>>>> If you can find some source that conclusively proves that
>>>>> not all pure functions are computable functions I would like
>>>>> to see it. All of the experts that I could find seem to agree
>>>>> that all pure functions in C would be computable functions
>>>>> by a Turing machine.
>>>>
>>>> So, you just don't understand that "Computable Function" is a
>>>> Term-of-the-art to talk about the mathematical mapping, an NOT the
>>>> algorithm that shows the mapping is computable.
>>>>
>>>
>>> Pure functions <are> Turing computable functions until you
>>> conclusively prove otherwise.
>>
>> So, you still don't understand the meaning of the words.
>>
>
>
> Try and point out the specific error and I will correct any
> mistake that you find. Until you provide a basis I will assume
> that your claim is baseless.
"Correct Simulation" to show something about non-termination, must be
per the methods of Computation Theory, which means like a UTM, which
means it does not stop.
A "Computable Function" isn't a program, but a mathematical concept of a
mapping from the input set to the output set for which there exists an
finite algoritm that computes it. (The program is that algorithm, not
the Function).
Note also, a "Pure Function" and this algorithm are NOT exactly
equivalent. Pure Function might take a hidden input that makes copies of
the function not equivalent, breaking them form being the requirements
of an algorithm, which is a bit stricter, as it requires that ALL COPIES
return the same answer for the same inputs.
Also, it is possible for an algorithm to violate the definiton of a
"Pure Function" in certain limited manners, and still be a proper
algorithm, the key is that the definition of an algorithm is a strictly
Input to Output relationship, and doesn't talk about how the answer is
given.
>
>> Your claim is like saying that cats are 10 story office building.
>>
>>>
>>>> One key point that make "Pure Functions" not necessarily equivalent
>>>> to a Turing Machine is the ability to get "hidden inputs" from
>>>> things like their own program address, something a Turing Machine
>>>> doesn't have.
>>>>
>>>
>>> *That is irrelevant to the current post*
>>> *You can always look at the title and see if you went off topic*
>>
>> No, you keep making the error, and thus destroy your arguement.
>>
>
> Since I am only responding to you via this single thread I
> don't have to cut off the first divergence from the title.
>
>>>
>>>
>>> *This boiler plate will be the only reply*
>>> I am using categorically exhaustive reasoning that can work
>>> through every possibility that can possibly exist in a feasible
>>> amount of time as long as the category is very very narrow.
>>>
>>> Enlarge the category a tiny little bit and then the time
>>> becomes infeasible.
>>>
>>> The tiniest little divergence from the title of this
>>> thread and I totally ignore and erase everything else
>>> that you say.
>>>
>>>
>>
>> And if you can't actually define your category or the thing to be
>> analyzied you are just wasting your time, as if you don't know where
>> you are going, it is hard to find the path.
>>
>
> The way I see it I defined it correctly and completely and you
> are simply pretending otherwise. Until you prove otherwise I
> will continue to assume this.
But since you can't clearly state it, it means we can't help you.
>
> You seem to favor baseless rhetoric because you know that baseless
> rhetoric with ad hominem mixed in is very convincing for gullible fools.
> Gullible fools are outside of my target audience.
>
Nope, your deception seems to be an attempt to go after gullible fools.
If you where honest, you could post you whole arguement and let it be
worked on.
From your past, the reason you need to break the arguement into pieces
is you need to seperate to logic to allow a change of definition between
the sections.
For instance, you definition here of correct simulation means your
results can not be used to show non-halting.
My guess is in a later section, you will pull out the rule that if a
correct simulation doesn't reach a final state, the input is
non-halting, which is just a LIE because you have changed definition mid
proof.
This has been your history.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-05-21 21:05 -0500 |
| Subject | Re: Every D correctly simulated by H cannot possibly reach its own line 06 and halt |
| Message-ID | <v2jju1$vqej$1@dont-email.me> |
| In reply to | #105375 |
On 5/21/2024 8:46 PM, Richard Damon wrote:
> On 5/21/24 10:22 AM, olcott wrote:
>> On 5/21/2024 7:03 AM, Richard Damon wrote:
>>> On 5/21/24 1:18 AM, olcott wrote:
>>>> On 5/20/2024 9:39 PM, Richard Damon wrote:
>>>>> On 5/20/24 10:25 PM, olcott wrote:
>>>>>> On 5/20/2024 7:57 PM, Richard Damon wrote:
>>>>>>> On 5/20/24 2:03 PM, olcott wrote:
>>>>>>>> On 5/20/2024 6:24 AM, Richard Damon wrote:
>>>>>>>>> On 5/19/24 11:22 PM, olcott wrote:
>>>>>>>>>> On 5/19/2024 10:11 PM, Richard Damon wrote:
>>>>>>>>>>> On 5/19/24 10:52 PM, olcott wrote:
>>>>>>>>>>>> On 5/19/2024 8:10 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 5/19/24 8:06 PM, olcott wrote:
>>>>>>>>>>>>>> On 5/1/2024 7:10 PM, Richard Damon wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> typedef int (*ptr)(); // ptr is pointer to int function
>>>>>>>>>>>>>> 00 int H(ptr p, ptr i);
>>>>>>>>>>>>>> 01 int D(ptr p)
>>>>>>>>>>>>>> 02 {
>>>>>>>>>>>>>> 03 int Halt_Status = H(p, p);
>>>>>>>>>>>>>> 04 if (Halt_Status)
>>>>>>>>>>>>>> 05 HERE: goto HERE;
>>>>>>>>>>>>>> 06 return Halt_Status;
>>>>>>>>>>>>>> 07 }
>>>>>>>>>>>>>> 08
>>>>>>>>>>>>>> 09 int main()
>>>>>>>>>>>>>> 10 {
>>>>>>>>>>>>>> 11 H(D,D);
>>>>>>>>>>>>>> 12 return 0;
>>>>>>>>>>>>>> 13 }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> In the above case a simulator is an x86 emulator that
>>>>>>>>>>>>>> correctly emulates at least one of the x86 instructions of
>>>>>>>>>>>>>> D in the order specified by the x86 instructions of D.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This may include correctly emulating the x86 instructions
>>>>>>>>>>>>>> of H in the order specified by the x86 instructions of H
>>>>>>>>>>>>>> thus calling H(D,D) in recursive simulation.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> For every H/D pair of the above template D correctly
>>>>>>>>>>>>>> simulated by
>>>>>>>>>>>>>> *pure function* H cannot possibly reach its own final
>>>>>>>>>>>>>> state at
>>>>>>>>>>>>>> line 06 and halt.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Ok, so adding that H is a pure function, that means that
>>>>>>>>>>>>> since your outer H(D,D) is going to return 0, all logic
>>>>>>>>>>>>> must be compatible with the fact that EVERY call to H(D,D)
>>>>>>>>>>>>> will also eventually return 0.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Remember also, THIS D is defined to call THIS H, that does
>>>>>>>>>>>>> exactly the same as the H that is deciding it.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> OK, good.
>>>>>>>>>>>
>>>>>>>>>>> Right, so it doesn't matter what any other D does, it matters
>>>>>>>>>>> what THIS D does, and this D calls aths H.
>>>>>>>>>>>
>>>>>>>>>>> Remember, you reinstated the Computation model by enforcing
>>>>>>>>>>> Pure Functions.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> <snip so that Message ID links to whole message>
>>>>>>>>>>>>>> We can use my unique time/date stamp as an alternative.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Remember, YOU are the one saying you are needing to
>>>>>>>>>>>>>>> change the definition from the classical theory, where we
>>>>>>>>>>>>>>> have things well defined.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> YOU have decider that H is just whatever C code you want
>>>>>>>>>>>>>>> to write for it, and D is the input proved. (which
>>>>>>>>>>>>>>> doesn't actually match the Linz or Sipser proof, but
>>>>>>>>>>>>>>> fairly close).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> With THAT set of definitions we have a lot of options
>>>>>>>>>>>>>>> that break your incorrectly assumed results.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The first method has been discussed here by Flibble.
>>>>>>>>>>>>>>> While the final answer he got to doesn't fit the
>>>>>>>>>>>>>>> requirements, the first part of the method DOES show that
>>>>>>>>>>>>>>> it is possible for an H to simulate to past line 3.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> THe basic idea is that if H(M,d) finds that its
>>>>>>>>>>>>>>> simulation of M(d) get to a call to H(M,d) then rather
>>>>>>>>>>>>>>> that your idea of just saying it will get stuck and
>>>>>>>>>>>>>>> declair the input invalid, since there ARE a number of
>>>>>>>>>>>>>>> possible inputs that there is a "correct" answer that H
>>>>>>>>>>>>>>> can give to
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> That D is calling H does not prove recursive simulation.
>>>>>>>>>>>>>> That D is calling H with its same parameters does seem
>>>>>>>>>>>>>> to prove non-halting recursive simulation.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Nope. Try to actuall PROVE it.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> That is off-topic for this post.
>>>>>>>>>>>> All that we need know is that no D simulated by any H
>>>>>>>>>>>> ever reaches its own line 06 and halts.
>>>>>>>>>>>
>>>>>>>>>>> Nope. Make a claim, you need to prove it.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> *In other different post not this one*
>>>>>>>>>>
>>>>>>>>>> I am using categorically exhaustive reasoning that can work
>>>>>>>>>> through every possibility that can possibly exist in a feasible
>>>>>>>>>> amount of time as long as the category is very very narrow.
>>>>>>>>>
>>>>>>>>> But you can't PRECISELY define the category, or what you want
>>>>>>>>> to reason about, so your logic is worthless as it is baseless.
>>>>>>>>>
>>>>>>>>
>>>>>>>> *POINT TO ANY ACTUAL MISTAKE OR AMBIGUITY WITH THIS VERSION*
>>>>>>>>
>>>>>>>> typedef int (*ptr)(); // ptr is pointer to int function
>>>>>>>> 00 int H(ptr p, ptr i);
>>>>>>>> 01 int D(ptr p)
>>>>>>>> 02 {
>>>>>>>> 03 int Halt_Status = H(p, p);
>>>>>>>> 04 if (Halt_Status)
>>>>>>>> 05 HERE: goto HERE;
>>>>>>>> 06 return Halt_Status;
>>>>>>>> 07 }
>>>>>>>> 08
>>>>>>>> 09 int main()
>>>>>>>> 10 {
>>>>>>>> 11 H(D,D);
>>>>>>>> 12 return 0;
>>>>>>>> 13 }
>>>>>>>>
>>>>>>>> In the above case a simulator is an x86 emulator that correctly
>>>>>>>> emulates at least one of the x86 instructions of D in the order
>>>>>>>> specified by the x86 instructions of D.
>>>>>>>>
>>>>>>>> This may include correctly emulating the x86 instructions of H
>>>>>>>> in the order specified by the x86 instructions of H thus calling
>>>>>>>> H(D,D) in recursive simulation.
>>>>>>>>
>>>>>>>> Execution Trace
>>>>>>>> Line 11: main() invokes H(D,D);
>>>>>>>>
>>>>>>>> keeps repeating (unless aborted)
>>>>>>>> Line 01:
>>>>>>>> Line 02:
>>>>>>>> Line 03: simulated D(D) invokes simulated H(D,D) that simulates
>>>>>>>> D(D)
>>>>>>>>
>>>>>>>> Simulation invariant:
>>>>>>>> D correctly simulated by H cannot possibly reach past its own
>>>>>>>> line 03.
>>>>>>>>
>>>>>>>> For every H/D pair of the above template D correctly simulated
>>>>>>>> by pure function (thus computable function) H cannot possibly
>>>>>>>> reach its own final state at line 06 and halt.
>>>>>>>>
>>>>>>>
>>>>>>> Which thus doesn't correct simulate the call to H
>>>>>>
>>>>>> *Counter-factual, try again*
>>>>>> We are not talking about any of your misconceptions the term:
>>>>>> "simulate" is expressly defined.
>>>>>
>>>>> And how did your H "Correctly" simulate the call to H?
>>>>>
>>>>
>>>> That does not matter as long as it is not impossible.
>>>
>>> But since you claim you did it, you need to show what you did.
>>>
>>
>> I cannot show the behavior of every element of an infinite set
>> a c function pairs.
>
> So, didn't you say that needing infinite operations to evaluate made
> something not a truth beared?
>
>>
>>> The problem is you don't seem to understand that somethings ARE
>>> impossible.
>>>
>>
>> It is certainly not impossible for pure function H to correctly
>> simulate D.
>
> No, but it is impossible for a pure function H to correctly simulate
> this D built on that H by the definition of Computation Theory AND
> provide an answer.
>
At this point we are only looking at H as a simulator.
We can have this H return the meaningless 56.
>>
>>> Like building a Turing Machine that always correctly determines if
>>> another Turing Machine/Input combination will halt.
>>>
>>> Your claims that you make one that answers the proof case, is just
>>> proven to be a lie, and your proof is based on first assuming it is
>>> possible and then using that "fact" to try to prove your answer,
>>> which is just the thing you claim you are not allowed to do.
>>>
>>
>> In the last two years I have not even exaggerated.
>> Lets call a truce on accusations of lying you eventually
>> proved that you were not lying about this key point and I
>> updated my spec to address the issue that you raised.
>
> Really, how many times did you say that I did not provide a counter
> example?
>
You persistently did refuse to provide the message_ID
this did make you look like a liar.
>
>
>>
>> I made sure to not call you a liar on this. I said that until
>> proved otherwise I will assume that you are a liar and then
>> you proved otherwise.
>
> But you continued to assert a statement that was untrue, even though it
> was proved incorrect, you LATER changed your definition to try to get
> around my answer,
>
You persistently did refuse to provide the message_ID
this did make you look like a liar.
> You still haven't refuted the first method.
>
Sure I have this H is ONLY simulator thus the first method
loses its basis.
>>
>>> Thus, it is proven that you whole concept is just built on
>>> inconsistant lies.
>>>
>>>>
>>>>>>
>>>>>> This is the only post about this subject that I will respond
>>>>>> to from you. I have to paint half of my house and empty my
>>>>>> garage within about a week.
>>>>>>
>>>>>> If you can find some source that conclusively proves that
>>>>>> not all pure functions are computable functions I would like
>>>>>> to see it. All of the experts that I could find seem to agree
>>>>>> that all pure functions in C would be computable functions
>>>>>> by a Turing machine.
>>>>>
>>>>> So, you just don't understand that "Computable Function" is a
>>>>> Term-of-the-art to talk about the mathematical mapping, an NOT the
>>>>> algorithm that shows the mapping is computable.
>>>>>
>>>>
>>>> Pure functions <are> Turing computable functions until you
>>>> conclusively prove otherwise.
>>>
>>> So, you still don't understand the meaning of the words.
>>>
>>
>>
>> Try and point out the specific error and I will correct any
>> mistake that you find. Until you provide a basis I will assume
>> that your claim is baseless.
>
> "Correct Simulation" to show something about non-termination, must be
> per the methods of Computation Theory, which means like a UTM, which
> means it does not stop.
>
It is essentially trivial to see that D correctly simulated by H
cannot possibly reach its own final state at line 06 because
D correctly simulated by H remains stuck in recursive simulation.
> A "Computable Function" isn't a program, but a mathematical concept of a
> mapping from the input set to the output set for which there exists an
> finite algoritm that computes it. (The program is that algorithm, not
> the Function).
>
How do we tell if a C function is Turing Computable?
> Note also, a "Pure Function" and this algorithm are NOT exactly
> equivalent. Pure Function might take a hidden input that makes copies of
> the function not equivalent, breaking them form being the requirements
> of an algorithm, which is a bit stricter, as it requires that ALL COPIES
> return the same answer for the same inputs.
>
These H/D pairs only simulate.
> Also, it is possible for an algorithm to violate the definiton of a
> "Pure Function" in certain limited manners, and still be a proper
> algorithm, the key is that the definition of an algorithm is a strictly
> Input to Output relationship, and doesn't talk about how the answer is
> given.
>
I am saying that it must be a pure function.
>>
>>> Your claim is like saying that cats are 10 story office building.
>>>
>>>>
>>>>> One key point that make "Pure Functions" not necessarily equivalent
>>>>> to a Turing Machine is the ability to get "hidden inputs" from
>>>>> things like their own program address, something a Turing Machine
>>>>> doesn't have.
>>>>>
>>>>
>>>> *That is irrelevant to the current post*
>>>> *You can always look at the title and see if you went off topic*
>>>
>>> No, you keep making the error, and thus destroy your arguement.
>>>
>>
>> Since I am only responding to you via this single thread I
>> don't have to cut off the first divergence from the title.
>>
>>>>
>>>>
>>>> *This boiler plate will be the only reply*
>>>> I am using categorically exhaustive reasoning that can work
>>>> through every possibility that can possibly exist in a feasible
>>>> amount of time as long as the category is very very narrow.
>>>>
>>>> Enlarge the category a tiny little bit and then the time
>>>> becomes infeasible.
>>>>
>>>> The tiniest little divergence from the title of this
>>>> thread and I totally ignore and erase everything else
>>>> that you say.
>>>>
>>>>
>>>
>>> And if you can't actually define your category or the thing to be
>>> analyzied you are just wasting your time, as if you don't know where
>>> you are going, it is hard to find the path.
>>>
>>
>> The way I see it I defined it correctly and completely and you
>> are simply pretending otherwise. Until you prove otherwise I
>> will continue to assume this.
>
> But since you can't clearly state it, it means we can't help you.
>
I stated it perfectly and the proof of this is that
you did not point to any gaps in my spec.
>>
>> You seem to favor baseless rhetoric because you know that baseless
>> rhetoric with ad hominem mixed in is very convincing for gullible fools.
>> Gullible fools are outside of my target audience.
>>
>
> Nope, your deception seems to be an attempt to go after gullible fools.
>
THE ONLY REASON THAT I WORK ON THIS IS TO MATHEMATICALLY
FORMALIZE THE NOTION OF TRUTH ITSELF SO THAT THE NAZI
LIARS CANNOT GET AWAY WITH THEIR LIES.
> If you where honest, you could post you whole arguement and let it be
> worked on.
>
WE ARE ONLY TALKING ABOUT THE SUBJECT LINE OF THIS THREAD.
> From your past, the reason you need to break the arguement into pieces
> is you need to seperate to logic to allow a change of definition between
> the sections.
>
IT IS BECAUSE I DON'T HAVE ENOUGH TIME LEFT TO TOLERATE
ENDLESS DEFECTION
> For instance, you definition here of correct simulation means your
> results can not be used to show non-halting.
>
WE CAN GET TO THIS POINT AFTER WE FINISH THE SUBJECT OF THE THREAD
I DON'T HAVE ENOUGH TIME LEFT TO TOLERATE ENDLESS DEFECTION
> My guess is in a later section, you will pull out the rule that if a
> correct simulation doesn't reach a final state, the input is
> non-halting, which is just a LIE because you have changed definition mid
> proof.
>
> This has been your history.
It is trivial to see that D correctly simulated by H cannot
possibly reach its own final state at line 06 and halt because
D correctly simulated by H remains stuck in recursive simulation.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-05-21 23:09 -0400 |
| Subject | Re: Every D correctly simulated by H cannot possibly reach its own line 06 and halt |
| Message-ID | <v2jnlu$1nrfv$1@i2pn2.org> |
| In reply to | #105381 |
On 5/21/24 10:05 PM, olcott wrote:
> On 5/21/2024 8:46 PM, Richard Damon wrote:
>> On 5/21/24 10:22 AM, olcott wrote:
>>> On 5/21/2024 7:03 AM, Richard Damon wrote:
>>>> On 5/21/24 1:18 AM, olcott wrote:
>>>>> On 5/20/2024 9:39 PM, Richard Damon wrote:
>>>>>> On 5/20/24 10:25 PM, olcott wrote:
>>>>>>> On 5/20/2024 7:57 PM, Richard Damon wrote:
>>>>>>>> On 5/20/24 2:03 PM, olcott wrote:
>>>>>>>>> On 5/20/2024 6:24 AM, Richard Damon wrote:
>>>>>>>>>> On 5/19/24 11:22 PM, olcott wrote:
>>>>>>>>>>> On 5/19/2024 10:11 PM, Richard Damon wrote:
>>>>>>>>>>>> On 5/19/24 10:52 PM, olcott wrote:
>>>>>>>>>>>>> On 5/19/2024 8:10 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 5/19/24 8:06 PM, olcott wrote:
>>>>>>>>>>>>>>> On 5/1/2024 7:10 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> typedef int (*ptr)(); // ptr is pointer to int function
>>>>>>>>>>>>>>> 00 int H(ptr p, ptr i);
>>>>>>>>>>>>>>> 01 int D(ptr p)
>>>>>>>>>>>>>>> 02 {
>>>>>>>>>>>>>>> 03 int Halt_Status = H(p, p);
>>>>>>>>>>>>>>> 04 if (Halt_Status)
>>>>>>>>>>>>>>> 05 HERE: goto HERE;
>>>>>>>>>>>>>>> 06 return Halt_Status;
>>>>>>>>>>>>>>> 07 }
>>>>>>>>>>>>>>> 08
>>>>>>>>>>>>>>> 09 int main()
>>>>>>>>>>>>>>> 10 {
>>>>>>>>>>>>>>> 11 H(D,D);
>>>>>>>>>>>>>>> 12 return 0;
>>>>>>>>>>>>>>> 13 }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> In the above case a simulator is an x86 emulator that
>>>>>>>>>>>>>>> correctly emulates at least one of the x86 instructions
>>>>>>>>>>>>>>> of D in the order specified by the x86 instructions of D.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This may include correctly emulating the x86 instructions
>>>>>>>>>>>>>>> of H in the order specified by the x86 instructions of H
>>>>>>>>>>>>>>> thus calling H(D,D) in recursive simulation.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> For every H/D pair of the above template D correctly
>>>>>>>>>>>>>>> simulated by
>>>>>>>>>>>>>>> *pure function* H cannot possibly reach its own final
>>>>>>>>>>>>>>> state at
>>>>>>>>>>>>>>> line 06 and halt.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Ok, so adding that H is a pure function, that means that
>>>>>>>>>>>>>> since your outer H(D,D) is going to return 0, all logic
>>>>>>>>>>>>>> must be compatible with the fact that EVERY call to H(D,D)
>>>>>>>>>>>>>> will also eventually return 0.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Remember also, THIS D is defined to call THIS H, that does
>>>>>>>>>>>>>> exactly the same as the H that is deciding it.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> OK, good.
>>>>>>>>>>>>
>>>>>>>>>>>> Right, so it doesn't matter what any other D does, it
>>>>>>>>>>>> matters what THIS D does, and this D calls aths H.
>>>>>>>>>>>>
>>>>>>>>>>>> Remember, you reinstated the Computation model by enforcing
>>>>>>>>>>>> Pure Functions.
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> <snip so that Message ID links to whole message>
>>>>>>>>>>>>>>> We can use my unique time/date stamp as an alternative.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Remember, YOU are the one saying you are needing to
>>>>>>>>>>>>>>>> change the definition from the classical theory, where
>>>>>>>>>>>>>>>> we have things well defined.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> YOU have decider that H is just whatever C code you want
>>>>>>>>>>>>>>>> to write for it, and D is the input proved. (which
>>>>>>>>>>>>>>>> doesn't actually match the Linz or Sipser proof, but
>>>>>>>>>>>>>>>> fairly close).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> With THAT set of definitions we have a lot of options
>>>>>>>>>>>>>>>> that break your incorrectly assumed results.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The first method has been discussed here by Flibble.
>>>>>>>>>>>>>>>> While the final answer he got to doesn't fit the
>>>>>>>>>>>>>>>> requirements, the first part of the method DOES show
>>>>>>>>>>>>>>>> that it is possible for an H to simulate to past line 3.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> THe basic idea is that if H(M,d) finds that its
>>>>>>>>>>>>>>>> simulation of M(d) get to a call to H(M,d) then rather
>>>>>>>>>>>>>>>> that your idea of just saying it will get stuck and
>>>>>>>>>>>>>>>> declair the input invalid, since there ARE a number of
>>>>>>>>>>>>>>>> possible inputs that there is a "correct" answer that H
>>>>>>>>>>>>>>>> can give to
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> That D is calling H does not prove recursive simulation.
>>>>>>>>>>>>>>> That D is calling H with its same parameters does seem
>>>>>>>>>>>>>>> to prove non-halting recursive simulation.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Nope. Try to actuall PROVE it.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> That is off-topic for this post.
>>>>>>>>>>>>> All that we need know is that no D simulated by any H
>>>>>>>>>>>>> ever reaches its own line 06 and halts.
>>>>>>>>>>>>
>>>>>>>>>>>> Nope. Make a claim, you need to prove it.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> *In other different post not this one*
>>>>>>>>>>>
>>>>>>>>>>> I am using categorically exhaustive reasoning that can work
>>>>>>>>>>> through every possibility that can possibly exist in a feasible
>>>>>>>>>>> amount of time as long as the category is very very narrow.
>>>>>>>>>>
>>>>>>>>>> But you can't PRECISELY define the category, or what you want
>>>>>>>>>> to reason about, so your logic is worthless as it is baseless.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> *POINT TO ANY ACTUAL MISTAKE OR AMBIGUITY WITH THIS VERSION*
>>>>>>>>>
>>>>>>>>> typedef int (*ptr)(); // ptr is pointer to int function
>>>>>>>>> 00 int H(ptr p, ptr i);
>>>>>>>>> 01 int D(ptr p)
>>>>>>>>> 02 {
>>>>>>>>> 03 int Halt_Status = H(p, p);
>>>>>>>>> 04 if (Halt_Status)
>>>>>>>>> 05 HERE: goto HERE;
>>>>>>>>> 06 return Halt_Status;
>>>>>>>>> 07 }
>>>>>>>>> 08
>>>>>>>>> 09 int main()
>>>>>>>>> 10 {
>>>>>>>>> 11 H(D,D);
>>>>>>>>> 12 return 0;
>>>>>>>>> 13 }
>>>>>>>>>
>>>>>>>>> In the above case a simulator is an x86 emulator that correctly
>>>>>>>>> emulates at least one of the x86 instructions of D in the order
>>>>>>>>> specified by the x86 instructions of D.
>>>>>>>>>
>>>>>>>>> This may include correctly emulating the x86 instructions of H
>>>>>>>>> in the order specified by the x86 instructions of H thus
>>>>>>>>> calling H(D,D) in recursive simulation.
>>>>>>>>>
>>>>>>>>> Execution Trace
>>>>>>>>> Line 11: main() invokes H(D,D);
>>>>>>>>>
>>>>>>>>> keeps repeating (unless aborted)
>>>>>>>>> Line 01:
>>>>>>>>> Line 02:
>>>>>>>>> Line 03: simulated D(D) invokes simulated H(D,D) that simulates
>>>>>>>>> D(D)
>>>>>>>>>
>>>>>>>>> Simulation invariant:
>>>>>>>>> D correctly simulated by H cannot possibly reach past its own
>>>>>>>>> line 03.
>>>>>>>>>
>>>>>>>>> For every H/D pair of the above template D correctly simulated
>>>>>>>>> by pure function (thus computable function) H cannot possibly
>>>>>>>>> reach its own final state at line 06 and halt.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Which thus doesn't correct simulate the call to H
>>>>>>>
>>>>>>> *Counter-factual, try again*
>>>>>>> We are not talking about any of your misconceptions the term:
>>>>>>> "simulate" is expressly defined.
>>>>>>
>>>>>> And how did your H "Correctly" simulate the call to H?
>>>>>>
>>>>>
>>>>> That does not matter as long as it is not impossible.
>>>>
>>>> But since you claim you did it, you need to show what you did.
>>>>
>>>
>>> I cannot show the behavior of every element of an infinite set
>>> a c function pairs.
>>
>> So, didn't you say that needing infinite operations to evaluate made
>> something not a truth beared?
>>
>>>
>>>> The problem is you don't seem to understand that somethings ARE
>>>> impossible.
>>>>
>>>
>>> It is certainly not impossible for pure function H to correctly
>>> simulate D.
>>
>> No, but it is impossible for a pure function H to correctly simulate
>> this D built on that H by the definition of Computation Theory AND
>> provide an answer.
>>
>
> At this point we are only looking at H as a simulator.
> We can have this H return the meaningless 56.
>
>>>
>>>> Like building a Turing Machine that always correctly determines if
>>>> another Turing Machine/Input combination will halt.
>>>>
>>>> Your claims that you make one that answers the proof case, is just
>>>> proven to be a lie, and your proof is based on first assuming it is
>>>> possible and then using that "fact" to try to prove your answer,
>>>> which is just the thing you claim you are not allowed to do.
>>>>
>>>
>>> In the last two years I have not even exaggerated.
>>> Lets call a truce on accusations of lying you eventually
>>> proved that you were not lying about this key point and I
>>> updated my spec to address the issue that you raised.
>>
>> Really, how many times did you say that I did not provide a counter
>> example?
>>
>
> You persistently did refuse to provide the message_ID
> this did make you look like a liar.
Because why do I need to provide a pointer to a message you read and
ignored.
Note, I kept on saying I would give it under a condition, one that I am
going to hold you to, that you admit that you have been wrong about your
claims that others haven't refuted you.
ANYTIME form now one that you make that claim, I can point out that you
have been wrong about this in the past.
>
>>
>>
>>>
>>> I made sure to not call you a liar on this. I said that until
>>> proved otherwise I will assume that you are a liar and then
>>> you proved otherwise.
>>
>> But you continued to assert a statement that was untrue, even though
>> it was proved incorrect, you LATER changed your definition to try to
>> get around my answer,
>>
>
> You persistently did refuse to provide the message_ID
> this did make you look like a liar.
Because you refued to make the pledge not to use the false arguement
that you have not be refuted.
>
>> You still haven't refuted the first method.
>>
>
> Sure I have this H is ONLY simulator thus the first method
> loses its basis.
Why is that? Isn't a valid simulation (one that your own H uses) is to
replace the call to H with an "equivalent" response. WHy else do you
list the simulation of the call H as the results of the simulation that
H does.
So, by your claim above, your H isn't allowed to presume by its logic
that a call to H will not return, as that isn't a "simulation" of the input.
Only by moving the goal posts, do you try to argue.
Note, this is why I am asking for you to come up with a PRECISE
specification of what you are claiming to do.
>
>>>
>>>> Thus, it is proven that you whole concept is just built on
>>>> inconsistant lies.
>>>>
>>>>>
>>>>>>>
>>>>>>> This is the only post about this subject that I will respond
>>>>>>> to from you. I have to paint half of my house and empty my
>>>>>>> garage within about a week.
>>>>>>>
>>>>>>> If you can find some source that conclusively proves that
>>>>>>> not all pure functions are computable functions I would like
>>>>>>> to see it. All of the experts that I could find seem to agree
>>>>>>> that all pure functions in C would be computable functions
>>>>>>> by a Turing machine.
>>>>>>
>>>>>> So, you just don't understand that "Computable Function" is a
>>>>>> Term-of-the-art to talk about the mathematical mapping, an NOT the
>>>>>> algorithm that shows the mapping is computable.
>>>>>>
>>>>>
>>>>> Pure functions <are> Turing computable functions until you
>>>>> conclusively prove otherwise.
>>>>
>>>> So, you still don't understand the meaning of the words.
>>>>
>>>
>>>
>>> Try and point out the specific error and I will correct any
>>> mistake that you find. Until you provide a basis I will assume
>>> that your claim is baseless.
>>
>> "Correct Simulation" to show something about non-termination, must be
>> per the methods of Computation Theory, which means like a UTM, which
>> means it does not stop.
>>
>
> It is essentially trivial to see that D correctly simulated by H
> cannot possibly reach its own final state at line 06 because
> D correctly simulated by H remains stuck in recursive simulation.
Which, due to your now clarified definition of what you mean by
"correctly simulated" means absolutly NOTHING in regards to the behavior
of the input.
>
>> A "Computable Function" isn't a program, but a mathematical concept of
>> a mapping from the input set to the output set for which there exists
>> an finite algoritm that computes it. (The program is that algorithm,
>> not the Function).
>>
>
> How do we tell if a C function is Turing Computable?
That Term doesn't apply to C funcitons at all, but to mathematical mappings.
Do you mean the computational equivalent of a Turing Machine?
>
>> Note also, a "Pure Function" and this algorithm are NOT exactly
>> equivalent. Pure Function might take a hidden input that makes copies
>> of the function not equivalent, breaking them form being the
>> requirements of an algorithm, which is a bit stricter, as it requires
>> that ALL COPIES return the same answer for the same inputs.
>>
>
> These H/D pairs only simulate.
And thus your logic has divorsed itself from behavior of the machine
described by the input, since your simulation is not "Correct" by the
correct meaning.
>
>> Also, it is possible for an algorithm to violate the definiton of a
>> "Pure Function" in certain limited manners, and still be a proper
>> algorithm, the key is that the definition of an algorithm is a
>> strictly Input to Output relationship, and doesn't talk about how the
>> answer is given.
>>
>
> I am saying that it must be a pure function.
And you would be wrong. I can show functions the Computational
Equivalent of a Turing Machine that violate the requirement of not using
static memory.
>
>>>
>>>> Your claim is like saying that cats are 10 story office building.
>>>>
>>>>>
>>>>>> One key point that make "Pure Functions" not necessarily
>>>>>> equivalent to a Turing Machine is the ability to get "hidden
>>>>>> inputs" from things like their own program address, something a
>>>>>> Turing Machine doesn't have.
>>>>>>
>>>>>
>>>>> *That is irrelevant to the current post*
>>>>> *You can always look at the title and see if you went off topic*
>>>>
>>>> No, you keep making the error, and thus destroy your arguement.
>>>>
>>>
>>> Since I am only responding to you via this single thread I
>>> don't have to cut off the first divergence from the title.
>>>
>>>>>
>>>>>
>>>>> *This boiler plate will be the only reply*
>>>>> I am using categorically exhaustive reasoning that can work
>>>>> through every possibility that can possibly exist in a feasible
>>>>> amount of time as long as the category is very very narrow.
>>>>>
>>>>> Enlarge the category a tiny little bit and then the time
>>>>> becomes infeasible.
>>>>>
>>>>> The tiniest little divergence from the title of this
>>>>> thread and I totally ignore and erase everything else
>>>>> that you say.
>>>>>
>>>>>
>>>>
>>>> And if you can't actually define your category or the thing to be
>>>> analyzied you are just wasting your time, as if you don't know where
>>>> you are going, it is hard to find the path.
>>>>
>>>
>>> The way I see it I defined it correctly and completely and you
>>> are simply pretending otherwise. Until you prove otherwise I
>>> will continue to assume this.
>>
>> But since you can't clearly state it, it means we can't help you.
>>
>
> I stated it perfectly and the proof of this is that
> you did not point to any gaps in my spec.
Nope.
>
>>>
>>> You seem to favor baseless rhetoric because you know that baseless
>>> rhetoric with ad hominem mixed in is very convincing for gullible fools.
>>> Gullible fools are outside of my target audience.
>>>
>>
>> Nope, your deception seems to be an attempt to go after gullible fools.
>>
>
> THE ONLY REASON THAT I WORK ON THIS IS TO MATHEMATICALLY
> FORMALIZE THE NOTION OF TRUTH ITSELF SO THAT THE NAZI
> LIARS CANNOT GET AWAY WITH THEIR LIES.
But since your logic is based on LIES, like that H(D,D) is allowed to
say its input is non-halting when D(D) Halts, that seems unlikely.
>
>> If you where honest, you could post you whole arguement and let it be
>> worked on.
>>
>
> WE ARE ONLY TALKING ABOUT THE SUBJECT LINE OF THIS THREAD.
You said otherwise.
>
>> From your past, the reason you need to break the arguement into
>> pieces is you need to seperate to logic to allow a change of
>> definition between the sections.
>>
>
> IT IS BECAUSE I DON'T HAVE ENOUGH TIME LEFT TO TOLERATE
> ENDLESS DEFECTION
So, why do you waste so much digging your heals on triva.
Just answer the questions and we can move on.
>
>> For instance, you definition here of correct simulation means your
>> results can not be used to show non-halting.
>>
>
> WE CAN GET TO THIS POINT AFTER WE FINISH THE SUBJECT OF THE THREAD
> I DON'T HAVE ENOUGH TIME LEFT TO TOLERATE ENDLESS DEFECTION
Then you don't have time to just repeat the same request over and over.
>
>> My guess is in a later section, you will pull out the rule that if a
>> correct simulation doesn't reach a final state, the input is
>> non-halting, which is just a LIE because you have changed definition
>> mid proof.
>>
>> This has been your history.
>
> It is trivial to see that D correctly simulated by H cannot
> possibly reach its own final state at line 06 and halt because
> D correctly simulated by H remains stuck in recursive simulation.
>
Unless H aborts its simulation, which it must do to answer. And, since
it does, that means the partial simulation it does, doesn't show that
the machine in non-halting.
This is one reason you need to clarify you exact meaning. Since you have
implied that your goal is about halting, you are stuck with the
definitions from that, and to allow deviations, we need EXPLICIT
agreement that these results can not be then just used to show
non-halting, as that would be a lie.
Of course, if you admit that you aren't working on deciding halting,
then you have just wasted you 20 years, so showing that you can POOP
decider this one machine doesn't mean anything. The non-computability of
Halting still can be used for all of the proofs it is part of.
And, if you want to revamp the logic system with new definitions, you
are working at the wrong end, you need to go to the foundations, and
start there, and fully define the axioms you are going to be using.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-05-21 22:52 -0500 |
| Subject | Re: Every D correctly simulated by H cannot possibly reach its own line 06 and halt |
| Message-ID | <v2jq5i$10qa6$1@dont-email.me> |
| In reply to | #105382 |
On 5/21/2024 10:09 PM, Richard Damon wrote: > On 5/21/24 10:05 PM, olcott wrote: >> On 5/21/2024 8:46 PM, Richard Damon wrote: >> >> You persistently did refuse to provide the message_ID >> this did make you look like a liar. > > Because why do I need to provide a pointer to a message you read and > ignored. > YOU CONTINUE TO USE THE CHANGE-THE-SUBJECT FAKE REBUTTAL AS SOON AS YOU DO THIS I IGNORED EVERYTHING ELSE THAT YOU SAID. > Note, I kept on saying I would give it under a condition, one that I am > going to hold you to, that you admit that you have been wrong about your > claims that others haven't refuted you. > You used a loophole that was not really there yet I can call this an honest mistake and not a lie. > ANYTIME form now one that you make that claim, I can point out that you > have been wrong about this in the past. > Message-ID with every claim that I have been wrong on any point going forward. >> >>> >>> >>>> >>>> I made sure to not call you a liar on this. I said that until >>>> proved otherwise I will assume that you are a liar and then >>>> you proved otherwise. >>> >>> But you continued to assert a statement that was untrue, even though >>> it was proved incorrect, you LATER changed your definition to try to >>> get around my answer, >>> >> >> You persistently did refuse to provide the message_ID >> this did make you look like a liar. > > Because you refued to make the pledge not to use the false arguement > that you have not be refuted. > You used a loophole that was not really there yet I can call this an honest mistake and not a lie. > >> >>> You still haven't refuted the first method. >>> >> >> Sure I have this H is ONLY simulator thus the first method >> loses its basis. > > Why is that? Isn't a valid simulation (one that your own H uses) is to > replace the call to H with an "equivalent" response. WHy else do you > list the simulation of the call H as the results of the simulation that > H does. > THAT FAILS TO MEET THIS SPEC THAT I WOULD NOT HAVE WRITTEN EXCEPT FOR YOU CRITIQUE, THANKS In the above case a simulator is an x86 emulator that correctly emulates at least one of the x86 instructions of D in the order specified by the x86 instructions of D. This may include correctly emulating the x86 instructions of H in the order specified by the x86 instructions of H thus calling H(D,D) in recursive simulation. > So, by your claim above, your H isn't allowed to presume by its logic > that a call to H will not return, as that isn't a "simulation" of the > input. > > Only by moving the goal posts, do you try to argue. > > Note, this is why I am asking for you to come up with a PRECISE > specification of what you are claiming to do. > *SURE AND THAT IS A GREAT IDEA THAT IS PROVING VERY HELPFUL THANKS* >> >>>> >>>>> Thus, it is proven that you whole concept is just built on >>>>> inconsistant lies. >>>>> >>>>>> >>>>>>>> >>>>>>>> This is the only post about this subject that I will respond >>>>>>>> to from you. I have to paint half of my house and empty my >>>>>>>> garage within about a week. >>>>>>>> >>>>>>>> If you can find some source that conclusively proves that >>>>>>>> not all pure functions are computable functions I would like >>>>>>>> to see it. All of the experts that I could find seem to agree >>>>>>>> that all pure functions in C would be computable functions >>>>>>>> by a Turing machine. >>>>>>> >>>>>>> So, you just don't understand that "Computable Function" is a >>>>>>> Term-of-the-art to talk about the mathematical mapping, an NOT >>>>>>> the algorithm that shows the mapping is computable. >>>>>>> >>>>>> >>>>>> Pure functions <are> Turing computable functions until you >>>>>> conclusively prove otherwise. >>>>> >>>>> So, you still don't understand the meaning of the words. >>>>> >>>> >>>> >>>> Try and point out the specific error and I will correct any >>>> mistake that you find. Until you provide a basis I will assume >>>> that your claim is baseless. >>> >>> "Correct Simulation" to show something about non-termination, must be >>> per the methods of Computation Theory, which means like a UTM, which >>> means it does not stop. >>> >> >> It is essentially trivial to see that D correctly simulated by H >> cannot possibly reach its own final state at line 06 because >> D correctly simulated by H remains stuck in recursive simulation. > > Which, due to your now clarified definition of what you mean by > "correctly simulated" means absolutly NOTHING in regards to the behavior > of the input. > In the above case a simulator is an x86 emulator that correctly emulates at least one of the x86 instructions of D in the order specified by the x86 instructions of D. This may include correctly emulating the x86 instructions of H in the order specified by the x86 instructions of H thus calling H(D,D) in recursive simulation. It is trivial to see that for every H/D pair of the infinite set of H/D pairs that match the above template that D correctly simulated by H cannot possibly reach its own final state at line 06 and halt because D correctly simulated by H remains stuck in recursive simulation. >> >>> A "Computable Function" isn't a program, but a mathematical concept >>> of a mapping from the input set to the output set for which there >>> exists an finite algoritm that computes it. (The program is that >>> algorithm, not the Function). >>> >> >> How do we tell if a C function is Turing Computable? > > That Term doesn't apply to C funcitons at all, but to mathematical > mappings. > > Do you mean the computational equivalent of a Turing Machine? > Not quite, almost. The computational equivalent of a Turing computable function. TM's can get stuck in loops. > >> >>> Note also, a "Pure Function" and this algorithm are NOT exactly >>> equivalent. Pure Function might take a hidden input that makes copies >>> of the function not equivalent, breaking them form being the >>> requirements of an algorithm, which is a bit stricter, as it requires >>> that ALL COPIES return the same answer for the same inputs. >>> >> >> These H/D pairs only simulate. > > And thus your logic has divorsed itself from behavior of the machine > described by the input, since your simulation is not "Correct" by the > correct meaning. > In the above case a simulator is an x86 emulator that correctly emulates at least one of the x86 instructions of D in the order specified by the x86 instructions of D. This may include correctly emulating the x86 instructions of H in the order specified by the x86 instructions of H thus calling H(D,D) in recursive simulation. Alternatives would be incorrectly emulating the x86 instructions of D or emulating them in the wrong order, or both. Likewise for H. >> >>> Also, it is possible for an algorithm to violate the definiton of a >>> "Pure Function" in certain limited manners, and still be a proper >>> algorithm, the key is that the definition of an algorithm is a >>> strictly Input to Output relationship, and doesn't talk about how the >>> answer is given. >>> >> >> I am saying that it must be a pure function. > > And you would be wrong. I can show functions the Computational > Equivalent of a Turing Machine that violate the requirement of not using > static memory. > Then my measure is more restrictive than necessary yet still sufficiently restrictive. >> >>>> >>>>> Your claim is like saying that cats are 10 story office building. >>>>> >>>>>> >>>>>>> One key point that make "Pure Functions" not necessarily >>>>>>> equivalent to a Turing Machine is the ability to get "hidden >>>>>>> inputs" from things like their own program address, something a >>>>>>> Turing Machine doesn't have. >>>>>>> >>>>>> >>>>>> *That is irrelevant to the current post* >>>>>> *You can always look at the title and see if you went off topic* >>>>> >>>>> No, you keep making the error, and thus destroy your arguement. >>>>> >>>> >>>> Since I am only responding to you via this single thread I >>>> don't have to cut off the first divergence from the title. >>>> >>>>>> >>>>>> >>>>>> *This boiler plate will be the only reply* >>>>>> I am using categorically exhaustive reasoning that can work >>>>>> through every possibility that can possibly exist in a feasible >>>>>> amount of time as long as the category is very very narrow. >>>>>> >>>>>> Enlarge the category a tiny little bit and then the time >>>>>> becomes infeasible. >>>>>> >>>>>> The tiniest little divergence from the title of this >>>>>> thread and I totally ignore and erase everything else >>>>>> that you say. >>>>>> >>>>>> >>>>> >>>>> And if you can't actually define your category or the thing to be >>>>> analyzied you are just wasting your time, as if you don't know >>>>> where you are going, it is hard to find the path. >>>>> >>>> >>>> The way I see it I defined it correctly and completely and you >>>> are simply pretending otherwise. Until you prove otherwise I >>>> will continue to assume this. >>> >>> But since you can't clearly state it, it means we can't help you. >>> >> >> I stated it perfectly and the proof of this is that >> you did not point to any gaps in my spec. > > Nope. > Failing to point to gaps right now is evidence that you are not telling the truth. Just like the election deniers. There is evidence somewhere, OK then give me a link or I will assume that you must be lying about election fraud evidence. >> >>>> >>>> You seem to favor baseless rhetoric because you know that baseless >>>> rhetoric with ad hominem mixed in is very convincing for gullible >>>> fools. >>>> Gullible fools are outside of my target audience. >>>> >>> >>> Nope, your deception seems to be an attempt to go after gullible fools. >>> >> >> THE ONLY REASON THAT I WORK ON THIS IS TO MATHEMATICALLY >> FORMALIZE THE NOTION OF TRUTH ITSELF SO THAT THE NAZI >> LIARS CANNOT GET AWAY WITH THEIR LIES. > > But since your logic is based on LIES, like that H(D,D) is allowed to > say its input is non-halting when D(D) Halts, that seems unlikely. > That you fail to comprehend what I say is not even slight evidence that I am incorrect. The one "mistake" that you pointed out used a loophole that didn't really exist. >> >>> If you where honest, you could post you whole arguement and let it be >>> worked on. >>> >> >> WE ARE ONLY TALKING ABOUT THE SUBJECT LINE OF THIS THREAD. > > You said otherwise. > >> >>> From your past, the reason you need to break the arguement into >>> pieces is you need to seperate to logic to allow a change of >>> definition between the sections. >>> >> >> IT IS BECAUSE I DON'T HAVE ENOUGH TIME LEFT TO TOLERATE >> ENDLESS DEFECTION > > So, why do you waste so much digging your heals on triva. > > Just answer the questions and we can move on. > *IT IS THE KEY BASIS OF MY WHOLE PROOF THUS NOT TRIVIA* >> >>> For instance, you definition here of correct simulation means your >>> results can not be used to show non-halting. >>> >> >> WE CAN GET TO THIS POINT AFTER WE FINISH THE SUBJECT OF THE THREAD >> I DON'T HAVE ENOUGH TIME LEFT TO TOLERATE ENDLESS DEFECTION > > Then you don't have time to just repeat the same request over and over. > *IT IS THE KEY BASIS OF MY WHOLE PROOF THUS NOT TRIVIA* *IT IS THE KEY BASIS OF MY WHOLE PROOF THUS NOT TRIVIA* *IT IS THE KEY BASIS OF MY WHOLE PROOF THUS NOT TRIVIA* >> >>> My guess is in a later section, you will pull out the rule that if a >>> correct simulation doesn't reach a final state, the input is >>> non-halting, which is just a LIE because you have changed definition >>> mid proof. >>> >>> This has been your history. >> >> It is trivial to see that D correctly simulated by H cannot >> possibly reach its own final state at line 06 and halt because >> D correctly simulated by H remains stuck in recursive simulation. >> > > Unless H aborts its simulation, which it must do to answer. And, since > it does, that means the partial simulation it does, doesn't show that > the machine in non-halting. > IT IS TRIVIAL TO SEE THAT WHEN 1 TO 2^64 STEPS OF D ARE CORRECTLY SIMULATED BY H THAT BECAUSE D REMAINS STUCK IN RECURSIVE SIMULATION THE REST IS OUTSIDE OF THE SCOPE OF THE TITLE OF THIS THREAD WE CAN GET TO OTHER POINTS AS SOON AS THIS POINT IS FINISHED > This is one reason you need to clarify you exact meaning. Since you have > implied that your goal is about halting, you are stuck with the > definitions from that, and to allow deviations, we need EXPLICIT > agreement that these results can not be then just used to show > non-halting, as that would be a lie. > > Of course, if you admit that you aren't working on deciding halting, > then you have just wasted you 20 years, so showing that you can POOP > decider this one machine doesn't mean anything. The non-computability of > Halting still can be used for all of the proofs it is part of. > > And, if you want to revamp the logic system with new definitions, you > are working at the wrong end, you need to go to the foundations, and > start there, and fully define the axioms you are going to be using. -- Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-05-22 07:48 -0400 |
| Subject | Re: Every D correctly simulated by H cannot possibly reach its own line 06 and halt |
| Message-ID | <v2km1n$1nrg0$2@i2pn2.org> |
| In reply to | #105384 |
On 5/21/24 11:52 PM, olcott wrote: > On 5/21/2024 10:09 PM, Richard Damon wrote: >> On 5/21/24 10:05 PM, olcott wrote: >> On 5/21/2024 8:46 PM, Richard >> Damon wrote: >>> >>> You persistently did refuse to provide the message_ID >>> this did make you look like a liar. >> >> Because why do I need to provide a pointer to a message you read and >> ignored. >> > > YOU CONTINUE TO USE THE CHANGE-THE-SUBJECT FAKE REBUTTAL > AS SOON AS YOU DO THIS I IGNORED EVERYTHING ELSE THAT YOU SAID. > >> Note, I kept on saying I would give it under a condition, one that I >> am going to hold you to, that you admit that you have been wrong about >> your claims that others haven't refuted you. >> > > You used a loophole that was not really there yet I can > call this an honest mistake and not a lie. > >> ANYTIME form now one that you make that claim, I can point out that >> you have been wrong about this in the past. >> > > Message-ID with every claim that I have been wrong > on any point going forward. > >>> >>>> >>>> >>>>> >>>>> I made sure to not call you a liar on this. I said that until >>>>> proved otherwise I will assume that you are a liar and then >>>>> you proved otherwise. >>>> >>>> But you continued to assert a statement that was untrue, even though >>>> it was proved incorrect, you LATER changed your definition to try to >>>> get around my answer, >>>> >>> >>> You persistently did refuse to provide the message_ID >>> this did make you look like a liar. >> >> Because you refued to make the pledge not to use the false arguement >> that you have not be refuted. >> > > You used a loophole that was not really there yet I can > call this an honest mistake and not a lie. The loophole was always there, bacause you kept on refering to the semantics of the C programming language, but not the sematics of Computation Theory, and thus the requirement of being a "Pure Function" is not present unless stated. You don't seem to understand the nature of "Requirements", and think they are flexible. You need to clearly state them up front, and then follow them. And, when you talk about something that someone else has defined, you don't get to change the definitions and requirements that they established unless you CLEARLY point out that you are not talking about what they were, but something prehaps related. Like the Truth Primitive. It can't "Reject" an input, but is required to give an ANSWER for every possible input. It is DEFINED what it should do to "non-sense", not "Reject" but to say they are not true. That this leads to the impossibility to create such a truth predicate, means exactly that. If you want to create an alternate but "similar" thing in the system, you can do so, but need to give it a different name. And then show if it is useful for anything. > >> >>> >>>> You still haven't refuted the first method. >>>> >>> >>> Sure I have this H is ONLY simulator thus the first method >>> loses its basis. >> >> Why is that? Isn't a valid simulation (one that your own H uses) is to >> replace the call to H with an "equivalent" response. WHy else do you >> list the simulation of the call H as the results of the simulation >> that H does. >> > > THAT FAILS TO MEET THIS SPEC THAT I WOULD NOT HAVE WRITTEN > EXCEPT FOR YOU CRITIQUE, THANKS And thus, it WAS an correct response for the problem as written. > > In the above case a simulator is an x86 emulator that correctly emulates > at least one of the x86 instructions of D in the order specified by the > x86 instructions of D. > > This may include correctly emulating the x86 instructions of H in the > order specified by the x86 instructions of H thus calling H(D,D) in > recursive simulation. Which isn't what you then claim your H's do. As your H's interpret a call to H as to be the effect of showing the machine that H simulates. ALL your proofs are based on such, now defined to be incorrect, simulations, so you have no grounds to make your claims. > > >> So, by your claim above, your H isn't allowed to presume by its logic >> that a call to H will not return, as that isn't a "simulation" of the >> input. >> >> Only by moving the goal posts, do you try to argue. >> >> Note, this is why I am asking for you to come up with a PRECISE >> specification of what you are claiming to do. >> > > *SURE AND THAT IS A GREAT IDEA THAT IS PROVING VERY HELPFUL THANKS* So, do so. What are the FULL specifications on what H does. What are the FULL specifications of what it is trying to determine. > >>> >>>>> >>>>>> Thus, it is proven that you whole concept is just built on >>>>>> inconsistant lies. >>>>>> >>>>>>> >>>>>>>>> >>>>>>>>> This is the only post about this subject that I will respond >>>>>>>>> to from you. I have to paint half of my house and empty my >>>>>>>>> garage within about a week. >>>>>>>>> >>>>>>>>> If you can find some source that conclusively proves that >>>>>>>>> not all pure functions are computable functions I would like >>>>>>>>> to see it. All of the experts that I could find seem to agree >>>>>>>>> that all pure functions in C would be computable functions >>>>>>>>> by a Turing machine. >>>>>>>> >>>>>>>> So, you just don't understand that "Computable Function" is a >>>>>>>> Term-of-the-art to talk about the mathematical mapping, an NOT >>>>>>>> the algorithm that shows the mapping is computable. >>>>>>>> >>>>>>> >>>>>>> Pure functions <are> Turing computable functions until you >>>>>>> conclusively prove otherwise. >>>>>> >>>>>> So, you still don't understand the meaning of the words. >>>>>> >>>>> >>>>> >>>>> Try and point out the specific error and I will correct any >>>>> mistake that you find. Until you provide a basis I will assume >>>>> that your claim is baseless. >>>> >>>> "Correct Simulation" to show something about non-termination, must >>>> be per the methods of Computation Theory, which means like a UTM, >>>> which means it does not stop. >>>> >>> >>> It is essentially trivial to see that D correctly simulated by H >>> cannot possibly reach its own final state at line 06 because >>> D correctly simulated by H remains stuck in recursive simulation. >> >> Which, due to your now clarified definition of what you mean by >> "correctly simulated" means absolutly NOTHING in regards to the >> behavior of the input. >> > > In the above case a simulator is an x86 emulator that correctly emulates > at least one of the x86 instructions of D in the order specified by the > x86 instructions of D. > > This may include correctly emulating the x86 instructions of H in the > order specified by the x86 instructions of H thus calling H(D,D) in > recursive simulation. > > It is trivial to see that for every H/D pair of the infinite > set of H/D pairs that match the above template that Try to prove it. You have already proven that you concept of "trivial to see" is not reliable. > > D correctly simulated by H cannot possibly reach its own final > state at line 06 and halt because D correctly simulated by > H remains stuck in recursive simulation. But then why is not the H that simulates just one step and then aborts, and says that its input didn't reach a final state, and thus in non-halting not also correct? The problem is you try to use logic about something other than THIS D to work your answer, which is like looking at 10 story office buildings to answer about your cat. Remember, Halting is a property of a PROGRAM, (not a template), and the PROGRAM D includes the H that it calls, so versions of your template-D that call other H's just are off topic for looking at THIS PROGRAM D. This needs to be part of your specifications. What is your H ACTUALLY looking at and what is it trying to decide. > > >>> >>>> A "Computable Function" isn't a program, but a mathematical concept >>>> of a mapping from the input set to the output set for which there >>>> exists an finite algoritm that computes it. (The program is that >>>> algorithm, not the Function). >>>> >>> >>> How do we tell if a C function is Turing Computable? >> >> That Term doesn't apply to C funcitons at all, but to mathematical >> mappings. >> >> Do you mean the computational equivalent of a Turing Machine? >> > > Not quite, almost. The computational equivalent of a Turing computable > function. TM's can get stuck in loops. Again, wrong term. Turing Machines are NOT "Computable Functions" If you want to specify that it always halts, then that term is a Decider. A Turing Machine that is a decider halts for all inputs, and it computes some Function, that it shows to be a Computable Function. > >> >>> >>>> Note also, a "Pure Function" and this algorithm are NOT exactly >>>> equivalent. Pure Function might take a hidden input that makes >>>> copies of the function not equivalent, breaking them form being the >>>> requirements of an algorithm, which is a bit stricter, as it >>>> requires that ALL COPIES return the same answer for the same inputs. >>>> >>> >>> These H/D pairs only simulate. >> >> And thus your logic has divorsed itself from behavior of the machine >> described by the input, since your simulation is not "Correct" by the >> correct meaning. >> > > In the above case a simulator is an x86 emulator that correctly emulates > at least one of the x86 instructions of D in the order specified by the > x86 instructions of D. > > This may include correctly emulating the x86 instructions of H in the > order specified by the x86 instructions of H thus calling H(D,D) in > recursive simulation. I think you mean MUST not MAY, or you allow the Flibble simulator. > > Alternatives would be incorrectly emulating the x86 instructions > of D or emulating them in the wrong order, or both. Likewise for H. And, you are still dropping your requirements on the structure of H. You STILL are allowing H to be the non-pure program I proposed. This just shows that it isn't really part of the requirements you are thinking of, just something you are trying to tack on to get around my example. The problem is, once you make H to must be the computational equivalent of a Turing machine, that means your logic you use must be compatible with such a machine, which means that if H(D,D) called by main returns 0, then no logical result can say that when D(D) calls H(D,D) that it will never return. You perhaps can show that H can not possible see that return, but that just shows the behavior is unknowable to H, not that it doesn't occur. This is a fundamental problem with you logic, you seem to think the unknowable doesn't actually happen. > >>> >>>> Also, it is possible for an algorithm to violate the definiton of a >>>> "Pure Function" in certain limited manners, and still be a proper >>>> algorithm, the key is that the definition of an algorithm is a >>>> strictly Input to Output relationship, and doesn't talk about how >>>> the answer is given. >>>> >>> >>> I am saying that it must be a pure function. >> >> And you would be wrong. I can show functions the Computational >> Equivalent of a Turing Machine that violate the requirement of not >> using static memory. >> > > Then my measure is more restrictive than necessary yet still > sufficiently restrictive. > No, because it also isn't restrictive enough, as for program-H to be the computational equivalent of the turing machine-h, then we need to be able to make a copy of your H that still behaves EXACTLY the same. Thus your H1 doesn't count, as it gives a different answer than H for the same input. The problem is your H takes a "hidden input" n the form of its program address, which still qualifies as a "Pure Function" but makes it not the equivalent of a Turing Machine. >>> >>>>> >>>>>> Your claim is like saying that cats are 10 story office building. >>>>>> >>>>>>> >>>>>>>> One key point that make "Pure Functions" not necessarily >>>>>>>> equivalent to a Turing Machine is the ability to get "hidden >>>>>>>> inputs" from things like their own program address, something a >>>>>>>> Turing Machine doesn't have. >>>>>>>> >>>>>>> >>>>>>> *That is irrelevant to the current post* >>>>>>> *You can always look at the title and see if you went off topic* >>>>>> >>>>>> No, you keep making the error, and thus destroy your arguement. >>>>>> >>>>> >>>>> Since I am only responding to you via this single thread I >>>>> don't have to cut off the first divergence from the title. >>>>> >>>>>>> >>>>>>> >>>>>>> *This boiler plate will be the only reply* >>>>>>> I am using categorically exhaustive reasoning that can work >>>>>>> through every possibility that can possibly exist in a feasible >>>>>>> amount of time as long as the category is very very narrow. >>>>>>> >>>>>>> Enlarge the category a tiny little bit and then the time >>>>>>> becomes infeasible. >>>>>>> >>>>>>> The tiniest little divergence from the title of this >>>>>>> thread and I totally ignore and erase everything else >>>>>>> that you say. >>>>>>> >>>>>>> >>>>>> >>>>>> And if you can't actually define your category or the thing to be >>>>>> analyzied you are just wasting your time, as if you don't know >>>>>> where you are going, it is hard to find the path. >>>>>> >>>>> >>>>> The way I see it I defined it correctly and completely and you >>>>> are simply pretending otherwise. Until you prove otherwise I >>>>> will continue to assume this. >>>> >>>> But since you can't clearly state it, it means we can't help you. >>>> >>> >>> I stated it perfectly and the proof of this is that >>> you did not point to any gaps in my spec. >> >> Nope. >> > > Failing to point to gaps right now is evidence that you > are not telling the truth. Just like the election deniers. Nope. You are being just like the election deniers. > > There is evidence somewhere, OK then give me a link or I will > assume that you must be lying about election fraud evidence. In other words, you are admitting that you make up what is actual true. Note, I said nothing about evidence of election fraud, that is you just reading words in to someones mouth. > >>> >>>>> >>>>> You seem to favor baseless rhetoric because you know that baseless >>>>> rhetoric with ad hominem mixed in is very convincing for gullible >>>>> fools. >>>>> Gullible fools are outside of my target audience. >>>>> >>>> >>>> Nope, your deception seems to be an attempt to go after gullible fools. >>>> >>> >>> THE ONLY REASON THAT I WORK ON THIS IS TO MATHEMATICALLY >>> FORMALIZE THE NOTION OF TRUTH ITSELF SO THAT THE NAZI >>> LIARS CANNOT GET AWAY WITH THEIR LIES. >> >> But since your logic is based on LIES, like that H(D,D) is allowed to >> say its input is non-halting when D(D) Halts, that seems unlikely. >> > > That you fail to comprehend what I say is not even slight > evidence that I am incorrect. The one "mistake" that you > pointed out used a loophole that didn't really exist. No, your logic is based on the changing meaning of words. To you a truth predicate doesn't need to meet the definition of a Truth Predicate (which you don't seem to know). You claim people means something with words that they do not mean, because you are too stupid to understand what they actually are meanng, so you make up something "dumb enough" for you to understand that you can refute. In other words, your logic is based on LIES > >>> >>>> If you where honest, you could post you whole arguement and let it >>>> be worked on. >>>> >>> >>> WE ARE ONLY TALKING ABOUT THE SUBJECT LINE OF THIS THREAD. >> >> You said otherwise. >> >>> >>>> From your past, the reason you need to break the arguement into >>>> pieces is you need to seperate to logic to allow a change of >>>> definition between the sections. >>>> >>> >>> IT IS BECAUSE I DON'T HAVE ENOUGH TIME LEFT TO TOLERATE >>> ENDLESS DEFECTION >> >> So, why do you waste so much digging your heals on triva. >> >> Just answer the questions and we can move on. >> > > *IT IS THE KEY BASIS OF MY WHOLE PROOF THUS NOT TRIVIA* And thus shows your whole proof to be meaningless. Proofs can not need to be broken down into pieces, but are a continous sequence of steps from the established truths of the system, proving new statements true, until reaching the final conclusion. The only reason to try to break up a proof into pieces is because there is a descrpency between the sections that needs to be hidden. > >>> >>>> For instance, you definition here of correct simulation means your >>>> results can not be used to show non-halting. >>>> >>> >>> WE CAN GET TO THIS POINT AFTER WE FINISH THE SUBJECT OF THE THREAD >>> I DON'T HAVE ENOUGH TIME LEFT TO TOLERATE ENDLESS DEFECTION >> >> Then you don't have time to just repeat the same request over and over. >> > > *IT IS THE KEY BASIS OF MY WHOLE PROOF THUS NOT TRIVIA* > *IT IS THE KEY BASIS OF MY WHOLE PROOF THUS NOT TRIVIA* > *IT IS THE KEY BASIS OF MY WHOLE PROOF THUS NOT TRIVIA* No, it can't be. If it is, your whole proof is just wrong. > >>> >>>> My guess is in a later section, you will pull out the rule that if a >>>> correct simulation doesn't reach a final state, the input is >>>> non-halting, which is just a LIE because you have changed definition >>>> mid proof. >>>> >>>> This has been your history. >>> >>> It is trivial to see that D correctly simulated by H cannot >>> possibly reach its own final state at line 06 and halt because >>> D correctly simulated by H remains stuck in recursive simulation. >>> >> >> Unless H aborts its simulation, which it must do to answer. And, since >> it does, that means the partial simulation it does, doesn't show that >> the machine in non-halting. >> > > IT IS TRIVIAL TO SEE THAT WHEN 1 TO 2^64 STEPS OF D ARE CORRECTLY > SIMULATED BY H THAT BECAUSE D REMAINS STUCK IN RECURSIVE SIMULATION And if H is defined to simulate for 2^64 steps, then it can be shown that for some biggger number, maybe 2^128 steps, if UTM(D,D) is run (with D still calling that original H) that this will reach an end, and thus D is NOT a non-halting input. > > THE REST IS OUTSIDE OF THE SCOPE OF THE TITLE OF THIS THREAD > WE CAN GET TO OTHER POINTS AS SOON AS THIS POINT IS FINISHED In other words, your scope is just to let you lie. Since you have shown yourself incapable of actually forming a coherenet definition of the problem, you are just lying. Again, because your definiton of H above didn't limit H to a pure function, my non-pure H refutes it. > >> This is one reason you need to clarify you exact meaning. Since you >> have implied that your goal is about halting, you are stuck with the >> definitions from that, and to allow deviations, we need EXPLICIT >> agreement that these results can not be then just used to show >> non-halting, as that would be a lie. >> >> Of course, if you admit that you aren't working on deciding halting, >> then you have just wasted you 20 years, so showing that you can POOP >> decider this one machine doesn't mean anything. The non-computability >> of Halting still can be used for all of the proofs it is part of. >> >> And, if you want to revamp the logic system with new definitions, you >> are working at the wrong end, you need to go to the foundations, and >> start there, and fully define the axioms you are going to be using. >
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-05-22 10:41 -0500 |
| Subject | Every D correctly simulated by H remains stuck in recursive simulation |
| Message-ID | <v2l3mr$188bi$1@dont-email.me> |
| In reply to | #105381 |
On 5/22/2024 5:26 AM, joes wrote:
> Am Tue, 21 May 2024 21:05:51 -0500 schrieb olcott:
>> On 5/21/2024 8:46 PM, Richard Damon wrote:
>>> On 5/21/24 10:22 AM, olcott wrote:
>>>> On 5/21/2024 7:03 AM, Richard Damon wrote:
>>>>> On 5/21/24 1:18 AM, olcott wrote:
>>>>>> On 5/20/2024 9:39 PM, Richard Damon wrote:
>>>>>>> On 5/20/24 10:25 PM, olcott wrote:
>>>>>>>> On 5/20/2024 7:57 PM, Richard Damon wrote:
>>>>>>>>> On 5/20/24 2:03 PM, olcott wrote:
>>>>>>>>>> On 5/20/2024 6:24 AM, Richard Damon wrote:
>>>>>>>>>>> On 5/19/24 11:22 PM, olcott wrote:
>>>>>>>>>>>> On 5/19/2024 10:11 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 5/19/24 10:52 PM, olcott wrote:
>>>>>>>>>>>>>> On 5/19/2024 8:10 PM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 5/19/24 8:06 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 5/1/2024 7:10 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>
>>> No, but it is impossible for a pure function H to correctly simulate
>>> this D built on that H by the definition of Computation Theory AND
>>> provide an answer.
>> At this point we are only looking at H as a simulator.
>> We can have this H return the meaningless 56.
>
> It must return the same value as its input would, or else run indefinitely.
>
typedef int (*ptr)(); // ptr is pointer to int function in C
00 int H(ptr p, ptr i);
01 int D(ptr p)
02 {
03 int Halt_Status = H(p, p);
04 if (Halt_Status)
05 HERE: goto HERE;
06 return Halt_Status;
07 }
08
09 int main()
10 {
11 H(D,D);
12 return 0;
13 }
I am just trying to get people to understand that for the infinite set
of H/D pairs matching the above template where D is correctly simulated
by pure function H that no D correctly simulated by pure function H can
possibly reach its own line 06 and halt because every D remains stuck in
recursive simulation.
>>> "Correct Simulation" to show something about non-termination, must be
>>> per the methods of Computation Theory, which means like a UTM, which
>>> means it does not stop.
>> It is essentially trivial to see that D correctly simulated by H
>> cannot possibly reach its own final state at line 06 because
>> D correctly simulated by H remains stuck in recursive simulation.
>
> This is much more understandable now that you added a reason. However,
> if one of those simulations aborts (because it detects infinite recursion),
> all of them must (because they are the same), making the abortion wrong.
> This is the whole argument.
>
*Halting means reaching a final state*
No D correctly simulated by pure function H can possibly reach its own
final state at line 06 halt because every D remains stuck in recursive
simulation.
>>> Note also, a "Pure Function" and this algorithm are NOT exactly
>>> equivalent. Pure Function might take a hidden input that makes copies of
>>> the function not equivalent, breaking them form being the requirements
>>> of an algorithm, which is a bit stricter, as it requires that ALL COPIES
>>> return the same answer for the same inputs.
>> These H/D pairs only simulate.
>
> No, they also recognise infinite recursion and abort, thus behaving
> differently (namely, terminating).
>
*Halting means reaching a final state*
No D correctly simulated by pure function H can possibly reach its own
final state at line 06 halt because every D remains stuck in recursive
simulation.
>>>>>> The tiniest little divergence from the title of this
>>>>>> thread and I totally ignore and erase everything else
>>>>>> that you say.
> > Very constructive.
>
Because of my POD24 diagnosis I do not have time for the endless
change-the-subject strawman deception form of rebuttal that wasted
fifteen years with Ben Bacarisse.
The subject is the title of this thread.
This can be exhaustively analyzed in finite time.
Expanding its scope a tiny little bit can increase the
time required beyond finite.
>>>>> And if you can't actually define your category or the thing to be
>>>>> analyzied you are just wasting your time, as if you don't know where
>>>>> you are going, it is hard to find the path.
>>>> The way I see it I defined it correctly and completely and you
>>>> are simply pretending otherwise. Until you prove otherwise I
>>>> will continue to assume this.
>
> If you think we are pretending, why bother?
>
I must address every rebuttal, even fake rebuttals or people
reviewing this after my death will be lead to believe that the
fake rebuttal was valid.
>>> But since you can't clearly state it, it means we can't help you.
>> I stated it perfectly and the proof of this is that
>> you did not point to any gaps in my spec.
>
>>>> You seem to favor baseless rhetoric because you know that baseless
>>>> rhetoric with ad hominem mixed in is very convincing for gullible fools.
>>>> Gullible fools are outside of my target audience.
>>> Nope, your deception seems to be an attempt to go after gullible fools.
>> THE ONLY REASON THAT I WORK ON THIS IS TO MATHEMATICALLY
>> FORMALIZE THE NOTION OF TRUTH ITSELF SO THAT THE NAZI
>> LIARS CANNOT GET AWAY WITH THEIR LIES.
>
> As if they would care.
>
They will care when their Nazi styled "big lie" propaganda
turns against them and causes their own downfall.
>>> If you where honest, you could post you whole arguement and let it be
>>> worked on.
>> WE ARE ONLY TALKING ABOUT THE SUBJECT LINE OF THIS THREAD.
>
>>> From your past, the reason you need to break the arguement into pieces
>>> is you need to seperate to logic to allow a change of definition between
>>> the sections.
>> IT IS BECAUSE I DON'T HAVE ENOUGH TIME LEFT TO TOLERATE
>> ENDLESS DEFECTION
>>
>>> For instance, you definition here of correct simulation means your
>>> results can not be used to show non-halting.
>> WE CAN GET TO THIS POINT AFTER WE FINISH THE SUBJECT OF THE THREAD
>> I DON'T HAVE ENOUGH TIME LEFT TO TOLERATE ENDLESS DEFECTION
>
> How ironic. You would get further if you didn’t impose this roadblock.
>
Dialogue on the subject since 2004 has proven that unless I prevent it
the endless change-the-subject form of strawman deception fake rebuttal
will permanently prevent closure on this.
>>> My guess is in a later section, you will pull out the rule that if a
>>> correct simulation doesn't reach a final state, the input is
>>> non-halting, which is just a LIE because you have changed definition mid
>>> proof.
>>> This has been your history.
> Quoted for posterity.
>
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-05-22 19:01 -0400 |
| Subject | Re: Every D correctly simulated by H remains stuck in recursive simulation |
| Message-ID | <v2ltgr$1nrfv$3@i2pn2.org> |
| In reply to | #105392 |
On 5/22/24 11:41 AM, olcott wrote:
> On 5/22/2024 5:26 AM, joes wrote:
>> Am Tue, 21 May 2024 21:05:51 -0500 schrieb olcott:
>>> On 5/21/2024 8:46 PM, Richard Damon wrote:
>>>> On 5/21/24 10:22 AM, olcott wrote:
>>>>> On 5/21/2024 7:03 AM, Richard Damon wrote:
>>>>>> On 5/21/24 1:18 AM, olcott wrote:
>>>>>>> On 5/20/2024 9:39 PM, Richard Damon wrote:
>>>>>>>> On 5/20/24 10:25 PM, olcott wrote:
>>>>>>>>> On 5/20/2024 7:57 PM, Richard Damon wrote:
>>>>>>>>>> On 5/20/24 2:03 PM, olcott wrote:
>>>>>>>>>>> On 5/20/2024 6:24 AM, Richard Damon wrote:
>>>>>>>>>>>> On 5/19/24 11:22 PM, olcott wrote:
>>>>>>>>>>>>> On 5/19/2024 10:11 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 5/19/24 10:52 PM, olcott wrote:
>>>>>>>>>>>>>>> On 5/19/2024 8:10 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 5/19/24 8:06 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 5/1/2024 7:10 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>
>>>> No, but it is impossible for a pure function H to correctly simulate
>>>> this D built on that H by the definition of Computation Theory AND
>>>> provide an answer.
>>> At this point we are only looking at H as a simulator.
>>> We can have this H return the meaningless 56.
>>
>> It must return the same value as its input would, or else run
>> indefinitely.
>>
>
> typedef int (*ptr)(); // ptr is pointer to int function in C
> 00 int H(ptr p, ptr i);
> 01 int D(ptr p)
> 02 {
> 03 int Halt_Status = H(p, p);
> 04 if (Halt_Status)
> 05 HERE: goto HERE;
> 06 return Halt_Status;
> 07 }
> 08
> 09 int main()
> 10 {
> 11 H(D,D);
> 12 return 0;
> 13 }
>
>
> I am just trying to get people to understand that for the infinite set
> of H/D pairs matching the above template where D is correctly simulated
> by pure function H that no D correctly simulated by pure function H can
> possibly reach its own line 06 and halt because every D remains stuck in
> recursive simulation.
But it CAN reach its final state when run or actaully completely and
correctly simulated by a real simulator (and not changed)
Your problem is that you definition of "Correct Simulation" and that of
a simulation that actually says something about non-halting are
different, so you can't use yours to reason about the other.
>
>>>> "Correct Simulation" to show something about non-termination, must be
>>>> per the methods of Computation Theory, which means like a UTM, which
>>>> means it does not stop.
>>> It is essentially trivial to see that D correctly simulated by H
>>> cannot possibly reach its own final state at line 06 because
>>> D correctly simulated by H remains stuck in recursive simulation.
>>
>> This is much more understandable now that you added a reason. However,
>> if one of those simulations aborts (because it detects infinite
>> recursion),
>> all of them must (because they are the same), making the abortion wrong.
>> This is the whole argument.
>>
>
> *Halting means reaching a final state*
> No D correctly simulated by pure function H can possibly reach its own
> final state at line 06 halt because every D remains stuck in recursive
> simulation.
But it CAN reach its final state when run or actaully completely and
correctly simulated by a real simulator (and not changed)
Your problem is that you definition of "Correct Simulation" and that of
a simulation that actually says something about non-halting are
different, so you can't use yours to reason about the other.
>
>>>> Note also, a "Pure Function" and this algorithm are NOT exactly
>>>> equivalent. Pure Function might take a hidden input that makes
>>>> copies of
>>>> the function not equivalent, breaking them form being the requirements
>>>> of an algorithm, which is a bit stricter, as it requires that ALL
>>>> COPIES
>>>> return the same answer for the same inputs.
>>> These H/D pairs only simulate.
>>
>> No, they also recognise infinite recursion and abort, thus behaving
>> differently (namely, terminating).
>>
>
> *Halting means reaching a final state*
> No D correctly simulated by pure function H can possibly reach its own
> final state at line 06 halt because every D remains stuck in recursive
> simulation.
BBut it CAN reach its final state when run or actaully completely and
correctly simulated by a real simulator (and not changed)
Your problem is that you definition of "Correct Simulation" and that of
a simulation that actually says something about non-halting are
different, so you can't use yours to reason about the other.
>
>>>>>>> The tiniest little divergence from the title of this
>>>>>>> thread and I totally ignore and erase everything else
>>>>>>> that you say.
>> > Very constructive.
>>
>
> Because of my POD24 diagnosis I do not have time for the endless
> change-the-subject strawman deception form of rebuttal that wasted
> fifteen years with Ben Bacarisse.
>
> The subject is the title of this thread.
> This can be exhaustively analyzed in finite time.
>
> Expanding its scope a tiny little bit can increase the
> time required beyond finite.
So, why are you hot working on handling the issues to allow you
discussion to move forwards, instead of dragging your heals.
I know, because you know you don't actually have anything that works, so
you hope to tire some out enough to mistaken agree to your ill defined
statement to allow you to form your fabrication of a unsound proof.
>
>>>>>> And if you can't actually define your category or the thing to be
>>>>>> analyzied you are just wasting your time, as if you don't know where
>>>>>> you are going, it is hard to find the path.
>>>>> The way I see it I defined it correctly and completely and you
>>>>> are simply pretending otherwise. Until you prove otherwise I
>>>>> will continue to assume this.
>>
>> If you think we are pretending, why bother?
>
> I must address every rebuttal, even fake rebuttals or people
> reviewing this after my death will be lead to believe that the
> fake rebuttal was valid.
So, you have a quandry, if you need to answer them, then you should and
not just drag your heals.
you have built up a LONG list of rebuttals that you haven't actually
answere, but just restated your origianl idea that had the fault found
in it.
That is NOT a rebutal, and when you are gone, people will see how stupid
your idea was, and how little you knew.
>
>>>> But since you can't clearly state it, it means we can't help you.
>>> I stated it perfectly and the proof of this is that
>>> you did not point to any gaps in my spec.
>>
>>>>> You seem to favor baseless rhetoric because you know that baseless
>>>>> rhetoric with ad hominem mixed in is very convincing for gullible
>>>>> fools.
>>>>> Gullible fools are outside of my target audience.
>>>> Nope, your deception seems to be an attempt to go after gullible fools.
>>> THE ONLY REASON THAT I WORK ON THIS IS TO MATHEMATICALLY
>>> FORMALIZE THE NOTION OF TRUTH ITSELF SO THAT THE NAZI
>>> LIARS CANNOT GET AWAY WITH THEIR LIES.
>>
>> As if they would care.
>>
>
> They will care when their Nazi styled "big lie" propaganda
> turns against them and causes their own downfall.
No, but you are just trying to use that "Big Lie" method.
>
>>>> If you where honest, you could post you whole arguement and let it be
>>>> worked on.
>>> WE ARE ONLY TALKING ABOUT THE SUBJECT LINE OF THIS THREAD.
>>
>>>> From your past, the reason you need to break the arguement into
>>>> pieces
>>>> is you need to seperate to logic to allow a change of definition
>>>> between
>>>> the sections.
>>> IT IS BECAUSE I DON'T HAVE ENOUGH TIME LEFT TO TOLERATE
>>> ENDLESS DEFECTION
>>>
>>>> For instance, you definition here of correct simulation means your
>>>> results can not be used to show non-halting.
>>> WE CAN GET TO THIS POINT AFTER WE FINISH THE SUBJECT OF THE THREAD
>>> I DON'T HAVE ENOUGH TIME LEFT TO TOLERATE ENDLESS DEFECTION
>>
>> How ironic. You would get further if you didn’t impose this roadblock.
>>
>
> Dialogue on the subject since 2004 has proven that unless I prevent it
> the endless change-the-subject form of strawman deception fake rebuttal
> will permanently prevent closure on this.
No, you have shown that you don't understand what you are talking about.
>
>>>> My guess is in a later section, you will pull out the rule that if a
>>>> correct simulation doesn't reach a final state, the input is
>>>> non-halting, which is just a LIE because you have changed definition
>>>> mid
>>>> proof.
>>>> This has been your history.
>> Quoted for posterity.
>>
>
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-05-22 21:15 -0500 |
| Subject | Re: Every D correctly simulated by H remains stuck in recursive simulation |
| Message-ID | <v2m8s8$1ievj$2@dont-email.me> |
| In reply to | #105407 |
On 5/22/2024 6:01 PM, Richard Damon wrote:
> On 5/22/24 11:41 AM, olcott wrote:
>>
>> typedef int (*ptr)(); // ptr is pointer to int function in C
>> 00 int H(ptr p, ptr i);
>> 01 int D(ptr p)
>> 02 {
>> 03 int Halt_Status = H(p, p);
>> 04 if (Halt_Status)
>> 05 HERE: goto HERE;
>> 06 return Halt_Status;
>> 07 }
>> 08
>> 09 int main()
>> 10 {
>> 11 H(D,D);
>> 12 return 0;
>> 13 }
>>
>>
>> I am just trying to get people to understand that for the infinite set
>> of H/D pairs matching the above template where D is correctly simulated
>> by pure function H that no D correctly simulated by pure function H can
>> possibly reach its own line 06 and halt because every D remains stuck in
>> recursive simulation.
>
> But it CAN reach its final state when run or actaully completely and
> correctly simulated by a real simulator (and not changed)
>
> Your problem is that you definition of "Correct Simulation" and that of
> a simulation that actually says something about non-halting are
> different, so you can't use yours to reason about the other.
>
*You are violating this definition*
*CORRECT SIMULATION DEFINED*
In the above case a simulator is an x86 emulator that correctly
emulates at least one of the x86 instructions of D in the order
specified by the x86 instructions of D.
This may include correctly emulating the x86 instructions of H in the
order specified by the x86 instructions of H thus calling H(D,D) in
recursive simulation.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-05-22 22:36 -0400 |
| Subject | Re: Every D correctly simulated by H remains stuck in recursive simulation |
| Message-ID | <v2ma2p$1qo0t$4@i2pn2.org> |
| In reply to | #105415 |
On 5/22/24 10:15 PM, olcott wrote:
> On 5/22/2024 6:01 PM, Richard Damon wrote:
>> On 5/22/24 11:41 AM, olcott wrote:
>>>
>>> typedef int (*ptr)(); // ptr is pointer to int function in C
>>> 00 int H(ptr p, ptr i);
>>> 01 int D(ptr p)
>>> 02 {
>>> 03 int Halt_Status = H(p, p);
>>> 04 if (Halt_Status)
>>> 05 HERE: goto HERE;
>>> 06 return Halt_Status;
>>> 07 }
>>> 08
>>> 09 int main()
>>> 10 {
>>> 11 H(D,D);
>>> 12 return 0;
>>> 13 }
>>>
>>>
>>> I am just trying to get people to understand that for the infinite set
>>> of H/D pairs matching the above template where D is correctly simulated
>>> by pure function H that no D correctly simulated by pure function H can
>>> possibly reach its own line 06 and halt because every D remains stuck in
>>> recursive simulation.
>>
>> But it CAN reach its final state when run or actaully completely and
>> correctly simulated by a real simulator (and not changed)
>>
>> Your problem is that you definition of "Correct Simulation" and that
>> of a simulation that actually says something about non-halting are
>> different, so you can't use yours to reason about the other.
>>
> *You are violating this definition*
>
> *CORRECT SIMULATION DEFINED*
> In the above case a simulator is an x86 emulator that correctly
> emulates at least one of the x86 instructions of D in the order
> specified by the x86 instructions of D.
>
> This may include correctly emulating the x86 instructions of H in the
> order specified by the x86 instructions of H thus calling H(D,D) in
> recursive simulation.
>
Nope, YOU are violating the definition of Correct Simulation that
relates a simulation to machine behavior.
Thus, you can claim all you want about your simulations, but you have
FOREVER disconnected your concept of simulation from the behavior of the
machine simulated, so you have no path to talking about "Halting".
Only by LYING and using contradictory definitions at the same time can
you even try.
You are just proving you don't understand how logic works.
You are just proving that your native tounge is the LIE.
That is why you need to formally and completely define your term, so
that your errors can be pointed out and deflected BEFORE you get an
agreement on a statement you can twist.
[toc] | [prev] | [next] | [standalone]
| From | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2024-05-22 09:52 +0200 |
| Subject | Re: Every D correctly simulated by H cannot possibly reach its own line 06 and halt |
| Message-ID | <v2k87j$12v0u$1@dont-email.me> |
| In reply to | #105381 |
Op 22.mei.2024 om 04:05 schreef olcott:
> On 5/21/2024 8:46 PM, Richard Damon wrote:
>> On 5/21/24 10:22 AM, olcott wrote:
>>> On 5/21/2024 7:03 AM, Richard Damon wrote:
>>>> On 5/21/24 1:18 AM, olcott wrote:
>>>>> On 5/20/2024 9:39 PM, Richard Damon wrote:
>>>>>> On 5/20/24 10:25 PM, olcott wrote:
>>>>>>> On 5/20/2024 7:57 PM, Richard Damon wrote:
>>>>>>>> On 5/20/24 2:03 PM, olcott wrote:
>>>>>>>>> On 5/20/2024 6:24 AM, Richard Damon wrote:
>>>>>>>>>> On 5/19/24 11:22 PM, olcott wrote:
>>>>>>>>>>> On 5/19/2024 10:11 PM, Richard Damon wrote:
>>>>>>>>>>>> On 5/19/24 10:52 PM, olcott wrote:
>>>>>>>>>>>>> On 5/19/2024 8:10 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 5/19/24 8:06 PM, olcott wrote:
>>>>>>>>>>>>>>> On 5/1/2024 7:10 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> typedef int (*ptr)(); // ptr is pointer to int function
>>>>>>>>>>>>>>> 00 int H(ptr p, ptr i);
>>>>>>>>>>>>>>> 01 int D(ptr p)
>>>>>>>>>>>>>>> 02 {
>>>>>>>>>>>>>>> 03 int Halt_Status = H(p, p);
>>>>>>>>>>>>>>> 04 if (Halt_Status)
>>>>>>>>>>>>>>> 05 HERE: goto HERE;
>>>>>>>>>>>>>>> 06 return Halt_Status;
>>>>>>>>>>>>>>> 07 }
>>>>>>>>>>>>>>> 08
>>>>>>>>>>>>>>> 09 int main()
>>>>>>>>>>>>>>> 10 {
>>>>>>>>>>>>>>> 11 H(D,D);
>>>>>>>>>>>>>>> 12 return 0;
>>>>>>>>>>>>>>> 13 }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> In the above case a simulator is an x86 emulator that
>>>>>>>>>>>>>>> correctly emulates at least one of the x86 instructions
>>>>>>>>>>>>>>> of D in the order specified by the x86 instructions of D.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This may include correctly emulating the x86 instructions
>>>>>>>>>>>>>>> of H in the order specified by the x86 instructions of H
>>>>>>>>>>>>>>> thus calling H(D,D) in recursive simulation.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> For every H/D pair of the above template D correctly
>>>>>>>>>>>>>>> simulated by
>>>>>>>>>>>>>>> *pure function* H cannot possibly reach its own final
>>>>>>>>>>>>>>> state at
>>>>>>>>>>>>>>> line 06 and halt.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Ok, so adding that H is a pure function, that means that
>>>>>>>>>>>>>> since your outer H(D,D) is going to return 0, all logic
>>>>>>>>>>>>>> must be compatible with the fact that EVERY call to H(D,D)
>>>>>>>>>>>>>> will also eventually return 0.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Remember also, THIS D is defined to call THIS H, that does
>>>>>>>>>>>>>> exactly the same as the H that is deciding it.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> OK, good.
>>>>>>>>>>>>
>>>>>>>>>>>> Right, so it doesn't matter what any other D does, it
>>>>>>>>>>>> matters what THIS D does, and this D calls aths H.
>>>>>>>>>>>>
>>>>>>>>>>>> Remember, you reinstated the Computation model by enforcing
>>>>>>>>>>>> Pure Functions.
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> <snip so that Message ID links to whole message>
>>>>>>>>>>>>>>> We can use my unique time/date stamp as an alternative.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Remember, YOU are the one saying you are needing to
>>>>>>>>>>>>>>>> change the definition from the classical theory, where
>>>>>>>>>>>>>>>> we have things well defined.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> YOU have decider that H is just whatever C code you want
>>>>>>>>>>>>>>>> to write for it, and D is the input proved. (which
>>>>>>>>>>>>>>>> doesn't actually match the Linz or Sipser proof, but
>>>>>>>>>>>>>>>> fairly close).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> With THAT set of definitions we have a lot of options
>>>>>>>>>>>>>>>> that break your incorrectly assumed results.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The first method has been discussed here by Flibble.
>>>>>>>>>>>>>>>> While the final answer he got to doesn't fit the
>>>>>>>>>>>>>>>> requirements, the first part of the method DOES show
>>>>>>>>>>>>>>>> that it is possible for an H to simulate to past line 3.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> THe basic idea is that if H(M,d) finds that its
>>>>>>>>>>>>>>>> simulation of M(d) get to a call to H(M,d) then rather
>>>>>>>>>>>>>>>> that your idea of just saying it will get stuck and
>>>>>>>>>>>>>>>> declair the input invalid, since there ARE a number of
>>>>>>>>>>>>>>>> possible inputs that there is a "correct" answer that H
>>>>>>>>>>>>>>>> can give to
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> That D is calling H does not prove recursive simulation.
>>>>>>>>>>>>>>> That D is calling H with its same parameters does seem
>>>>>>>>>>>>>>> to prove non-halting recursive simulation.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Nope. Try to actuall PROVE it.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> That is off-topic for this post.
>>>>>>>>>>>>> All that we need know is that no D simulated by any H
>>>>>>>>>>>>> ever reaches its own line 06 and halts.
>>>>>>>>>>>>
>>>>>>>>>>>> Nope. Make a claim, you need to prove it.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> *In other different post not this one*
>>>>>>>>>>>
>>>>>>>>>>> I am using categorically exhaustive reasoning that can work
>>>>>>>>>>> through every possibility that can possibly exist in a feasible
>>>>>>>>>>> amount of time as long as the category is very very narrow.
>>>>>>>>>>
>>>>>>>>>> But you can't PRECISELY define the category, or what you want
>>>>>>>>>> to reason about, so your logic is worthless as it is baseless.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> *POINT TO ANY ACTUAL MISTAKE OR AMBIGUITY WITH THIS VERSION*
>>>>>>>>>
>>>>>>>>> typedef int (*ptr)(); // ptr is pointer to int function
>>>>>>>>> 00 int H(ptr p, ptr i);
>>>>>>>>> 01 int D(ptr p)
>>>>>>>>> 02 {
>>>>>>>>> 03 int Halt_Status = H(p, p);
>>>>>>>>> 04 if (Halt_Status)
>>>>>>>>> 05 HERE: goto HERE;
>>>>>>>>> 06 return Halt_Status;
>>>>>>>>> 07 }
>>>>>>>>> 08
>>>>>>>>> 09 int main()
>>>>>>>>> 10 {
>>>>>>>>> 11 H(D,D);
>>>>>>>>> 12 return 0;
>>>>>>>>> 13 }
>>>>>>>>>
>>>>>>>>> In the above case a simulator is an x86 emulator that correctly
>>>>>>>>> emulates at least one of the x86 instructions of D in the order
>>>>>>>>> specified by the x86 instructions of D.
>>>>>>>>>
>>>>>>>>> This may include correctly emulating the x86 instructions of H
>>>>>>>>> in the order specified by the x86 instructions of H thus
>>>>>>>>> calling H(D,D) in recursive simulation.
>>>>>>>>>
>>>>>>>>> Execution Trace
>>>>>>>>> Line 11: main() invokes H(D,D);
>>>>>>>>>
>>>>>>>>> keeps repeating (unless aborted)
>>>>>>>>> Line 01:
>>>>>>>>> Line 02:
>>>>>>>>> Line 03: simulated D(D) invokes simulated H(D,D) that simulates
>>>>>>>>> D(D)
>>>>>>>>>
>>>>>>>>> Simulation invariant:
>>>>>>>>> D correctly simulated by H cannot possibly reach past its own
>>>>>>>>> line 03.
>>>>>>>>>
>>>>>>>>> For every H/D pair of the above template D correctly simulated
>>>>>>>>> by pure function (thus computable function) H cannot possibly
>>>>>>>>> reach its own final state at line 06 and halt.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Which thus doesn't correct simulate the call to H
>>>>>>>
>>>>>>> *Counter-factual, try again*
>>>>>>> We are not talking about any of your misconceptions the term:
>>>>>>> "simulate" is expressly defined.
>>>>>>
>>>>>> And how did your H "Correctly" simulate the call to H?
>>>>>>
>>>>>
>>>>> That does not matter as long as it is not impossible.
>>>>
>>>> But since you claim you did it, you need to show what you did.
>>>>
>>>
>>> I cannot show the behavior of every element of an infinite set
>>> a c function pairs.
>>
>> So, didn't you say that needing infinite operations to evaluate made
>> something not a truth beared?
>>
>>>
>>>> The problem is you don't seem to understand that somethings ARE
>>>> impossible.
>>>>
>>>
>>> It is certainly not impossible for pure function H to correctly
>>> simulate D.
>>
>> No, but it is impossible for a pure function H to correctly simulate
>> this D built on that H by the definition of Computation Theory AND
>> provide an answer.
>>
>
> At this point we are only looking at H as a simulator.
> We can have this H return the meaningless 56.
>
>>>
>>>> Like building a Turing Machine that always correctly determines if
>>>> another Turing Machine/Input combination will halt.
>>>>
>>>> Your claims that you make one that answers the proof case, is just
>>>> proven to be a lie, and your proof is based on first assuming it is
>>>> possible and then using that "fact" to try to prove your answer,
>>>> which is just the thing you claim you are not allowed to do.
>>>>
>>>
>>> In the last two years I have not even exaggerated.
>>> Lets call a truce on accusations of lying you eventually
>>> proved that you were not lying about this key point and I
>>> updated my spec to address the issue that you raised.
>>
>> Really, how many times did you say that I did not provide a counter
>> example?
>>
>
> You persistently did refuse to provide the message_ID
> this did make you look like a liar.
>
>>
>>
>>>
>>> I made sure to not call you a liar on this. I said that until
>>> proved otherwise I will assume that you are a liar and then
>>> you proved otherwise.
>>
>> But you continued to assert a statement that was untrue, even though
>> it was proved incorrect, you LATER changed your definition to try to
>> get around my answer,
>>
>
> You persistently did refuse to provide the message_ID
> this did make you look like a liar.
>
>> You still haven't refuted the first method.
>>
>
> Sure I have this H is ONLY simulator thus the first method
> loses its basis.
>
>>>
>>>> Thus, it is proven that you whole concept is just built on
>>>> inconsistant lies.
>>>>
>>>>>
>>>>>>>
>>>>>>> This is the only post about this subject that I will respond
>>>>>>> to from you. I have to paint half of my house and empty my
>>>>>>> garage within about a week.
>>>>>>>
>>>>>>> If you can find some source that conclusively proves that
>>>>>>> not all pure functions are computable functions I would like
>>>>>>> to see it. All of the experts that I could find seem to agree
>>>>>>> that all pure functions in C would be computable functions
>>>>>>> by a Turing machine.
>>>>>>
>>>>>> So, you just don't understand that "Computable Function" is a
>>>>>> Term-of-the-art to talk about the mathematical mapping, an NOT the
>>>>>> algorithm that shows the mapping is computable.
>>>>>>
>>>>>
>>>>> Pure functions <are> Turing computable functions until you
>>>>> conclusively prove otherwise.
>>>>
>>>> So, you still don't understand the meaning of the words.
>>>>
>>>
>>>
>>> Try and point out the specific error and I will correct any
>>> mistake that you find. Until you provide a basis I will assume
>>> that your claim is baseless.
>>
>> "Correct Simulation" to show something about non-termination, must be
>> per the methods of Computation Theory, which means like a UTM, which
>> means it does not stop.
>>
>
> It is essentially trivial to see that D correctly simulated by H
> cannot possibly reach its own final state at line 06 because
> D correctly simulated by H remains stuck in recursive simulation.
>
>> A "Computable Function" isn't a program, but a mathematical concept of
>> a mapping from the input set to the output set for which there exists
>> an finite algoritm that computes it. (The program is that algorithm,
>> not the Function).
>>
>
> How do we tell if a C function is Turing Computable?
>
>> Note also, a "Pure Function" and this algorithm are NOT exactly
>> equivalent. Pure Function might take a hidden input that makes copies
>> of the function not equivalent, breaking them form being the
>> requirements of an algorithm, which is a bit stricter, as it requires
>> that ALL COPIES return the same answer for the same inputs.
>>
>
> These H/D pairs only simulate.
>
>> Also, it is possible for an algorithm to violate the definiton of a
>> "Pure Function" in certain limited manners, and still be a proper
>> algorithm, the key is that the definition of an algorithm is a
>> strictly Input to Output relationship, and doesn't talk about how the
>> answer is given.
>>
>
> I am saying that it must be a pure function.
>
>>>
>>>> Your claim is like saying that cats are 10 story office building.
>>>>
>>>>>
>>>>>> One key point that make "Pure Functions" not necessarily
>>>>>> equivalent to a Turing Machine is the ability to get "hidden
>>>>>> inputs" from things like their own program address, something a
>>>>>> Turing Machine doesn't have.
>>>>>>
>>>>>
>>>>> *That is irrelevant to the current post*
>>>>> *You can always look at the title and see if you went off topic*
>>>>
>>>> No, you keep making the error, and thus destroy your arguement.
>>>>
>>>
>>> Since I am only responding to you via this single thread I
>>> don't have to cut off the first divergence from the title.
>>>
>>>>>
>>>>>
>>>>> *This boiler plate will be the only reply*
>>>>> I am using categorically exhaustive reasoning that can work
>>>>> through every possibility that can possibly exist in a feasible
>>>>> amount of time as long as the category is very very narrow.
>>>>>
>>>>> Enlarge the category a tiny little bit and then the time
>>>>> becomes infeasible.
>>>>>
>>>>> The tiniest little divergence from the title of this
>>>>> thread and I totally ignore and erase everything else
>>>>> that you say.
>>>>>
>>>>>
>>>>
>>>> And if you can't actually define your category or the thing to be
>>>> analyzied you are just wasting your time, as if you don't know where
>>>> you are going, it is hard to find the path.
>>>>
>>>
>>> The way I see it I defined it correctly and completely and you
>>> are simply pretending otherwise. Until you prove otherwise I
>>> will continue to assume this.
>>
>> But since you can't clearly state it, it means we can't help you.
>>
>
> I stated it perfectly and the proof of this is that
> you did not point to any gaps in my spec.
>
olcott seems to have problems with the meaning of the word 'proof'. If
nobody point to a gap, it is not a proof that no gaps exist.
Similarly for other cases: It is not a proof if nobody shows a
counter-example.
[toc] | [prev] | [next] | [standalone]
| From | joes <noreply@example.com> |
|---|---|
| Date | 2024-05-22 10:26 +0000 |
| Subject | Re: Every D correctly simulated by H cannot possibly reach its own line 06 and halt |
| Message-ID | <v2kh7o$1omk3$1@i2pn2.org> |
| In reply to | #105381 |
Am Tue, 21 May 2024 21:05:51 -0500 schrieb olcott: > On 5/21/2024 8:46 PM, Richard Damon wrote: >> On 5/21/24 10:22 AM, olcott wrote: >>> On 5/21/2024 7:03 AM, Richard Damon wrote: >>>> On 5/21/24 1:18 AM, olcott wrote: >>>>> On 5/20/2024 9:39 PM, Richard Damon wrote: >>>>>> On 5/20/24 10:25 PM, olcott wrote: >>>>>>> On 5/20/2024 7:57 PM, Richard Damon wrote: >>>>>>>> On 5/20/24 2:03 PM, olcott wrote: >>>>>>>>> On 5/20/2024 6:24 AM, Richard Damon wrote: >>>>>>>>>> On 5/19/24 11:22 PM, olcott wrote: >>>>>>>>>>> On 5/19/2024 10:11 PM, Richard Damon wrote: >>>>>>>>>>>> On 5/19/24 10:52 PM, olcott wrote: >>>>>>>>>>>>> On 5/19/2024 8:10 PM, Richard Damon wrote: >>>>>>>>>>>>>> On 5/19/24 8:06 PM, olcott wrote: >>>>>>>>>>>>>>> On 5/1/2024 7:10 PM, Richard Damon wrote: >>>>>>>>>>>>>>> >> No, but it is impossible for a pure function H to correctly simulate >> this D built on that H by the definition of Computation Theory AND >> provide an answer. > At this point we are only looking at H as a simulator. > We can have this H return the meaningless 56. It must return the same value as its input would, or else run indefinitely. >> "Correct Simulation" to show something about non-termination, must be >> per the methods of Computation Theory, which means like a UTM, which >> means it does not stop. > It is essentially trivial to see that D correctly simulated by H > cannot possibly reach its own final state at line 06 because > D correctly simulated by H remains stuck in recursive simulation. This is much more understandable now that you added a reason. However, if one of those simulations aborts (because it detects infinite recursion), all of them must (because they are the same), making the abortion wrong. This is the whole argument. >> Note also, a "Pure Function" and this algorithm are NOT exactly >> equivalent. Pure Function might take a hidden input that makes copies of >> the function not equivalent, breaking them form being the requirements >> of an algorithm, which is a bit stricter, as it requires that ALL COPIES >> return the same answer for the same inputs. > These H/D pairs only simulate. No, they also recognise infinite recursion and abort, thus behaving differently (namely, terminating). >>>>> The tiniest little divergence from the title of this >>>>> thread and I totally ignore and erase everything else >>>>> that you say. Very constructive. >>>> And if you can't actually define your category or the thing to be >>>> analyzied you are just wasting your time, as if you don't know where >>>> you are going, it is hard to find the path. >>> The way I see it I defined it correctly and completely and you >>> are simply pretending otherwise. Until you prove otherwise I >>> will continue to assume this. If you think we are pretending, why bother? >> But since you can't clearly state it, it means we can't help you. > I stated it perfectly and the proof of this is that > you did not point to any gaps in my spec. >>> You seem to favor baseless rhetoric because you know that baseless >>> rhetoric with ad hominem mixed in is very convincing for gullible fools. >>> Gullible fools are outside of my target audience. >> Nope, your deception seems to be an attempt to go after gullible fools. > THE ONLY REASON THAT I WORK ON THIS IS TO MATHEMATICALLY > FORMALIZE THE NOTION OF TRUTH ITSELF SO THAT THE NAZI > LIARS CANNOT GET AWAY WITH THEIR LIES. As if they would care. >> If you where honest, you could post you whole arguement and let it be >> worked on. > WE ARE ONLY TALKING ABOUT THE SUBJECT LINE OF THIS THREAD. >> From your past, the reason you need to break the arguement into pieces >> is you need to seperate to logic to allow a change of definition between >> the sections. > IT IS BECAUSE I DON'T HAVE ENOUGH TIME LEFT TO TOLERATE > ENDLESS DEFECTION > >> For instance, you definition here of correct simulation means your >> results can not be used to show non-halting. > WE CAN GET TO THIS POINT AFTER WE FINISH THE SUBJECT OF THE THREAD > I DON'T HAVE ENOUGH TIME LEFT TO TOLERATE ENDLESS DEFECTION How ironic. You would get further if you didn’t impose this roadblock. >> My guess is in a later section, you will pull out the rule that if a >> correct simulation doesn't reach a final state, the input is >> non-halting, which is just a LIE because you have changed definition mid >> proof. >> This has been your history. Quoted for posterity. -- joes
[toc] | [prev] | [next] | [standalone]
| From | immibis <news@immibis.com> |
|---|---|
| Date | 2024-05-20 13:31 +0200 |
| Subject | Re: Can D simulated by H terminate normally? Message_ID Provided V2 |
| Message-ID | <v2fcag$3v3p1$2@dont-email.me> |
| In reply to | #105267 |
On 20/05/24 05:11, Richard Damon wrote: > Nope. Make a claim, you need to prove it. You just made a claim. Prove that he needs to prove it.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-05-20 10:23 -0500 |
| Subject | Re: Can D simulated by H terminate normally? Message_ID Provided V2 |
| Message-ID | <v2fpt4$1pfh$6@dont-email.me> |
| In reply to | #105286 |
On 5/20/2024 6:31 AM, immibis wrote:
> On 20/05/24 05:11, Richard Damon wrote:
>> Nope. Make a claim, you need to prove it.
>
> You just made a claim. Prove that he needs to prove it.
I cannot prove verified facts to liars or to people having insufficient
knowledge of the semantics of the C programming language.
The halt status of the following C functions is entirely self-evident
to anyone having sufficient knowledge of the semantics of the C
programming language.
void Infinite_Recursion(u32 N)
{
Infinite_Recursion(N);
}
int factorial(int n) // called with 5
{
if (n >= 1)
return n*factorial(n-1);
else
return 1;
}
void Infinite_Loop()
{
HERE: goto HERE;
}
void This_Halts()
{
return;
}
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
Page 7 of 18 — ← Prev page 1 … 5 6 [7] 8 9 … 18 Next page →
Back to top | Article view | comp.theory
csiph-web