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 11 of 19 — ← Prev page 1 … 9 10 [11] 12 13 … 19 Next page →
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-26 19:41 -0400 |
| Subject | Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met |
| Message-ID | <v5i8v2$17ej1$1@i2pn2.org> |
| In reply to | #107857 |
On 6/26/24 8:58 AM, olcott wrote: > On 6/26/2024 3:41 AM, Mikko wrote: >> On 2024-06-26 02:29:59 +0000, olcott said: >> >>> On 6/25/2024 9:23 PM, Richard Damon wrote: >>>> On 6/25/24 10:05 PM, olcott wrote: >>>>> On 6/25/2024 8:47 PM, Richard Damon wrote: >>>>>> On 6/25/24 1:45 PM, olcott wrote: >>>>>>> On 6/25/2024 9:46 AM, Alan Mackenzie wrote: >>>>>>>> Hi, Ben. >>>>>>>> >>>>>>>> Ben Bacarisse <ben@bsb.me.uk> wrote: >>>>>>>>> Alan Mackenzie <acm@muc.de> writes: >>>>>>>> >>>>>>>>>> In comp.theory olcott <polcott333@gmail.com> wrote: >>>>>>>>>>> On 6/25/2024 4:22 AM, joes wrote: >>>>>>>>>>>> Am Sat, 22 Jun 2024 13:47:24 -0500 schrieb olcott: >>>>>>>>>>>>> On 6/22/2024 1:39 PM, Fred. Zwarts wrote: >>>>>>>>>>>>>> Op 21.jun.2024 om 15:21 schreef olcott: >>>>>>>> >>>>>>>>>>>>> When we stipulate that the only measure of a correct >>>>>>>>>>>>> emulation is the >>>>>>>>>>>>> semantics of the x86 programming language then we see that >>>>>>>>>>>>> when DDD is >>>>>>>>>>>>> correctly emulated by H0 that its call to H0(DDD) cannot >>>>>>>>>>>>> possibly >>>>>>>>>>>>> return. >>>>>>>>>>>> Yes. Which is wrong, because H0 should terminate. >>>>>>>> >>>>>>>>>> [ .... ] >>>>>>>> >>>>>>>>>>> The call from DDD to H0(DDD) when DDD is correctly emulated >>>>>>>>>>> by H0 cannot possibly return. >>>>>>>> >>>>>>>>>>> Until you acknowledge this is true, this is the >>>>>>>>>>> only thing that I am willing to talk to you about. >>>>>>>> >>>>>>>>>> I think you are talking at cross purposes. Joes's point is >>>>>>>>>> that H0 >>>>>>>>>> should terminate because it's a decider. You're saying that >>>>>>>>>> when H0 is >>>>>>>>>> "correctly" emulating, it won't terminate. I don't recall >>>>>>>>>> seeing anybody >>>>>>>>>> arguing against that. >>>>>>>> >>>>>>>>>> So you're saying, in effect, H0 is not a decider. I don't >>>>>>>>>> think anybody >>>>>>>>>> else would argue against that, either. >>>>>>>> >>>>>>>>> He's been making exactly the same nonsense argument for years. It >>>>>>>>> became crystal clear a little over three years ago when he made >>>>>>>>> the >>>>>>>>> mistake of posting the pseudo-code for H -- a step by step >>>>>>>>> simulator >>>>>>>>> that stopped simulating (famously on line 15) when some pattern >>>>>>>>> was >>>>>>>>> detected. He declared false (not halting) to be the correct >>>>>>>>> result for >>>>>>>>> the halting computation H(H_Hat(), H_Hat()) because of what >>>>>>>>> H(H_Hat(), >>>>>>>>> H_Hat()) would do "if line 15 were commented out"! >>>>>>>> >>>>>>>>> PO does occasionally make it clear what the shell game is. >>>>>>>> >>>>>>>> I think it's important for (relative) newcomers to the newsgroup to >>>>>>>> become aware of this. Each one of them is trying to help PO >>>>>>>> improve his >>>>>>>> level of learning. They will eventually give up, as you and I have >>>>>>>> done, recognising (as Mike Terry, in particular, has done) that >>>>>>>> enriching PO's intellect is a quite impossible task. >>>>>>>> >>>>>>>> What's the betting he'll respond to this post with his usual short >>>>>>>> sequence of x86 assembly code together with a demand to recognise >>>>>>>> something or other as non-terminating? >>>>>>>> >>>>>>>>> -- >>>>>>>>> Ben. >>>>>>>> >>>>>>> >>>>>>> <MIT Professor Sipser agreed to ONLY these verbatim words >>>>>>> 10/13/2022> >>>>>>> If simulating halt decider H correctly simulates its input D >>>>>>> until H correctly determines that its simulated D would never >>>>>>> stop running unless aborted then >>>>>>> >>>>>>> H can abort its simulation of D and correctly report that D >>>>>>> specifies a non-halting sequence of configurations. >>>>>>> </MIT Professor Sipser agreed to ONLY these verbatim words >>>>>>> 10/13/2022> >>>>>>> >>>>>>> On 10/14/2022 7:44 PM, Ben Bacarisse wrote: >>>>>>> > I don't think that is the shell game. PO really /has/ an H >>>>>>> > (it's trivial to do for this one case) that correctly determines >>>>>>> > that P(P) *would* never stop running *unless* aborted. >>>>>>> > >>>>>>> > He knows and accepts that P(P) actually does stop. The >>>>>>> > wrong answer is justified by what would happen if H >>>>>>> > (and hence a different P) where not what they actually are. >>>>>>> > >>>>>>> >>>>>>> Ben thinks that I tricked professor Sipser into agreeing >>>>>>> with something that he did not fully understand. >>>>>>> >>>>>>> *The real issue is that no one here sufficiently understands* >>>>>>> *the highlighted portion of the following definition* >>>>>>> >>>>>>> Computable functions are the formalized analogue of the >>>>>>> intuitive notion of algorithms, in the sense that a >>>>>>> function is computable if there exists an algorithm >>>>>>> that can do the job of the function, i.e. >>>>>>> >>>>>>> *given an input of the function domain* >>>>>>> *it can return the corresponding output* >>>>>>> >>>>>>> https://en.wikipedia.org/wiki/Computable_function >>>>>>> >>>>>>> >>>>>> >>>>>> But only if the function is, in fact, computable. >>>>>> >>>>>> Since Halting isn't, you can't use that fact. >>>>> >>>>> If I ask you: What time is it? >>>>> and you do not tell me the answer to the question hidden >>>>> in my mind "What did you have for dinner?" We cannot say >>>>> that you provided the wrong answer when you tell me what >>>>> time it is. >>>> >>>> Because I answered the actual question. >>>> >>>> Just like the "Halt Decider" needs to answer the "Halt Decider >>>> Question" and not answer about POOP. >>>> >>>>> >>>>> When we ask H to tell us whether its actual input halts >>>>> H can only answer that P correctly simulated by H will not halt. >>>>> H cannot answer the question hidden in your mind. >>>>> >>>> >>>> Then you are just admitting that it can't be a Halt Decider. >>>> >>>> If it isn't what the definition requires, it just isn't one. >>> >>> Yes and everyone knows that computer scientists are much >>> more infallible than God thus cannot possibly ever make >>> a definition that is incoherent in ways that these 100% >>> infallible computer scientists never noticed. >> >> Actually, it is the opposite. Everybody, or at least all computer >> scientists and engineers, know that they, and all peaple, are fallible, >> at least when making programs and when inferring about programs. >> Therefore >> computer engineers demand that every program must be tested, and computer >> scinetists demand that every claim is proven. >> > > If this was true then everyone here would already know > that H(P,P) is not even being asked about the behavior > of the directly executed P(P). No, everyone, but it seems you and a few of your friends. understand the meaning of specifications are requirements. > > The only reason they disagree is the infallible word > of the gospel of textbook tells them so. > Which, when it quotes the "Gods" of the field, IT IS INFALLIBLE. Remember, those who define a field, are the authority to say what its definitions are. You don't need to follow them if you stay out of the game, but entering the game is a submission to the rules.
[toc] | [prev] | [next] | [standalone]
| From | Mikko <mikko.levanto@iki.fi> |
|---|---|
| Date | 2024-06-27 10:36 +0300 |
| Subject | Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met |
| Message-ID | <v5j4p0$2ksq3$1@dont-email.me> |
| In reply to | #107857 |
On 2024-06-26 12:58:59 +0000, olcott said: > On 6/26/2024 3:41 AM, Mikko wrote: >> On 2024-06-26 02:29:59 +0000, olcott said: >> >>> On 6/25/2024 9:23 PM, Richard Damon wrote: >>>> On 6/25/24 10:05 PM, olcott wrote: >>>>> On 6/25/2024 8:47 PM, Richard Damon wrote: >>>>>> On 6/25/24 1:45 PM, olcott wrote: >>>>>>> On 6/25/2024 9:46 AM, Alan Mackenzie wrote: >>>>>>>> Hi, Ben. >>>>>>>> >>>>>>>> Ben Bacarisse <ben@bsb.me.uk> wrote: >>>>>>>>> Alan Mackenzie <acm@muc.de> writes: >>>>>>>> >>>>>>>>>> In comp.theory olcott <polcott333@gmail.com> wrote: >>>>>>>>>>> On 6/25/2024 4:22 AM, joes wrote: >>>>>>>>>>>> Am Sat, 22 Jun 2024 13:47:24 -0500 schrieb olcott: >>>>>>>>>>>>> On 6/22/2024 1:39 PM, Fred. Zwarts wrote: >>>>>>>>>>>>>> Op 21.jun.2024 om 15:21 schreef olcott: >>>>>>>> >>>>>>>>>>>>> When we stipulate that the only measure of a correct emulation is the >>>>>>>>>>>>> semantics of the x86 programming language then we see that when DDD is >>>>>>>>>>>>> correctly emulated by H0 that its call to H0(DDD) cannot possibly >>>>>>>>>>>>> return. >>>>>>>>>>>> Yes. Which is wrong, because H0 should terminate. >>>>>>>> >>>>>>>>>> [ .... ] >>>>>>>> >>>>>>>>>>> The call from DDD to H0(DDD) when DDD is correctly emulated >>>>>>>>>>> by H0 cannot possibly return. >>>>>>>> >>>>>>>>>>> Until you acknowledge this is true, this is the >>>>>>>>>>> only thing that I am willing to talk to you about. >>>>>>>> >>>>>>>>>> I think you are talking at cross purposes. Joes's point is that H0 >>>>>>>>>> should terminate because it's a decider. You're saying that when H0 is >>>>>>>>>> "correctly" emulating, it won't terminate. I don't recall seeing anybody >>>>>>>>>> arguing against that. >>>>>>>> >>>>>>>>>> So you're saying, in effect, H0 is not a decider. I don't think anybody >>>>>>>>>> else would argue against that, either. >>>>>>>> >>>>>>>>> He's been making exactly the same nonsense argument for years. It >>>>>>>>> became crystal clear a little over three years ago when he made the >>>>>>>>> mistake of posting the pseudo-code for H -- a step by step simulator >>>>>>>>> that stopped simulating (famously on line 15) when some pattern was >>>>>>>>> detected. He declared false (not halting) to be the correct result for >>>>>>>>> the halting computation H(H_Hat(), H_Hat()) because of what H(H_Hat(), >>>>>>>>> H_Hat()) would do "if line 15 were commented out"! >>>>>>>> >>>>>>>>> PO does occasionally make it clear what the shell game is. >>>>>>>> >>>>>>>> I think it's important for (relative) newcomers to the newsgroup to >>>>>>>> become aware of this. Each one of them is trying to help PO improve his >>>>>>>> level of learning. They will eventually give up, as you and I have >>>>>>>> done, recognising (as Mike Terry, in particular, has done) that >>>>>>>> enriching PO's intellect is a quite impossible task. >>>>>>>> >>>>>>>> What's the betting he'll respond to this post with his usual short >>>>>>>> sequence of x86 assembly code together with a demand to recognise >>>>>>>> something or other as non-terminating? >>>>>>>> >>>>>>>>> -- >>>>>>>>> Ben. >>>>>>>> >>>>>>> >>>>>>> <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>>>> If simulating halt decider H correctly simulates its input D >>>>>>> until H correctly determines that its simulated D would never >>>>>>> stop running unless aborted then >>>>>>> >>>>>>> H can abort its simulation of D and correctly report that D >>>>>>> specifies a non-halting sequence of configurations. >>>>>>> </MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>>>> >>>>>>> On 10/14/2022 7:44 PM, Ben Bacarisse wrote: >>>>>>> > I don't think that is the shell game. PO really /has/ an H >>>>>>> > (it's trivial to do for this one case) that correctly determines >>>>>>> > that P(P) *would* never stop running *unless* aborted. >>>>>>> > >>>>>>> > He knows and accepts that P(P) actually does stop. The >>>>>>> > wrong answer is justified by what would happen if H >>>>>>> > (and hence a different P) where not what they actually are. >>>>>>> > >>>>>>> >>>>>>> Ben thinks that I tricked professor Sipser into agreeing >>>>>>> with something that he did not fully understand. >>>>>>> >>>>>>> *The real issue is that no one here sufficiently understands* >>>>>>> *the highlighted portion of the following definition* >>>>>>> >>>>>>> Computable functions are the formalized analogue of the >>>>>>> intuitive notion of algorithms, in the sense that a >>>>>>> function is computable if there exists an algorithm >>>>>>> that can do the job of the function, i.e. >>>>>>> >>>>>>> *given an input of the function domain* >>>>>>> *it can return the corresponding output* >>>>>>> >>>>>>> https://en.wikipedia.org/wiki/Computable_function >>>>>>> >>>>>>> >>>>>> >>>>>> But only if the function is, in fact, computable. >>>>>> >>>>>> Since Halting isn't, you can't use that fact. >>>>> >>>>> If I ask you: What time is it? >>>>> and you do not tell me the answer to the question hidden >>>>> in my mind "What did you have for dinner?" We cannot say >>>>> that you provided the wrong answer when you tell me what >>>>> time it is. >>>> >>>> Because I answered the actual question. >>>> >>>> Just like the "Halt Decider" needs to answer the "Halt Decider >>>> Question" and not answer about POOP. >>>> >>>>> >>>>> When we ask H to tell us whether its actual input halts >>>>> H can only answer that P correctly simulated by H will not halt. >>>>> H cannot answer the question hidden in your mind. >>>>> >>>> >>>> Then you are just admitting that it can't be a Halt Decider. >>>> >>>> If it isn't what the definition requires, it just isn't one. >>> >>> Yes and everyone knows that computer scientists are much >>> more infallible than God thus cannot possibly ever make >>> a definition that is incoherent in ways that these 100% >>> infallible computer scientists never noticed. >> >> Actually, it is the opposite. Everybody, or at least all computer >> scientists and engineers, know that they, and all peaple, are fallible, >> at least when making programs and when inferring about programs. Therefore >> computer engineers demand that every program must be tested, and computer >> scinetists demand that every claim is proven. > > If this was true then everyone here would already know > that H(P,P) is not even being asked about the behavior > of the directly executed P(P). Everyone knwos that H(P,P) is not asked anything. -- Mikko
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-27 09:10 -0500 |
| Subject | Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met |
| Message-ID | <v5jrrq$2o58l$4@dont-email.me> |
| In reply to | #107920 |
On 6/27/2024 2:36 AM, Mikko wrote: > On 2024-06-26 12:58:59 +0000, olcott said: > >> On 6/26/2024 3:41 AM, Mikko wrote: >>> On 2024-06-26 02:29:59 +0000, olcott said: >>> >>>> On 6/25/2024 9:23 PM, Richard Damon wrote: >>>>> On 6/25/24 10:05 PM, olcott wrote: >>>>>> On 6/25/2024 8:47 PM, Richard Damon wrote: >>>>>>> On 6/25/24 1:45 PM, olcott wrote: >>>>>>>> On 6/25/2024 9:46 AM, Alan Mackenzie wrote: >>>>>>>>> Hi, Ben. >>>>>>>>> >>>>>>>>> Ben Bacarisse <ben@bsb.me.uk> wrote: >>>>>>>>>> Alan Mackenzie <acm@muc.de> writes: >>>>>>>>> >>>>>>>>>>> In comp.theory olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>> On 6/25/2024 4:22 AM, joes wrote: >>>>>>>>>>>>> Am Sat, 22 Jun 2024 13:47:24 -0500 schrieb olcott: >>>>>>>>>>>>>> On 6/22/2024 1:39 PM, Fred. Zwarts wrote: >>>>>>>>>>>>>>> Op 21.jun.2024 om 15:21 schreef olcott: >>>>>>>>> >>>>>>>>>>>>>> When we stipulate that the only measure of a correct >>>>>>>>>>>>>> emulation is the >>>>>>>>>>>>>> semantics of the x86 programming language then we see that >>>>>>>>>>>>>> when DDD is >>>>>>>>>>>>>> correctly emulated by H0 that its call to H0(DDD) cannot >>>>>>>>>>>>>> possibly >>>>>>>>>>>>>> return. >>>>>>>>>>>>> Yes. Which is wrong, because H0 should terminate. >>>>>>>>> >>>>>>>>>>> [ .... ] >>>>>>>>> >>>>>>>>>>>> The call from DDD to H0(DDD) when DDD is correctly emulated >>>>>>>>>>>> by H0 cannot possibly return. >>>>>>>>> >>>>>>>>>>>> Until you acknowledge this is true, this is the >>>>>>>>>>>> only thing that I am willing to talk to you about. >>>>>>>>> >>>>>>>>>>> I think you are talking at cross purposes. Joes's point is >>>>>>>>>>> that H0 >>>>>>>>>>> should terminate because it's a decider. You're saying that >>>>>>>>>>> when H0 is >>>>>>>>>>> "correctly" emulating, it won't terminate. I don't recall >>>>>>>>>>> seeing anybody >>>>>>>>>>> arguing against that. >>>>>>>>> >>>>>>>>>>> So you're saying, in effect, H0 is not a decider. I don't >>>>>>>>>>> think anybody >>>>>>>>>>> else would argue against that, either. >>>>>>>>> >>>>>>>>>> He's been making exactly the same nonsense argument for >>>>>>>>>> years. It >>>>>>>>>> became crystal clear a little over three years ago when he >>>>>>>>>> made the >>>>>>>>>> mistake of posting the pseudo-code for H -- a step by step >>>>>>>>>> simulator >>>>>>>>>> that stopped simulating (famously on line 15) when some >>>>>>>>>> pattern was >>>>>>>>>> detected. He declared false (not halting) to be the correct >>>>>>>>>> result for >>>>>>>>>> the halting computation H(H_Hat(), H_Hat()) because of what >>>>>>>>>> H(H_Hat(), >>>>>>>>>> H_Hat()) would do "if line 15 were commented out"! >>>>>>>>> >>>>>>>>>> PO does occasionally make it clear what the shell game is. >>>>>>>>> >>>>>>>>> I think it's important for (relative) newcomers to the >>>>>>>>> newsgroup to >>>>>>>>> become aware of this. Each one of them is trying to help PO >>>>>>>>> improve his >>>>>>>>> level of learning. They will eventually give up, as you and I >>>>>>>>> have >>>>>>>>> done, recognising (as Mike Terry, in particular, has done) that >>>>>>>>> enriching PO's intellect is a quite impossible task. >>>>>>>>> >>>>>>>>> What's the betting he'll respond to this post with his usual short >>>>>>>>> sequence of x86 assembly code together with a demand to recognise >>>>>>>>> something or other as non-terminating? >>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Ben. >>>>>>>>> >>>>>>>> >>>>>>>> <MIT Professor Sipser agreed to ONLY these verbatim words >>>>>>>> 10/13/2022> >>>>>>>> If simulating halt decider H correctly simulates its input D >>>>>>>> until H correctly determines that its simulated D would never >>>>>>>> stop running unless aborted then >>>>>>>> >>>>>>>> H can abort its simulation of D and correctly report that D >>>>>>>> specifies a non-halting sequence of configurations. >>>>>>>> </MIT Professor Sipser agreed to ONLY these verbatim words >>>>>>>> 10/13/2022> >>>>>>>> >>>>>>>> On 10/14/2022 7:44 PM, Ben Bacarisse wrote: >>>>>>>> > I don't think that is the shell game. PO really /has/ an H >>>>>>>> > (it's trivial to do for this one case) that correctly determines >>>>>>>> > that P(P) *would* never stop running *unless* aborted. >>>>>>>> > >>>>>>>> > He knows and accepts that P(P) actually does stop. The >>>>>>>> > wrong answer is justified by what would happen if H >>>>>>>> > (and hence a different P) where not what they actually are. >>>>>>>> > >>>>>>>> >>>>>>>> Ben thinks that I tricked professor Sipser into agreeing >>>>>>>> with something that he did not fully understand. >>>>>>>> >>>>>>>> *The real issue is that no one here sufficiently understands* >>>>>>>> *the highlighted portion of the following definition* >>>>>>>> >>>>>>>> Computable functions are the formalized analogue of the >>>>>>>> intuitive notion of algorithms, in the sense that a >>>>>>>> function is computable if there exists an algorithm >>>>>>>> that can do the job of the function, i.e. >>>>>>>> >>>>>>>> *given an input of the function domain* >>>>>>>> *it can return the corresponding output* >>>>>>>> >>>>>>>> https://en.wikipedia.org/wiki/Computable_function >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> But only if the function is, in fact, computable. >>>>>>> >>>>>>> Since Halting isn't, you can't use that fact. >>>>>> >>>>>> If I ask you: What time is it? >>>>>> and you do not tell me the answer to the question hidden >>>>>> in my mind "What did you have for dinner?" We cannot say >>>>>> that you provided the wrong answer when you tell me what >>>>>> time it is. >>>>> >>>>> Because I answered the actual question. >>>>> >>>>> Just like the "Halt Decider" needs to answer the "Halt Decider >>>>> Question" and not answer about POOP. >>>>> >>>>>> >>>>>> When we ask H to tell us whether its actual input halts >>>>>> H can only answer that P correctly simulated by H will not halt. >>>>>> H cannot answer the question hidden in your mind. >>>>>> >>>>> >>>>> Then you are just admitting that it can't be a Halt Decider. >>>>> >>>>> If it isn't what the definition requires, it just isn't one. >>>> >>>> Yes and everyone knows that computer scientists are much >>>> more infallible than God thus cannot possibly ever make >>>> a definition that is incoherent in ways that these 100% >>>> infallible computer scientists never noticed. >>> >>> Actually, it is the opposite. Everybody, or at least all computer >>> scientists and engineers, know that they, and all peaple, are fallible, >>> at least when making programs and when inferring about programs. >>> Therefore >>> computer engineers demand that every program must be tested, and >>> computer >>> scinetists demand that every claim is proven. >> >> If this was true then everyone here would already know >> that H(P,P) is not even being asked about the behavior >> of the directly executed P(P). > > Everyone knwos that H(P,P) is not asked anything. > In computability theory and computational complexity theory, a decision problem is a computational problem that can be posed as a yes–no question of the input values. https://en.wikipedia.org/wiki/Decision_problem -- 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 | Mikko <mikko.levanto@iki.fi> |
|---|---|
| Date | 2024-06-27 18:35 +0300 |
| Subject | Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met |
| Message-ID | <v5k0ru$2q29e$1@dont-email.me> |
| In reply to | #107929 |
On 2024-06-27 14:10:02 +0000, olcott said: > On 6/27/2024 2:36 AM, Mikko wrote: >> On 2024-06-26 12:58:59 +0000, olcott said: >> >>> On 6/26/2024 3:41 AM, Mikko wrote: >>>> On 2024-06-26 02:29:59 +0000, olcott said: >>>> >>>>> On 6/25/2024 9:23 PM, Richard Damon wrote: >>>>>> On 6/25/24 10:05 PM, olcott wrote: >>>>>>> On 6/25/2024 8:47 PM, Richard Damon wrote: >>>>>>>> On 6/25/24 1:45 PM, olcott wrote: >>>>>>>>> On 6/25/2024 9:46 AM, Alan Mackenzie wrote: >>>>>>>>>> Hi, Ben. >>>>>>>>>> >>>>>>>>>> Ben Bacarisse <ben@bsb.me.uk> wrote: >>>>>>>>>>> Alan Mackenzie <acm@muc.de> writes: >>>>>>>>>> >>>>>>>>>>>> In comp.theory olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>> On 6/25/2024 4:22 AM, joes wrote: >>>>>>>>>>>>>> Am Sat, 22 Jun 2024 13:47:24 -0500 schrieb olcott: >>>>>>>>>>>>>>> On 6/22/2024 1:39 PM, Fred. Zwarts wrote: >>>>>>>>>>>>>>>> Op 21.jun.2024 om 15:21 schreef olcott: >>>>>>>>>> >>>>>>>>>>>>>>> When we stipulate that the only measure of a correct emulation is the >>>>>>>>>>>>>>> semantics of the x86 programming language then we see that when DDD is >>>>>>>>>>>>>>> correctly emulated by H0 that its call to H0(DDD) cannot possibly >>>>>>>>>>>>>>> return. >>>>>>>>>>>>>> Yes. Which is wrong, because H0 should terminate. >>>>>>>>>> >>>>>>>>>>>> [ .... ] >>>>>>>>>> >>>>>>>>>>>>> The call from DDD to H0(DDD) when DDD is correctly emulated >>>>>>>>>>>>> by H0 cannot possibly return. >>>>>>>>>> >>>>>>>>>>>>> Until you acknowledge this is true, this is the >>>>>>>>>>>>> only thing that I am willing to talk to you about. >>>>>>>>>> >>>>>>>>>>>> I think you are talking at cross purposes. Joes's point is that H0 >>>>>>>>>>>> should terminate because it's a decider. You're saying that when H0 is >>>>>>>>>>>> "correctly" emulating, it won't terminate. I don't recall seeing anybody >>>>>>>>>>>> arguing against that. >>>>>>>>>> >>>>>>>>>>>> So you're saying, in effect, H0 is not a decider. I don't think anybody >>>>>>>>>>>> else would argue against that, either. >>>>>>>>>> >>>>>>>>>>> He's been making exactly the same nonsense argument for years. It >>>>>>>>>>> became crystal clear a little over three years ago when he made the >>>>>>>>>>> mistake of posting the pseudo-code for H -- a step by step simulator >>>>>>>>>>> that stopped simulating (famously on line 15) when some pattern was >>>>>>>>>>> detected. He declared false (not halting) to be the correct result for >>>>>>>>>>> the halting computation H(H_Hat(), H_Hat()) because of what H(H_Hat(), >>>>>>>>>>> H_Hat()) would do "if line 15 were commented out"! >>>>>>>>>> >>>>>>>>>>> PO does occasionally make it clear what the shell game is. >>>>>>>>>> >>>>>>>>>> I think it's important for (relative) newcomers to the newsgroup to >>>>>>>>>> become aware of this. Each one of them is trying to help PO improve his >>>>>>>>>> level of learning. They will eventually give up, as you and I have >>>>>>>>>> done, recognising (as Mike Terry, in particular, has done) that >>>>>>>>>> enriching PO's intellect is a quite impossible task. >>>>>>>>>> >>>>>>>>>> What's the betting he'll respond to this post with his usual short >>>>>>>>>> sequence of x86 assembly code together with a demand to recognise >>>>>>>>>> something or other as non-terminating? >>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Ben. >>>>>>>>>> >>>>>>>>> >>>>>>>>> <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>>>>>> If simulating halt decider H correctly simulates its input D >>>>>>>>> until H correctly determines that its simulated D would never >>>>>>>>> stop running unless aborted then >>>>>>>>> >>>>>>>>> H can abort its simulation of D and correctly report that D >>>>>>>>> specifies a non-halting sequence of configurations. >>>>>>>>> </MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>>>>>> >>>>>>>>> On 10/14/2022 7:44 PM, Ben Bacarisse wrote: >>>>>>>>> > I don't think that is the shell game. PO really /has/ an H >>>>>>>>> > (it's trivial to do for this one case) that correctly determines >>>>>>>>> > that P(P) *would* never stop running *unless* aborted. >>>>>>>>> > >>>>>>>>> > He knows and accepts that P(P) actually does stop. The >>>>>>>>> > wrong answer is justified by what would happen if H >>>>>>>>> > (and hence a different P) where not what they actually are. >>>>>>>>> > >>>>>>>>> >>>>>>>>> Ben thinks that I tricked professor Sipser into agreeing >>>>>>>>> with something that he did not fully understand. >>>>>>>>> >>>>>>>>> *The real issue is that no one here sufficiently understands* >>>>>>>>> *the highlighted portion of the following definition* >>>>>>>>> >>>>>>>>> Computable functions are the formalized analogue of the >>>>>>>>> intuitive notion of algorithms, in the sense that a >>>>>>>>> function is computable if there exists an algorithm >>>>>>>>> that can do the job of the function, i.e. >>>>>>>>> >>>>>>>>> *given an input of the function domain* >>>>>>>>> *it can return the corresponding output* >>>>>>>>> >>>>>>>>> https://en.wikipedia.org/wiki/Computable_function >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> But only if the function is, in fact, computable. >>>>>>>> >>>>>>>> Since Halting isn't, you can't use that fact. >>>>>>> >>>>>>> If I ask you: What time is it? >>>>>>> and you do not tell me the answer to the question hidden >>>>>>> in my mind "What did you have for dinner?" We cannot say >>>>>>> that you provided the wrong answer when you tell me what >>>>>>> time it is. >>>>>> >>>>>> Because I answered the actual question. >>>>>> >>>>>> Just like the "Halt Decider" needs to answer the "Halt Decider >>>>>> Question" and not answer about POOP. >>>>>> >>>>>>> >>>>>>> When we ask H to tell us whether its actual input halts >>>>>>> H can only answer that P correctly simulated by H will not halt. >>>>>>> H cannot answer the question hidden in your mind. >>>>>>> >>>>>> >>>>>> Then you are just admitting that it can't be a Halt Decider. >>>>>> >>>>>> If it isn't what the definition requires, it just isn't one. >>>>> >>>>> Yes and everyone knows that computer scientists are much >>>>> more infallible than God thus cannot possibly ever make >>>>> a definition that is incoherent in ways that these 100% >>>>> infallible computer scientists never noticed. >>>> >>>> Actually, it is the opposite. Everybody, or at least all computer >>>> scientists and engineers, know that they, and all peaple, are fallible, >>>> at least when making programs and when inferring about programs. Therefore >>>> computer engineers demand that every program must be tested, and computer >>>> scinetists demand that every claim is proven. >>> >>> If this was true then everyone here would already know >>> that H(P,P) is not even being asked about the behavior >>> of the directly executed P(P). >> >> Everyone knwos that H(P,P) is not asked anything. >> > > In computability theory and computational complexity theory, a > decision problem is a computational problem that can be posed as > a yes–no question of the input values. > https://en.wikipedia.org/wiki/Decision_problem That's right. But that question cannot be presented to the decider. Only the input values can. -- Mikko
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-27 11:56 -0500 |
| Subject | Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met |
| Message-ID | <v5k5ko$2qsdr$1@dont-email.me> |
| In reply to | #107930 |
On 6/27/2024 10:35 AM, Mikko wrote: > On 2024-06-27 14:10:02 +0000, olcott said: > >> On 6/27/2024 2:36 AM, Mikko wrote: >>> On 2024-06-26 12:58:59 +0000, olcott said: >>> >>>> On 6/26/2024 3:41 AM, Mikko wrote: >>>>> On 2024-06-26 02:29:59 +0000, olcott said: >>>>> >>>>>> On 6/25/2024 9:23 PM, Richard Damon wrote: >>>>>>> On 6/25/24 10:05 PM, olcott wrote: >>>>>>>> On 6/25/2024 8:47 PM, Richard Damon wrote: >>>>>>>>> On 6/25/24 1:45 PM, olcott wrote: >>>>>>>>>> On 6/25/2024 9:46 AM, Alan Mackenzie wrote: >>>>>>>>>>> Hi, Ben. >>>>>>>>>>> >>>>>>>>>>> Ben Bacarisse <ben@bsb.me.uk> wrote: >>>>>>>>>>>> Alan Mackenzie <acm@muc.de> writes: >>>>>>>>>>> >>>>>>>>>>>>> In comp.theory olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>> On 6/25/2024 4:22 AM, joes wrote: >>>>>>>>>>>>>>> Am Sat, 22 Jun 2024 13:47:24 -0500 schrieb olcott: >>>>>>>>>>>>>>>> On 6/22/2024 1:39 PM, Fred. Zwarts wrote: >>>>>>>>>>>>>>>>> Op 21.jun.2024 om 15:21 schreef olcott: >>>>>>>>>>> >>>>>>>>>>>>>>>> When we stipulate that the only measure of a correct >>>>>>>>>>>>>>>> emulation is the >>>>>>>>>>>>>>>> semantics of the x86 programming language then we see >>>>>>>>>>>>>>>> that when DDD is >>>>>>>>>>>>>>>> correctly emulated by H0 that its call to H0(DDD) cannot >>>>>>>>>>>>>>>> possibly >>>>>>>>>>>>>>>> return. >>>>>>>>>>>>>>> Yes. Which is wrong, because H0 should terminate. >>>>>>>>>>> >>>>>>>>>>>>> [ .... ] >>>>>>>>>>> >>>>>>>>>>>>>> The call from DDD to H0(DDD) when DDD is correctly emulated >>>>>>>>>>>>>> by H0 cannot possibly return. >>>>>>>>>>> >>>>>>>>>>>>>> Until you acknowledge this is true, this is the >>>>>>>>>>>>>> only thing that I am willing to talk to you about. >>>>>>>>>>> >>>>>>>>>>>>> I think you are talking at cross purposes. Joes's point is >>>>>>>>>>>>> that H0 >>>>>>>>>>>>> should terminate because it's a decider. You're saying >>>>>>>>>>>>> that when H0 is >>>>>>>>>>>>> "correctly" emulating, it won't terminate. I don't recall >>>>>>>>>>>>> seeing anybody >>>>>>>>>>>>> arguing against that. >>>>>>>>>>> >>>>>>>>>>>>> So you're saying, in effect, H0 is not a decider. I don't >>>>>>>>>>>>> think anybody >>>>>>>>>>>>> else would argue against that, either. >>>>>>>>>>> >>>>>>>>>>>> He's been making exactly the same nonsense argument for >>>>>>>>>>>> years. It >>>>>>>>>>>> became crystal clear a little over three years ago when he >>>>>>>>>>>> made the >>>>>>>>>>>> mistake of posting the pseudo-code for H -- a step by step >>>>>>>>>>>> simulator >>>>>>>>>>>> that stopped simulating (famously on line 15) when some >>>>>>>>>>>> pattern was >>>>>>>>>>>> detected. He declared false (not halting) to be the correct >>>>>>>>>>>> result for >>>>>>>>>>>> the halting computation H(H_Hat(), H_Hat()) because of what >>>>>>>>>>>> H(H_Hat(), >>>>>>>>>>>> H_Hat()) would do "if line 15 were commented out"! >>>>>>>>>>> >>>>>>>>>>>> PO does occasionally make it clear what the shell game is. >>>>>>>>>>> >>>>>>>>>>> I think it's important for (relative) newcomers to the >>>>>>>>>>> newsgroup to >>>>>>>>>>> become aware of this. Each one of them is trying to help PO >>>>>>>>>>> improve his >>>>>>>>>>> level of learning. They will eventually give up, as you and >>>>>>>>>>> I have >>>>>>>>>>> done, recognising (as Mike Terry, in particular, has done) that >>>>>>>>>>> enriching PO's intellect is a quite impossible task. >>>>>>>>>>> >>>>>>>>>>> What's the betting he'll respond to this post with his usual >>>>>>>>>>> short >>>>>>>>>>> sequence of x86 assembly code together with a demand to >>>>>>>>>>> recognise >>>>>>>>>>> something or other as non-terminating? >>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Ben. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> <MIT Professor Sipser agreed to ONLY these verbatim words >>>>>>>>>> 10/13/2022> >>>>>>>>>> If simulating halt decider H correctly simulates its input D >>>>>>>>>> until H correctly determines that its simulated D would >>>>>>>>>> never >>>>>>>>>> stop running unless aborted then >>>>>>>>>> >>>>>>>>>> H can abort its simulation of D and correctly report that D >>>>>>>>>> specifies a non-halting sequence of configurations. >>>>>>>>>> </MIT Professor Sipser agreed to ONLY these verbatim words >>>>>>>>>> 10/13/2022> >>>>>>>>>> >>>>>>>>>> On 10/14/2022 7:44 PM, Ben Bacarisse wrote: >>>>>>>>>> > I don't think that is the shell game. PO really /has/ an H >>>>>>>>>> > (it's trivial to do for this one case) that correctly >>>>>>>>>> determines >>>>>>>>>> > that P(P) *would* never stop running *unless* aborted. >>>>>>>>>> > >>>>>>>>>> > He knows and accepts that P(P) actually does stop. The >>>>>>>>>> > wrong answer is justified by what would happen if H >>>>>>>>>> > (and hence a different P) where not what they actually are. >>>>>>>>>> > >>>>>>>>>> >>>>>>>>>> Ben thinks that I tricked professor Sipser into agreeing >>>>>>>>>> with something that he did not fully understand. >>>>>>>>>> >>>>>>>>>> *The real issue is that no one here sufficiently understands* >>>>>>>>>> *the highlighted portion of the following definition* >>>>>>>>>> >>>>>>>>>> Computable functions are the formalized analogue of the >>>>>>>>>> intuitive notion of algorithms, in the sense that a >>>>>>>>>> function is computable if there exists an algorithm >>>>>>>>>> that can do the job of the function, i.e. >>>>>>>>>> >>>>>>>>>> *given an input of the function domain* >>>>>>>>>> *it can return the corresponding output* >>>>>>>>>> >>>>>>>>>> https://en.wikipedia.org/wiki/Computable_function >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> But only if the function is, in fact, computable. >>>>>>>>> >>>>>>>>> Since Halting isn't, you can't use that fact. >>>>>>>> >>>>>>>> If I ask you: What time is it? >>>>>>>> and you do not tell me the answer to the question hidden >>>>>>>> in my mind "What did you have for dinner?" We cannot say >>>>>>>> that you provided the wrong answer when you tell me what >>>>>>>> time it is. >>>>>>> >>>>>>> Because I answered the actual question. >>>>>>> >>>>>>> Just like the "Halt Decider" needs to answer the "Halt Decider >>>>>>> Question" and not answer about POOP. >>>>>>> >>>>>>>> >>>>>>>> When we ask H to tell us whether its actual input halts >>>>>>>> H can only answer that P correctly simulated by H will not halt. >>>>>>>> H cannot answer the question hidden in your mind. >>>>>>>> >>>>>>> >>>>>>> Then you are just admitting that it can't be a Halt Decider. >>>>>>> >>>>>>> If it isn't what the definition requires, it just isn't one. >>>>>> >>>>>> Yes and everyone knows that computer scientists are much >>>>>> more infallible than God thus cannot possibly ever make >>>>>> a definition that is incoherent in ways that these 100% >>>>>> infallible computer scientists never noticed. >>>>> >>>>> Actually, it is the opposite. Everybody, or at least all computer >>>>> scientists and engineers, know that they, and all peaple, are >>>>> fallible, >>>>> at least when making programs and when inferring about programs. >>>>> Therefore >>>>> computer engineers demand that every program must be tested, and >>>>> computer >>>>> scinetists demand that every claim is proven. >>>> >>>> If this was true then everyone here would already know >>>> that H(P,P) is not even being asked about the behavior >>>> of the directly executed P(P). >>> >>> Everyone knwos that H(P,P) is not asked anything. >>> >> >> In computability theory and computational complexity theory, a >> decision problem is a computational problem that can be posed as >> a yes–no question of the input values. >> https://en.wikipedia.org/wiki/Decision_problem > > That's right. But that question cannot be presented to the decider. > Only the input values can. > In other words you are saying that Turing machines do not typically understand English. None-the-less no-one here understands that every halt decider is only required to report on the behavior that its actual input actually maps to. Instead everyone here expects that the halt decider must map to the English description of what the authors of textbooks expect it to map to. We already agreed that Turing machines do not typically understand English, so this assumption is stupid. *DDD correctly simulated by H0 DOES NOT HALT* Everyone here stupidly ignores that the pathological relationship that DDD calls H0(DDD) changes the behavior of DDD. -- 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-27 17:25 +0000 |
| Subject | Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met |
| Message-ID | <v5k79o$19nfi$1@i2pn2.org> |
| In reply to | #107931 |
Am Thu, 27 Jun 2024 11:56:56 -0500 schrieb olcott: > On 6/27/2024 10:35 AM, Mikko wrote: >> On 2024-06-27 14:10:02 +0000, olcott said: >>> On 6/27/2024 2:36 AM, Mikko wrote: >>>> On 2024-06-26 12:58:59 +0000, olcott said: >>>>> On 6/26/2024 3:41 AM, Mikko wrote: >>>>>> On 2024-06-26 02:29:59 +0000, olcott said: >>>>>>> On 6/25/2024 9:23 PM, Richard Damon wrote: >>>>>>>> On 6/25/24 10:05 PM, olcott wrote: >>>>>>>>> On 6/25/2024 8:47 PM, Richard Damon wrote: >>>>>>>>>> On 6/25/24 1:45 PM, olcott wrote: >>>>>>>>>>> On 6/25/2024 9:46 AM, Alan Mackenzie wrote: >>>>>>>>>>>> Ben Bacarisse <ben@bsb.me.uk> wrote: >>>>>>>>>>>>> Alan Mackenzie <acm@muc.de> writes: >>>>>>>>>>>>>> In comp.theory olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>>> On 6/25/2024 4:22 AM, joes wrote: >>>>>>>>>>>>>>>> Am Sat, 22 Jun 2024 13:47:24 -0500 schrieb olcott: >>>>>>>>>>>>>>>>> On 6/22/2024 1:39 PM, Fred. Zwarts wrote: >>>>>>>>>>>>>>>>>> Op 21.jun.2024 om 15:21 schreef olcott: >>>>> If this was true then everyone here would already know that H(P,P) >>>>> is not even being asked about the behavior of the directly executed >>>>> P(P). >>>> >>>> Everyone knwos that H(P,P) is not asked anything. >>>> >>> In computability theory and computational complexity theory, a >>> decision problem is a computational problem that can be posed as a >>> yes–no question of the input values. >> >> That's right. But that question cannot be presented to the decider. >> Only the input values can. >> > In other words you are saying that Turing machines do not typically > understand English. No. The input is merely a variable in the question. The question is implicit. > None-the-less no-one here understands that every halt decider is only > required to report on the behavior that its actual input actually maps > to. That is a tautology: „It must simulate that way that it can.” But it is not free to make something up and claim itself infallible > Instead everyone here expects that the halt decider must map to the > English description of what the authors of textbooks expect it to map > to. That is the definition of a halt decider. If it does not fit that definition, it is not one. > *DDD simulated by H0 DOES NOT HALT* *incorrectly Yes, it does not halt. That is a wrong simulation, as DDD does halt. > Everyone here stupidly ignores that the pathological relationship that > DDD calls H0(DDD) changes the behavior of DDD. A simulator can’t change the behaviour of its input, it is bound by it.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-27 12:38 -0500 |
| Subject | Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met |
| Message-ID | <v5k824$2qsdr$6@dont-email.me> |
| In reply to | #107935 |
On 6/27/2024 12:25 PM, joes wrote: > Am Thu, 27 Jun 2024 11:56:56 -0500 schrieb olcott: >> On 6/27/2024 10:35 AM, Mikko wrote: >>> On 2024-06-27 14:10:02 +0000, olcott said: >>>> On 6/27/2024 2:36 AM, Mikko wrote: >>>>> On 2024-06-26 12:58:59 +0000, olcott said: >>>>>> On 6/26/2024 3:41 AM, Mikko wrote: >>>>>>> On 2024-06-26 02:29:59 +0000, olcott said: >>>>>>>> On 6/25/2024 9:23 PM, Richard Damon wrote: >>>>>>>>> On 6/25/24 10:05 PM, olcott wrote: >>>>>>>>>> On 6/25/2024 8:47 PM, Richard Damon wrote: >>>>>>>>>>> On 6/25/24 1:45 PM, olcott wrote: >>>>>>>>>>>> On 6/25/2024 9:46 AM, Alan Mackenzie wrote: >>>>>>>>>>>>> Ben Bacarisse <ben@bsb.me.uk> wrote: >>>>>>>>>>>>>> Alan Mackenzie <acm@muc.de> writes: >>>>>>>>>>>>>>> In comp.theory olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>>>> On 6/25/2024 4:22 AM, joes wrote: >>>>>>>>>>>>>>>>> Am Sat, 22 Jun 2024 13:47:24 -0500 schrieb olcott: >>>>>>>>>>>>>>>>>> On 6/22/2024 1:39 PM, Fred. Zwarts wrote: >>>>>>>>>>>>>>>>>>> Op 21.jun.2024 om 15:21 schreef olcott: > >>>>>> If this was true then everyone here would already know that H(P,P) >>>>>> is not even being asked about the behavior of the directly executed >>>>>> P(P). >>>>> >>>>> Everyone knwos that H(P,P) is not asked anything. >>>>> >>>> In computability theory and computational complexity theory, a >>>> decision problem is a computational problem that can be posed as a >>>> yes–no question of the input values. >>> >>> That's right. But that question cannot be presented to the decider. >>> Only the input values can. >>> >> In other words you are saying that Turing machines do not typically >> understand English. > No. The input is merely a variable in the question. The question is > implicit. > Not at all. That is flat out incorrect. The input is a specific finite string of bytes that has the semantics of the x86 programming language. >> None-the-less no-one here understands that every halt decider is only >> required to report on the behavior that its actual input actually maps >> to. > That is a tautology: „It must simulate that way that it can.” > But it is not free to make something up and claim itself infallible > DDD correctly simulated by H0 cannot possible halt. The same thing goes for the conventional halting problem input. >> Instead everyone here expects that the halt decider must map to the >> English description of what the authors of textbooks expect it to map >> to. > That is the definition of a halt decider. If it does not fit that > definition, it is not one. > We could "define" a zipangnitfark as a square circle that has a radius of a zebra with each equally length side having the length of a misconception. Some definitions ARE incorrect. >> *DDD simulated by H0 DOES NOT HALT* > *incorrectly > Yes, it does not halt. That is a wrong simulation, as DDD does halt. > >> Everyone here stupidly ignores that the pathological relationship that >> DDD calls H0(DDD) changes the behavior of DDD. > A simulator can’t change the behaviour of its input, it is bound by it. > -- 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 | Mikko <mikko.levanto@iki.fi> |
|---|---|
| Date | 2024-06-28 12:25 +0300 |
| Subject | Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met |
| Message-ID | <v5lvhu$39e8b$1@dont-email.me> |
| In reply to | #107937 |
On 2024-06-27 17:38:12 +0000, olcott said: > On 6/27/2024 12:25 PM, joes wrote: >> Am Thu, 27 Jun 2024 11:56:56 -0500 schrieb olcott: >>> On 6/27/2024 10:35 AM, Mikko wrote: >>>> On 2024-06-27 14:10:02 +0000, olcott said: >>>>> On 6/27/2024 2:36 AM, Mikko wrote: >>>>>> On 2024-06-26 12:58:59 +0000, olcott said: >>>>>>> On 6/26/2024 3:41 AM, Mikko wrote: >>>>>>>> On 2024-06-26 02:29:59 +0000, olcott said: >>>>>>>>> On 6/25/2024 9:23 PM, Richard Damon wrote: >>>>>>>>>> On 6/25/24 10:05 PM, olcott wrote: >>>>>>>>>>> On 6/25/2024 8:47 PM, Richard Damon wrote: >>>>>>>>>>>> On 6/25/24 1:45 PM, olcott wrote: >>>>>>>>>>>>> On 6/25/2024 9:46 AM, Alan Mackenzie wrote: >>>>>>>>>>>>>> Ben Bacarisse <ben@bsb.me.uk> wrote: >>>>>>>>>>>>>>> Alan Mackenzie <acm@muc.de> writes: >>>>>>>>>>>>>>>> In comp.theory olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>>>>> On 6/25/2024 4:22 AM, joes wrote: >>>>>>>>>>>>>>>>>> Am Sat, 22 Jun 2024 13:47:24 -0500 schrieb olcott: >>>>>>>>>>>>>>>>>>> On 6/22/2024 1:39 PM, Fred. Zwarts wrote: >>>>>>>>>>>>>>>>>>>> Op 21.jun.2024 om 15:21 schreef olcott: >> >>>>>>> If this was true then everyone here would already know that H(P,P) >>>>>>> is not even being asked about the behavior of the directly executed >>>>>>> P(P). >>>>>> >>>>>> Everyone knwos that H(P,P) is not asked anything. >>>>>> >>>>> In computability theory and computational complexity theory, a >>>>> decision problem is a computational problem that can be posed as a >>>>> yes–no question of the input values. >>>> >>>> That's right. But that question cannot be presented to the decider. >>>> Only the input values can. >>>> >>> In other words you are saying that Turing machines do not typically >>> understand English. > >> No. The input is merely a variable in the question. The question is >> implicit. >> > Not at all. That is flat out incorrect. You are wrong. The input is the variable in the question. The question is not a part of the input. > The input is a specific finite string of bytes that > has the semantics of the x86 programming language. For a decider that is made for that sort of input. But there cannot be any question in that input. >>> None-the-less no-one here understands that every halt decider is only >>> required to report on the behavior that its actual input actually maps >>> to. > >> That is a tautology: „It must simulate that way that it can.” >> But it is not free to make something up and claim itself infallible >> > DDD correctly simulated by H0 cannot possible halt. > The same thing goes for the conventional halting problem input. > >>> Instead everyone here expects that the halt decider must map to the >>> English description of what the authors of textbooks expect it to map >>> to. > >> That is the definition of a halt decider. If it does not fit that >> definition, it is not one. >> > > We could "define" a zipangnitfark as a square circle > that has a radius of a zebra with each equally > length side having the length of a misconception. > > Some definitions ARE incorrect. That definition is not incorrect. It may be unsuitable for your purposes but that does not make it incorrect. All parts of a good definition are there: the term for the concept, the superconcept, and the differentiating feature. Definitions like this would be a great improvement to your writings. -- Mikko
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-28 10:21 -0500 |
| Subject | Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met |
| Message-ID | <v5mkdb$3cibm$6@dont-email.me> |
| In reply to | #107953 |
On 6/28/2024 4:25 AM, Mikko wrote: > On 2024-06-27 17:38:12 +0000, olcott said: > >> On 6/27/2024 12:25 PM, joes wrote: >>> Am Thu, 27 Jun 2024 11:56:56 -0500 schrieb olcott: >>> No. The input is merely a variable in the question. The question is >>> implicit. >>> >> Not at all. That is flat out incorrect. > > You are wrong. The input is the variable in the question. The question > is not a part of the input. > The input is the machine address of the finite string of x86 machine code. >> The input is a specific finite string of bytes that >> has the semantics of the x86 programming language. > > For a decider that is made for that sort of input. But there cannot be > any question in that input. > The question is: Does this finite string of machine code specify behavior that terminates normally? >>>> None-the-less no-one here understands that every halt decider is only >>>> required to report on the behavior that its actual input actually maps >>>> to. >> >>> That is a tautology: „It must simulate that way that it can.” >>> But it is not free to make something up and claim itself infallible >>> >> DDD correctly simulated by H0 cannot possible halt. >> The same thing goes for the conventional halting problem input. >> >>>> Instead everyone here expects that the halt decider must map to the >>>> English description of what the authors of textbooks expect it to map >>>> to. >> >>> That is the definition of a halt decider. If it does not fit that >>> definition, it is not one. >>> >> >> We could "define" a zipangnitfark as a square circle >> that has a radius of a zebra with each equally >> length side having the length of a misconception. >> >> Some definitions ARE incorrect. > > That definition is not incorrect. It has type mismatch errors making it incorrect. If I ask you how many kilos do your misconceptions weigh you cannot provide a correct answer because of the type mismatch error in the question. > It may be unsuitable for your purposes > but that does not make it incorrect. All parts of a good definition are > there: the term for the concept, the superconcept, and the differentiating > feature. Definitions like this would be a great improvement to your > writings. > Incoherent definitions are incorrect definitions. When I define Snitfinbangflizzledroop as the square-root of misconceptions about the US constitution my definition is incorrect because there is no mapping from the input of misconceptions about the US constitution to any square-root value. -- 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-28 16:21 +0000 |
| Subject | Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met |
| Message-ID | <v5mnu0$1d3t3$1@i2pn2.org> |
| In reply to | #107970 |
Am Fri, 28 Jun 2024 10:21:15 -0500 schrieb olcott: > On 6/28/2024 4:25 AM, Mikko wrote: >> On 2024-06-27 17:38:12 +0000, olcott said: >>> On 6/27/2024 12:25 PM, joes wrote: >>>> Am Thu, 27 Jun 2024 11:56:56 -0500 schrieb olcott: >> You are wrong. The input is the variable in the question. The question >> is not a part of the input. > The input is the machine address of the finite string of x86 machine > code. And in that input there is no question about whether itself halts. That is in the programming of the analyser. >>> The input is a specific finite string of bytes that has the semantics >>> of the x86 programming language. >> For a decider that is made for that sort of input. But there cannot be >> any question in that input. > The question is: > Does this finite string of machine code specify behavior that terminates > normally? And the question is not: Do I, the analyser, give the correct answer? It has no power to declare itself the authority. >>>>> None-the-less no-one here understands that every halt decider is >>>>> only required to report on the behavior that its actual input >>>>> actually maps to. What do you even mean? Of course it follows its programming and does not spontaneously generate an answer. It may not be possible to write such a program: then there is indeed no machine that can compute it, but the input still has a defined halting status >>>>> Instead everyone here expects that the halt decider must map to the >>>>> English description of what the authors of textbooks expect it to >>>>> map to. >>>> That is the definition of a halt decider. If it does not fit that >>>> definition, it is not one. >>> Some definitions ARE incorrect. >> That definition is not incorrect. > When I define Snitfinbangflizzledroop as the square-root of > misconceptions about the US constitution my definition is incorrect > because there is no mapping from the input of misconceptions about the > US constitution to any square-root value. There is an obvious mapping from D to its behaviour: run it, or give it to any simulator /that it does not call/.
[toc] | [prev] | [next] | [standalone]
| From | Mikko <mikko.levanto@iki.fi> |
|---|---|
| Date | 2024-06-29 11:05 +0300 |
| Subject | Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met |
| Message-ID | <v5of91$3r6an$1@dont-email.me> |
| In reply to | #107970 |
On 2024-06-28 15:21:15 +0000, olcott said: > On 6/28/2024 4:25 AM, Mikko wrote: >> On 2024-06-27 17:38:12 +0000, olcott said: >> >>> On 6/27/2024 12:25 PM, joes wrote: >>>> Am Thu, 27 Jun 2024 11:56:56 -0500 schrieb olcott: >>>> No. The input is merely a variable in the question. The question is >>>> implicit. >>>> >>> Not at all. That is flat out incorrect. >> >> You are wrong. The input is the variable in the question. The question >> is not a part of the input. > > The input is the machine address of the finite string > of x86 machine code. Not just the address. The input include everyting the pregram reads, in particular the finite string the input points to. But the current point is that there is no question there and not place to where a question could be put. >>> The input is a specific finite string of bytes that >>> has the semantics of the x86 programming language. >> >> For a decider that is made for that sort of input. But there cannot be >> any question in that input. > The question is: > Does this finite string of machine code specify behavior > that terminates normally? That is the question the program is expected to answer but the program cannot be asked that question, or any other. >>>>> None-the-less no-one here understands that every halt decider is only >>>>> required to report on the behavior that its actual input actually maps >>>>> to. >>> >>>> That is a tautology: „It must simulate that way that it can.” >>>> But it is not free to make something up and claim itself infallible >>>> >>> DDD correctly simulated by H0 cannot possible halt. >>> The same thing goes for the conventional halting problem input. >>> >>>>> Instead everyone here expects that the halt decider must map to the >>>>> English description of what the authors of textbooks expect it to map >>>>> to. >>> >>>> That is the definition of a halt decider. If it does not fit that >>>> definition, it is not one. >>>> >>> >>> We could "define" a zipangnitfark as a square circle >>> that has a radius of a zebra with each equally >>> length side having the length of a misconception. >>> >>> Some definitions ARE incorrect. >> >> That definition is not incorrect. > > It has type mismatch errors making it incorrect. The type mismatch error might make all use of the definition incorrect but not the definition itself. > If I ask you how many kilos do your misconceptions > weigh you cannot provide a correct answer because > of the type mismatch error in the question. I can provide an answer that I consder correct. > Incoherent definitions are incorrect definitions. They are not incorrect but probably useless for their purpose. > When I define Snitfinbangflizzledroop as the square-root > of misconceptions about the US constitution my definition > is incorrect because there is no mapping from the input > of misconceptions about the US constitution to any square-root > value. That does not make the definition incorrect. You just can't apply that definition if you don't know the mapping. -- Mikko
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-27 19:57 -0400 |
| Subject | Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met |
| Message-ID | <v5ku8k$1as00$1@i2pn2.org> |
| In reply to | #107931 |
On 6/27/24 12:56 PM, olcott wrote: > On 6/27/2024 10:35 AM, Mikko wrote: >> On 2024-06-27 14:10:02 +0000, olcott said: >> >>> On 6/27/2024 2:36 AM, Mikko wrote: >>>> On 2024-06-26 12:58:59 +0000, olcott said: >>>> >>>>> On 6/26/2024 3:41 AM, Mikko wrote: >>>>>> On 2024-06-26 02:29:59 +0000, olcott said: >>>>>> >>>>>>> On 6/25/2024 9:23 PM, Richard Damon wrote: >>>>>>>> On 6/25/24 10:05 PM, olcott wrote: >>>>>>>>> On 6/25/2024 8:47 PM, Richard Damon wrote: >>>>>>>>>> On 6/25/24 1:45 PM, olcott wrote: >>>>>>>>>>> On 6/25/2024 9:46 AM, Alan Mackenzie wrote: >>>>>>>>>>>> Hi, Ben. >>>>>>>>>>>> >>>>>>>>>>>> Ben Bacarisse <ben@bsb.me.uk> wrote: >>>>>>>>>>>>> Alan Mackenzie <acm@muc.de> writes: >>>>>>>>>>>> >>>>>>>>>>>>>> In comp.theory olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>>> On 6/25/2024 4:22 AM, joes wrote: >>>>>>>>>>>>>>>> Am Sat, 22 Jun 2024 13:47:24 -0500 schrieb olcott: >>>>>>>>>>>>>>>>> On 6/22/2024 1:39 PM, Fred. Zwarts wrote: >>>>>>>>>>>>>>>>>> Op 21.jun.2024 om 15:21 schreef olcott: >>>>>>>>>>>> >>>>>>>>>>>>>>>>> When we stipulate that the only measure of a correct >>>>>>>>>>>>>>>>> emulation is the >>>>>>>>>>>>>>>>> semantics of the x86 programming language then we see >>>>>>>>>>>>>>>>> that when DDD is >>>>>>>>>>>>>>>>> correctly emulated by H0 that its call to H0(DDD) >>>>>>>>>>>>>>>>> cannot possibly >>>>>>>>>>>>>>>>> return. >>>>>>>>>>>>>>>> Yes. Which is wrong, because H0 should terminate. >>>>>>>>>>>> >>>>>>>>>>>>>> [ .... ] >>>>>>>>>>>> >>>>>>>>>>>>>>> The call from DDD to H0(DDD) when DDD is correctly emulated >>>>>>>>>>>>>>> by H0 cannot possibly return. >>>>>>>>>>>> >>>>>>>>>>>>>>> Until you acknowledge this is true, this is the >>>>>>>>>>>>>>> only thing that I am willing to talk to you about. >>>>>>>>>>>> >>>>>>>>>>>>>> I think you are talking at cross purposes. Joes's point >>>>>>>>>>>>>> is that H0 >>>>>>>>>>>>>> should terminate because it's a decider. You're saying >>>>>>>>>>>>>> that when H0 is >>>>>>>>>>>>>> "correctly" emulating, it won't terminate. I don't recall >>>>>>>>>>>>>> seeing anybody >>>>>>>>>>>>>> arguing against that. >>>>>>>>>>>> >>>>>>>>>>>>>> So you're saying, in effect, H0 is not a decider. I don't >>>>>>>>>>>>>> think anybody >>>>>>>>>>>>>> else would argue against that, either. >>>>>>>>>>>> >>>>>>>>>>>>> He's been making exactly the same nonsense argument for >>>>>>>>>>>>> years. It >>>>>>>>>>>>> became crystal clear a little over three years ago when he >>>>>>>>>>>>> made the >>>>>>>>>>>>> mistake of posting the pseudo-code for H -- a step by step >>>>>>>>>>>>> simulator >>>>>>>>>>>>> that stopped simulating (famously on line 15) when some >>>>>>>>>>>>> pattern was >>>>>>>>>>>>> detected. He declared false (not halting) to be the >>>>>>>>>>>>> correct result for >>>>>>>>>>>>> the halting computation H(H_Hat(), H_Hat()) because of what >>>>>>>>>>>>> H(H_Hat(), >>>>>>>>>>>>> H_Hat()) would do "if line 15 were commented out"! >>>>>>>>>>>> >>>>>>>>>>>>> PO does occasionally make it clear what the shell game is. >>>>>>>>>>>> >>>>>>>>>>>> I think it's important for (relative) newcomers to the >>>>>>>>>>>> newsgroup to >>>>>>>>>>>> become aware of this. Each one of them is trying to help PO >>>>>>>>>>>> improve his >>>>>>>>>>>> level of learning. They will eventually give up, as you and >>>>>>>>>>>> I have >>>>>>>>>>>> done, recognising (as Mike Terry, in particular, has done) that >>>>>>>>>>>> enriching PO's intellect is a quite impossible task. >>>>>>>>>>>> >>>>>>>>>>>> What's the betting he'll respond to this post with his usual >>>>>>>>>>>> short >>>>>>>>>>>> sequence of x86 assembly code together with a demand to >>>>>>>>>>>> recognise >>>>>>>>>>>> something or other as non-terminating? >>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Ben. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> <MIT Professor Sipser agreed to ONLY these verbatim words >>>>>>>>>>> 10/13/2022> >>>>>>>>>>> If simulating halt decider H correctly simulates its >>>>>>>>>>> input D >>>>>>>>>>> until H correctly determines that its simulated D would >>>>>>>>>>> never >>>>>>>>>>> stop running unless aborted then >>>>>>>>>>> >>>>>>>>>>> H can abort its simulation of D and correctly report that D >>>>>>>>>>> specifies a non-halting sequence of configurations. >>>>>>>>>>> </MIT Professor Sipser agreed to ONLY these verbatim words >>>>>>>>>>> 10/13/2022> >>>>>>>>>>> >>>>>>>>>>> On 10/14/2022 7:44 PM, Ben Bacarisse wrote: >>>>>>>>>>> > I don't think that is the shell game. PO really /has/ an H >>>>>>>>>>> > (it's trivial to do for this one case) that correctly >>>>>>>>>>> determines >>>>>>>>>>> > that P(P) *would* never stop running *unless* aborted. >>>>>>>>>>> > >>>>>>>>>>> > He knows and accepts that P(P) actually does stop. The >>>>>>>>>>> > wrong answer is justified by what would happen if H >>>>>>>>>>> > (and hence a different P) where not what they actually are. >>>>>>>>>>> > >>>>>>>>>>> >>>>>>>>>>> Ben thinks that I tricked professor Sipser into agreeing >>>>>>>>>>> with something that he did not fully understand. >>>>>>>>>>> >>>>>>>>>>> *The real issue is that no one here sufficiently understands* >>>>>>>>>>> *the highlighted portion of the following definition* >>>>>>>>>>> >>>>>>>>>>> Computable functions are the formalized analogue of the >>>>>>>>>>> intuitive notion of algorithms, in the sense that a >>>>>>>>>>> function is computable if there exists an algorithm >>>>>>>>>>> that can do the job of the function, i.e. >>>>>>>>>>> >>>>>>>>>>> *given an input of the function domain* >>>>>>>>>>> *it can return the corresponding output* >>>>>>>>>>> >>>>>>>>>>> https://en.wikipedia.org/wiki/Computable_function >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> But only if the function is, in fact, computable. >>>>>>>>>> >>>>>>>>>> Since Halting isn't, you can't use that fact. >>>>>>>>> >>>>>>>>> If I ask you: What time is it? >>>>>>>>> and you do not tell me the answer to the question hidden >>>>>>>>> in my mind "What did you have for dinner?" We cannot say >>>>>>>>> that you provided the wrong answer when you tell me what >>>>>>>>> time it is. >>>>>>>> >>>>>>>> Because I answered the actual question. >>>>>>>> >>>>>>>> Just like the "Halt Decider" needs to answer the "Halt Decider >>>>>>>> Question" and not answer about POOP. >>>>>>>> >>>>>>>>> >>>>>>>>> When we ask H to tell us whether its actual input halts >>>>>>>>> H can only answer that P correctly simulated by H will not halt. >>>>>>>>> H cannot answer the question hidden in your mind. >>>>>>>>> >>>>>>>> >>>>>>>> Then you are just admitting that it can't be a Halt Decider. >>>>>>>> >>>>>>>> If it isn't what the definition requires, it just isn't one. >>>>>>> >>>>>>> Yes and everyone knows that computer scientists are much >>>>>>> more infallible than God thus cannot possibly ever make >>>>>>> a definition that is incoherent in ways that these 100% >>>>>>> infallible computer scientists never noticed. >>>>>> >>>>>> Actually, it is the opposite. Everybody, or at least all computer >>>>>> scientists and engineers, know that they, and all peaple, are >>>>>> fallible, >>>>>> at least when making programs and when inferring about programs. >>>>>> Therefore >>>>>> computer engineers demand that every program must be tested, and >>>>>> computer >>>>>> scinetists demand that every claim is proven. >>>>> >>>>> If this was true then everyone here would already know >>>>> that H(P,P) is not even being asked about the behavior >>>>> of the directly executed P(P). >>>> >>>> Everyone knwos that H(P,P) is not asked anything. >>>> >>> >>> In computability theory and computational complexity theory, a >>> decision problem is a computational problem that can be posed as >>> a yes–no question of the input values. >>> https://en.wikipedia.org/wiki/Decision_problem >> >> That's right. But that question cannot be presented to the decider. >> Only the input values can. >> > In other words you are saying that Turing machines do not > typically understand English. Nor are they expected to. > > None-the-less no-one here understands that every halt decider > is only required to report on the behavior that its actual > input actually maps to. Right. > > Instead everyone here expects that the halt decider must map > to the English description of what the authors of textbooks > expect it to map to. But that is the definition of the problem that it is supposed to answer, and defined the "behavior" of the actual input. > > We already agreed that Turing machines do not typically > understand English, so this assumption is stupid. > > *DDD correctly simulated by H0 DOES NOT HALT* Which isn't a valid property of DDD, so not a proper question for the decider. It is a property of the machien PAIR, DDD and H0, so a decider of that question would be something like POOP(DDD, H0) which computes the mapping of the decider/input pair to the answer of the question can this decider correct simulate this input to its final state, which also isn't a proper question, as it isn't a "Can" type of question, but a "Does". Since H0 has fixed behavior, it only does what it does, so the hypthetical nature of the word "Can" doesn't apply. > > Everyone here stupidly ignores that the pathological > relationship that DDD calls H0(DDD) changes the behavior > of DDD. > > But it doesn't, as its behavior is, and only is, what it does when run. And DDD and H0 need to be SPECIFIC machine to even talk about their behavior, and thus both of those behaviors have been lock by design, and H
[toc] | [prev] | [next] | [standalone]
| From | Mikko <mikko.levanto@iki.fi> |
|---|---|
| Date | 2024-06-28 11:30 +0300 |
| Subject | Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met |
| Message-ID | <v5lsba$38t1k$1@dont-email.me> |
| In reply to | #107931 |
On 2024-06-27 16:56:56 +0000, olcott said: > On 6/27/2024 10:35 AM, Mikko wrote: >> On 2024-06-27 14:10:02 +0000, olcott said: >> >>> On 6/27/2024 2:36 AM, Mikko wrote: >>>> On 2024-06-26 12:58:59 +0000, olcott said: >>>> >>>>> On 6/26/2024 3:41 AM, Mikko wrote: >>>>>> On 2024-06-26 02:29:59 +0000, olcott said: >>>>>> >>>>>>> On 6/25/2024 9:23 PM, Richard Damon wrote: >>>>>>>> On 6/25/24 10:05 PM, olcott wrote: >>>>>>>>> On 6/25/2024 8:47 PM, Richard Damon wrote: >>>>>>>>>> On 6/25/24 1:45 PM, olcott wrote: >>>>>>>>>>> On 6/25/2024 9:46 AM, Alan Mackenzie wrote: >>>>>>>>>>>> Hi, Ben. >>>>>>>>>>>> >>>>>>>>>>>> Ben Bacarisse <ben@bsb.me.uk> wrote: >>>>>>>>>>>>> Alan Mackenzie <acm@muc.de> writes: >>>>>>>>>>>> >>>>>>>>>>>>>> In comp.theory olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>>> On 6/25/2024 4:22 AM, joes wrote: >>>>>>>>>>>>>>>> Am Sat, 22 Jun 2024 13:47:24 -0500 schrieb olcott: >>>>>>>>>>>>>>>>> On 6/22/2024 1:39 PM, Fred. Zwarts wrote: >>>>>>>>>>>>>>>>>> Op 21.jun.2024 om 15:21 schreef olcott: >>>>>>>>>>>> >>>>>>>>>>>>>>>>> When we stipulate that the only measure of a correct emulation is the >>>>>>>>>>>>>>>>> semantics of the x86 programming language then we see that when DDD is >>>>>>>>>>>>>>>>> correctly emulated by H0 that its call to H0(DDD) cannot possibly >>>>>>>>>>>>>>>>> return. >>>>>>>>>>>>>>>> Yes. Which is wrong, because H0 should terminate. >>>>>>>>>>>> >>>>>>>>>>>>>> [ .... ] >>>>>>>>>>>> >>>>>>>>>>>>>>> The call from DDD to H0(DDD) when DDD is correctly emulated >>>>>>>>>>>>>>> by H0 cannot possibly return. >>>>>>>>>>>> >>>>>>>>>>>>>>> Until you acknowledge this is true, this is the >>>>>>>>>>>>>>> only thing that I am willing to talk to you about. >>>>>>>>>>>> >>>>>>>>>>>>>> I think you are talking at cross purposes. Joes's point is that H0 >>>>>>>>>>>>>> should terminate because it's a decider. You're saying that when H0 is >>>>>>>>>>>>>> "correctly" emulating, it won't terminate. I don't recall seeing anybody >>>>>>>>>>>>>> arguing against that. >>>>>>>>>>>> >>>>>>>>>>>>>> So you're saying, in effect, H0 is not a decider. I don't think anybody >>>>>>>>>>>>>> else would argue against that, either. >>>>>>>>>>>> >>>>>>>>>>>>> He's been making exactly the same nonsense argument for years. It >>>>>>>>>>>>> became crystal clear a little over three years ago when he made the >>>>>>>>>>>>> mistake of posting the pseudo-code for H -- a step by step simulator >>>>>>>>>>>>> that stopped simulating (famously on line 15) when some pattern was >>>>>>>>>>>>> detected. He declared false (not halting) to be the correct result for >>>>>>>>>>>>> the halting computation H(H_Hat(), H_Hat()) because of what H(H_Hat(), >>>>>>>>>>>>> H_Hat()) would do "if line 15 were commented out"! >>>>>>>>>>>> >>>>>>>>>>>>> PO does occasionally make it clear what the shell game is. >>>>>>>>>>>> >>>>>>>>>>>> I think it's important for (relative) newcomers to the newsgroup to >>>>>>>>>>>> become aware of this. Each one of them is trying to help PO improve his >>>>>>>>>>>> level of learning. They will eventually give up, as you and I have >>>>>>>>>>>> done, recognising (as Mike Terry, in particular, has done) that >>>>>>>>>>>> enriching PO's intellect is a quite impossible task. >>>>>>>>>>>> >>>>>>>>>>>> What's the betting he'll respond to this post with his usual short >>>>>>>>>>>> sequence of x86 assembly code together with a demand to recognise >>>>>>>>>>>> something or other as non-terminating? >>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Ben. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>>>>>>>> If simulating halt decider H correctly simulates its input D >>>>>>>>>>> until H correctly determines that its simulated D would never >>>>>>>>>>> stop running unless aborted then >>>>>>>>>>> >>>>>>>>>>> H can abort its simulation of D and correctly report that D >>>>>>>>>>> specifies a non-halting sequence of configurations. >>>>>>>>>>> </MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>>>>>>>> >>>>>>>>>>> On 10/14/2022 7:44 PM, Ben Bacarisse wrote: >>>>>>>>>>> > I don't think that is the shell game. PO really /has/ an H >>>>>>>>>>> > (it's trivial to do for this one case) that correctly determines >>>>>>>>>>> > that P(P) *would* never stop running *unless* aborted. >>>>>>>>>>> > >>>>>>>>>>> > He knows and accepts that P(P) actually does stop. The >>>>>>>>>>> > wrong answer is justified by what would happen if H >>>>>>>>>>> > (and hence a different P) where not what they actually are. >>>>>>>>>>> > >>>>>>>>>>> >>>>>>>>>>> Ben thinks that I tricked professor Sipser into agreeing >>>>>>>>>>> with something that he did not fully understand. >>>>>>>>>>> >>>>>>>>>>> *The real issue is that no one here sufficiently understands* >>>>>>>>>>> *the highlighted portion of the following definition* >>>>>>>>>>> >>>>>>>>>>> Computable functions are the formalized analogue of the >>>>>>>>>>> intuitive notion of algorithms, in the sense that a >>>>>>>>>>> function is computable if there exists an algorithm >>>>>>>>>>> that can do the job of the function, i.e. >>>>>>>>>>> >>>>>>>>>>> *given an input of the function domain* >>>>>>>>>>> *it can return the corresponding output* >>>>>>>>>>> >>>>>>>>>>> https://en.wikipedia.org/wiki/Computable_function >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> But only if the function is, in fact, computable. >>>>>>>>>> >>>>>>>>>> Since Halting isn't, you can't use that fact. >>>>>>>>> >>>>>>>>> If I ask you: What time is it? >>>>>>>>> and you do not tell me the answer to the question hidden >>>>>>>>> in my mind "What did you have for dinner?" We cannot say >>>>>>>>> that you provided the wrong answer when you tell me what >>>>>>>>> time it is. >>>>>>>> >>>>>>>> Because I answered the actual question. >>>>>>>> >>>>>>>> Just like the "Halt Decider" needs to answer the "Halt Decider >>>>>>>> Question" and not answer about POOP. >>>>>>>> >>>>>>>>> >>>>>>>>> When we ask H to tell us whether its actual input halts >>>>>>>>> H can only answer that P correctly simulated by H will not halt. >>>>>>>>> H cannot answer the question hidden in your mind. >>>>>>>>> >>>>>>>> >>>>>>>> Then you are just admitting that it can't be a Halt Decider. >>>>>>>> >>>>>>>> If it isn't what the definition requires, it just isn't one. >>>>>>> >>>>>>> Yes and everyone knows that computer scientists are much >>>>>>> more infallible than God thus cannot possibly ever make >>>>>>> a definition that is incoherent in ways that these 100% >>>>>>> infallible computer scientists never noticed. >>>>>> >>>>>> Actually, it is the opposite. Everybody, or at least all computer >>>>>> scientists and engineers, know that they, and all peaple, are fallible, >>>>>> at least when making programs and when inferring about programs. Therefore >>>>>> computer engineers demand that every program must be tested, and computer >>>>>> scinetists demand that every claim is proven. >>>>> >>>>> If this was true then everyone here would already know >>>>> that H(P,P) is not even being asked about the behavior >>>>> of the directly executed P(P). >>>> >>>> Everyone knwos that H(P,P) is not asked anything. >>>> >>> >>> In computability theory and computational complexity theory, a >>> decision problem is a computational problem that can be posed as >>> a yes–no question of the input values. >>> https://en.wikipedia.org/wiki/Decision_problem >> >> That's right. But that question cannot be presented to the decider. >> Only the input values can. >> > In other words you are saying that Turing machines do not > typically understand English. I didn't mean it that generally, only about deciders, but yes, typical Turing machines do not understand any English. More specifically, the specification of a halt decider (or any typical decider) prevents it from being asked in any language. > None-the-less no-one here understands that every halt decider > is only required to report on the behavior that its actual > input actually maps to. As far as I have seen, most of them do. And not just maps but maps in the way specified by the problem statement. > Instead everyone here expects that the halt decider must map > to the English description of what the authors of textbooks > expect it to map to. Your "everyone" is a lie. As far as I have seen, nobody has expressed that expectation, and several have said otherwise. > We already agreed that Turing machines do not typically > understand English, so this assumption is stupid. You may have agreed but you failed to keep that agreement. > *DDD correctly simulated by H0 DOES NOT HALT* The message where DDD was introduced specifies that DDD halts if and only if H0 halts. > Everyone here stupidly ignores that the pathological > relationship that DDD calls H0(DDD) changes the behavior > of DDD. If and only if it changes the behaviour of H0, which is possible if and only if H0 is not a pure function. -- Mikko
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-28 07:40 -0500 |
| Subject | Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met |
| Message-ID | <v5mb0p$3b1p0$2@dont-email.me> |
| In reply to | #107950 |
On 6/28/2024 3:30 AM, Mikko wrote:
> On 2024-06-27 16:56:56 +0000, olcott said:
>
>> On 6/27/2024 10:35 AM, Mikko wrote:
>>> On 2024-06-27 14:10:02 +0000, olcott said:
>>>>
>>>> In computability theory and computational complexity theory, a
>>>> decision problem is a computational problem that can be posed as
>>>> a yes–no question of the input values.
>>>> https://en.wikipedia.org/wiki/Decision_problem
>>>
>>> That's right. But that question cannot be presented to the decider.
>>> Only the input values can.
>>>
>> In other words you are saying that Turing machines do not
>> typically understand English.
>
> I didn't mean it that generally, only about deciders, but yes, typical
> Turing machines do not understand any English. More specifically, the
> specification of a halt decider (or any typical decider) prevents it
> from being asked in any language.
>
// The question: Is x > y ?
bool GreaterThan(int x, int y) { return (x > y); }
Deciders are always asked a yes/no question of their
inputs in their own native language.
>> None-the-less no-one here understands that every halt decider
>> is only required to report on the behavior that its actual
>> input actually maps to.
>
> As far as I have seen, most of them do. And not just maps but maps
> in the way specified by the problem statement.
>
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call H0(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
The call from DDD to H0(DDD) when N steps of DDD are correctly
emulated by any pure function x86 emulator H0 cannot possibly return.
The behavior of the directly executed DDD() is irrelevant
because that is not the behavior of the input. Deciders
compute the mapping from their actual finite string input
to an output by a sequence of finite string transformations.
In this case the sequence is the line-by-line execution
trace of the behavior of DDD correctly emulated by H0.
The behavior of this input must include and cannot ignore
the recursive emulation specified by the fact that DDD is
calling its own emulator. That people think they can just
pretend that this is not happening is ridiculous.
>> Instead everyone here expects that the halt decider must map
>> to the English description of what the authors of textbooks
>> expect it to map to.
>
> Your "everyone" is a lie. As far as I have seen, nobody has expressed
> that expectation, and several have said otherwise.
>
Everyone that states an opinion says that the decider
must go by the textbook definitions of the problem thus
not the problem instance actually encoded by the input.
>> We already agreed that Turing machines do not typically
>> understand English, so this assumption is stupid.
>
> You may have agreed but you failed to keep that agreement.
>
>> *DDD correctly simulated by H0 DOES NOT HALT*
>
> The message where DDD was introduced specifies that DDD halts
> if and only if H0 halts.
>
That is simply ignorance of the details of software engineering.
>> Everyone here stupidly ignores that the pathological
>> relationship that DDD calls H0(DDD) changes the behavior
>> of DDD.
>
> If and only if it changes the behaviour of H0, which is possible if
> and only if H0 is not a pure function.
>
The directly executed H0 always uses this criteria and returns a
correct halt status for every input in its domain.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its input D
until H correctly determines that its simulated D would never
stop running unless aborted then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
--
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-28 13:04 +0000 |
| Subject | Re: Ben agrees that Sipser approved criteria is met |
| Message-ID | <v5mcc9$1cgj0$2@i2pn2.org> |
| In reply to | #107956 |
Am Fri, 28 Jun 2024 07:40:57 -0500 schrieb olcott: > On 6/28/2024 3:30 AM, Mikko wrote: >> On 2024-06-27 16:56:56 +0000, olcott said: > Deciders are always asked a yes/no question of their > inputs in their own native language. Yes, and the question here is „Does the input halt?” and not „Do I simulate this to halt?”. >>> Instead everyone here expects that the halt decider must map >>> to the English description of what the authors of textbooks >>> expect it to map to. Naturally. Why should it not work as defined. > Everyone that states an opinion says that the decider > must go by the textbook definitions of the problem thus > not the problem instance actually encoded by the input. That IS the instance encoded by the input. We call H with DDD, not H with H(DDD).
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-28 23:49 -0400 |
| Subject | Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met |
| Message-ID | <v5o089$1eli4$3@i2pn2.org> |
| In reply to | #107956 |
On 6/28/24 8:40 AM, olcott wrote:
> On 6/28/2024 3:30 AM, Mikko wrote:
>> On 2024-06-27 16:56:56 +0000, olcott said:
>>
>>> On 6/27/2024 10:35 AM, Mikko wrote:
>>>> On 2024-06-27 14:10:02 +0000, olcott said:
>>>>>
>>>>> In computability theory and computational complexity theory, a
>>>>> decision problem is a computational problem that can be posed as
>>>>> a yes–no question of the input values.
>>>>> https://en.wikipedia.org/wiki/Decision_problem
>>>>
>>>> That's right. But that question cannot be presented to the decider.
>>>> Only the input values can.
>>>>
>>> In other words you are saying that Turing machines do not
>>> typically understand English.
>>
>> I didn't mean it that generally, only about deciders, but yes, typical
>> Turing machines do not understand any English. More specifically, the
>> specification of a halt decider (or any typical decider) prevents it
>> from being asked in any language.
>>
>
> // The question: Is x > y ?
> bool GreaterThan(int x, int y) { return (x > y); }
>
> Deciders are always asked a yes/no question of their
> inputs in their own native language.
>
>>> None-the-less no-one here understands that every halt decider
>>> is only required to report on the behavior that its actual
>>> input actually maps to.
>>
>> As far as I have seen, most of them do. And not just maps but maps
>> in the way specified by the problem statement.
>>
> _DDD()
> [00002172] 55 push ebp ; housekeeping
> [00002173] 8bec mov ebp,esp ; housekeeping
> [00002175] 6872210000 push 00002172 ; push DDD
> [0000217a] e853f4ffff call 000015d2 ; call H0(DDD)
> [0000217f] 83c404 add esp,+04
> [00002182] 5d pop ebp
> [00002183] c3 ret
> Size in bytes:(0018) [00002183]
>
> The call from DDD to H0(DDD) when N steps of DDD are correctly
> emulated by any pure function x86 emulator H0 cannot possibly return.
So?
>
> The behavior of the directly executed DDD() is irrelevant
> because that is not the behavior of the input. Deciders
> compute the mapping from their actual finite string input
> to an output by a sequence of finite string transformations.
No, the "behavior" of the input is what the question being asked defines
it to be.
>
> In this case the sequence is the line-by-line execution
> trace of the behavior of DDD correctly emulated by H0.
Which, is not a proper definition of the behavior of the input, as it
depends on more tham just the input, but on the machine the input is
given to.
Properties of the input for a decider need to be OBJECTIVE properties of
the input, and not SUBJECTIVE properties, as the mapping is defined to
be a mapping of JUST THE INPUT, and thus, doesn't include the decider it
is given to.
>
> The behavior of this input must include and cannot ignore
> the recursive emulation specified by the fact that DDD is
> calling its own emulator. That people think they can just
> pretend that this is not happening is ridiculous.
Right, and since your decider RESOLVES that recursion by aborting and
return, THAT BEHAIVIOR is part of the behavior of the input, since to
perform your definition of the input, you needed to include the decider
it was paired to in the input, that fixes the behavor to what that
decider did.
>
>>> Instead everyone here expects that the halt decider must map
>>> to the English description of what the authors of textbooks
>>> expect it to map to.
>>
>> Your "everyone" is a lie. As far as I have seen, nobody has expressed
>> that expectation, and several have said otherwise.
>>
> Everyone that states an opinion says that the decider
> must go by the textbook definitions of the problem thus
> not the problem instance actually encoded by the input.
It must go by THE DEFINITION OF THE PROBLEM, if that is from a textbook,
then yes, the textbook is authorative, and to say otherwise is just a LIE.
The input doesn't encode the problem statement, so can't disagree with it.
>
>>> We already agreed that Turing machines do not typically
>>> understand English, so this assumption is stupid.
>>
>> You may have agreed but you failed to keep that agreement.
>>
>>> *DDD correctly simulated by H0 DOES NOT HALT*
>>
>> The message where DDD was introduced specifies that DDD halts
>> if and only if H0 halts.
>>
> That is simply ignorance of the details of software engineering.
Nope, that is just facts. YOU do not seem to have basic knowledge of
software engineering.
>
>>> Everyone here stupidly ignores that the pathological
>>> relationship that DDD calls H0(DDD) changes the behavior
>>> of DDD.
>>
>> If and only if it changes the behaviour of H0, which is possible if
>> and only if H0 is not a pure function.
>>
> The directly executed H0 always uses this criteria and returns a
> correct halt status for every input in its domain.
And, if H0 is the defined pure function, then so will any correcgtly
simulated copy of it, and do exactly the same thing.
>
> <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
> If simulating halt decider H correctly simulates its input D
> until H correctly determines that its simulated D would never
> stop running unless aborted then
>
> H can abort its simulation of D and correctly report that D
> specifies a non-halting sequence of configurations.
> </MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>
>
Nope, since no H0 actually does a "Correct Simulation" or a "Correct
Determination of a Correct Simultion" (by anything) since the only
defintion he uses of a "Correct Simulation" is a simulation that EXACTLY
reproduces the results of directly executed machine the input
represents, which means it will never abort its simulation.
Thus, H0 can NEVER correctly avail itself of the second clause.
[toc] | [prev] | [next] | [standalone]
| From | Mikko <mikko.levanto@iki.fi> |
|---|---|
| Date | 2024-06-29 11:10 +0300 |
| Subject | Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met |
| Message-ID | <v5ofhm$3r7v4$1@dont-email.me> |
| In reply to | #107956 |
On 2024-06-28 12:40:57 +0000, olcott said:
> On 6/28/2024 3:30 AM, Mikko wrote:
>> On 2024-06-27 16:56:56 +0000, olcott said:
>>
>>> On 6/27/2024 10:35 AM, Mikko wrote:
>>>> On 2024-06-27 14:10:02 +0000, olcott said:
>>>>>
>>>>> In computability theory and computational complexity theory, a
>>>>> decision problem is a computational problem that can be posed as
>>>>> a yes–no question of the input values.
>>>>> https://en.wikipedia.org/wiki/Decision_problem
>>>>
>>>> That's right. But that question cannot be presented to the decider.
>>>> Only the input values can.
>>>>
>>> In other words you are saying that Turing machines do not
>>> typically understand English.
>>
>> I didn't mean it that generally, only about deciders, but yes, typical
>> Turing machines do not understand any English. More specifically, the
>> specification of a halt decider (or any typical decider) prevents it
>> from being asked in any language.
>>
>
> // The question: Is x > y ?
> bool GreaterThan(int x, int y) { return (x > y); }
>
> Deciders are always asked a yes/no question of their
> inputs in their own native language.
A call of GreaterThan must give two integers as arguments. There
is no place where a question could be put. An integer is not a
question.
--
Mikko
[toc] | [prev] | [next] | [standalone]
| From | Mike Terry <news.dead.person.stones@darjeeling.plus.com> |
|---|---|
| Date | 2024-06-25 16:41 +0100 |
| Subject | Re: DDD correctly emulated by H0 |
| Message-ID | <5F-dnWs4IamzeOf7nZ2dnZfqnPidnZ2d@brightview.co.uk> |
| In reply to | #107791 |
On 25/06/2024 14:46, Alan Mackenzie wrote: > [ Followup-To: set ] > > In comp.theory olcott <polcott333@gmail.com> wrote: >> On 6/25/2024 4:22 AM, joes wrote: >>> Am Sat, 22 Jun 2024 13:47:24 -0500 schrieb olcott: >>>> On 6/22/2024 1:39 PM, Fred. Zwarts wrote: >>>>> Op 21.jun.2024 om 15:21 schreef olcott: > >>>> When we stipulate that the only measure of a correct emulation is the >>>> semantics of the x86 programming language then we see that when DDD is >>>> correctly emulated by H0 that its call to H0(DDD) cannot possibly >>>> return. >>> Yes. Which is wrong, because H0 should terminate. > > [ .... ] > >> The call from DDD to H0(DDD) when DDD is correctly emulated >> by H0 cannot possibly return. > >> Until you acknowledge this is true, this is the >> only thing that I am willing to talk to you about. > > I think you are talking at cross purposes. Joes's point is that H0 > should terminate because it's a decider. You're saying that when H0 is > "correctly" emulating, it won't terminate. I don't recall seeing anybody > arguing against that. Hehe, everyone has an opinion on what PO is saying! :) So here's mine: I think PO is saying that when DDD is correctly *emulated* [not "correctly /emulating/"] then "it" will not return. To be clear, that's saying that the /emulation/ does not get as far as the final return, i.e. outer H0 will stop emulating (aka "abort") without having emulated DDD's return statement. PO has acknowledged that the outer H0 will return after aborting its emulation. So what? I hear everyone asking. So what indeed! The "behaviour" of a partial emulation is not the behaviour of the computation itself [trivially] and not what the HP is about. But PO then gets hopelessly muddled, thinking at least two wrong things: 1) That DDD would /never/ have terminated in "1-oo steps of emulation", i.e. that DDD really doesn't halt, not simply that H0 aborted it before it returned. (Thats muddling all the different examples of H in his head each with their own personalised (D,D) inputs into one single super-H/super-D. Of course, the FIXED DDD under discussion /does/ in fact return in some finite number of steps. H0 is also fixed and is coded in a way that aborts /before/ that number of steps is emulated.) 2) PO knows that the /reason/ H0 decided to abort was that it matched his "infinite recursive emulation" pattern in the emulation trace - therefore he believes it's correct to decide non-halting because his pattern proves that. (That's just Wrong, but PO really really really believes the pattern is sound, so that's the end of it. He has no intention or capability of ever attempting to prove his rule is sound.) Mike.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-25 10:56 -0500 |
| Subject | Re: DDD correctly emulated by H0 |
| Message-ID | <v5epbl$1k7as$1@dont-email.me> |
| In reply to | #107799 |
On 6/25/2024 10:41 AM, Mike Terry wrote: > On 25/06/2024 14:46, Alan Mackenzie wrote: >> [ Followup-To: set ] >> >> In comp.theory olcott <polcott333@gmail.com> wrote: >>> On 6/25/2024 4:22 AM, joes wrote: >>>> Am Sat, 22 Jun 2024 13:47:24 -0500 schrieb olcott: >>>>> On 6/22/2024 1:39 PM, Fred. Zwarts wrote: >>>>>> Op 21.jun.2024 om 15:21 schreef olcott: >> >>>>> When we stipulate that the only measure of a correct emulation is the >>>>> semantics of the x86 programming language then we see that when DDD is >>>>> correctly emulated by H0 that its call to H0(DDD) cannot possibly >>>>> return. >>>> Yes. Which is wrong, because H0 should terminate. >> >> [ .... ] >> >>> The call from DDD to H0(DDD) when DDD is correctly emulated >>> by H0 cannot possibly return. >> >>> Until you acknowledge this is true, this is the >>> only thing that I am willing to talk to you about. >> >> I think you are talking at cross purposes. Joes's point is that H0 >> should terminate because it's a decider. You're saying that when H0 is >> "correctly" emulating, it won't terminate. I don't recall seeing anybody >> arguing against that. > > Hehe, everyone has an opinion on what PO is saying! :) > > So here's mine: I think PO is saying that when DDD is correctly > *emulated* [not "correctly /emulating/"] then "it" will not return. > > To be clear, that's saying that the /emulation/ does not get as far as > the final return, i.e. outer H0 will stop emulating (aka "abort") > without having emulated DDD's return statement. PO has acknowledged > that the outer H0 will return after aborting its emulation. > > So what? I hear everyone asking. So what indeed! The "behaviour" of a > partial emulation is not the behaviour of the computation itself > [trivially] and not what the HP is about. But PO then gets hopelessly > muddled, thinking at least two wrong things: > _DDD() [00002172] 55 push ebp ; housekeeping [00002173] 8bec mov ebp,esp ; housekeeping [00002175] 6872210000 push 00002172 ; push DDD [0000217a] e853f4ffff call 000015d2 ; call H0(DDD) [0000217f] 83c404 add esp,+04 [00002182] 5d pop ebp [00002183] c3 ret Size in bytes:(0018) [00002183] The call from DDD to H0(DDD) (when DDD is correctly emulated by any H0 that can possibly exist at machine address 0000217a) H0 cannot possibly return. *In other words you insist on flatly disagreeing with the* *semantics of the x86 programming language* Not very smart of you. > 1) That DDD would /never/ have terminated in "1-oo steps of emulation", > i.e. that DDD really doesn't halt, not simply that H0 aborted it before > it returned. (Thats muddling all the different examples of H in his > head each with their own personalised (D,D) inputs into one single > super-H/super-D. Of course, the FIXED DDD under discussion /does/ in > fact return in some finite number of steps. H0 is also fixed and is > coded in a way that aborts /before/ that number of steps is emulated.) > Strawman deception. DDD correctly simulated by any H0 that can possibly exist at machine address 0000217a is not the same as DDD correctly simulated by any H1 that DDD never calls. The strawman deception is a kind of lie. Why lie? > 2) PO knows that the /reason/ H0 decided to abort was that it matched > his "infinite recursive emulation" pattern in the emulation trace - > therefore he believes it's correct to decide non-halting because his > pattern proves that. (That's just Wrong, but PO really really really > believes the pattern is sound, so that's the end of it. He has no > intention or capability of ever attempting to prove his rule is sound.) > > > Mike. > -- 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 | <v4ijlc$kqh$1@i2pn2.org> |
| In reply to | #107111 |
On 6/14/24 9:15 AM, olcott wrote: > 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). OF course it is. The nature of the input doesn't affet the form of the question that H is supposed to answer. > > If I ask you: What time is it? > and my actual unstated question is: > What is the outside temperature where you are? Which just makes you the LIAR that you already showed you are. H as ONE and ONLY one question it is supposed to answer, if it is a Halt decider, and that is "Does the Machine represented by your input halt when run?" Anything else is just a lie, > > Can a correct answer to the stated question be > a correct answer to the unstated question? But asking the quesiton you don't mean, OR answering the question you weren't asked are just forms of lies. Of course, a liar like you should understand that, or is the pathology making it so you can't understand that nature? > > H(D,D) is not even being asked about the behavior of D(D) > I guses you are just admitting that you have been lying about what H is supposed to be for all thewse years. IF it WAS a halt decider, that iis EXACTLY what it is being asked about. >>> >>> 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. But it programer is supposed to. I guess you are admitting at being a failure as a programmer. > > The only definition that H sees is the combination of > its algorithm with the finite string of machine language > of its input. Which means the prograamer didn't do his job. > > 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). > Which is what makes it impossible to build a decider that snwers the question. Which is perfectly fine, as the big question is was it possible to do so. > 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). No, you are just lying agsin. Thers *IS* a mapping for the finite string input to H and the answer, it is based on the behavior of the UTM processing of the input. If it halts, then the mapping of that string is to Yes, if it doesn't then the mapping of that string is to No > >>> >>> 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. So? Admitted not perfect isn't perfect, but I guess it is better than lying you do that your incorrect answer is correct. At least it seems it never gives a wrong answer, just sometimes says it can't answer. > >>> >>>> 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. But of course we can ask H the question. if it is a Halt Decider, then just giving it the input asks it the quesion. I don't think you understand how programs work. > >> 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). > Sure it can. just call H(D,D). That asks it the question if H is a Halt decider. >>> >>>> 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. Nope. Bot for a LIAR like you, it may not be understandable. > >> 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. But there is. If H(D,D) returns 0, then the mapping of (D,D) is to yes. If H(D,D) returns 1, then the mapping of (D,D) is to no. H, being a fixed deterministic program, will do one of the two, or just fail to be the decider it needs to be. You don't seem to understand that fact, H doesm't get to "choose" its answer, its answer to EVERY input you can give it was fixed when H was programmed. > >> 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. But the question is the correct question, you just don't seem to understand how programs work. > >> You, like normal, don't understand your requirements and capabilities. >> >
[toc] | [prev] | [next] | [standalone]
Page 11 of 19 — ← Prev page 1 … 9 10 [11] 12 13 … 19 Next page →
Back to top | Article view | comp.theory
csiph-web