Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.theory > #106862 > unrolled thread
| Started by | olcott <polcott333@gmail.com> |
|---|---|
| First post | 2024-06-09 22:54 -0500 |
| Last post | 2024-06-12 08:24 +0200 |
| Articles | 20 on this page of 373 — 11 participants |
Back to article view | Back to comp.theory
Re: D correctly simulated by H proved for THREE YEARS --- olcott <polcott333@gmail.com> - 2024-06-09 22:54 -0500
Re: D correctly simulated by H proved for THREE YEARS --- joes <noreply@example.com> - 2024-06-10 08:35 +0000
Re: D correctly simulated by H proved for THREE YEARS --- Mikko <mikko.levanto@iki.fi> - 2024-06-10 12:59 +0300
Re: D correctly simulated by H proved for THREE YEARS --- olcott <polcott333@gmail.com> - 2024-06-10 10:33 -0500
Re: D correctly simulated by H proved for THREE YEARS --- Mikko <mikko.levanto@iki.fi> - 2024-06-11 12:00 +0300
Re: D correctly simulated by H proved for THREE YEARS --- rewritten olcott <polcott333@gmail.com> - 2024-06-11 12:10 -0500
Re: D correctly simulated by H proved for THREE YEARS --- olcott <polcott333@gmail.com> - 2024-06-10 09:36 -0500
Re: D correctly simulated by H proved for THREE YEARS --- joes <noreply@example.com> - 2024-06-10 15:25 +0000
Re: D correctly simulated by H proved for THREE YEARS --- olcott <polcott333@gmail.com> - 2024-06-10 10:36 -0500
Re: D simulated by H unproved for THREE YEARS --- joes <noreply@example.com> - 2024-06-10 17:06 +0000
Re: D simulated by H unproved for THREE YEARS --- olcott <polcott333@gmail.com> - 2024-06-10 12:31 -0500
Re: D correctly simulated by H proved for THREE YEARS --- Richard Damon <richard@damon-family.org> - 2024-06-10 07:16 -0400
Re: D correctly simulated by H proved for THREE YEARS --- Richard admits his error olcott <polcott333@gmail.com> - 2024-06-10 21:06 -0500
Re: D correctly simulated by H proved for THREE YEARS --- Richard admits his error Richard Damon <richard@damon-family.org> - 2024-06-10 23:32 -0400
Re: D correctly simulated by H proved for THREE YEARS --- Richard admits his error olcott <polcott333@gmail.com> - 2024-06-10 23:31 -0500
Re: D correctly simulated by H proved for THREE YEARS --- Richard admits his error Richard Damon <richard@damon-family.org> - 2024-06-11 07:47 -0400
Re: D correctly simulated by H proved for THREE YEARS --- rewritten olcott <polcott333@gmail.com> - 2024-06-11 12:12 -0500
Re: D correctly simulated by H proved for THREE YEARS --- rewritten Richard Damon <richard@damon-family.org> - 2024-06-11 18:47 -0400
Re: D correctly simulated by H proved for THREE YEARS --- rewritten olcott <polcott333@gmail.com> - 2024-06-11 18:23 -0500
Re: D correctly simulated by H proved for THREE YEARS --- rewritten Python <python@invalid.org> - 2024-06-12 02:20 +0200
Re: D correctly simulated by H proved for THREE YEARS --- rewritten olcott <polcott333@gmail.com> - 2024-06-11 19:57 -0500
Re: D correctly simulated by H proved for THREE YEARS --- rewritten Richard Damon <richard@damon-family.org> - 2024-06-11 22:32 -0400
Re: D correctly simulated by H proved for THREE YEARS --- rewritten olcott <polcott333@gmail.com> - 2024-06-11 22:34 -0500
Re: D correctly simulated by H proved for THREE YEARS --- rewritten Richard Damon <richard@damon-family.org> - 2024-06-12 07:33 -0400
Re: D correctly simulated by H proved for THREE YEARS --- finite string transformation rules olcott <polcott333@gmail.com> - 2024-06-12 11:50 -0500
Re: D correctly simulated by H proved for THREE YEARS --- finite string transformation rules Richard Damon <richard@damon-family.org> - 2024-06-12 18:59 -0400
Re: D correctly simulated by H proved for THREE YEARS --- finite string transformation rules olcott <polcott333@gmail.com> - 2024-06-12 18:12 -0500
Re: D correctly simulated by H proved for THREE YEARS --- finite string transformation rules Richard Damon <richard@damon-family.org> - 2024-06-12 19:41 -0400
Re: D correctly simulated by H proved for THREE YEARS --- finite string transformation rules olcott <polcott333@gmail.com> - 2024-06-12 18:53 -0500
Re: D correctly simulated by H proved for THREE YEARS --- finite string transformation rules Richard Damon <richard@damon-family.org> - 2024-06-12 20:37 -0400
Re: D correctly simulated by H proved for THREE YEARS --- finite string transformation rules olcott <polcott333@gmail.com> - 2024-06-12 20:19 -0500
Re: D correctly simulated by H proved for THREE YEARS --- finite string transformation rules Richard Damon <richard@damon-family.org> - 2024-06-12 21:50 -0400
Re: D correctly simulated by H proved for THREE YEARS --- finite string transformation rules olcott <polcott333@gmail.com> - 2024-06-12 20:54 -0500
Re: D correctly simulated by H proved for THREE YEARS --- finite string transformation rules Richard Damon <richard@damon-family.org> - 2024-06-12 22:06 -0400
Re: D correctly simulated by H proved for THREE YEARS --- finite string transformation rules olcott <polcott333@gmail.com> - 2024-06-12 21:21 -0500
Re: D correctly simulated by H proved for THREE YEARS --- finite string transformation rules Richard Damon <richard@damon-family.org> - 2024-06-12 22:57 -0400
Re: D correctly simulated by H proved for THREE YEARS --- finite string transformation rules olcott <polcott333@gmail.com> - 2024-06-12 22:24 -0500
Re: D correctly simulated by H proved for THREE YEARS --- finite string transformation rules Richard Damon <richard@damon-family.org> - 2024-06-12 23:45 -0400
Re: D correctly simulated by H proved for THREE YEARS --- finite string transformation rules olcott <polcott333@gmail.com> - 2024-06-12 22:58 -0500
Re: D correctly simulated by H proved for THREE YEARS --- finite string transformation rules Richard Damon <richard@damon-family.org> - 2024-06-13 07:31 -0400
Re: D correctly simulated by H proved for THREE YEARS --- finite string transformation rules olcott <polcott333@gmail.com> - 2024-06-13 10:32 -0500
Re: D correctly simulated by H proved for THREE YEARS --- finite string transformation rules joes <noreply@example.com> - 2024-06-13 17:34 +0000
Re: D correctly simulated by H proved for THREE YEARS --- finite string transformation rules Richard Damon <richard@damon-family.org> - 2024-06-13 21:24 -0400
Re: D correctly simulated by H proved for THREE YEARS --- finite string transformation rules olcott <polcott333@gmail.com> - 2024-06-13 20:39 -0500
Re: D correctly simulated by H proved for THREE YEARS --- finite string transformation rules Richard Damon <richard@damon-family.org> - 2024-06-13 23:04 -0400
H(D,D) cannot even be asked about the behavior of D(D) olcott <polcott333@gmail.com> - 2024-06-13 22:14 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) Richard Damon <richard@damon-family.org> - 2024-06-13 23:44 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) olcott <polcott333@gmail.com> - 2024-06-13 23:13 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) Richard Damon <richard@damon-family.org> - 2024-06-14 07:39 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) olcott <polcott333@gmail.com> - 2024-06-14 08:15 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) joes <noreply@example.com> - 2024-06-14 15:54 +0000
Re: H(D,D) cannot even be asked about the behavior of D(D) olcott <polcott333@gmail.com> - 2024-06-14 12:39 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) Richard Damon <richard@damon-family.org> - 2024-06-14 19:27 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) joes <noreply@example.com> - 2024-06-15 11:34 +0000
Re: H(D,D) cannot even be asked about the behavior of D(D) olcott <polcott333@gmail.com> - 2024-06-15 07:21 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) Richard Damon <richard@damon-family.org> - 2024-06-15 09:52 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) Mikko <mikko.levanto@iki.fi> - 2024-06-15 15:33 +0300
Re: H(D,D) cannot even be asked about the behavior of D(D) olcott <polcott333@gmail.com> - 2024-06-15 08:24 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) Richard Damon <richard@damon-family.org> - 2024-06-15 09:51 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) Mikko <mikko.levanto@iki.fi> - 2024-06-16 12:15 +0300
Re: H(D,D) cannot even be asked about the behavior of D(D) olcott <polcott333@gmail.com> - 2024-06-16 07:59 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) Mikko <mikko.levanto@iki.fi> - 2024-06-17 10:10 +0300
Re: H(D,D) cannot even be asked about the behavior of D(D) olcott <polcott333@gmail.com> - 2024-06-17 07:51 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) Mikko <mikko.levanto@iki.fi> - 2024-06-18 10:44 +0300
Re: H(D,D) cannot even be asked about the behavior of D(D) olcott <polcott333@gmail.com> - 2024-06-18 07:46 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) Mikko <mikko.levanto@iki.fi> - 2024-06-18 18:36 +0300
Re: H(D,D) cannot even be asked about the behavior of D(D) olcott <polcott333@gmail.com> - 2024-06-18 10:44 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) Mikko <mikko.levanto@iki.fi> - 2024-06-18 19:27 +0300
Re: H(D,D) cannot even be asked about the behavior of D(D) olcott <polcott333@gmail.com> - 2024-06-18 11:36 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) Mikko <mikko.levanto@iki.fi> - 2024-06-19 11:07 +0300
Re: H(D,D) cannot even be asked about the behavior of D(D) olcott <polcott333@gmail.com> - 2024-06-19 08:37 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) Mikko <mikko.levanto@iki.fi> - 2024-06-20 08:04 +0300
Re: H(D,D) cannot even be asked about the behavior of D(D) olcott <polcott333@gmail.com> - 2024-06-20 00:15 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) Mikko <mikko.levanto@iki.fi> - 2024-06-20 17:42 +0300
Re: H(D,D) cannot even be asked about the behavior of D(D) olcott <polcott333@gmail.com> - 2024-06-20 10:04 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) joes <noreply@example.com> - 2024-06-20 16:16 +0000
Re: H(D,D) cannot even be asked about the behavior of D(D) olcott <polcott333@gmail.com> - 2024-06-20 11:28 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-21 10:05 +0200
Re: H(D,D) cannot even be asked about the behavior of D(D) olcott <polcott333@gmail.com> - 2024-06-21 08:13 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) Richard Damon <richard@damon-family.org> - 2024-06-21 10:27 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) Richard Damon <richard@damon-family.org> - 2024-06-20 21:55 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) olcott <polcott333@gmail.com> - 2024-06-20 21:04 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) Richard Damon <richard@damon-family.org> - 2024-06-20 22:38 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Boilerplate Reply olcott <polcott333@gmail.com> - 2024-06-20 21:46 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Boilerplate Reply Richard Damon <richard@damon-family.org> - 2024-06-20 22:59 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Boilerplate Reply olcott <polcott333@gmail.com> - 2024-06-20 22:30 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Boilerplate Reply Richard Damon <richard@damon-family.org> - 2024-06-20 23:52 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Boilerplate Reply olcott <polcott333@gmail.com> - 2024-06-20 23:01 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Boilerplate Reply Richard Damon <richard@damon-family.org> - 2024-06-21 10:36 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Boilerplate Reply olcott <polcott333@gmail.com> - 2024-06-21 11:56 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Boilerplate Reply Richard Damon <richard@damon-family.org> - 2024-06-21 13:06 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Boilerplate Reply olcott <polcott333@gmail.com> - 2024-06-21 12:16 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Boilerplate Reply Richard Damon <richard@damon-family.org> - 2024-06-21 13:26 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Boilerplate Reply olcott <polcott333@gmail.com> - 2024-06-21 12:38 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Boilerplate Reply Richard Damon <richard@damon-family.org> - 2024-06-21 13:52 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Boilerplate Reply olcott <polcott333@gmail.com> - 2024-06-21 13:18 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Boilerplate Reply Richard Damon <richard@damon-family.org> - 2024-06-21 14:42 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Boilerplate Reply olcott <polcott333@gmail.com> - 2024-06-21 13:53 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Boilerplate Reply Richard Damon <richard@damon-family.org> - 2024-06-21 15:05 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Boilerplate Reply olcott <polcott333@gmail.com> - 2024-06-21 14:19 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Boilerplate Reply Richard Damon <richard@damon-family.org> - 2024-06-21 15:33 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Boilerplate Reply olcott <polcott333@gmail.com> - 2024-06-21 14:45 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Boilerplate Reply Richard Damon <richard@damon-family.org> - 2024-06-21 16:00 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Boilerplate Reply olcott <polcott333@gmail.com> - 2024-06-21 15:52 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Boilerplate Reply Richard Damon <richard@damon-family.org> - 2024-06-21 17:10 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Boilerplate Reply olcott <polcott333@gmail.com> - 2024-06-21 16:25 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Boilerplate Reply Richard Damon <richard@damon-family.org> - 2024-06-21 17:46 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Boilerplate Reply olcott <polcott333@gmail.com> - 2024-06-21 17:44 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Boilerplate Reply Richard Damon <richard@damon-family.org> - 2024-06-21 18:58 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Boilerplate Reply olcott <polcott333@gmail.com> - 2024-06-21 18:11 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Boilerplate Reply Richard Damon <richard@damon-family.org> - 2024-06-21 19:36 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Dogma olcott <polcott333@gmail.com> - 2024-06-21 18:27 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Dogma Richard Damon <richard@damon-family.org> - 2024-06-21 19:38 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Dogma olcott <polcott333@gmail.com> - 2024-06-21 22:16 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Dogma joes <noreply@example.com> - 2024-06-22 04:24 +0000
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Dogma olcott <polcott333@gmail.com> - 2024-06-21 23:31 -0500
Re: Dogma -- other deciders joes <noreply@example.com> - 2024-06-22 08:59 +0000
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Dogma Richard Damon <richard@damon-family.org> - 2024-06-22 09:03 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Dogma olcott <polcott333@gmail.com> - 2024-06-22 08:12 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Dogma Richard Damon <richard@damon-family.org> - 2024-06-22 09:38 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Dogma Richard Damon <richard@damon-family.org> - 2024-06-22 08:59 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Dogma olcott <polcott333@gmail.com> - 2024-06-22 08:12 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Dogma Richard Damon <richard@damon-family.org> - 2024-06-22 09:38 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Boilerplate Reply joes <noreply@example.com> - 2024-06-22 04:09 +0000
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Boilerplate Reply olcott <polcott333@gmail.com> - 2024-06-21 23:18 -0500
Re: Boilerplate Reply -- different simulation joes <noreply@example.com> - 2024-06-22 08:47 +0000
Re: Boilerplate Reply -- different simulation olcott <polcott333@gmail.com> - 2024-06-22 08:08 -0500
Re: Boilerplate Reply -- different simulation joes <noreply@example.com> - 2024-06-22 14:36 +0000
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Boilerplate Reply Richard Damon <richard@damon-family.org> - 2024-06-22 09:05 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Boilerplate Reply olcott <polcott333@gmail.com> - 2024-06-22 08:15 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Boilerplate Reply Richard Damon <richard@damon-family.org> - 2024-06-22 09:35 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Boilerplate Reply Mikko <mikko.levanto@iki.fi> - 2024-06-22 12:08 +0300
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Boilerplate Reply olcott <polcott333@gmail.com> - 2024-06-22 07:58 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Boilerplate Reply Richard Damon <richard@damon-family.org> - 2024-06-22 09:22 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Boilerplate Reply olcott <polcott333@gmail.com> - 2024-06-21 08:49 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Boilerplate Reply Richard Damon <richard@damon-family.org> - 2024-06-21 10:41 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) Mikko <mikko.levanto@iki.fi> - 2024-06-21 10:16 +0300
Re: H(D,D) cannot even be asked about the behavior of D(D) olcott <polcott333@gmail.com> - 2024-06-21 08:21 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) Richard Damon <richard@damon-family.org> - 2024-06-21 10:43 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) Mikko <mikko.levanto@iki.fi> - 2024-06-22 14:06 +0300
Re: H(D,D) cannot even be asked about the behavior of D(D) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-22 20:39 +0200
DDD correctly emulated by H0 olcott <polcott333@gmail.com> - 2024-06-22 13:47 -0500
Re: DDD correctly emulated by H0 "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-22 20:53 +0200
Re: DDD correctly emulated by H0 olcott <polcott333@gmail.com> - 2024-06-22 13:56 -0500
Re: DDD correctly emulated by H0 Richard Damon <richard@damon-family.org> - 2024-06-22 15:11 -0400
Re: DDD correctly emulated by H0 joes <noreply@example.com> - 2024-06-25 09:22 +0000
Re: DDD correctly emulated by H0 olcott <polcott333@gmail.com> - 2024-06-25 08:16 -0500
Re: DDD correctly emulated by H0 Alan Mackenzie <acm@muc.de> - 2024-06-25 13:46 +0000
Re: DDD correctly emulated by H0 olcott <polcott333@gmail.com> - 2024-06-25 09:03 -0500
Re: DDD correctly emulated by H0 Alan Mackenzie <acm@muc.de> - 2024-06-25 14:32 +0000
Re: DDD correctly emulated by H0 joes <noreply@example.com> - 2024-06-25 16:28 +0000
Re: DDD correctly emulated by H0 olcott <polcott333@gmail.com> - 2024-06-25 12:21 -0500
Re: DDD correctly emulated by H0 joes <noreply@example.com> - 2024-06-25 20:25 +0000
Re: DDD correctly emulated by H0 Ben Bacarisse <ben@bsb.me.uk> - 2024-06-25 15:04 +0100
Re: DDD correctly emulated by H0 --- Ben fails to understand computable functions olcott <polcott333@gmail.com> - 2024-06-25 09:21 -0500
Re: DDD correctly emulated by H0 --- Ben fails to understand computable functions Richard Damon <richard@damon-family.org> - 2024-06-25 21:47 -0400
Re: DDD correctly emulated by H0 Alan Mackenzie <acm@muc.de> - 2024-06-25 14:46 +0000
Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met olcott <polcott333@gmail.com> - 2024-06-25 12:45 -0500
Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met Richard Damon <richard@damon-family.org> - 2024-06-25 21:47 -0400
Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met olcott <polcott333@gmail.com> - 2024-06-25 21:05 -0500
Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met Richard Damon <richard@damon-family.org> - 2024-06-25 22:23 -0400
Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met olcott <polcott333@gmail.com> - 2024-06-25 21:29 -0500
Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met Richard Damon <richard@damon-family.org> - 2024-06-25 22:55 -0400
Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met olcott <polcott333@gmail.com> - 2024-06-25 22:29 -0500
Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met Richard Damon <richard@damon-family.org> - 2024-06-25 23:35 -0400
Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met olcott <polcott333@gmail.com> - 2024-06-25 22:42 -0500
Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met Richard Damon <richard@damon-family.org> - 2024-06-26 07:02 -0400
Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met olcott <polcott333@gmail.com> - 2024-06-26 08:42 -0500
Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met Richard Damon <richard@damon-family.org> - 2024-06-26 19:41 -0400
Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met olcott <polcott333@gmail.com> - 2024-06-26 18:46 -0500
Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met Richard Damon <richard@damon-family.org> - 2024-06-26 19:55 -0400
Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met olcott <polcott333@gmail.com> - 2024-06-26 19:20 -0500
Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met Richard Damon <richard@damon-family.org> - 2024-06-26 20:42 -0400
Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2024-06-27 02:15 +0100
Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2024-06-27 02:30 +0100
Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met Richard Damon <richard@damon-family.org> - 2024-06-26 21:52 -0400
Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2024-06-27 03:06 +0100
Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met olcott <polcott333@gmail.com> - 2024-06-26 21:29 -0500
Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met Richard Damon <richard@damon-family.org> - 2024-06-26 22:38 -0400
Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met Richard Damon <richard@damon-family.org> - 2024-06-26 22:39 -0400
Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met olcott <polcott333@gmail.com> - 2024-06-26 21:51 -0500
Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met Richard Damon <richard@damon-family.org> - 2024-06-26 23:16 -0400
Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met olcott <polcott333@gmail.com> - 2024-06-26 22:34 -0500
Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met Richard Damon <richard@damon-family.org> - 2024-06-27 07:34 -0400
Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met olcott <polcott333@gmail.com> - 2024-06-27 08:35 -0500
Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met Richard Damon <richard@damon-family.org> - 2024-06-27 19:57 -0400
Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met olcott <polcott333@gmail.com> - 2024-06-26 21:13 -0500
Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met Richard Damon <richard@damon-family.org> - 2024-06-26 22:39 -0400
Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met olcott <polcott333@gmail.com> - 2024-06-26 21:56 -0500
Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met Richard Damon <richard@damon-family.org> - 2024-06-26 23:15 -0400
Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met olcott <polcott333@gmail.com> - 2024-06-26 22:30 -0500
Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met Richard Damon <richard@damon-family.org> - 2024-06-27 07:34 -0400
Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met olcott <polcott333@gmail.com> - 2024-06-27 09:00 -0500
Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met Richard Damon <richard@damon-family.org> - 2024-06-27 19:57 -0400
Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met olcott <polcott333@gmail.com> - 2024-06-26 21:04 -0500
Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2024-06-27 03:16 +0100
Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met olcott <polcott333@gmail.com> - 2024-06-26 21:35 -0500
Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met olcott <polcott333@gmail.com> - 2024-06-26 21:00 -0500
Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met Mikko <mikko.levanto@iki.fi> - 2024-06-26 11:41 +0300
Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met olcott <polcott333@gmail.com> - 2024-06-26 07:58 -0500
Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met Richard Damon <richard@damon-family.org> - 2024-06-26 19:41 -0400
Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met Mikko <mikko.levanto@iki.fi> - 2024-06-27 10:36 +0300
Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met olcott <polcott333@gmail.com> - 2024-06-27 09:10 -0500
Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met Mikko <mikko.levanto@iki.fi> - 2024-06-27 18:35 +0300
Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met olcott <polcott333@gmail.com> - 2024-06-27 11:56 -0500
Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met joes <noreply@example.com> - 2024-06-27 17:25 +0000
Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met olcott <polcott333@gmail.com> - 2024-06-27 12:38 -0500
Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met Mikko <mikko.levanto@iki.fi> - 2024-06-28 12:25 +0300
Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met olcott <polcott333@gmail.com> - 2024-06-28 10:21 -0500
Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met joes <noreply@example.com> - 2024-06-28 16:21 +0000
Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met Mikko <mikko.levanto@iki.fi> - 2024-06-29 11:05 +0300
Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met Richard Damon <richard@damon-family.org> - 2024-06-27 19:57 -0400
Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met Mikko <mikko.levanto@iki.fi> - 2024-06-28 11:30 +0300
Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met olcott <polcott333@gmail.com> - 2024-06-28 07:40 -0500
Re: Ben agrees that Sipser approved criteria is met joes <noreply@example.com> - 2024-06-28 13:04 +0000
Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met Richard Damon <richard@damon-family.org> - 2024-06-28 23:49 -0400
Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met Mikko <mikko.levanto@iki.fi> - 2024-06-29 11:10 +0300
Re: DDD correctly emulated by H0 Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2024-06-25 16:41 +0100
Re: DDD correctly emulated by H0 olcott <polcott333@gmail.com> - 2024-06-25 10:56 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) Richard Damon <richard@damon-family.org> - 2024-06-14 19:27 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) olcott <polcott333@gmail.com> - 2024-06-14 19:34 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) Richard Damon <richard@damon-family.org> - 2024-06-14 21:38 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) olcott <polcott333@gmail.com> - 2024-06-14 20:59 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) Richard Damon <richard@damon-family.org> - 2024-06-14 22:16 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) olcott <polcott333@gmail.com> - 2024-06-14 21:25 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) Richard Damon <richard@damon-family.org> - 2024-06-14 22:48 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) olcott <polcott333@gmail.com> - 2024-06-14 21:52 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) Richard Damon <richard@damon-family.org> - 2024-06-14 23:43 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) olcott <polcott333@gmail.com> - 2024-06-14 21:06 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) Richard Damon <richard@damon-family.org> - 2024-06-14 22:17 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Truth Itself is not Broken. olcott <polcott333@gmail.com> - 2024-06-14 21:39 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Truth Itself is not Broken. Richard Damon <richard@damon-family.org> - 2024-06-14 22:50 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Truth Itself is not Broken. olcott <polcott333@gmail.com> - 2024-06-14 21:56 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Truth Itself is not Broken. Richard Damon <richard@damon-family.org> - 2024-06-14 23:36 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Truth Itself is not Broken. olcott <polcott333@gmail.com> - 2024-06-14 22:39 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Truth Itself is not Broken. Richard Damon <richard@damon-family.org> - 2024-06-14 23:48 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Truth Itself is not Broken. olcott <polcott333@gmail.com> - 2024-06-14 22:55 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Truth Itself is not Broken. Richard Damon <richard@damon-family.org> - 2024-06-15 06:56 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Truth Itself is not Broken. olcott <polcott333@gmail.com> - 2024-06-15 08:35 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Truth Itself is not Broken. Richard Damon <richard@damon-family.org> - 2024-06-15 09:51 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Truth Itself is not Broken. olcott <polcott333@gmail.com> - 2024-06-15 09:23 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Truth Itself is not Broken. Richard Damon <richard@damon-family.org> - 2024-06-15 10:46 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Truth Itself is not Broken. olcott <polcott333@gmail.com> - 2024-06-15 10:03 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Truth Itself is not Broken. Richard Damon <richard@damon-family.org> - 2024-06-15 11:18 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Truth Itself is not Broken. olcott <polcott333@gmail.com> - 2024-06-15 10:41 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Truth Itself is not Broken. Richard Damon <richard@damon-family.org> - 2024-06-15 11:52 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Truth Itself is not Broken. olcott <polcott333@gmail.com> - 2024-06-15 11:11 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Truth Itself is not Broken. Richard Damon <richard@damon-family.org> - 2024-06-15 12:24 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Truth Itself is not Broken. olcott <polcott333@gmail.com> - 2024-06-15 11:31 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Truth Itself is not Broken. Richard Damon <richard@damon-family.org> - 2024-06-15 12:39 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Truth Itself is not Broken. olcott <polcott333@gmail.com> - 2024-06-15 11:50 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Truth Itself is not Broken. Richard Damon <richard@damon-family.org> - 2024-06-15 13:04 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Truth Itself is not Broken. olcott <polcott333@gmail.com> - 2024-06-15 12:16 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Truth Itself is not Broken. Richard Damon <richard@damon-family.org> - 2024-06-15 13:23 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Truth Itself is not Broken. olcott <polcott333@gmail.com> - 2024-06-15 12:33 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Truth Itself is not Broken. Richard Damon <richard@damon-family.org> - 2024-06-15 13:41 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Truth Itself is not Broken. olcott <polcott333@gmail.com> - 2024-06-15 13:03 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Truth Itself is not Broken. Richard Damon <richard@damon-family.org> - 2024-06-15 14:10 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Truth Itself is not Broken. olcott <polcott333@gmail.com> - 2024-06-15 14:16 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Truth Itself is not Broken. Richard Damon <richard@damon-family.org> - 2024-06-15 19:06 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Truth Itself is not Broken. olcott <polcott333@gmail.com> - 2024-06-15 18:28 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Truth Itself is not Broken. Richard Damon <richard@damon-family.org> - 2024-06-15 19:51 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Truth Itself is not Broken. olcott <polcott333@gmail.com> - 2024-06-15 19:39 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Truth Itself is not Broken. Richard Damon <richard@damon-family.org> - 2024-06-15 21:11 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Truth Itself is not Broken. olcott <polcott333@gmail.com> - 2024-06-15 20:57 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Truth Itself is not Broken. Richard Damon <richard@damon-family.org> - 2024-06-15 22:32 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Truth Itself is not Broken. olcott <polcott333@gmail.com> - 2024-06-15 22:16 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Truth Itself is not Broken. Richard Damon <richard@damon-family.org> - 2024-06-16 07:44 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Truth Itself is not Broken. olcott <polcott333@gmail.com> - 2024-06-16 08:21 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Truth Itself is not Broken. Richard Damon <richard@damon-family.org> - 2024-06-16 13:30 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Truth Itself is not Broken. joes <noreply@example.com> - 2024-06-15 11:48 +0000
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Truth Itself is not Broken. olcott <polcott333@gmail.com> - 2024-06-15 07:26 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Truth Itself is not Broken. (Just misunderstood) Richard Damon <richard@damon-family.org> - 2024-06-15 09:52 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Truth Itself is not Broken. (Just misunderstood) olcott <polcott333@gmail.com> - 2024-06-15 09:44 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Truth Itself is not Broken. (Just misunderstood) Richard Damon <richard@damon-family.org> - 2024-06-15 11:09 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Truth Itself is not Broken. (Just misunderstood) olcott <polcott333@gmail.com> - 2024-06-15 10:17 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) --- Truth Itself is not Broken. (Just misunderstood) Richard Damon <richard@damon-family.org> - 2024-06-15 11:24 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) joes <noreply@example.com> - 2024-06-14 08:38 +0000
Re: H(D,D) cannot even be asked about the behavior of D(D) olcott <polcott333@gmail.com> - 2024-06-14 07:34 -0500
H(D,D) cannot even be asked about the behavior of D(D) V2 ---ignoring all other replies olcott <polcott333@gmail.com> - 2024-06-15 09:37 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) V2 ---ignoring all other replies Richard Damon <richard@damon-family.org> - 2024-06-15 11:00 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) V2 ---ignoring all other replies olcott <polcott333@gmail.com> - 2024-06-15 10:07 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) V2 ---ignoring all other replies Richard Damon <richard@damon-family.org> - 2024-06-15 11:12 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) V2 ---ignoring all other replies olcott <polcott333@gmail.com> - 2024-06-15 10:54 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) V2 ---ignoring all other replies joes <noreply@example.com> - 2024-06-15 16:11 +0000
Re: H(D,D) cannot even be asked about the behavior of D(D) V2 ---ignoring all other replies olcott <polcott333@gmail.com> - 2024-06-15 11:19 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) V2 ---ignoring all other replies Richard Damon <richard@damon-family.org> - 2024-06-15 12:26 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) V2 ---ignoring all other replies olcott <polcott333@gmail.com> - 2024-06-15 11:31 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) V2 ---ignoring all other replies Richard Damon <richard@damon-family.org> - 2024-06-15 12:41 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) V2 ---ignoring all other replies Richard Damon <richard@damon-family.org> - 2024-06-15 12:12 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) V2 ---ignoring all other replies olcott <polcott333@gmail.com> - 2024-06-15 11:23 -0500
H(D,D) cannot even be asked about the behavior of D(D) V3 ---IGNORING ALL OTHER REPLIES olcott <polcott333@gmail.com> - 2024-06-15 11:57 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) V3 ---IGNORING ALL OTHER REPLIES Richard Damon <richard@damon-family.org> - 2024-06-15 13:17 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) V3 ---IGNORING ALL OTHER REPLIES olcott <polcott333@gmail.com> - 2024-06-15 12:39 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) V3 ---IGNORING ALL OTHER REPLIES Richard Damon <richard@damon-family.org> - 2024-06-15 14:08 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) V3 ---IGNORING ALL OTHER REPLIES olcott <polcott333@gmail.com> - 2024-06-15 13:55 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) V3 ---IGNORING ALL OTHER REPLIES Richard Damon <richard@damon-family.org> - 2024-06-15 19:15 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) V3 ---IGNORING ALL OTHER REPLIES olcott <polcott333@gmail.com> - 2024-06-15 18:40 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) V3 ---IGNORING ALL OTHER REPLIES Richard Damon <richard@damon-family.org> - 2024-06-15 19:57 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) V3 ---IGNORING ALL OTHER REPLIES olcott <polcott333@gmail.com> - 2024-06-15 19:44 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) V3 ---IGNORING ALL OTHER REPLIES Richard Damon <richard@damon-family.org> - 2024-06-15 21:13 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) V3 ---IGNORING ALL OTHER REPLIES olcott <polcott333@gmail.com> - 2024-06-15 20:39 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) V3 ---IGNORING ALL OTHER REPLIES Richard Damon <richard@damon-family.org> - 2024-06-15 22:02 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) V3 ---IGNORING ALL OTHER REPLIES olcott <polcott333@gmail.com> - 2024-06-15 22:22 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) V3 ---IGNORING ALL OTHER REPLIES Mikko <mikko.levanto@iki.fi> - 2024-06-16 11:34 +0300
Re: H(D,D) cannot even be asked about the behavior of D(D) V3 ---IGNORING ALL OTHER REPLIES olcott <polcott333@gmail.com> - 2024-06-16 07:53 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) V3 ---IGNORING ALL OTHER REPLIES Richard Damon <richard@damon-family.org> - 2024-06-16 07:44 -0400
Re: H(D,D) cannot even be asked about the behavior of D(D) V3 ---IGNORING ALL OTHER REPLIES olcott <polcott333@gmail.com> - 2024-06-16 08:04 -0500
Re: H(D,D) cannot even be asked about the behavior of D(D) V3 ---IGNORING ALL OTHER REPLIES Richard Damon <richard@damon-family.org> - 2024-06-16 13:30 -0400
Re: D correctly simulated by H proved for THREE YEARS --- finite string transformation rules joes <noreply@example.com> - 2024-06-13 08:05 +0000
Re: D correctly simulated by H proved for THREE YEARS --- finite string transformation rules olcott <polcott333@gmail.com> - 2024-06-13 07:55 -0500
Re: D correctly simulated by H proved for THREE YEARS --- finite string transformation rules onion@anon.invalid (Mr Ön!on) - 2024-06-13 14:52 +0100
Re: ❄ Snowflake ❄❄ Snowflake ❄❄ Snowflake ❄❄ Snowflake ❄❄ Snowflake ❄❄ Snowflake ❄❄ Snowflake ❄❄ Snowflake ❄❄ Snowflake ❄❄ Snowflake ❄❄ Snowflake ❄❄ Snowflake ❄❄ Snowflake ❄❄ Snowflake ❄❄ Snowflake ❄❄ Snowflake ❄❄ Snowflake ❄❄ Snowflake ❄❄ Snowflake ❄❄ Snowflake ❄❄ Snowflake ❄❄ Snowflake ❄❄ Snowflake ❄❄ Snowflake ❄ 🏳️🌈D correctly simulated by H proved for THREE YEARS --- finite string transformation rules🏳️🌈 ❄ Snowflake ❄❄ Snowflake ❄❄ Snowflake ❄❄ Snowflake ❄❄ Snowflake ❄❄ Snowflake ❄❄ Snowflake ❄❄ Snowflake ❄❄ Snowflake ❄❄ Snowflake ❄❄ Snowflake ❄❄ Snowflake ❄❄ Snowflake ❄❄ Snowflake ❄❄ Snowflake ❄❄ Snowflake ❄❄ Snowflake ❄❄ Snowflake ❄❄ Snowflake ❄❄ Snowflake ❄❄ Snowflake ❄❄ Snowflake ❄❄ Snowflake ❄❄ Snowflake ❄ (Was: 🏳️🌈D correctly simulated by H proved for THREE YEARS --- finite string transformation rules🏳️🌈) 🌈💐🌻🌺🌹🌻💐🌷🌺🌈Jen🌈💐🌻🌺🌹🌻💐🌷🌺🌈 Dershmender 💐🌻🌺🌹🌻💐🌷🌺🐶笛🌈💐🌻🌺🌹🌻💐🌷🌺🌈 <root@127.0.0.1> - 2024-06-13 14:51 +0000
Re: D correctly simulated by H proved for THREE YEARS --- finite string transformation rules Richard Damon <richard@damon-family.org> - 2024-06-13 21:28 -0400
Re: D correctly simulated by H proved for THREE YEARS --- finite string transformation rules joes <noreply@example.com> - 2024-06-13 08:42 +0000
Re: D correctly simulated by H proved for THREE YEARS --- finite string transformation rules joes <noreply@example.com> - 2024-06-13 08:52 +0000
Re: D correctly simulated by H proved for THREE YEARS --- finite string transformation rules olcott <polcott333@gmail.com> - 2024-06-13 07:58 -0500
Re: D correctly simulated by H proved for THREE YEARS --- finite string transformation rules joes <noreply@example.com> - 2024-06-13 16:53 +0000
Re: D correctly simulated by H proved for THREE YEARS --- finite string transformation rules olcott <polcott333@gmail.com> - 2024-06-13 12:06 -0500
Re: D correctly simulated by H proved for THREE YEARS --- simulating vs. deciding joes <noreply@example.com> - 2024-06-13 17:38 +0000
Re: D correctly simulated by H proved for THREE YEARS --- simulating vs. deciding olcott <polcott333@gmail.com> - 2024-06-14 07:07 -0500
Re: D correctly simulated by H proved for THREE YEARS --- rewritten Richard Damon <richard@damon-family.org> - 2024-06-11 22:30 -0400
Re: D correctly simulated by H proved for THREE YEARS --- rewritten olcott <polcott333@gmail.com> - 2024-06-11 22:21 -0500
Re: D correctly simulated by H proved for THREE YEARS --- rewritten Richard Damon <richard@damon-family.org> - 2024-06-12 07:33 -0400
Re: D correctly simulated by H proved for THREE YEARS --- rewritten olcott <polcott333@gmail.com> - 2024-06-12 11:57 -0500
Re: D correctly simulated by H proved for THREE YEARS --- rewritten Richard Damon <richard@damon-family.org> - 2024-06-12 19:03 -0400
Re: D correctly simulated by H proved for THREE YEARS --- rewritten olcott <polcott333@gmail.com> - 2024-06-12 18:25 -0500
Re: D correctly simulated by H proved for THREE YEARS --- rewritten Richard Damon <richard@damon-family.org> - 2024-06-12 19:45 -0400
Re: D correctly simulated by H proved for THREE YEARS --- rewritten olcott <polcott333@gmail.com> - 2024-06-12 19:37 -0500
Re: D correctly simulated by H proved for THREE YEARS --- rewritten Richard Damon <richard@damon-family.org> - 2024-06-12 20:52 -0400
Re: D correctly simulated by H proved for THREE YEARS --- rewritten olcott <polcott333@gmail.com> - 2024-06-12 20:27 -0500
Re: D correctly simulated by H proved for THREE YEARS --- rewritten Richard Damon <richard@damon-family.org> - 2024-06-12 21:36 -0400
Re: D correctly simulated by H proved for THREE YEARS --- rewritten olcott <polcott333@gmail.com> - 2024-06-12 20:50 -0500
Re: D correctly simulated by H proved for THREE YEARS --- rewritten Richard Damon <richard@damon-family.org> - 2024-06-12 22:16 -0400
Re: D correctly simulated by H proved for THREE YEARS --- rewritten olcott <polcott333@gmail.com> - 2024-06-12 21:25 -0500
Re: D correctly simulated by H proved for THREE YEARS --- rewritten Richard Damon <richard@damon-family.org> - 2024-06-12 22:37 -0400
Re: D correctly simulated by H proved for THREE YEARS --- rewritten olcott <polcott333@gmail.com> - 2024-06-12 21:48 -0500
Re: D correctly simulated by H proved for THREE YEARS --- rewritten Richard Damon <richard@damon-family.org> - 2024-06-12 23:08 -0400
Re: D correctly simulated by H proved for THREE YEARS --- rewritten olcott <polcott333@gmail.com> - 2024-06-12 22:26 -0500
Re: D correctly simulated by H proved for THREE YEARS --- rewritten Richard Damon <richard@damon-family.org> - 2024-06-12 23:49 -0400
Re: D correctly simulated by H proved for THREE YEARS --- rewritten olcott <polcott333@gmail.com> - 2024-06-12 23:06 -0500
Re: D correctly simulated by H proved for THREE YEARS --- rewritten joes <noreply@example.com> - 2024-06-13 08:23 +0000
Re: D correctly simulated by H proved for THREE YEARS --- rewritten Richard Damon <richard@damon-family.org> - 2024-06-13 07:31 -0400
Re: D correctly simulated by H proved for THREE YEARS --- rewritten olcott <polcott333@gmail.com> - 2024-06-13 08:37 -0500
Re: D correctly simulated by H proved for THREE YEARS --- rewritten joes <noreply@example.com> - 2024-06-13 17:19 +0000
Re: D correctly simulated by H proved for THREE YEARS --- rewritten Richard Damon <richard@damon-family.org> - 2024-06-13 22:19 -0400
Re: D correctly simulated by H proved for THREE YEARS --- rewritten olcott <polcott333@gmail.com> - 2024-06-13 21:22 -0500
Re: D correctly simulated by H proved for THREE YEARS --- rewritten Richard Damon <richard@damon-family.org> - 2024-06-13 23:06 -0400
Re: D correctly simulated by H proved for THREE YEARS --- rewritten joes <noreply@example.com> - 2024-06-13 08:12 +0000
Re: D correctly simulated by H proved for THREE YEARS --- finite sting transformations olcott <polcott333@gmail.com> - 2024-06-13 08:07 -0500
Re: D correctly simulated by H proved for THREE YEARS --- finite sting transfermentations joes <noreply@example.com> - 2024-06-13 17:06 +0000
Re: D correctly simulated by H proved for THREE YEARS --- finite sting transfermentations olcott <polcott333@gmail.com> - 2024-06-13 13:07 -0500
Re: D correctly simulated by H proved for THREE YEARS --- finite sting transfermentations Richard Damon <richard@damon-family.org> - 2024-06-13 22:30 -0400
Re: D correctly simulated by H proved for THREE YEARS --- finite sting transfermentations olcott <polcott333@gmail.com> - 2024-06-13 21:31 -0500
Re: D correctly simulated by H proved for THREE YEARS --- finite sting transformations Richard Damon <richard@damon-family.org> - 2024-06-13 22:27 -0400
Re: D correctly simulated by H proved for THREE YEARS --- finite sting transformations olcott <polcott333@gmail.com> - 2024-06-13 21:30 -0500
Re: D correctly simulated by H proved for THREE YEARS --- rewritten joes <noreply@example.com> - 2024-06-13 08:49 +0000
Re: D correctly simulated by H proved for THREE YEARS --- rewritten olcott <polcott333@gmail.com> - 2024-06-13 08:10 -0500
Re: D correctly simulated by H proved for THREE YEARS --- rewritten Alan Mackenzie <acm@muc.de> - 2024-06-13 14:35 +0000
Re: D correctly simulated by H proved for THREE YEARS --- rewritten olcott <polcott333@gmail.com> - 2024-06-13 10:08 -0500
Re: D correctly simulated by H proved for THREE YEARS --- rewritten joes <noreply@example.com> - 2024-06-13 17:26 +0000
Re: D correctly simulated by H proved for THREE YEARS --- rewritten olcott <polcott333@gmail.com> - 2024-06-14 07:05 -0500
Re: D correctly simulated by H proved for THREE YEARS --- rewritten Richard Damon <richard@damon-family.org> - 2024-06-14 19:27 -0400
Re: D correctly simulated by H proved for THREE YEARS --- rewritten olcott <polcott333@gmail.com> - 2024-06-14 19:40 -0500
Re: D correctly simulated by H proved for THREE YEARS --- rewritten Richard Damon <richard@damon-family.org> - 2024-06-14 21:58 -0400
Re: D correctly simulated by H proved for THREE YEARS --- rewritten olcott <polcott333@gmail.com> - 2024-06-14 21:06 -0500
Re: D correctly simulated by H proved for THREE YEARS --- rewritten Richard Damon <richard@damon-family.org> - 2024-06-14 22:05 -0400
Re: D correctly simulated by H proved for THREE YEARS --- rewritten olcott <polcott333@gmail.com> - 2024-06-14 21:07 -0500
Re: D correctly simulated by H proved for THREE YEARS --- rewritten Richard Damon <richard@damon-family.org> - 2024-06-13 22:35 -0400
Re: D correctly simulated by H proved for THREE YEARS --- specification joes <noreply@example.com> - 2024-06-13 17:09 +0000
Re: D correctly simulated by H proved for THREE YEARS --- rewritten Richard Damon <richard@damon-family.org> - 2024-06-13 22:31 -0400
Re: D correctly simulated by H proved for THREE YEARS --- rewritten olcott <polcott333@gmail.com> - 2024-06-13 21:33 -0500
Re: D correctly simulated by H proved for THREE YEARS --- rewritten "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-12 08:24 +0200
Page 3 of 19 — ← Prev page 1 2 [3] 4 5 … 19 Next page →
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-13 10:32 -0500 |
| Subject | Re: D correctly simulated by H proved for THREE YEARS --- finite string transformation rules |
| Message-ID | <v4f3ec$2akmh$2@dont-email.me> |
| In reply to | #107056 |
On 6/13/2024 6:31 AM, Richard Damon wrote: > On 6/12/24 11:58 PM, olcott wrote: >> On 6/12/2024 10:45 PM, Richard Damon wrote: >>> On 6/12/24 11:24 PM, olcott wrote: >>>> On 6/12/2024 9:57 PM, Richard Damon wrote: >>>>> On 6/12/24 10:21 PM, olcott wrote: >>>>>> On 6/12/2024 9:06 PM, Richard Damon wrote: >>>>>>> On 6/12/24 9:54 PM, olcott wrote: >>>>>>>> On 6/12/2024 8:50 PM, Richard Damon wrote: >>>>>>>>> On 6/12/24 9:19 PM, olcott wrote: >>>>>>>>>> >>>>>>>>>> I am saying there is no mapping from the input TO THE QUESTION. >>>>>>>>>> H IS NOT EVEN BEING ASKED ABOUT THE BEHAVIOR OF D(D). >>>>>>>>>> >>>>>>>>> >>>>>>>>> So, you admit that you are lying about H being a Halt Decider. >>>>>>>>> >>>>>>>> >>>>>>>> No I admit that you are too stupid to understand what I am saying. >>>>>>> >>>>>>> How is it a H >>>>>>> >>>>>> >>>>>> I gave you the source-code. >>>>> >>>>> So? >>>>> >>>>> Last time I commented about somethihg from the source code you said >>>>> that didn't apply. >>>>> >>>>> It also, as you have admitted, has bugs in its trace routine, so it >>>>> can't produce a trace of the quality you seem to want. >>>>> >>>> >>>> I never said anything like that. >>> >>> You admitted that it didn't produce the "Correct Simulation" output >>> that it was supposed to produce. >>> >> >> It was never supposed to produce this. >> As I explain on page five of this other 2021 paper. >> >> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation > > But acting as a "pure simulator until ..." is NOT the same as acting as > a pure simulator. > > And thus the "transform" is invalid, as shown by the fact that P(P) > halts even though H(P,P) uses its logic to say that it doesn't. > > Thus, your "logic" introduces a FALSE premise into its logic, and thus > its conclusion is INVALID. > > Can you show an ACTUAL accepted statement that says you are allowed to > do that transform, or is this just another of your "it seems right, so I > will assume it to be right" statements that just makes your logic wrong. > > Your logic is just subject to the power of the paradox. > >> >>> The output wasn't the simulation it did, but the execution trace of >>> your decider itself. >>> >>>> >>>>> Do you deny that with the H defined so that H(D,D) will return 0, >>>>> as it does in your source code that making main() call D(D) that >>>>> that D(D) will not return? >>>>> >>>>> You even posted a trace of that operation, but its trace has the >>>>> same error that all your traces do, so I don't want to call that >>>>> "Correct" any more, as that would be a LIE. >>>>> >>>>>> >>>>>>>> >>>>>>>>> Because Halt Deciders *ARE* being asked about the behavior of >>>>>>>>> the machine their input describes, in this case D(D). >>>>>>>>> >>>>>>>> >>>>>>>> This never has been precisely correct. That is a dumbed down >>>>>>>> version for people that do not really understand these things. >>>>>>> >>>>>>> Source for that claim? and not that it is just another of your >>>>>>> unverifiable false claims? >>>>>>> >>>>>> >>>>>> Actual comprehension is my source. That it is over-your-head >>>>>> does not make me incorrect. >>>>> >>>>> I other words, you ADMIT that it is just a "I made itup" up, but it >>>>> must be true" sort of statement, so doesn't actualuy have an >>>>> accepted truth-maker for it, so is just a LIE. >>>>> >>>>> That's par for the course. >>>>> >>>>> That you can't actually show it, shows you ARE incorrect for >>>>> claiming it. >>>>> >>>>>> >>>>>> How do you think that halt deciders figure out the question that >>>>>> they are being asked, do they look up the question on a textbook? >>>>> >>>>> They don't need to. There Programmer needs to figure that out. >>>>> >>>>> Programs don't "think", they "Compute", and do it per their >>>>> instuctions given to them. >>>>> >>>>> You just don't seem to understand the essential nature of Programs >>>>> do you. >>>>> >>>>>> >>>>>>> You have a big list of things you have claimed but NEVER were >>>>>>> able to show a proof, and thus effectively admitted that you made >>>>>>> up your claims, which means they can be considered to be LIE. >>>>>>> >>>>>> >>>>>> No it means that the reasoning behind them must be carefully >>>>>> assessed. >>>>> >>>>> But you can't give any actual "reasoning", only your own >>>>> unsubstantiated claims based on wrong defintions. >>>>> >>>> >>>> *COMPUTE THE MAPPING FROM INPUTS* >>>> Is currently totally over-your-head >>>> yet has a specific meaning using those terms >>>> according to their conventional meanings. >>>> >>>> Tell me in your own words what you think >>>> COMPUTE THE MAPPING FROM INPUTS means. >>> >>> >>> It takes the input, and TRIES to process them to the answer >>> corresponding to the mapping it is supposed to be computing. >>> >>> Yes, ALL programs the meet the very basic definition of a decider >>> (giving an answer for all possible input) computes SOME mapping of >>> the input ot the output (which provides the count of the number of >>> possible mappings that are computable). So H is some sort of decider, >>> >>> But to be a decider for a specific function, it needs to compute the >>> mapping that matches that function. So, A Halt Decider, to be a HALT >>> decider, needs to generate the exact same mapping as the Halting >>> mathematical function, which is defined in terms of the behavior of >>> the machine represented by the input. >>> >>> This seems to be just totally beyond your understanding, that there >>> are actual REQUIREMENTS that must be met for something to be "Correct". >>> >>> Note, the word *THE* in your phrase meens a specific simgular >>> mapping, that is the mapping defined by the function it is named for. >>> >>> Your H computes *A* mapping, but not the Halting Function mapping. >>> And the exact details of that mapping is a function of the decider >>> you create to try to compute it, as H and H1 generate different >>> answers for the D built on H (and for the D1 built on H1). Thus your >>> "POOP" mapping is different for each H you want to ask about, so in >>> one sense, isn't even a correct question to be asking. >>> >>> It isn't asking about the decider deciding on the behavior of the >>> input correctly simulated by itself, but the decider needing to >>> decider on the behavior of the input correctly simulated by a >>> particular H that was choosen. >>> >>> >>>> >>> >> >> Try and show the steps of the mapping that you expect in >> terms of D correctly simulated by H, line by line. > > But I don't claim a mapping of D correctly simulated by H, as that is a > INVALID criteria, as I explained. > > Since you call H a "Halt Decider", its criteria is, and can only be, the > behavior of the directly executed D(D), or something that EXACTLY agrees > with that behavior, > It is contingent upon you to show the exact steps of how H computes the mapping from the x86 machine language finite string input to H(D,D) using the finite string transformation rules specified by the semantics of the x86 programming language that reaches the behavior of the directly executed D(D) When I ask anyone to show the detailed steps of the mapping from the machine language finite string of D to the behavior of D(D) *THEY CHANGE THE SUBJECT BECAUSE THEY ALREADY KNOW THAT I AM CORRECT* -- 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 | joes <noreply@example.com> |
|---|---|
| Date | 2024-06-13 17:34 +0000 |
| Subject | Re: D correctly simulated by H proved for THREE YEARS --- finite string transformation rules |
| Message-ID | <v4fajt$3smqv$5@i2pn2.org> |
| In reply to | #107069 |
Am Thu, 13 Jun 2024 10:32:28 -0500 schrieb olcott: > On 6/13/2024 6:31 AM, Richard Damon wrote: >> On 6/12/24 11:58 PM, olcott wrote: >>> On 6/12/2024 10:45 PM, Richard Damon wrote: >>>> On 6/12/24 11:24 PM, olcott wrote: >>>>> On 6/12/2024 9:57 PM, Richard Damon wrote: >>>>>> On 6/12/24 10:21 PM, olcott wrote: >>>>>>> On 6/12/2024 9:06 PM, Richard Damon wrote: >>>>>>>> On 6/12/24 9:54 PM, olcott wrote: >>>>>>>>> On 6/12/2024 8:50 PM, Richard Damon wrote: >>>>>>>>>> On 6/12/24 9:19 PM, olcott wrote: >>>> You admitted that it didn't produce the "Correct Simulation" output >>>> that it was supposed to produce. >>> It was never supposed to produce this. Gold. >> But acting as a "pure simulator until ..." is NOT the same as acting as >> a pure simulator. >> And thus the "transform" is invalid, as shown by the fact that P(P) >> halts even though H(P,P) uses its logic to say that it doesn't. >> Thus, your "logic" introduces a FALSE premise into its logic, and thus >> its conclusion is INVALID. Nice. >>>>> Tell me in your own words what you think COMPUTE THE MAPPING FROM >>>>> INPUTS means. >>>> It takes the input, and TRIES to process them to the answer >>>> corresponding to the mapping it is supposed to be computing. >>>> But to be a decider for a specific function, it needs to compute the >>>> mapping that matches that function. So, A Halt Decider, to be a HALT >>>> decider, needs to generate the exact same mapping as the Halting >>>> mathematical function, which is defined in terms of the behavior of >>>> the machine represented by the input. >>>> Your H computes *A* mapping, but not the Halting Function mapping. >>>> And the exact details of that mapping is a function of the decider >>>> you create to try to compute it, as H and H1 generate different >>>> answers for the D built on H (and for the D1 built on H1). Thus your >>>> "POOP" mapping is different for each H you want to ask about, so in >>>> one sense, isn't even a correct question to be asking. >>>> >>>> It isn't asking about the decider deciding on the behavior of the >>>> input correctly simulated by itself, but the decider needing to >>>> decide on the behavior of the input correctly simulated by a >>>> particular H that was choosen. >>>> >>> Try and show the steps of the mapping that you expect in terms of D >>> correctly simulated by H, line by line. Exactly the steps D would take. >> Since you call H a "Halt Decider", its criterion is, and can only be, >> the behavior of the directly executed D(D), > It is contingent upon you to show the exact steps of how H computes the > mapping from the x86 machine language finite string input to H(D,D) > using the finite string transformation rules specified by the semantics > of the x86 programming language that reaches the behavior of the > directly executed D(D) Do you know about UTMs? > When I ask anyone to show the detailed steps of the mapping from the > machine language finite string of D to the behavior of D(D) You're smart enough to reason about the behaviour of D from its description yourself. -- joes
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-13 21:24 -0400 |
| Subject | Re: D correctly simulated by H proved for THREE YEARS --- finite string transformation rules |
| Message-ID | <v4g65a$3tn6q$1@i2pn2.org> |
| In reply to | #107069 |
On 6/13/24 11:32 AM, olcott wrote:
> On 6/13/2024 6:31 AM, Richard Damon wrote:
>> On 6/12/24 11:58 PM, olcott wrote:
>>> On 6/12/2024 10:45 PM, Richard Damon wrote:
>>>> On 6/12/24 11:24 PM, olcott wrote:
>>>>> On 6/12/2024 9:57 PM, Richard Damon wrote:
>>>>>> On 6/12/24 10:21 PM, olcott wrote:
>>>>>>> On 6/12/2024 9:06 PM, Richard Damon wrote:
>>>>>>>> On 6/12/24 9:54 PM, olcott wrote:
>>>>>>>>> On 6/12/2024 8:50 PM, Richard Damon wrote:
>>>>>>>>>> On 6/12/24 9:19 PM, olcott wrote:
>>>>>>>>>>>
>>>>>>>>>>> I am saying there is no mapping from the input TO THE QUESTION.
>>>>>>>>>>> H IS NOT EVEN BEING ASKED ABOUT THE BEHAVIOR OF D(D).
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> So, you admit that you are lying about H being a Halt Decider.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> No I admit that you are too stupid to understand what I am saying.
>>>>>>>>
>>>>>>>> How is it a H
>>>>>>>>
>>>>>>>
>>>>>>> I gave you the source-code.
>>>>>>
>>>>>> So?
>>>>>>
>>>>>> Last time I commented about somethihg from the source code you
>>>>>> said that didn't apply.
>>>>>>
>>>>>> It also, as you have admitted, has bugs in its trace routine, so
>>>>>> it can't produce a trace of the quality you seem to want.
>>>>>>
>>>>>
>>>>> I never said anything like that.
>>>>
>>>> You admitted that it didn't produce the "Correct Simulation" output
>>>> that it was supposed to produce.
>>>>
>>>
>>> It was never supposed to produce this.
>>> As I explain on page five of this other 2021 paper.
>>>
>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>
>> But acting as a "pure simulator until ..." is NOT the same as acting
>> as a pure simulator.
>>
>> And thus the "transform" is invalid, as shown by the fact that P(P)
>> halts even though H(P,P) uses its logic to say that it doesn't.
>>
>> Thus, your "logic" introduces a FALSE premise into its logic, and thus
>> its conclusion is INVALID.
>>
>> Can you show an ACTUAL accepted statement that says you are allowed to
>> do that transform, or is this just another of your "it seems right, so
>> I will assume it to be right" statements that just makes your logic
>> wrong.
>>
>> Your logic is just subject to the power of the paradox.
>>
>>>
>>>> The output wasn't the simulation it did, but the execution trace of
>>>> your decider itself.
>>>>
>>>>>
>>>>>> Do you deny that with the H defined so that H(D,D) will return 0,
>>>>>> as it does in your source code that making main() call D(D) that
>>>>>> that D(D) will not return?
>>>>>>
>>>>>> You even posted a trace of that operation, but its trace has the
>>>>>> same error that all your traces do, so I don't want to call that
>>>>>> "Correct" any more, as that would be a LIE.
>>>>>>
>>>>>>>
>>>>>>>>>
>>>>>>>>>> Because Halt Deciders *ARE* being asked about the behavior of
>>>>>>>>>> the machine their input describes, in this case D(D).
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> This never has been precisely correct. That is a dumbed down
>>>>>>>>> version for people that do not really understand these things.
>>>>>>>>
>>>>>>>> Source for that claim? and not that it is just another of your
>>>>>>>> unverifiable false claims?
>>>>>>>>
>>>>>>>
>>>>>>> Actual comprehension is my source. That it is over-your-head
>>>>>>> does not make me incorrect.
>>>>>>
>>>>>> I other words, you ADMIT that it is just a "I made itup" up, but
>>>>>> it must be true" sort of statement, so doesn't actualuy have an
>>>>>> accepted truth-maker for it, so is just a LIE.
>>>>>>
>>>>>> That's par for the course.
>>>>>>
>>>>>> That you can't actually show it, shows you ARE incorrect for
>>>>>> claiming it.
>>>>>>
>>>>>>>
>>>>>>> How do you think that halt deciders figure out the question that
>>>>>>> they are being asked, do they look up the question on a textbook?
>>>>>>
>>>>>> They don't need to. There Programmer needs to figure that out.
>>>>>>
>>>>>> Programs don't "think", they "Compute", and do it per their
>>>>>> instuctions given to them.
>>>>>>
>>>>>> You just don't seem to understand the essential nature of Programs
>>>>>> do you.
>>>>>>
>>>>>>>
>>>>>>>> You have a big list of things you have claimed but NEVER were
>>>>>>>> able to show a proof, and thus effectively admitted that you
>>>>>>>> made up your claims, which means they can be considered to be LIE.
>>>>>>>>
>>>>>>>
>>>>>>> No it means that the reasoning behind them must be carefully
>>>>>>> assessed.
>>>>>>
>>>>>> But you can't give any actual "reasoning", only your own
>>>>>> unsubstantiated claims based on wrong defintions.
>>>>>>
>>>>>
>>>>> *COMPUTE THE MAPPING FROM INPUTS*
>>>>> Is currently totally over-your-head
>>>>> yet has a specific meaning using those terms
>>>>> according to their conventional meanings.
>>>>>
>>>>> Tell me in your own words what you think
>>>>> COMPUTE THE MAPPING FROM INPUTS means.
>>>>
>>>>
>>>> It takes the input, and TRIES to process them to the answer
>>>> corresponding to the mapping it is supposed to be computing.
>>>>
>>>> Yes, ALL programs the meet the very basic definition of a decider
>>>> (giving an answer for all possible input) computes SOME mapping of
>>>> the input ot the output (which provides the count of the number of
>>>> possible mappings that are computable). So H is some sort of decider,
>>>>
>>>> But to be a decider for a specific function, it needs to compute the
>>>> mapping that matches that function. So, A Halt Decider, to be a HALT
>>>> decider, needs to generate the exact same mapping as the Halting
>>>> mathematical function, which is defined in terms of the behavior of
>>>> the machine represented by the input.
>>>>
>>>> This seems to be just totally beyond your understanding, that there
>>>> are actual REQUIREMENTS that must be met for something to be "Correct".
>>>>
>>>> Note, the word *THE* in your phrase meens a specific simgular
>>>> mapping, that is the mapping defined by the function it is named for.
>>>>
>>>> Your H computes *A* mapping, but not the Halting Function mapping.
>>>> And the exact details of that mapping is a function of the decider
>>>> you create to try to compute it, as H and H1 generate different
>>>> answers for the D built on H (and for the D1 built on H1). Thus your
>>>> "POOP" mapping is different for each H you want to ask about, so in
>>>> one sense, isn't even a correct question to be asking.
>>>>
>>>> It isn't asking about the decider deciding on the behavior of the
>>>> input correctly simulated by itself, but the decider needing to
>>>> decider on the behavior of the input correctly simulated by a
>>>> particular H that was choosen.
>>>>
>>>>
>>>>>
>>>>
>>>
>>> Try and show the steps of the mapping that you expect in
>>> terms of D correctly simulated by H, line by line.
>>
>> But I don't claim a mapping of D correctly simulated by H, as that is
>> a INVALID criteria, as I explained.
>>
>> Since you call H a "Halt Decider", its criteria is, and can only be,
>> the behavior of the directly executed D(D), or something that EXACTLY
>> agrees with that behavior,
>>
>
> It is contingent upon you to show the exact steps of how H computes
> the mapping from the x86 machine language finite string input to
> H(D,D) using the finite string transformation rules specified by
> the semantics of the x86 programming language that reaches the
> behavior of the directly executed D(D)
>
Why? I don't claim it can.
In fact, I have told you that I will not engage in your foolish idea of
what H can or can not do with its partial simulation of the input, until
you show why that has relevence.
You seem to be stuck on that as way to try to avoid the issues that have
been pointed out in the other parts of your proof, which just confirms
that you really have no idea how to handle the issues pointed out.
> When I ask anyone to show the detailed steps of the mapping from
> the machine language finite string of D to the behavior of D(D)
> *THEY CHANGE THE SUBJECT BECAUSE THEY ALREADY KNOW THAT I AM CORRECT*
>
And THAT is a different question, when you drop the "by H" part of the
requirement it becomes technically feasable,
I can show you an "incorrect trace" that makes the same error that you
claim to be a "correct" simulation.
That being one YOU posted a while back as:
On 4/27/21 12:55 AM, olcott wrote:
Message-ID: <Teudndbu59GVBBr9nZ2dnUU7-V2dnZ2d@giganews.com>
> void H_Hat(u32 P)
> {
> u32 Input_Halts = Halts(P, P);
> if (Input_Halts)
> HERE: goto HERE;
> }
>
>
> int main()
> {
> H_Hat((u32)H_Hat);
> }
>
>
> _H_Hat()
> [00000b98](01) 55 push ebp
> [00000b99](02) 8bec mov ebp,esp
>
[00000b9b](01) 51 push ecx
> [00000b9c](03) 8b4508 mov eax,[ebp+08]
> [00000b9f](01) 50 push eax
> [00000ba0](03) 8b4d08 mov ecx,[ebp+08]
> [00000ba3](01) 51 push ecx
> [00000ba4](05) e88ffdffff call 00000938
> [00000ba9](03) 83c408 add esp,+08
> [00000bac](03) 8945fc mov [ebp-04],eax
> [00000baf](04) 837dfc00 cmp dword [ebp-04],+00
> [00000bb3](02) 7402 jz 00000bb7
> [00000bb5](02) ebfe jmp 00000bb5
> [00000bb7](02) 8be5 mov esp,ebp
> [00000bb9](01) 5d pop ebp
> [00000bba](01) c3 ret
> Size in bytes:(0035) [00000bba]
>
> _main()
> [00000bc8](01) 55 push ebp
> [00000bc9](02) 8bec mov ebp,esp
> [00000bcb](05) 68980b0000 push 00000b98
> [00000bd0](05) e8c3ffffff call 00000b98
> [00000bd5](03) 83c404 add esp,+04
> [00000bd8](02) 33c0 xor eax,eax
> [00000bda](01) 5d pop ebp
> [00000bdb](01) c3 ret
> Size in bytes:(0020) [00000bdb]
>
> ===============================
> ...[00000bc8][001015d4][00000000](01) 55 push ebp
> ...[00000bc9][001015d4][00000000](02) 8bec mov ebp,esp
> ...[00000bcb][001015d0][00000b98](05) 68980b0000 push 00000b98
> ...[00000bd0][001015cc][00000bd5](05) e8c3ffffff call 00000b98
> ...[00000b98][001015c8][001015d4](01) 55 push ebp
> ...[00000b99][001015c8][001015d4](02) 8bec mov ebp,esp
> ...[00000b9b][001015c4][00000000](01) 51 push ecx
> ...[00000b9c][001015c4][00000000](03) 8b4508 mov eax,[ebp+08]
> ...[00000b9f][001015c0][00000b98](01) 50 push eax
> ...[00000ba0][001015c0][00000b98](03) 8b4d08 mov ecx,[ebp+08]
> ...[00000ba3][001015bc][00000b98](01) 51 push ecx
> ...[00000ba4][001015b8][00000ba9](05) e88ffdffff call 00000938
> Begin Local Halt Decider Simulation at Machine Address:b98
> ...[00000b98][00211674][00211678](01) 55 push ebp
> ...[00000b99][00211674][00211678](02) 8bec mov ebp,esp
> ...[00000b9b][00211670][00201644](01) 51 push ecx
> ...[00000b9c][00211670][00201644](03) 8b4508 mov eax,[ebp+08]
> ...[00000b9f][0021166c][00000b98](01) 50 push eax
> ...[00000ba0][0021166c][00000b98](03) 8b4d08 mov ecx,[ebp+08]
> ...[00000ba3][00211668][00000b98](01) 51 push ecx
> ...[00000ba4][00211664][00000ba9](05) e88ffdffff call 00000938
> ...[00000b98][0025c09c][0025c0a0](01) 55 push ebp
> ...[00000b99][0025c09c][0025c0a0](02) 8bec mov ebp,esp
> ...[00000b9b][0025c098][0024c06c](01) 51 push ecx
> ...[00000b9c][0025c098][0024c06c](03) 8b4508 mov eax,[ebp+08]
> ...[00000b9f][0025c094][00000b98](01) 50 push eax
> ...[00000ba0][0025c094][00000b98](03) 8b4d08 mov ecx,[ebp+08]
> ...[00000ba3][0025c090][00000b98](01) 51 push ecx
> ...[00000ba4][0025c08c][00000ba9](05) e88ffdffff call 00000938
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
Above decision was from the call the Halts inside H_Hat, deciding that
H_Hat(H_Hat) seems to be non-halting, it then returns that answer and is
processed below:
> ...[00000ba9][001015c4][00000000](03) 83c408 add esp,+08
> ...[00000bac][001015c4][00000000](03) 8945fc mov [ebp-04],eax
> ...[00000baf][001015c4][00000000](04) 837dfc00 cmp dword [ebp-04],+00
> ...[00000bb3][001015c4][00000000](02) 7402 jz 00000bb7
> ...[00000bb7][001015c8][001015d4](02) 8be5 mov esp,ebp
> ...[00000bb9][001015cc][00000bd5](01) 5d pop ebp
> ...[00000bba][001015d0][00000b98](01) c3 ret
> ...[00000bd5][001015d4][00000000](03) 83c404 add esp,+04
> ...[00000bd8][001015d4][00000000](02) 33c0 xor eax,eax
> ...[00000bda][001015d8][00100000](01) 5d pop ebp
> ...[00000bdb][001015dc][00000098](01) c3 ret
SEE IT HALTED!
> Number_of_User_Instructions(39)
> Number of Instructions Executed(26567)
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-13 20:39 -0500 |
| Subject | Re: D correctly simulated by H proved for THREE YEARS --- finite string transformation rules |
| Message-ID | <v4g6vr$2ic0g$1@dont-email.me> |
| In reply to | #107083 |
On 6/13/2024 8:24 PM, Richard Damon wrote: > On 6/13/24 11:32 AM, olcott wrote: >> On 6/13/2024 6:31 AM, Richard Damon wrote: >>> On 6/12/24 11:58 PM, olcott wrote: >>>> On 6/12/2024 10:45 PM, Richard Damon wrote: >>>>> On 6/12/24 11:24 PM, olcott wrote: >>>>>> On 6/12/2024 9:57 PM, Richard Damon wrote: >>>>>>> On 6/12/24 10:21 PM, olcott wrote: >>>>>>>> On 6/12/2024 9:06 PM, Richard Damon wrote: >>>>>>>>> On 6/12/24 9:54 PM, olcott wrote: >>>>>>>>>> On 6/12/2024 8:50 PM, Richard Damon wrote: >>>>>>>>>>> On 6/12/24 9:19 PM, olcott wrote: >>>>>>>>>>>> >>>>>>>>>>>> I am saying there is no mapping from the input TO THE QUESTION. >>>>>>>>>>>> H IS NOT EVEN BEING ASKED ABOUT THE BEHAVIOR OF D(D). >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> So, you admit that you are lying about H being a Halt Decider. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> No I admit that you are too stupid to understand what I am >>>>>>>>>> saying. >>>>>>>>> >>>>>>>>> How is it a H >>>>>>>>> >>>>>>>> >>>>>>>> I gave you the source-code. >>>>>>> >>>>>>> So? >>>>>>> >>>>>>> Last time I commented about somethihg from the source code you >>>>>>> said that didn't apply. >>>>>>> >>>>>>> It also, as you have admitted, has bugs in its trace routine, so >>>>>>> it can't produce a trace of the quality you seem to want. >>>>>>> >>>>>> >>>>>> I never said anything like that. >>>>> >>>>> You admitted that it didn't produce the "Correct Simulation" output >>>>> that it was supposed to produce. >>>>> >>>> >>>> It was never supposed to produce this. >>>> As I explain on page five of this other 2021 paper. >>>> >>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation >>> >>> But acting as a "pure simulator until ..." is NOT the same as acting >>> as a pure simulator. >>> >>> And thus the "transform" is invalid, as shown by the fact that P(P) >>> halts even though H(P,P) uses its logic to say that it doesn't. >>> >>> Thus, your "logic" introduces a FALSE premise into its logic, and >>> thus its conclusion is INVALID. >>> >>> Can you show an ACTUAL accepted statement that says you are allowed >>> to do that transform, or is this just another of your "it seems >>> right, so I will assume it to be right" statements that just makes >>> your logic wrong. >>> >>> Your logic is just subject to the power of the paradox. >>> >>>> >>>>> The output wasn't the simulation it did, but the execution trace of >>>>> your decider itself. >>>>> >>>>>> >>>>>>> Do you deny that with the H defined so that H(D,D) will return 0, >>>>>>> as it does in your source code that making main() call D(D) that >>>>>>> that D(D) will not return? >>>>>>> >>>>>>> You even posted a trace of that operation, but its trace has the >>>>>>> same error that all your traces do, so I don't want to call that >>>>>>> "Correct" any more, as that would be a LIE. >>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>>>>> Because Halt Deciders *ARE* being asked about the behavior of >>>>>>>>>>> the machine their input describes, in this case D(D). >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> This never has been precisely correct. That is a dumbed down >>>>>>>>>> version for people that do not really understand these things. >>>>>>>>> >>>>>>>>> Source for that claim? and not that it is just another of your >>>>>>>>> unverifiable false claims? >>>>>>>>> >>>>>>>> >>>>>>>> Actual comprehension is my source. That it is over-your-head >>>>>>>> does not make me incorrect. >>>>>>> >>>>>>> I other words, you ADMIT that it is just a "I made itup" up, but >>>>>>> it must be true" sort of statement, so doesn't actualuy have an >>>>>>> accepted truth-maker for it, so is just a LIE. >>>>>>> >>>>>>> That's par for the course. >>>>>>> >>>>>>> That you can't actually show it, shows you ARE incorrect for >>>>>>> claiming it. >>>>>>> >>>>>>>> >>>>>>>> How do you think that halt deciders figure out the question that >>>>>>>> they are being asked, do they look up the question on a textbook? >>>>>>> >>>>>>> They don't need to. There Programmer needs to figure that out. >>>>>>> >>>>>>> Programs don't "think", they "Compute", and do it per their >>>>>>> instuctions given to them. >>>>>>> >>>>>>> You just don't seem to understand the essential nature of >>>>>>> Programs do you. >>>>>>> >>>>>>>> >>>>>>>>> You have a big list of things you have claimed but NEVER were >>>>>>>>> able to show a proof, and thus effectively admitted that you >>>>>>>>> made up your claims, which means they can be considered to be LIE. >>>>>>>>> >>>>>>>> >>>>>>>> No it means that the reasoning behind them must be carefully >>>>>>>> assessed. >>>>>>> >>>>>>> But you can't give any actual "reasoning", only your own >>>>>>> unsubstantiated claims based on wrong defintions. >>>>>>> >>>>>> >>>>>> *COMPUTE THE MAPPING FROM INPUTS* >>>>>> Is currently totally over-your-head >>>>>> yet has a specific meaning using those terms >>>>>> according to their conventional meanings. >>>>>> >>>>>> Tell me in your own words what you think >>>>>> COMPUTE THE MAPPING FROM INPUTS means. >>>>> >>>>> >>>>> It takes the input, and TRIES to process them to the answer >>>>> corresponding to the mapping it is supposed to be computing. >>>>> >>>>> Yes, ALL programs the meet the very basic definition of a decider >>>>> (giving an answer for all possible input) computes SOME mapping of >>>>> the input ot the output (which provides the count of the number of >>>>> possible mappings that are computable). So H is some sort of decider, >>>>> >>>>> But to be a decider for a specific function, it needs to compute >>>>> the mapping that matches that function. So, A Halt Decider, to be a >>>>> HALT decider, needs to generate the exact same mapping as the >>>>> Halting mathematical function, which is defined in terms of the >>>>> behavior of the machine represented by the input. >>>>> >>>>> This seems to be just totally beyond your understanding, that there >>>>> are actual REQUIREMENTS that must be met for something to be >>>>> "Correct". >>>>> >>>>> Note, the word *THE* in your phrase meens a specific simgular >>>>> mapping, that is the mapping defined by the function it is named for. >>>>> >>>>> Your H computes *A* mapping, but not the Halting Function mapping. >>>>> And the exact details of that mapping is a function of the decider >>>>> you create to try to compute it, as H and H1 generate different >>>>> answers for the D built on H (and for the D1 built on H1). Thus >>>>> your "POOP" mapping is different for each H you want to ask about, >>>>> so in one sense, isn't even a correct question to be asking. >>>>> >>>>> It isn't asking about the decider deciding on the behavior of the >>>>> input correctly simulated by itself, but the decider needing to >>>>> decider on the behavior of the input correctly simulated by a >>>>> particular H that was choosen. >>>>> >>>>> >>>>>> >>>>> >>>> >>>> Try and show the steps of the mapping that you expect in >>>> terms of D correctly simulated by H, line by line. >>> >>> But I don't claim a mapping of D correctly simulated by H, as that is >>> a INVALID criteria, as I explained. >>> >>> Since you call H a "Halt Decider", its criteria is, and can only be, >>> the behavior of the directly executed D(D), or something that EXACTLY >>> agrees with that behavior, >>> >> >> It is contingent upon you to show the exact steps of how H computes >> the mapping from the x86 machine language finite string input to >> H(D,D) using the finite string transformation rules specified by >> the semantics of the x86 programming language that reaches the >> behavior of the directly executed D(D) >> > > Why? I don't claim it can. > That means that H cannot even be asked the question: "Does D halt on its input?" > In fact, I have told you that I will not engage in your foolish idea of > what H can or can not do with its partial simulation of the input, until > you show why that has relevence. > The relevance keeps going over your head. > You seem to be stuck on that as way to try to avoid the issues that have > been pointed out in the other parts of your proof, which just confirms > that you really have no idea how to handle the issues pointed out. > *I am saying a whole BRAND-NEW-THING* There is no way to encode a decider and an input such that you can even ask H if D(D) halts when there is a pathological relationship between H and D. -- 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-06-13 23:04 -0400 |
| Subject | Re: D correctly simulated by H proved for THREE YEARS --- finite string transformation rules |
| Message-ID | <v4gc0b$3tn6r$6@i2pn2.org> |
| In reply to | #107085 |
On 6/13/24 9:39 PM, olcott wrote: > On 6/13/2024 8:24 PM, Richard Damon wrote: >> On 6/13/24 11:32 AM, olcott wrote: >>> On 6/13/2024 6:31 AM, Richard Damon wrote: >>>> On 6/12/24 11:58 PM, olcott wrote: >>>>> On 6/12/2024 10:45 PM, Richard Damon wrote: >>>>>> On 6/12/24 11:24 PM, olcott wrote: >>>>>>> On 6/12/2024 9:57 PM, Richard Damon wrote: >>>>>>>> On 6/12/24 10:21 PM, olcott wrote: >>>>>>>>> On 6/12/2024 9:06 PM, Richard Damon wrote: >>>>>>>>>> On 6/12/24 9:54 PM, olcott wrote: >>>>>>>>>>> On 6/12/2024 8:50 PM, Richard Damon wrote: >>>>>>>>>>>> On 6/12/24 9:19 PM, olcott wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> I am saying there is no mapping from the input TO THE >>>>>>>>>>>>> QUESTION. >>>>>>>>>>>>> H IS NOT EVEN BEING ASKED ABOUT THE BEHAVIOR OF D(D). >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> So, you admit that you are lying about H being a Halt Decider. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> No I admit that you are too stupid to understand what I am >>>>>>>>>>> saying. >>>>>>>>>> >>>>>>>>>> How is it a H >>>>>>>>>> >>>>>>>>> >>>>>>>>> I gave you the source-code. >>>>>>>> >>>>>>>> So? >>>>>>>> >>>>>>>> Last time I commented about somethihg from the source code you >>>>>>>> said that didn't apply. >>>>>>>> >>>>>>>> It also, as you have admitted, has bugs in its trace routine, so >>>>>>>> it can't produce a trace of the quality you seem to want. >>>>>>>> >>>>>>> >>>>>>> I never said anything like that. >>>>>> >>>>>> You admitted that it didn't produce the "Correct Simulation" >>>>>> output that it was supposed to produce. >>>>>> >>>>> >>>>> It was never supposed to produce this. >>>>> As I explain on page five of this other 2021 paper. >>>>> >>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation >>>> >>>> But acting as a "pure simulator until ..." is NOT the same as acting >>>> as a pure simulator. >>>> >>>> And thus the "transform" is invalid, as shown by the fact that P(P) >>>> halts even though H(P,P) uses its logic to say that it doesn't. >>>> >>>> Thus, your "logic" introduces a FALSE premise into its logic, and >>>> thus its conclusion is INVALID. >>>> >>>> Can you show an ACTUAL accepted statement that says you are allowed >>>> to do that transform, or is this just another of your "it seems >>>> right, so I will assume it to be right" statements that just makes >>>> your logic wrong. >>>> >>>> Your logic is just subject to the power of the paradox. >>>> >>>>> >>>>>> The output wasn't the simulation it did, but the execution trace >>>>>> of your decider itself. >>>>>> >>>>>>> >>>>>>>> Do you deny that with the H defined so that H(D,D) will return >>>>>>>> 0, as it does in your source code that making main() call D(D) >>>>>>>> that that D(D) will not return? >>>>>>>> >>>>>>>> You even posted a trace of that operation, but its trace has the >>>>>>>> same error that all your traces do, so I don't want to call that >>>>>>>> "Correct" any more, as that would be a LIE. >>>>>>>> >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Because Halt Deciders *ARE* being asked about the behavior >>>>>>>>>>>> of the machine their input describes, in this case D(D). >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> This never has been precisely correct. That is a dumbed down >>>>>>>>>>> version for people that do not really understand these things. >>>>>>>>>> >>>>>>>>>> Source for that claim? and not that it is just another of your >>>>>>>>>> unverifiable false claims? >>>>>>>>>> >>>>>>>>> >>>>>>>>> Actual comprehension is my source. That it is over-your-head >>>>>>>>> does not make me incorrect. >>>>>>>> >>>>>>>> I other words, you ADMIT that it is just a "I made itup" up, but >>>>>>>> it must be true" sort of statement, so doesn't actualuy have an >>>>>>>> accepted truth-maker for it, so is just a LIE. >>>>>>>> >>>>>>>> That's par for the course. >>>>>>>> >>>>>>>> That you can't actually show it, shows you ARE incorrect for >>>>>>>> claiming it. >>>>>>>> >>>>>>>>> >>>>>>>>> How do you think that halt deciders figure out the question that >>>>>>>>> they are being asked, do they look up the question on a textbook? >>>>>>>> >>>>>>>> They don't need to. There Programmer needs to figure that out. >>>>>>>> >>>>>>>> Programs don't "think", they "Compute", and do it per their >>>>>>>> instuctions given to them. >>>>>>>> >>>>>>>> You just don't seem to understand the essential nature of >>>>>>>> Programs do you. >>>>>>>> >>>>>>>>> >>>>>>>>>> You have a big list of things you have claimed but NEVER were >>>>>>>>>> able to show a proof, and thus effectively admitted that you >>>>>>>>>> made up your claims, which means they can be considered to be >>>>>>>>>> LIE. >>>>>>>>>> >>>>>>>>> >>>>>>>>> No it means that the reasoning behind them must be carefully >>>>>>>>> assessed. >>>>>>>> >>>>>>>> But you can't give any actual "reasoning", only your own >>>>>>>> unsubstantiated claims based on wrong defintions. >>>>>>>> >>>>>>> >>>>>>> *COMPUTE THE MAPPING FROM INPUTS* >>>>>>> Is currently totally over-your-head >>>>>>> yet has a specific meaning using those terms >>>>>>> according to their conventional meanings. >>>>>>> >>>>>>> Tell me in your own words what you think >>>>>>> COMPUTE THE MAPPING FROM INPUTS means. >>>>>> >>>>>> >>>>>> It takes the input, and TRIES to process them to the answer >>>>>> corresponding to the mapping it is supposed to be computing. >>>>>> >>>>>> Yes, ALL programs the meet the very basic definition of a decider >>>>>> (giving an answer for all possible input) computes SOME mapping of >>>>>> the input ot the output (which provides the count of the number of >>>>>> possible mappings that are computable). So H is some sort of decider, >>>>>> >>>>>> But to be a decider for a specific function, it needs to compute >>>>>> the mapping that matches that function. So, A Halt Decider, to be >>>>>> a HALT decider, needs to generate the exact same mapping as the >>>>>> Halting mathematical function, which is defined in terms of the >>>>>> behavior of the machine represented by the input. >>>>>> >>>>>> This seems to be just totally beyond your understanding, that >>>>>> there are actual REQUIREMENTS that must be met for something to be >>>>>> "Correct". >>>>>> >>>>>> Note, the word *THE* in your phrase meens a specific simgular >>>>>> mapping, that is the mapping defined by the function it is named for. >>>>>> >>>>>> Your H computes *A* mapping, but not the Halting Function mapping. >>>>>> And the exact details of that mapping is a function of the decider >>>>>> you create to try to compute it, as H and H1 generate different >>>>>> answers for the D built on H (and for the D1 built on H1). Thus >>>>>> your "POOP" mapping is different for each H you want to ask about, >>>>>> so in one sense, isn't even a correct question to be asking. >>>>>> >>>>>> It isn't asking about the decider deciding on the behavior of the >>>>>> input correctly simulated by itself, but the decider needing to >>>>>> decider on the behavior of the input correctly simulated by a >>>>>> particular H that was choosen. >>>>>> >>>>>> >>>>>>> >>>>>> >>>>> >>>>> Try and show the steps of the mapping that you expect in >>>>> terms of D correctly simulated by H, line by line. >>>> >>>> But I don't claim a mapping of D correctly simulated by H, as that >>>> is a INVALID criteria, as I explained. >>>> >>>> Since you call H a "Halt Decider", its criteria is, and can only be, >>>> the behavior of the directly executed D(D), or something that >>>> EXACTLY agrees with that behavior, >>>> >>> >>> It is contingent upon you to show the exact steps of how H computes >>> the mapping from the x86 machine language finite string input to >>> H(D,D) using the finite string transformation rules specified by >>> the semantics of the x86 programming language that reaches the >>> behavior of the directly executed D(D) >>> >> >> Why? I don't claim it can. >> > > That means that H cannot even be asked the question: > "Does D halt on its input?" WHy not? After all, H does what it does, the PERSON we ask is the programmer. We can ask them what H is supposed to do, and if they say Halt Decider, we pull out the definition, that H(<M>,d) needs to report on whether M(d) will halt when run, and we can check it. Since we see that H(<D>,<D>) doesn't report on the correct behavior of D(<D>) we can positively say that H is NOT a correct Halt Decider. We can also pose to the programmer > >> In fact, I have told you that I will not engage in your foolish idea >> of what H can or can not do with its partial simulation of the input, >> until you show why that has relevence. >> > > The relevance keeps going over your head. Nope, over yours. You don't "Ask a program to do something", but use a program to answer the question is was designed to answer. Yes, you could try to make a master decider, that you feed a description of the problem, and the inputs to answer it on. But, since Halting is proven impossible, that means that we can't build a master decider that can correctly solve the halting problem either. > >> You seem to be stuck on that as way to try to avoid the issues that >> have been pointed out in the other parts of your proof, which just >> confirms that you really have no idea how to handle the issues pointed >> out. >> > > *I am saying a whole BRAND-NEW-THING* > There is no way to encode a decider and an input such that > you can even ask H if D(D) halts when there is a pathological > relationship between H and D. > Yep, that was proven around 100 years ago, since you can't build a custom built decider to solve halting, you can't build a machine that takes a problem description and describe halting and get it to answer the question. You are just stuck with the clear fact that you keep on actually showing the statement to be true that you have been claiming to disprove, because you clearly don't understand what you are saying.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-13 22:14 -0500 |
| Subject | H(D,D) cannot even be asked about the behavior of D(D) |
| Message-ID | <v4gcjc$2msea$1@dont-email.me> |
| In reply to | #107097 |
On 6/13/2024 10:04 PM, Richard Damon wrote: > On 6/13/24 9:39 PM, olcott wrote: >> On 6/13/2024 8:24 PM, Richard Damon wrote: >>> On 6/13/24 11:32 AM, olcott wrote: >>>> >>>> It is contingent upon you to show the exact steps of how H computes >>>> the mapping from the x86 machine language finite string input to >>>> H(D,D) using the finite string transformation rules specified by >>>> the semantics of the x86 programming language that reaches the >>>> behavior of the directly executed D(D) >>>> >>> >>> Why? I don't claim it can. >>> >> >> That means that H cannot even be asked the question: >> "Does D halt on its input?" > > WHy not? After all, H does what it does, the PERSON we ask is the > programmer. > *When H and D have a pathological relationship to each other* There is no way to encode any H such that it can be asked: Does D(D) halt? You must see this from the POV of H or you won't get it. H cannot read your theory of computation textbooks, it only knows what it directly sees, its actual input. If there is no possible way for H to transform its input into the behavior of D(D) then H cannot be asked about the behavior of D(D). -- 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-06-13 23:44 -0400 |
| Subject | Re: H(D,D) cannot even be asked about the behavior of D(D) |
| Message-ID | <v4geab$3tn6r$8@i2pn2.org> |
| In reply to | #107099 |
On 6/13/24 11:14 PM, olcott wrote: > On 6/13/2024 10:04 PM, Richard Damon wrote: >> On 6/13/24 9:39 PM, olcott wrote: >>> On 6/13/2024 8:24 PM, Richard Damon wrote: >>>> On 6/13/24 11:32 AM, olcott wrote: >>>>> >>>>> It is contingent upon you to show the exact steps of how H computes >>>>> the mapping from the x86 machine language finite string input to >>>>> H(D,D) using the finite string transformation rules specified by >>>>> the semantics of the x86 programming language that reaches the >>>>> behavior of the directly executed D(D) >>>>> >>>> >>>> Why? I don't claim it can. >>>> >>> >>> That means that H cannot even be asked the question: >>> "Does D halt on its input?" >> >> WHy not? After all, H does what it does, the PERSON we ask is the >> programmer. >> > > *When H and D have a pathological relationship to each other* > There is no way to encode any H such that it can be asked: > Does D(D) halt? Which just pproves that Halting is non-computable. You keep on doing that, Making claims that show the truth of the statement you are trying to disprove. The fact you don't undrstand that, just show how little you understand what you are saying. > > You must see this from the POV of H or you won't get it. > H cannot read your theory of computation textbooks, it > only knows what it directly sees, its actual input. But H doesn't HAVE a "poimt of view". H is just a "mechanical" computation. It is a rote algorithm that does what it has been told to do. It really seems likem you just don't understand the concept of deterministic automatons, and Willful beings as being different. Which just shows how ignorant you are about what you talk about. > > If there is no possible way for H to transform its input > into the behavior of D(D) then H cannot be asked about > the behavior of D(D). > No, it says it can't do it, not that it can't be asked to do it. We are allowed to ask questions, that have answers, that are too hard to compute. THe input to H(D,D) DOES have a behaivor when run, so there IS a correct answer, so the question is valid. It just turns out to hard to be computed. You just don't understand the rules of the game, because it seems you never never even tried to learn them. This has cause you to show your utter ignoracnce of the topic, and your reckless disregard for the turth.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-13 23:13 -0500 |
| Subject | Re: H(D,D) cannot even be asked about the behavior of D(D) |
| Message-ID | <v4gg0s$2nim8$2@dont-email.me> |
| In reply to | #107100 |
On 6/13/2024 10:44 PM, Richard Damon wrote: > On 6/13/24 11:14 PM, olcott wrote: >> On 6/13/2024 10:04 PM, Richard Damon wrote: >>> On 6/13/24 9:39 PM, olcott wrote: >>>> On 6/13/2024 8:24 PM, Richard Damon wrote: >>>>> On 6/13/24 11:32 AM, olcott wrote: >>>>>> >>>>>> It is contingent upon you to show the exact steps of how H computes >>>>>> the mapping from the x86 machine language finite string input to >>>>>> H(D,D) using the finite string transformation rules specified by >>>>>> the semantics of the x86 programming language that reaches the >>>>>> behavior of the directly executed D(D) >>>>>> >>>>> >>>>> Why? I don't claim it can. >>>>> >>>> >>>> That means that H cannot even be asked the question: >>>> "Does D halt on its input?" >>> >>> WHy not? After all, H does what it does, the PERSON we ask is the >>> programmer. >>> >> >> *When H and D have a pathological relationship to each other* >> There is no way to encode any H such that it can be asked: >> Does D(D) halt? > > Which just pproves that Halting is non-computable. > No it is more than that. H cannot even be asked the question: Does D(D) halt? You already admitted the basis for this. > You keep on doing that, Making claims that show the truth of the > statement you are trying to disprove. > The fact you don't undrstand that, just show how little you understand > what you are saying. > >> >> You must see this from the POV of H or you won't get it. >> H cannot read your theory of computation textbooks, it >> only knows what it directly sees, its actual input. > > But H doesn't HAVE a "poimt of view". > When H is a simulating halt decider you can't even ask it about the behavior of D(D). You already said that it cannot map its input to the behavior of D(D). That means that you cannot ask H(D,D) about the behavior of D(D). What seems to me to be the world's leading termination analyzer symbolically executes its transformed input. https://link.springer.com/content/pdf/10.1007/978-3-030-99527-0_21.pdf It takes C programs and translates them into something like generic assembly language and then symbolically executes them to form a directed graph of their behavior. x86utm and HH do something similar in a much more limited fashion. > H is just a "mechanical" computation. It is a rote algorithm that does > what it has been told to do. > H cannot be asked the question Does DD(D) halt? There is no way to encode that. You already admitted this when you said the finite string input to H(D,D) cannot be mapped to the behavior of D(D). > It really seems likem you just don't understand the concept of > deterministic automatons, and Willful beings as being different. > > Which just shows how ignorant you are about what you talk about. > The issue is that you don't understand truthmaker theory. You can not simply correctly wave your hands to get H to know what question is being asked. >> >> If there is no possible way for H to transform its input >> into the behavior of D(D) then H cannot be asked about >> the behavior of D(D). >> > > No, it says it can't do it, not that it can't be asked to do it. > It can't even be asked. You said that yourself. The input to H(D,D) cannot be transformed into the behavior of D(D). -- 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-06-14 07:39 -0400 |
| Subject | Re: H(D,D) cannot even be asked about the behavior of D(D) |
| Message-ID | <v4ha63$3v16r$2@i2pn2.org> |
| In reply to | #107102 |
On 6/14/24 12:13 AM, olcott wrote: > On 6/13/2024 10:44 PM, Richard Damon wrote: >> On 6/13/24 11:14 PM, olcott wrote: >>> On 6/13/2024 10:04 PM, Richard Damon wrote: >>>> On 6/13/24 9:39 PM, olcott wrote: >>>>> On 6/13/2024 8:24 PM, Richard Damon wrote: >>>>>> On 6/13/24 11:32 AM, olcott wrote: >>>>>>> >>>>>>> It is contingent upon you to show the exact steps of how H computes >>>>>>> the mapping from the x86 machine language finite string input to >>>>>>> H(D,D) using the finite string transformation rules specified by >>>>>>> the semantics of the x86 programming language that reaches the >>>>>>> behavior of the directly executed D(D) >>>>>>> >>>>>> >>>>>> Why? I don't claim it can. >>>>>> >>>>> >>>>> That means that H cannot even be asked the question: >>>>> "Does D halt on its input?" >>>> >>>> WHy not? After all, H does what it does, the PERSON we ask is the >>>> programmer. >>>> >>> >>> *When H and D have a pathological relationship to each other* >>> There is no way to encode any H such that it can be asked: >>> Does D(D) halt? >> >> Which just pproves that Halting is non-computable. >> > > No it is more than that. > H cannot even be asked the question: > Does D(D) halt? No, you just don't understand the proper meaning of "ask" when applied to a deterministic entity. > > You already admitted the basis for this. No, that is something different. > >> You keep on doing that, Making claims that show the truth of the >> statement you are trying to disprove. >> The fact you don't undrstand that, just show how little you understand >> what you are saying. >> >>> >>> You must see this from the POV of H or you won't get it. >>> H cannot read your theory of computation textbooks, it >>> only knows what it directly sees, its actual input. >> >> But H doesn't HAVE a "poimt of view". >> > > When H is a simulating halt decider you can't even ask it > about the behavior of D(D). You already said that it cannot > map its input to the behavior of D(D). That means that you > cannot ask H(D,D) about the behavior of D(D). OF course you can, becaue, BY DEFIINITION, that is the ONLY thing it does with its inputs. > > What seems to me to be the world's leading termination > analyzer symbolically executes its transformed input. > https://link.springer.com/content/pdf/10.1007/978-3-030-99527-0_21.pdf > > It takes C programs and translates them into something like > generic assembly language and then symbolically executes them > to form a directed graph of their behavior. x86utm and HH do > something similar in a much more limited fashion. And note, it only gives difinitive answers for SOME input. > >> H is just a "mechanical" computation. It is a rote algorithm that does >> what it has been told to do. >> > > H cannot be asked the question Does DD(D) halt? > There is no way to encode that. You already admitted > this when you said the finite string input to H(D,D) > cannot be mapped to the behavior of D(D). It is every time it is given an input, at least if H is a halt decider. That is what halt deciders (if they exist) do. > >> It really seems likem you just don't understand the concept of >> deterministic automatons, and Willful beings as being different. >> >> Which just shows how ignorant you are about what you talk about. >> > > The issue is that you don't understand truthmaker theory. > You can not simply correctly wave your hands to get H to know > what question is being asked. No, YOU don't understand Truth. > >>> >>> If there is no possible way for H to transform its input >>> into the behavior of D(D) then H cannot be asked about >>> the behavior of D(D). >>> >> >> No, it says it can't do it, not that it can't be asked to do it. >> > > It can't even be asked. You said that yourself. > The input to H(D,D) cannot be transformed into > the behavior of D(D). > No, we can't make an arbitrary problem solver, since we can show there are unsolvable problems. Nothing says we can't encode the Halting Question into an input. What can't be done it create a program that gives the right answer for all such inputs. You, like normal, don't understand your requirements and capabilities.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-14 08:15 -0500 |
| Subject | Re: H(D,D) cannot even be asked about the behavior of D(D) |
| Message-ID | <v4hfq9$2sdqr$5@dont-email.me> |
| In reply to | #107106 |
On 6/14/2024 6:39 AM, Richard Damon wrote: > On 6/14/24 12:13 AM, olcott wrote: >> On 6/13/2024 10:44 PM, Richard Damon wrote: >>> On 6/13/24 11:14 PM, olcott wrote: >>>> On 6/13/2024 10:04 PM, Richard Damon wrote: >>>>> On 6/13/24 9:39 PM, olcott wrote: >>>>>> On 6/13/2024 8:24 PM, Richard Damon wrote: >>>>>>> On 6/13/24 11:32 AM, olcott wrote: >>>>>>>> >>>>>>>> It is contingent upon you to show the exact steps of how H computes >>>>>>>> the mapping from the x86 machine language finite string input to >>>>>>>> H(D,D) using the finite string transformation rules specified by >>>>>>>> the semantics of the x86 programming language that reaches the >>>>>>>> behavior of the directly executed D(D) >>>>>>>> >>>>>>> >>>>>>> Why? I don't claim it can. >>>>>>> >>>>>> >>>>>> That means that H cannot even be asked the question: >>>>>> "Does D halt on its input?" >>>>> >>>>> WHy not? After all, H does what it does, the PERSON we ask is the >>>>> programmer. >>>>> >>>> >>>> *When H and D have a pathological relationship to each other* >>>> There is no way to encode any H such that it can be asked: >>>> Does D(D) halt? >>> >>> Which just pproves that Halting is non-computable. >>> >> >> No it is more than that. >> H cannot even be asked the question: >> Does D(D) halt? > > No, you just don't understand the proper meaning of "ask" when applied > to a deterministic entity. > When H and D have a pathological relationship to each other then H(D,D) is not being asked about the behavior of D(D). H1(D,D) has no such pathological relationship thus D correctly simulated by H1 is the behavior of D(D). If I ask you: What time is it? and my actual unstated question is: What is the outside temperature where you are? Can a correct answer to the stated question be a correct answer to the unstated question? H(D,D) is not even being asked about the behavior of D(D) >> >> You already admitted the basis for this. > > No, that is something different. > >> >>> You keep on doing that, Making claims that show the truth of the >>> statement you are trying to disprove. >>> The fact you don't undrstand that, just show how little you >>> understand what you are saying. >>> >>>> >>>> You must see this from the POV of H or you won't get it. >>>> H cannot read your theory of computation textbooks, it >>>> only knows what it directly sees, its actual input. >>> >>> But H doesn't HAVE a "poimt of view". >>> >> >> When H is a simulating halt decider you can't even ask it >> about the behavior of D(D). You already said that it cannot >> map its input to the behavior of D(D). That means that you >> cannot ask H(D,D) about the behavior of D(D). > > OF course you can, becaue, BY DEFIINITION, that is the ONLY thing it > does with its inputs. > That definition might be in textbooks, yet H does not and cannot read textbooks. The only definition that H sees is the combination of its algorithm with the finite string of machine language of its input. It is impossible to encode any algorithm such that H and D have a pathological relationship and have H even see the behavior of D(D). You already admitted there there is no mapping from the finite string of machine code of the input to H(D,D) to the behavior of D(D). >> >> What seems to me to be the world's leading termination >> analyzer symbolically executes its transformed input. >> https://link.springer.com/content/pdf/10.1007/978-3-030-99527-0_21.pdf >> >> It takes C programs and translates them into something like >> generic assembly language and then symbolically executes them >> to form a directed graph of their behavior. x86utm and HH do >> something similar in a much more limited fashion. > > And note, it only gives difinitive answers for SOME input. > It is my understanding is that it does this much better than anyone else does. AProVE "symbolically executes the LLVM program". The LLVM program is essentially the C program translated into a generic assembly language. >> >>> H is just a "mechanical" computation. It is a rote algorithm that >>> does what it has been told to do. >>> >> >> H cannot be asked the question Does DD(D) halt? >> There is no way to encode that. You already admitted >> this when you said the finite string input to H(D,D) >> cannot be mapped to the behavior of D(D). > > It is every time it is given an input, at least if H is a halt decider. > If you cannot even ask H the question that you want answered then this is not an actual case of undecidability. H does correctly answer the actual question that it was actually asked. > That is what halt deciders (if they exist) do. > When H and D are defined to have a pathological relationship then H cannot even be asked about the behavior of D(D). >> >>> It really seems likem you just don't understand the concept of >>> deterministic automatons, and Willful beings as being different. >>> >>> Which just shows how ignorant you are about what you talk about. >>> >> >> The issue is that you don't understand truthmaker theory. >> You can not simply correctly wave your hands to get H to know >> what question is being asked. > > No, YOU don't understand Truth. > You understand truthmaker theory better than most experts in the field. The best expert in the field is only pretty sure that the Liar Paradox is not true. >> >>>> >>>> If there is no possible way for H to transform its input >>>> into the behavior of D(D) then H cannot be asked about >>>> the behavior of D(D). >>>> >>> >>> No, it says it can't do it, not that it can't be asked to do it. >>> >> >> It can't even be asked. You said that yourself. >> The input to H(D,D) cannot be transformed into >> the behavior of D(D). >> > > No, we can't make an arbitrary problem solver, since we can show there > are unsolvable problems. > That is a whole other different issue. The key subset of this is that the notion of undecidability is a ruse. > Nothing says we can't encode the Halting Question into an input. If there is no mapping from the input to H(D,D) to the behavior of D(D) then H cannot possibly be asked about behavior that it cannot possibly see. > What > can't be done it create a program that gives the right answer for all > such inputs. > Expecting a correct answer to the wrong question is only foolishness. > You, like normal, don't understand your requirements and capabilities. > -- 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 | joes <noreply@example.com> |
|---|---|
| Date | 2024-06-14 15:54 +0000 |
| Subject | Re: H(D,D) cannot even be asked about the behavior of D(D) |
| Message-ID | <v4hp3r$3viml$1@i2pn2.org> |
| In reply to | #107111 |
Am Fri, 14 Jun 2024 08:15:52 -0500 schrieb olcott: > On 6/14/2024 6:39 AM, Richard Damon wrote: >> On 6/14/24 12:13 AM, olcott wrote: >>> On 6/13/2024 10:44 PM, Richard Damon wrote: >>>> On 6/13/24 11:14 PM, olcott wrote: >>>>> On 6/13/2024 10:04 PM, Richard Damon wrote: >>>>>> On 6/13/24 9:39 PM, olcott wrote: >>>>>>> On 6/13/2024 8:24 PM, Richard Damon wrote: >>>>>>>> On 6/13/24 11:32 AM, olcott wrote: >>> H cannot even be asked the question: Does D(D) halt? >> No, you just don't understand the proper meaning of "ask" when applied >> to a deterministic entity. > When H and D have a pathological relationship to each other then H(D,D) > is not being asked about the behavior of D(D). H1(D,D) has no such > pathological relationship thus D correctly simulated by H1 is the > behavior of D(D). H is asked whether its input halts, and by definition should give the (right) answer for every input. D by construction is pathological to the supposed decider it is constructed on. H1 can not decide D1. For every "decider" we can construct an undecidable pathological program. No decider decides every input. > Can a correct answer to the stated question be a correct answer to the > unstated question? > H(D,D) is not even being asked about the behavior of D(D) It can't be asked any other way. >>> When H is a simulating halt decider you can't even ask it about the >>> behavior of D(D). You already said that it cannot map its input to the >>> behavior of D(D). That means that you cannot ask H(D,D) about the >>> behavior of D(D). >> OF course you can, becaue, BY DEFINITION, that is the ONLY thing it >> does with its inputs. > That definition might be in textbooks, > yet H does not and cannot read textbooks. That is very confusing. H still adheres to textbooks. > The only definition that H sees is the combination of its algorithm with > the finite string of machine language of its input. H does not see its own algorithm, it only follows its internal programming. A machine and input completely determine the behaviour, whether that is D(D) or H(D, D). > It is impossible to encode any algorithm such that H and D have a > pathological relationship and have H even see the behavior of D(D). H literally gets it as input. > You already admitted there there is no mapping from the finite string of > machine code of the input to H(D,D) to the behavior of D(D). Which means that H can't simulate D(D). Other machines can do so. >> And note, it only gives difinitive answers for SOME input. > It is my understanding is that it does this much better than anyone else > does. AProVE "symbolically executes the LLVM program". Better doesn't cut it. H should work for ALL programs, especially for D. >>>> H is just a "mechanical" computation. It is a rote algorithm that >>>> does what it has been told to do. >>> H cannot be asked the question Does D(D) halt? >>> There is no way to encode that. You already admitted this when you >>> said the finite string input to H(D,D) >>> cannot be mapped to the behavior of D(D). H answers that question for every other input. The question "What is your answer/Is your answer right?" is pointless and not even computed by H. >> It is every time it is given an input, at least if H is a halt decider. > If you cannot even ask H the question that you want answered then this > is not an actual case of undecidability. H does correctly answer the > actual question that it was actually asked. D(D) is a valid input. H should be universal. >> That is what halt deciders (if they exist) do. > When H and D are defined to have a pathological relationship then H > cannot even be asked about the behavior of D(D). H cannot give a correct ANSWER about D(D). >>>> It really seems likem you just don't understand the concept of >>>> deterministic automata, and Willful beings as being different. >>> You can not simply correctly wave your hands to get H to know what >>> question is being asked. H doesn't need to know. It is programmed to answer a fixed question, and the input completely determines the answer. >>> It can't even be asked. You said that yourself. >>> The input to H(D,D) cannot be transformed into the behavior of D(D). It can, just not by H. >> No, we can't make an arbitrary problem solver, since we can show there >> are unsolvable problems. > That is a whole other different issue. > The key subset of this is that the notion of undecidability is a ruse. A ruse for what? >> Nothing says we can't encode the Halting Question into an input. > If there is no mapping from the input to H(D,D) to the behavior of D(D) > then H cannot possibly be asked about behavior that it cannot possibly > see. It can be asked and be wrong. >> What can't be done it create a program that gives the right answer for >> all such inputs. > Expecting a correct answer to the wrong question is only foolishness. The question is just whether D(D) halts. Where do you disagree with the halting problem proof? -- joes
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-14 12:39 -0500 |
| Subject | Re: H(D,D) cannot even be asked about the behavior of D(D) |
| Message-ID | <v4hv85$3021v$1@dont-email.me> |
| In reply to | #107113 |
On 6/14/2024 10:54 AM, joes wrote:
> Am Fri, 14 Jun 2024 08:15:52 -0500 schrieb olcott:
>> On 6/14/2024 6:39 AM, Richard Damon wrote:
>>> On 6/14/24 12:13 AM, olcott wrote:
>>>> On 6/13/2024 10:44 PM, Richard Damon wrote:
>>>>> On 6/13/24 11:14 PM, olcott wrote:
>>>>>> On 6/13/2024 10:04 PM, Richard Damon wrote:
>>>>>>> On 6/13/24 9:39 PM, olcott wrote:
>>>>>>>> On 6/13/2024 8:24 PM, Richard Damon wrote:
>>>>>>>>> On 6/13/24 11:32 AM, olcott wrote:
>
>>>> H cannot even be asked the question: Does D(D) halt?
>>> No, you just don't understand the proper meaning of "ask" when applied
>>> to a deterministic entity.
>> When H and D have a pathological relationship to each other then H(D,D)
>> is not being asked about the behavior of D(D). H1(D,D) has no such
>> pathological relationship thus D correctly simulated by H1 is the
>> behavior of D(D).
> H is asked whether its input halts, and by definition should give the
> (right) answer for every input.
If we used that definition of decider then no human ever decided
anything because every human has made at least one mistake.
I use the term "termination analyzer" as a close fit. The term
partial halt decider is more accurate yet confuses most people.
A partial halt decider is a halt decider with a limited domain.
> D by construction is pathological to the supposed decider it is
> constructed on. H1 can not decide D1. For every "decider" we can construct
> an undecidable pathological program. No decider decides every input.
>
Parroting what you memorized by rote is not very deep understanding.
Understanding that the halting problem counter-example input that
does the opposite of whatever value the halt decider returns is
merely the Liar Paradox in disguise is a much deeper understanding.
>> Can a correct answer to the stated question be a correct answer to the
>> unstated question?
>> H(D,D) is not even being asked about the behavior of D(D)
>
> It can't be asked any other way.
>
It can't be asked in any way what-so-ever because it is
already being asked a different question.
>>>> When H is a simulating halt decider you can't even ask it about the
>>>> behavior of D(D). You already said that it cannot map its input to the
>>>> behavior of D(D). That means that you cannot ask H(D,D) about the
>>>> behavior of D(D).
>>> OF course you can, becaue, BY DEFINITION, that is the ONLY thing it
>>> does with its inputs.
>> That definition might be in textbooks,
>> yet H does not and cannot read textbooks.
>
> That is very confusing. H still adheres to textbooks.
>
No the textbooks have it incorrectly.
>> The only definition that H sees is the combination of its algorithm with
>> the finite string of machine language of its input.
> H does not see its own algorithm, it only follows its internal
> programming. A machine and input completely determine the behaviour,
> whether that is D(D) or H(D, D).
>
No H (with a pathological relationship to D) can possibly see the
behavior of D(D).
>> It is impossible to encode any algorithm such that H and D have a
>> pathological relationship and have H even see the behavior of D(D).
>
> H literally gets it as input.
>
The input DOES NOT SPECIFY THE BEHAVIOR OF D(D).
The input specifies the behavior WITHIN THE PATHOLOGICAL RELATIONSHIP
It does not specify the behavior WITHOUT THE PATHOLOGICAL RELATIONSHIP.
>> You already admitted there there is no mapping from the finite string of
>> machine code of the input to H(D,D) to the behavior of D(D).
>
> Which means that H can't simulate D(D). Other machines can do so.
>
H cannot simulate D(D) for the same reason that
int sum(int x, int y) { return x + y; }
sum(3,4) cannot return the sum of 5 + 6;
>>> And note, it only gives difinitive answers for SOME input.
>> It is my understanding is that it does this much better than anyone else
>> does. AProVE "symbolically executes the LLVM program".
>
> Better doesn't cut it. H should work for ALL programs, especially for D.
>
You don't even have a slight clue about termination analyzers.
>>>>> H is just a "mechanical" computation. It is a rote algorithm that
>>>>> does what it has been told to do.
>>>> H cannot be asked the question Does D(D) halt?
>>>> There is no way to encode that. You already admitted this when you
>>>> said the finite string input to H(D,D)
>>>> cannot be mapped to the behavior of D(D).
>
> H answers that question for every other input.
> The question "What is your answer/Is your answer right?" is pointless
> and not even computed by H.
>
It is ridiculously stupid to think that the pathological
relationship between H and D cannot possibly change the
behavior of D especially when it has been conclusively
proven that it DOES CHANGE THE BEHAVIOR OF D
>>> It is every time it is given an input, at least if H is a halt decider.
>> If you cannot even ask H the question that you want answered then this
>> is not an actual case of undecidability. H does correctly answer the
>> actual question that it was actually asked.
>
> D(D) is a valid input. H should be universal.
>
Likewise the Liar Paradox *should* be true or false,
except for the fact that it isn't.
>>> That is what halt deciders (if they exist) do.
>> When H and D are defined to have a pathological relationship then H
>> cannot even be asked about the behavior of D(D).
>
> H cannot give a correct ANSWER about D(D).
>
H cannot be asked the right question.
>>>>> It really seems likem you just don't understand the concept of
>>>>> deterministic automata, and Willful beings as being different.
>>>> You can not simply correctly wave your hands to get H to know what
>>>> question is being asked.
> H doesn't need to know. It is programmed to answer a fixed question,
> and the input completely determines the answer.
>
The fixed question that H is asked is:
Can your input terminate normally?
The answer to that question is: NO.
>>>> It can't even be asked. You said that yourself.
>>>> The input to H(D,D) cannot be transformed into the behavior of D(D).
> It can, just not by H.
>
How crazy is it to expect a correct answer to a
different question than the one you asked?
>>> No, we can't make an arbitrary problem solver, since we can show there
>>> are unsolvable problems.
>> That is a whole other different issue.
>> The key subset of this is that the notion of undecidability is a ruse.
> A ruse for what?
>
>>> Nothing says we can't encode the Halting Question into an input.
>> If there is no mapping from the input to H(D,D) to the behavior of D(D)
>> then H cannot possibly be asked about behavior that it cannot possibly
>> see.
> It can be asked and be wrong.
>
>>> What can't be done it create a program that gives the right answer for
>>> all such inputs.
>> Expecting a correct answer to the wrong question is only foolishness.
> The question is just whether D(D) halts.
>
> Where do you disagree with the halting problem proof?
>
There are several different issues the key one of these issues
that two PhD computer science professors agree with me on is
that there is something wrong with it along the lines of it
being isomorphic to the Liar Paradox.
--
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-06-14 19:27 -0400 |
| Subject | Re: H(D,D) cannot even be asked about the behavior of D(D) |
| Message-ID | <v4ijle$kqh$2@i2pn2.org> |
| In reply to | #107114 |
On 6/14/24 1:39 PM, olcott wrote:
> On 6/14/2024 10:54 AM, joes wrote:
>> Am Fri, 14 Jun 2024 08:15:52 -0500 schrieb olcott:
>>> On 6/14/2024 6:39 AM, Richard Damon wrote:
>>>> On 6/14/24 12:13 AM, olcott wrote:
>>>>> On 6/13/2024 10:44 PM, Richard Damon wrote:
>>>>>> On 6/13/24 11:14 PM, olcott wrote:
>>>>>>> On 6/13/2024 10:04 PM, Richard Damon wrote:
>>>>>>>> On 6/13/24 9:39 PM, olcott wrote:
>>>>>>>>> On 6/13/2024 8:24 PM, Richard Damon wrote:
>>>>>>>>>> On 6/13/24 11:32 AM, olcott wrote:
>>
>>>>> H cannot even be asked the question: Does D(D) halt?
>>>> No, you just don't understand the proper meaning of "ask" when applied
>>>> to a deterministic entity.
>>> When H and D have a pathological relationship to each other then H(D,D)
>>> is not being asked about the behavior of D(D). H1(D,D) has no such
>>> pathological relationship thus D correctly simulated by H1 is the
>>> behavior of D(D).
>> H is asked whether its input halts, and by definition should give the
>> (right) answer for every input.
>
> If we used that definition of decider then no human ever decided
> anything because every human has made at least one mistake.
But Humans are NOT deciders in the Computation Theory sense, because we
don't run deterministic algorithms.
This seems to be part of your fundamental problem, yiu just don't know
what you are talking about, and don't understand the difference between
willful beings, and deterministic algorithms.
> I use the term "termination analyzer" as a close fit. The term
> partial halt decider is more accurate yet confuses most people.
> A partial halt decider is a halt decider with a limited domain.
>
>> D by construction is pathological to the supposed decider it is
>> constructed on. H1 can not decide D1. For every "decider" we can
>> construct
>> an undecidable pathological program. No decider decides every input.
>>
>
> Parroting what you memorized by rote is not very deep understanding.
>
> Understanding that the halting problem counter-example input that
> does the opposite of whatever value the halt decider returns is
> merely the Liar Paradox in disguise is a much deeper understanding.
>
>>> Can a correct answer to the stated question be a correct answer to the
>>> unstated question?
>>> H(D,D) is not even being asked about the behavior of D(D)
> >
>> It can't be asked any other way.
>>
> It can't be asked in any way what-so-ever because it is
> already being asked a different question.
>
>>>>> When H is a simulating halt decider you can't even ask it about the
>>>>> behavior of D(D). You already said that it cannot map its input to the
>>>>> behavior of D(D). That means that you cannot ask H(D,D) about the
>>>>> behavior of D(D).
>>>> OF course you can, becaue, BY DEFINITION, that is the ONLY thing it
>>>> does with its inputs.
>>> That definition might be in textbooks,
>>> yet H does not and cannot read textbooks.
> >
>> That is very confusing. H still adheres to textbooks.
>>
> No the textbooks have it incorrectly.
>
>>> The only definition that H sees is the combination of its algorithm with
>>> the finite string of machine language of its input.
>
>> H does not see its own algorithm, it only follows its internal
>> programming. A machine and input completely determine the behaviour,
>> whether that is D(D) or H(D, D).
>>
>
> No H (with a pathological relationship to D) can possibly see the
> behavior of D(D).
>
>>> It is impossible to encode any algorithm such that H and D have a
>>> pathological relationship and have H even see the behavior of D(D).
> >
>> H literally gets it as input.
>>
>
> The input DOES NOT SPECIFY THE BEHAVIOR OF D(D).
> The input specifies the behavior WITHIN THE PATHOLOGICAL RELATIONSHIP
> It does not specify the behavior WITHOUT THE PATHOLOGICAL RELATIONSHIP.
>
>>> You already admitted there there is no mapping from the finite string of
>>> machine code of the input to H(D,D) to the behavior of D(D).
> >
>> Which means that H can't simulate D(D). Other machines can do so.
>>
>
> H cannot simulate D(D) for the same reason that
> int sum(int x, int y) { return x + y; }
> sum(3,4) cannot return the sum of 5 + 6;
>
>
>>>> And note, it only gives difinitive answers for SOME input.
>>> It is my understanding is that it does this much better than anyone else
>>> does. AProVE "symbolically executes the LLVM program".
> >
>> Better doesn't cut it. H should work for ALL programs, especially for D.
>>
>
> You don't even have a slight clue about termination analyzers.
>
>>>>>> H is just a "mechanical" computation. It is a rote algorithm that
>>>>>> does what it has been told to do.
>>>>> H cannot be asked the question Does D(D) halt?
>>>>> There is no way to encode that. You already admitted this when you
>>>>> said the finite string input to H(D,D)
>>>>> cannot be mapped to the behavior of D(D).
> >
>> H answers that question for every other input.
>> The question "What is your answer/Is your answer right?" is pointless
>> and not even computed by H.
>>
>
> It is ridiculously stupid to think that the pathological
> relationship between H and D cannot possibly change the
> behavior of D especially when it has been conclusively
> proven that it DOES CHANGE THE BEHAVIOR OF D
>
>>>> It is every time it is given an input, at least if H is a halt decider.
>>> If you cannot even ask H the question that you want answered then this
>>> is not an actual case of undecidability. H does correctly answer the
>>> actual question that it was actually asked.
> >
>> D(D) is a valid input. H should be universal.
>>
>
> Likewise the Liar Paradox *should* be true or false,
> except for the fact that it isn't.
>
>
>>>> That is what halt deciders (if they exist) do.
>>> When H and D are defined to have a pathological relationship then H
>>> cannot even be asked about the behavior of D(D).
> >
>> H cannot give a correct ANSWER about D(D).
>>
>
> H cannot be asked the right question.
>
>>>>>> It really seems likem you just don't understand the concept of
>>>>>> deterministic automata, and Willful beings as being different.
>>>>> You can not simply correctly wave your hands to get H to know what
>>>>> question is being asked.
>> H doesn't need to know. It is programmed to answer a fixed question,
>> and the input completely determines the answer.
>>
>
> The fixed question that H is asked is:
> Can your input terminate normally?
> The answer to that question is: NO.
>
>>>>> It can't even be asked. You said that yourself.
>>>>> The input to H(D,D) cannot be transformed into the behavior of D(D).
>> It can, just not by H.
>>
>
> How crazy is it to expect a correct answer to a
> different question than the one you asked?
>
>>>> No, we can't make an arbitrary problem solver, since we can show there
>>>> are unsolvable problems.
>>> That is a whole other different issue.
>>> The key subset of this is that the notion of undecidability is a ruse.
>> A ruse for what?
>>
>>>> Nothing says we can't encode the Halting Question into an input.
>>> If there is no mapping from the input to H(D,D) to the behavior of D(D)
>>> then H cannot possibly be asked about behavior that it cannot possibly
>>> see.
>> It can be asked and be wrong.
>>
>>>> What can't be done it create a program that gives the right answer for
>>>> all such inputs.
>>> Expecting a correct answer to the wrong question is only foolishness.
>> The question is just whether D(D) halts.
>>
>> Where do you disagree with the halting problem proof?
>>
>
> There are several different issues the key one of these issues
> that two PhD computer science professors agree with me on is
> that there is something wrong with it along the lines of it
> being isomorphic to the Liar Paradox.
>
[toc] | [prev] | [next] | [standalone]
| From | joes <noreply@example.com> |
|---|---|
| Date | 2024-06-15 11:34 +0000 |
| Subject | Re: H(D,D) cannot even be asked about the behavior of D(D) |
| Message-ID | <v4ju8f$222a$1@i2pn2.org> |
| In reply to | #107114 |
Am Fri, 14 Jun 2024 12:39:15 -0500 schrieb olcott:
> On 6/14/2024 10:54 AM, joes wrote:
>> Am Fri, 14 Jun 2024 08:15:52 -0500 schrieb olcott:
>>> On 6/14/2024 6:39 AM, Richard Damon wrote:
>>>> On 6/14/24 12:13 AM, olcott wrote:
>>>>> On 6/13/2024 10:44 PM, Richard Damon wrote:
>>>>>> On 6/13/24 11:14 PM, olcott wrote:
>>>>>>> On 6/13/2024 10:04 PM, Richard Damon wrote:
>>>>>>>> On 6/13/24 9:39 PM, olcott wrote:
>>>>>>>>> On 6/13/2024 8:24 PM, Richard Damon wrote:
>>>>>>>>>> On 6/13/24 11:32 AM, olcott wrote:
>>> When H and D have a pathological relationship to each other then
>>> H(D,D) is not being asked about the behavior of D(D). H1(D,D) has no
>>> such pathological relationship thus D correctly simulated by H1 is the
>>> behavior of D(D).
What is H1 asked?
>> H is asked whether its input halts, and by definition should give the
>> (right) answer for every input.
> If we used that definition of decider then no human ever decided
> anything because every human has made at least one mistake.
Yes. Humans are not machines.
> I use the term "termination analyzer" as a close fit. The term partial
> halt decider is more accurate yet confuses most people.
I have not seen you use that term before. You have not called it partial.
That was confusing.
>> D by construction is pathological to the supposed decider it is
>> constructed on. H1 can not decide D1. For every "decider" we can
>> construct an undecidable pathological program. No decider decides every
>> input.
> Parroting what you memorized by rote is not very deep understanding.
This was my own phrasing. Can you explain the halting problem proof?
> Understanding that the halting problem counter-example input that does
> the opposite of whatever value the halt decider returns is merely the
> Liar Paradox in disguise is a much deeper understanding.
I know that.
>>> H(D,D) is not even being asked about the behavior of D(D)
>> It can't be asked any other way.
> It can't be asked in any way what-so-ever because it is already being
> asked a different question.
Is that question "Do you answer yes?"?
>>>>> When H is a simulating halt decider you can't even ask it about the
>>>>> behavior of D(D). You already said that it cannot map its input to
>>>>> the behavior of D(D). That means that you cannot ask H(D,D) about
>>>>> the behavior of D(D).
>>>> OF course you can, becaue, BY DEFINITION, that is the ONLY thing it
>>>> does with its inputs.
>>> That definition might be in textbooks,
>>> yet H does not and cannot read textbooks.
>> That is very confusing. H still adheres to textbooks.
> No the textbooks have it incorrectly.
>>> The only definition that H sees is the combination of its algorithm
>>> with the finite string of machine language of its input.
>> H does not see its own algorithm, it only follows its internal
>> programming. A machine and input completely determine the behaviour,
>> whether that is D(D) or H(D, D).
> No H (with a pathological relationship to D) can possibly see the
> behavior of D(D).
That is not a problem with D, but with H not being total.
>>> It is impossible to encode any algorithm such that H and D have a
>>> pathological relationship and have H even see the behavior of D(D).
>> H literally gets it as input.
> The input DOES NOT SPECIFY THE BEHAVIOR OF D(D).
> The input specifies the behavior WITHIN THE PATHOLOGICAL RELATIONSHIP It
> does not specify the behavior WITHOUT THE PATHOLOGICAL RELATIONSHIP.
There is no difference. If an H exists, it gives one answer. D then does
the opposite. H cannot change its answer. Other analysers can see that
H gives the wrong answer.
>>> You already admitted there there is no mapping from the finite string
>>> of machine code of the input to H(D,D) to the behavior of D(D).
>> Which means that H can't simulate D(D). Other machines can do so.
> H cannot simulate D(D) for the same reason that int sum(int x, int y) {
> return x + y; } sum(3,4) cannot return the sum of 5 + 6;
>>>> And note, it only gives definitive answers for SOME input.
>>> It is my understanding is that it does this much better than anyone
>>> else does. AProVE "symbolically executes the LLVM program".
>> Better doesn't cut it. H should work for ALL programs, especially for
>> D.
> You don't even have a slight clue about termination analyzers.
Why do you say that? A (partial) termination analyser doesn't disprove
the halting problem.
>>>>> H cannot be asked the question Does D(D) halt?
>>>>> There is no way to encode that. You already admitted this when you
>>>>> said the finite string input to H(D,D)
>>>>> cannot be mapped to the behavior of D(D).
>> H answers that question for every other input.
>> The question "What is your answer/Is your answer right?" is pointless
>> and not even computed by H.
> It is ridiculously stupid to think that the pathological relationship
> between H and D cannot possibly change the behavior of D especially when
> it has been conclusively proven that it DOES CHANGE THE BEHAVIOR OF D
D as a machine is completely specified and a valid Turing machine:
It asks a supposed decider if it halts, and then does the opposite,
making the decider wrong.
Other deciders than the one it calls can simulate or decide it.
D has exactly one fixed behaviour, like all TMs.
The behaviour of H should change because of the recursion, but it has to
make up its mind. D goes "I'm gonna do the opposite of what you said".
>>> If you cannot even ask H the question that you want answered then this
>>> is not an actual case of undecidability. H does correctly answer the
>>> actual question that it was actually asked.
That would be the wrong question.
>> D(D) is a valid input. H should be universal.
> Likewise the Liar Paradox *should* be true or false,
> except for the fact that it isn't.
>>> When H and D are defined to have a pathological relationship then H
>>> cannot even be asked about the behavior of D(D).
>> H cannot give a correct ANSWER about D(D).
> H cannot be asked the right question.
Then H would be faulty.
>>>>> You can not simply wave your hands to get H to know what
>>>>> question is being asked.
>> H doesn't need to know. It is programmed to answer a fixed question,
>> and the input completely determines the answer.
> The fixed question that H is asked is:
> Can your input terminate normally?
Does the input terminate, rather.
> The answer to that question is: NO.
If that were so, this would be given to D, since it asks H about itself.
In this case, it would actually terminate. If H said Yes, it would go
into an infinite loop.
>>>>> It can't even be asked. You said that yourself.
>>>>> The input to H(D,D) cannot be transformed into the behavior of D(D).
>> It can, just not by H.
> How crazy is it to expect a correct answer to a different question than
> the one you asked?
>>>> No, we can't make an arbitrary problem solver, since we can show
>>>> there are unsolvable problems.
>>> That is a whole other different issue.
>>> The key subset of this is that the notion of undecidability is a ruse.
>> A ruse for what?
There are undecidable problems. Like halting.
>>>> Nothing says we can't encode the Halting Question into an input.
>>> If there is no mapping from the input to H(D,D) to the behavior of
>>> D(D) then H cannot possibly be asked about behavior that it cannot
>>> possibly see.
>> It can be asked and be wrong.
>>>> What can't be done is create a program that gives the right answer
>>>> for all such inputs.
>>> Expecting a correct answer to the wrong question is only foolishness.
>> The question is just whether D(D) halts.
>> Where do you disagree with the halting problem proof?
> There are several different issues the key one of these issues [...]
> is that there is something wrong with it along the lines of it being
> isomorphic to the Liar Paradox.
"Something along the lines"? Can you point to the step where you disagree?
Thanks for your extended reply.
--
joes
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-15 07:21 -0500 |
| Subject | Re: H(D,D) cannot even be asked about the behavior of D(D) |
| Message-ID | <v4k10h$3f0hc$3@dont-email.me> |
| In reply to | #107151 |
On 6/15/2024 6:34 AM, joes wrote:
> Am Fri, 14 Jun 2024 12:39:15 -0500 schrieb olcott:
>> On 6/14/2024 10:54 AM, joes wrote:
>>> Am Fri, 14 Jun 2024 08:15:52 -0500 schrieb olcott:
>>>> On 6/14/2024 6:39 AM, Richard Damon wrote:
>>>>> On 6/14/24 12:13 AM, olcott wrote:
>>>>>> On 6/13/2024 10:44 PM, Richard Damon wrote:
>>>>>>> On 6/13/24 11:14 PM, olcott wrote:
>>>>>>>> On 6/13/2024 10:04 PM, Richard Damon wrote:
>>>>>>>>> On 6/13/24 9:39 PM, olcott wrote:
>>>>>>>>>> On 6/13/2024 8:24 PM, Richard Damon wrote:
>>>>>>>>>>> On 6/13/24 11:32 AM, olcott wrote:
>
>>>> When H and D have a pathological relationship to each other then
>>>> H(D,D) is not being asked about the behavior of D(D). H1(D,D) has no
>>>> such pathological relationship thus D correctly simulated by H1 is the
>>>> behavior of D(D).
> What is H1 asked?
>>> H is asked whether its input halts, and by definition should give the
>>> (right) answer for every input.
>> If we used that definition of decider then no human ever decided
>> anything because every human has made at least one mistake.
> Yes. Humans are not machines.
>> I use the term "termination analyzer" as a close fit. The term partial
>> halt decider is more accurate yet confuses most people.
> I have not seen you use that term before. You have not called it partial.
> That was confusing.
>
>>> D by construction is pathological to the supposed decider it is
>>> constructed on. H1 can not decide D1. For every "decider" we can
>>> construct an undecidable pathological program. No decider decides every
>>> input.
>> Parroting what you memorized by rote is not very deep understanding.
> This was my own phrasing. Can you explain the halting problem proof?
>> Understanding that the halting problem counter-example input that does
>> the opposite of whatever value the halt decider returns is merely the
>> Liar Paradox in disguise is a much deeper understanding.
>
> I know that.
>
If you really knew that then you would know that the
Halting probe is a mere ruse.
>>>> H(D,D) is not even being asked about the behavior of D(D)
>>> It can't be asked any other way.
>> It can't be asked in any way what-so-ever because it is already being
>> asked a different question.
> Is that question "Do you answer yes?"?
>
>>>>>> When H is a simulating halt decider you can't even ask it about the
>>>>>> behavior of D(D). You already said that it cannot map its input to
>>>>>> the behavior of D(D). That means that you cannot ask H(D,D) about
>>>>>> the behavior of D(D).
>>>>> OF course you can, becaue, BY DEFINITION, that is the ONLY thing it
>>>>> does with its inputs.
>>>> That definition might be in textbooks,
>>>> yet H does not and cannot read textbooks.
>>> That is very confusing. H still adheres to textbooks.
>> No the textbooks have it incorrectly.
>
>
>>>> The only definition that H sees is the combination of its algorithm
>>>> with the finite string of machine language of its input.
>>> H does not see its own algorithm, it only follows its internal
>>> programming. A machine and input completely determine the behaviour,
>>> whether that is D(D) or H(D, D).
>> No H (with a pathological relationship to D) can possibly see the
>> behavior of D(D).
> That is not a problem with D, but with H not being total.
>
>>>> It is impossible to encode any algorithm such that H and D have a
>>>> pathological relationship and have H even see the behavior of D(D).
>>> H literally gets it as input.
>> The input DOES NOT SPECIFY THE BEHAVIOR OF D(D).
>> The input specifies the behavior WITHIN THE PATHOLOGICAL RELATIONSHIP It
>> does not specify the behavior WITHOUT THE PATHOLOGICAL RELATIONSHIP.
> There is no difference. If an H exists, it gives one answer. D then does
> the opposite. H cannot change its answer. Other analysers can see that
> H gives the wrong answer.
>
>>>> You already admitted there there is no mapping from the finite string
>>>> of machine code of the input to H(D,D) to the behavior of D(D).
>>> Which means that H can't simulate D(D). Other machines can do so.
>> H cannot simulate D(D) for the same reason that int sum(int x, int y) {
>> return x + y; } sum(3,4) cannot return the sum of 5 + 6;
>
>>>>> And note, it only gives definitive answers for SOME input.
>>>> It is my understanding is that it does this much better than anyone
>>>> else does. AProVE "symbolically executes the LLVM program".
>>> Better doesn't cut it. H should work for ALL programs, especially for
>>> D.
>> You don't even have a slight clue about termination analyzers.
> Why do you say that? A (partial) termination analyser doesn't disprove
> the halting problem.
>
>>>>>> H cannot be asked the question Does D(D) halt?
>>>>>> There is no way to encode that. You already admitted this when you
>>>>>> said the finite string input to H(D,D)
>>>>>> cannot be mapped to the behavior of D(D).
>>> H answers that question for every other input.
>>> The question "What is your answer/Is your answer right?" is pointless
>>> and not even computed by H.
>> It is ridiculously stupid to think that the pathological relationship
>> between H and D cannot possibly change the behavior of D especially when
>> it has been conclusively proven that it DOES CHANGE THE BEHAVIOR OF D
> D as a machine is completely specified and a valid Turing machine:
> It asks a supposed decider if it halts, and then does the opposite,
> making the decider wrong.
> Other deciders than the one it calls can simulate or decide it.
> D has exactly one fixed behaviour, like all TMs.
> The behaviour of H should change because of the recursion, but it has to
> make up its mind. D goes "I'm gonna do the opposite of what you said".
>
>>>> If you cannot even ask H the question that you want answered then this
>>>> is not an actual case of undecidability. H does correctly answer the
>>>> actual question that it was actually asked.
> That would be the wrong question.
>>> D(D) is a valid input. H should be universal.
>> Likewise the Liar Paradox *should* be true or false,
>> except for the fact that it isn't.
>
>>>> When H and D are defined to have a pathological relationship then H
>>>> cannot even be asked about the behavior of D(D).
>>> H cannot give a correct ANSWER about D(D).
>> H cannot be asked the right question.
> Then H would be faulty.
>
>>>>>> You can not simply wave your hands to get H to know what
>>>>>> question is being asked.
>>> H doesn't need to know. It is programmed to answer a fixed question,
>>> and the input completely determines the answer.
>> The fixed question that H is asked is:
>> Can your input terminate normally?
> Does the input terminate, rather.
>> The answer to that question is: NO.
> If that were so, this would be given to D, since it asks H about itself.
> In this case, it would actually terminate. If H said Yes, it would go
> into an infinite loop.
>
>>>>>> It can't even be asked. You said that yourself.
>>>>>> The input to H(D,D) cannot be transformed into the behavior of D(D).
>>> It can, just not by H.
>> How crazy is it to expect a correct answer to a different question than
>> the one you asked?
>
>>>>> No, we can't make an arbitrary problem solver, since we can show
>>>>> there are unsolvable problems.
>>>> That is a whole other different issue.
>>>> The key subset of this is that the notion of undecidability is a ruse.
>>> A ruse for what?
> There are undecidable problems. Like halting.
>
>>>>> Nothing says we can't encode the Halting Question into an input.
>>>> If there is no mapping from the input to H(D,D) to the behavior of
>>>> D(D) then H cannot possibly be asked about behavior that it cannot
>>>> possibly see.
No it cannot even be asked and the technical details
of this are over everyone's head.
Computing the map from the input to H(D,D) to the
behavior of D(D) has nothing to do with Google maps.
>>> It can be asked and be wrong.
>
>>>>> What can't be done is create a program that gives the right answer
>>>>> for all such inputs.
>>>> Expecting a correct answer to the wrong question is only foolishness.
>>> The question is just whether D(D) halts.
>>> Where do you disagree with the halting problem proof?
>> There are several different issues the key one of these issues [...]
>> is that there is something wrong with it along the lines of it being
>> isomorphic to the Liar Paradox.
> "Something along the lines"? Can you point to the step where you disagree?
>
> Thanks for your extended reply.
>
You don't hardly have any clue about any of this.
--
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-06-15 09:52 -0400 |
| Subject | Re: H(D,D) cannot even be asked about the behavior of D(D) |
| Message-ID | <v4k6a2$2218$6@i2pn2.org> |
| In reply to | #107159 |
On 6/15/24 8:21 AM, olcott wrote:
> On 6/15/2024 6:34 AM, joes wrote:
>> Am Fri, 14 Jun 2024 12:39:15 -0500 schrieb olcott:
>>> On 6/14/2024 10:54 AM, joes wrote:
>>>> Am Fri, 14 Jun 2024 08:15:52 -0500 schrieb olcott:
>>>>> On 6/14/2024 6:39 AM, Richard Damon wrote:
>>>>>> On 6/14/24 12:13 AM, olcott wrote:
>>>>>>> On 6/13/2024 10:44 PM, Richard Damon wrote:
>>>>>>>> On 6/13/24 11:14 PM, olcott wrote:
>>>>>>>>> On 6/13/2024 10:04 PM, Richard Damon wrote:
>>>>>>>>>> On 6/13/24 9:39 PM, olcott wrote:
>>>>>>>>>>> On 6/13/2024 8:24 PM, Richard Damon wrote:
>>>>>>>>>>>> On 6/13/24 11:32 AM, olcott wrote:
>>
>>>>> When H and D have a pathological relationship to each other then
>>>>> H(D,D) is not being asked about the behavior of D(D). H1(D,D) has no
>>>>> such pathological relationship thus D correctly simulated by H1 is the
>>>>> behavior of D(D).
>> What is H1 asked?
>>>> H is asked whether its input halts, and by definition should give the
>>>> (right) answer for every input.
>>> If we used that definition of decider then no human ever decided
>>> anything because every human has made at least one mistake.
>> Yes. Humans are not machines.
>>> I use the term "termination analyzer" as a close fit. The term partial
>>> halt decider is more accurate yet confuses most people.
>> I have not seen you use that term before. You have not called it partial.
>> That was confusing.
>>
>>>> D by construction is pathological to the supposed decider it is
>>>> constructed on. H1 can not decide D1. For every "decider" we can
>>>> construct an undecidable pathological program. No decider decides every
>>>> input.
>>> Parroting what you memorized by rote is not very deep understanding.
>> This was my own phrasing. Can you explain the halting problem proof?
>>> Understanding that the halting problem counter-example input that does
>>> the opposite of whatever value the halt decider returns is merely the
>>> Liar Paradox in disguise is a much deeper understanding.
> >
>> I know that.
>>
>
> If you really knew that then you would know that the
> Halting probe is a mere ruse.
No, the Halting Problem is a real problem.
Your "rebuttal" is the Ruse, because it LIES about what it is doing
>
>>>>> H(D,D) is not even being asked about the behavior of D(D)
>>>> It can't be asked any other way.
>>> It can't be asked in any way what-so-ever because it is already being
>>> asked a different question.
>> Is that question "Do you answer yes?"?
>>
>>>>>>> When H is a simulating halt decider you can't even ask it about the
>>>>>>> behavior of D(D). You already said that it cannot map its input to
>>>>>>> the behavior of D(D). That means that you cannot ask H(D,D) about
>>>>>>> the behavior of D(D).
>>>>>> OF course you can, becaue, BY DEFINITION, that is the ONLY thing it
>>>>>> does with its inputs.
>>>>> That definition might be in textbooks,
>>>>> yet H does not and cannot read textbooks.
>>>> That is very confusing. H still adheres to textbooks.
>>> No the textbooks have it incorrectly.
>>
>>
>>>>> The only definition that H sees is the combination of its algorithm
>>>>> with the finite string of machine language of its input.
>>>> H does not see its own algorithm, it only follows its internal
>>>> programming. A machine and input completely determine the behaviour,
>>>> whether that is D(D) or H(D, D).
>>> No H (with a pathological relationship to D) can possibly see the
>>> behavior of D(D).
>> That is not a problem with D, but with H not being total.
>>
>>>>> It is impossible to encode any algorithm such that H and D have a
>>>>> pathological relationship and have H even see the behavior of D(D).
>>>> H literally gets it as input.
>>> The input DOES NOT SPECIFY THE BEHAVIOR OF D(D).
>>> The input specifies the behavior WITHIN THE PATHOLOGICAL RELATIONSHIP It
>>> does not specify the behavior WITHOUT THE PATHOLOGICAL RELATIONSHIP.
>> There is no difference. If an H exists, it gives one answer. D then does
>> the opposite. H cannot change its answer. Other analysers can see that
>> H gives the wrong answer.
>>
>>>>> You already admitted there there is no mapping from the finite string
>>>>> of machine code of the input to H(D,D) to the behavior of D(D).
>>>> Which means that H can't simulate D(D). Other machines can do so.
>>> H cannot simulate D(D) for the same reason that int sum(int x, int y) {
>>> return x + y; } sum(3,4) cannot return the sum of 5 + 6;
>>
>>>>>> And note, it only gives definitive answers for SOME input.
>>>>> It is my understanding is that it does this much better than anyone
>>>>> else does. AProVE "symbolically executes the LLVM program".
>>>> Better doesn't cut it. H should work for ALL programs, especially for
>>>> D.
>>> You don't even have a slight clue about termination analyzers.
>> Why do you say that? A (partial) termination analyser doesn't disprove
>> the halting problem.
>>
>>>>>>> H cannot be asked the question Does D(D) halt?
>>>>>>> There is no way to encode that. You already admitted this when you
>>>>>>> said the finite string input to H(D,D)
>>>>>>> cannot be mapped to the behavior of D(D).
>>>> H answers that question for every other input.
>>>> The question "What is your answer/Is your answer right?" is pointless
>>>> and not even computed by H.
>>> It is ridiculously stupid to think that the pathological relationship
>>> between H and D cannot possibly change the behavior of D especially when
>>> it has been conclusively proven that it DOES CHANGE THE BEHAVIOR OF D
>> D as a machine is completely specified and a valid Turing machine:
>> It asks a supposed decider if it halts, and then does the opposite,
>> making the decider wrong.
>> Other deciders than the one it calls can simulate or decide it.
>> D has exactly one fixed behaviour, like all TMs.
>> The behaviour of H should change because of the recursion, but it has to
>> make up its mind. D goes "I'm gonna do the opposite of what you said".
>>
>>>>> If you cannot even ask H the question that you want answered then this
>>>>> is not an actual case of undecidability. H does correctly answer the
>>>>> actual question that it was actually asked.
>> That would be the wrong question.
>>>> D(D) is a valid input. H should be universal.
>>> Likewise the Liar Paradox *should* be true or false,
>>> except for the fact that it isn't.
>>
>>>>> When H and D are defined to have a pathological relationship then H
>>>>> cannot even be asked about the behavior of D(D).
>>>> H cannot give a correct ANSWER about D(D).
>>> H cannot be asked the right question.
>> Then H would be faulty.
>>
>>>>>>> You can not simply wave your hands to get H to know what
>>>>>>> question is being asked.
>>>> H doesn't need to know. It is programmed to answer a fixed question,
>>>> and the input completely determines the answer.
>>> The fixed question that H is asked is:
>>> Can your input terminate normally?
>> Does the input terminate, rather.
>>> The answer to that question is: NO.
>> If that were so, this would be given to D, since it asks H about itself.
>> In this case, it would actually terminate. If H said Yes, it would go
>> into an infinite loop.
>>
>>>>>>> It can't even be asked. You said that yourself.
>>>>>>> The input to H(D,D) cannot be transformed into the behavior of D(D).
>>>> It can, just not by H.
>>> How crazy is it to expect a correct answer to a different question than
>>> the one you asked?
>>
>>>>>> No, we can't make an arbitrary problem solver, since we can show
>>>>>> there are unsolvable problems.
>>>>> That is a whole other different issue.
>>>>> The key subset of this is that the notion of undecidability is a ruse.
>>>> A ruse for what?
>> There are undecidable problems. Like halting.
>>
>>>>>> Nothing says we can't encode the Halting Question into an input.
>>>>> If there is no mapping from the input to H(D,D) to the behavior of
>>>>> D(D) then H cannot possibly be asked about behavior that it cannot
>>>>> possibly see.
>
> No it cannot even be asked and the technical details
> of this are over everyone's head.
But it can be asked.
The fact you don't understand how just shows your own mental abiltity,
not anything about the problem itself.
>
> Computing the map from the input to H(D,D) to the
> behavior of D(D) has nothing to do with Google maps.
>
>>>> It can be asked and be wrong.
>>
>>>>>> What can't be done is create a program that gives the right answer
>>>>>> for all such inputs.
>>>>> Expecting a correct answer to the wrong question is only foolishness.
>>>> The question is just whether D(D) halts.
>>>> Where do you disagree with the halting problem proof?
>>> There are several different issues the key one of these issues [...]
>>> is that there is something wrong with it along the lines of it being
>>> isomorphic to the Liar Paradox.
>> "Something along the lines"? Can you point to the step where you
>> disagree?
>>
>> Thanks for your extended reply.
>>
>
> You don't hardly have any clue about any of this.
>
No, *YOU* have proven you don't know anything about this, and have
admitted it yourself a number of times.
[toc] | [prev] | [next] | [standalone]
| From | Mikko <mikko.levanto@iki.fi> |
|---|---|
| Date | 2024-06-15 15:33 +0300 |
| Subject | Re: H(D,D) cannot even be asked about the behavior of D(D) |
| Message-ID | <v4k1m4$3f99u$1@dont-email.me> |
| In reply to | #107151 |
On 2024-06-15 11:34:39 +0000, joes said: > Am Fri, 14 Jun 2024 12:39:15 -0500 schrieb olcott: >> On 6/14/2024 10:54 AM, joes wrote: >>> Am Fri, 14 Jun 2024 08:15:52 -0500 schrieb olcott: >>>> On 6/14/2024 6:39 AM, Richard Damon wrote: >>>>> On 6/14/24 12:13 AM, olcott wrote: >>>>>> On 6/13/2024 10:44 PM, Richard Damon wrote: >>>>>>> On 6/13/24 11:14 PM, olcott wrote: >>>>>>>> On 6/13/2024 10:04 PM, Richard Damon wrote: >>>>>>>>> On 6/13/24 9:39 PM, olcott wrote: >>>>>>>>>> On 6/13/2024 8:24 PM, Richard Damon wrote: >>>>>>>>>>> On 6/13/24 11:32 AM, olcott wrote: > >>>> When H and D have a pathological relationship to each other then >>>> H(D,D) is not being asked about the behavior of D(D). H1(D,D) has no >>>> such pathological relationship thus D correctly simulated by H1 is the >>>> behavior of D(D). > What is H1 asked? >>> H is asked whether its input halts, and by definition should give the >>> (right) answer for every input. >> If we used that definition of decider then no human ever decided >> anything because every human has made at least one mistake. > Yes. Humans are not machines. >> I use the term "termination analyzer" as a close fit. The term partial >> halt decider is more accurate yet confuses most people. Olcott has used the term "termination analyzer", though whether he knows what it means is unclear. The main difference is that a halt decider or partial halt decider takes descriptions of both a Turing machine (or other program) and an input and determines whether that machine halts with that input but a termination analyzer takes only the dexcription of a Turing machine (or other program) and attempts to determine whether that machine halts with every input. The term "analyzer" instead "decider" indicates that it may fail to determine on some inputs and that it may produce additional information that may be useful. The intent is to create termination analyzers that are useful for practical purposes. -- Mikko
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-15 08:24 -0500 |
| Subject | Re: H(D,D) cannot even be asked about the behavior of D(D) |
| Message-ID | <v4k4mt$3fnqu$1@dont-email.me> |
| In reply to | #107162 |
On 6/15/2024 7:33 AM, Mikko wrote: > On 2024-06-15 11:34:39 +0000, joes said: > >> Am Fri, 14 Jun 2024 12:39:15 -0500 schrieb olcott: >>> On 6/14/2024 10:54 AM, joes wrote: >>>> Am Fri, 14 Jun 2024 08:15:52 -0500 schrieb olcott: >>>>> On 6/14/2024 6:39 AM, Richard Damon wrote: >>>>>> On 6/14/24 12:13 AM, olcott wrote: >>>>>>> On 6/13/2024 10:44 PM, Richard Damon wrote: >>>>>>>> On 6/13/24 11:14 PM, olcott wrote: >>>>>>>>> On 6/13/2024 10:04 PM, Richard Damon wrote: >>>>>>>>>> On 6/13/24 9:39 PM, olcott wrote: >>>>>>>>>>> On 6/13/2024 8:24 PM, Richard Damon wrote: >>>>>>>>>>>> On 6/13/24 11:32 AM, olcott wrote: >> >>>>> When H and D have a pathological relationship to each other then >>>>> H(D,D) is not being asked about the behavior of D(D). H1(D,D) has no >>>>> such pathological relationship thus D correctly simulated by H1 is the >>>>> behavior of D(D). >> What is H1 asked? >>>> H is asked whether its input halts, and by definition should give the >>>> (right) answer for every input. >>> If we used that definition of decider then no human ever decided >>> anything because every human has made at least one mistake. >> Yes. Humans are not machines. >>> I use the term "termination analyzer" as a close fit. The term partial >>> halt decider is more accurate yet confuses most people. > > Olcott has used the term "termination analyzer", though whether he knows > what it means is unclear. > To prove (non-)termination of a C program, AProVE uses the Clang compiler [7] to translate it to the intermediate representation of the LLVM framework [15]. Then AProVE symbolically executes the LLVM program and uses abstraction to obtain a finite symbolic execution graph (SEG) containing all possible program runs. *AProVE: Non-Termination Witnesses for C Programs* https://link.springer.com/content/pdf/10.1007/978-3-030-99527-0_21.pdf > The main difference is that a halt decider or partial halt decider takes > descriptions of both a Turing machine (or other program) and an input and > determines whether that machine halts with that input H(D,D) is only required to get this one input correctly thus H is a halt decider with a domain restricted to D. > but a termination > analyzer takes only the dexcription of a Turing machine (or other program) > and attempts to determine whether that machine halts with every input. > The term "analyzer" instead "decider" indicates that it may fail to > determine on some inputs Yes that is the distinction that I intend. > and that it may produce additional information > that may be useful. The intent is to create termination analyzers that > are useful for practical purposes. > -- 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-06-15 09:51 -0400 |
| Subject | Re: H(D,D) cannot even be asked about the behavior of D(D) |
| Message-ID | <v4k69r$2218$5@i2pn2.org> |
| In reply to | #107166 |
On 6/15/24 9:24 AM, olcott wrote: > On 6/15/2024 7:33 AM, Mikko wrote: >> On 2024-06-15 11:34:39 +0000, joes said: >> >>> Am Fri, 14 Jun 2024 12:39:15 -0500 schrieb olcott: >>>> On 6/14/2024 10:54 AM, joes wrote: >>>>> Am Fri, 14 Jun 2024 08:15:52 -0500 schrieb olcott: >>>>>> On 6/14/2024 6:39 AM, Richard Damon wrote: >>>>>>> On 6/14/24 12:13 AM, olcott wrote: >>>>>>>> On 6/13/2024 10:44 PM, Richard Damon wrote: >>>>>>>>> On 6/13/24 11:14 PM, olcott wrote: >>>>>>>>>> On 6/13/2024 10:04 PM, Richard Damon wrote: >>>>>>>>>>> On 6/13/24 9:39 PM, olcott wrote: >>>>>>>>>>>> On 6/13/2024 8:24 PM, Richard Damon wrote: >>>>>>>>>>>>> On 6/13/24 11:32 AM, olcott wrote: >>> >>>>>> When H and D have a pathological relationship to each other then >>>>>> H(D,D) is not being asked about the behavior of D(D). H1(D,D) has no >>>>>> such pathological relationship thus D correctly simulated by H1 is >>>>>> the >>>>>> behavior of D(D). >>> What is H1 asked? >>>>> H is asked whether its input halts, and by definition should give the >>>>> (right) answer for every input. >>>> If we used that definition of decider then no human ever decided >>>> anything because every human has made at least one mistake. >>> Yes. Humans are not machines. >>>> I use the term "termination analyzer" as a close fit. The term partial >>>> halt decider is more accurate yet confuses most people. >> >> Olcott has used the term "termination analyzer", though whether he knows >> what it means is unclear. >> > > To prove (non-)termination of a C program, AProVE uses the Clang > compiler [7] to translate it to the intermediate representation of the > LLVM framework [15]. Then AProVE symbolically executes the LLVM program > and uses abstraction to obtain a finite symbolic execution graph (SEG) > containing all possible program runs. > > *AProVE: Non-Termination Witnesses for C Programs* > https://link.springer.com/content/pdf/10.1007/978-3-030-99527-0_21.pdf > >> The main difference is that a halt decider or partial halt decider takes >> descriptions of both a Turing machine (or other program) and an input and >> determines whether that machine halts with that input > > H(D,D) is only required to get this one input correctly thus H is > a halt decider with a domain restricted to D. > And since it gets the one answer it is resposible for wrong, it fails. Since H(D,D) returns 0, it can be proven that D(D) will halt, which *IS* the behavior a "Halt Decider" (even a limited halt decider) is responsible for answering about, so H(D,D) is just WRONG. >> but a termination >> analyzer takes only the dexcription of a Turing machine (or other >> program) >> and attempts to determine whether that machine halts with every input. >> The term "analyzer" instead "decider" indicates that it may fail to >> determine on some inputs > > Yes that is the distinction that I intend. But it fails on the one machine you want it to answer about. > >> and that it may produce additional information >> that may be useful. The intent is to create termination analyzers that >> are useful for practical purposes. >> >
[toc] | [prev] | [next] | [standalone]
| From | Mikko <mikko.levanto@iki.fi> |
|---|---|
| Date | 2024-06-16 12:15 +0300 |
| Subject | Re: H(D,D) cannot even be asked about the behavior of D(D) |
| Message-ID | <v4maeo$3vv3f$1@dont-email.me> |
| In reply to | #107166 |
On 2024-06-15 13:24:45 +0000, olcott said: > On 6/15/2024 7:33 AM, Mikko wrote: >> On 2024-06-15 11:34:39 +0000, joes said: >> >>> Am Fri, 14 Jun 2024 12:39:15 -0500 schrieb olcott: >>>> On 6/14/2024 10:54 AM, joes wrote: >>>>> Am Fri, 14 Jun 2024 08:15:52 -0500 schrieb olcott: >>>>>> On 6/14/2024 6:39 AM, Richard Damon wrote: >>>>>>> On 6/14/24 12:13 AM, olcott wrote: >>>>>>>> On 6/13/2024 10:44 PM, Richard Damon wrote: >>>>>>>>> On 6/13/24 11:14 PM, olcott wrote: >>>>>>>>>> On 6/13/2024 10:04 PM, Richard Damon wrote: >>>>>>>>>>> On 6/13/24 9:39 PM, olcott wrote: >>>>>>>>>>>> On 6/13/2024 8:24 PM, Richard Damon wrote: >>>>>>>>>>>>> On 6/13/24 11:32 AM, olcott wrote: >>> >>>>>> When H and D have a pathological relationship to each other then >>>>>> H(D,D) is not being asked about the behavior of D(D). H1(D,D) has no >>>>>> such pathological relationship thus D correctly simulated by H1 is the >>>>>> behavior of D(D). >>> What is H1 asked? >>>>> H is asked whether its input halts, and by definition should give the >>>>> (right) answer for every input. >>>> If we used that definition of decider then no human ever decided >>>> anything because every human has made at least one mistake. >>> Yes. Humans are not machines. >>>> I use the term "termination analyzer" as a close fit. The term partial >>>> halt decider is more accurate yet confuses most people. >> >> Olcott has used the term "termination analyzer", though whether he knows >> what it means is unclear. >> > > To prove (non-)termination of a C program, AProVE uses the Clang > compiler [7] to translate it to the intermediate representation of the > LLVM framework [15]. Then AProVE symbolically executes the LLVM program > and uses abstraction to obtain a finite symbolic execution graph (SEG) > containing all possible program runs. AProVE is a particular attempt, not a defintion. > *AProVE: Non-Termination Witnesses for C Programs* > https://link.springer.com/content/pdf/10.1007/978-3-030-99527-0_21.pdf > >> The main difference is that a halt decider or partial halt decider takes >> descriptions of both a Turing machine (or other program) and an input and >> determines whether that machine halts with that input > > H(D,D) is only required to get this one input correctly thus H is > a halt decider with a domain restricted to D. Nevertheless, it takes both the program and its input inputs. -- Mikko
[toc] | [prev] | [next] | [standalone]
Page 3 of 19 — ← Prev page 1 2 [3] 4 5 … 19 Next page →
Back to top | Article view | comp.theory
csiph-web