Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.theory > #117472 > unrolled thread
| Started by | olcott <polcott333@gmail.com> |
|---|---|
| First post | 2025-05-04 21:23 -0500 |
| Last post | 2025-05-06 22:07 -0400 |
| Articles | 20 on this page of 628 — 16 participants |
Back to article view | Back to comp.theory
Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-04 21:23 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Mikko <mikko.levanto@iki.fi> - 2025-05-05 10:01 +0300
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Alan Mackenzie <acm@muc.de> - 2025-05-05 10:47 +0000
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-05 10:33 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Alan Mackenzie <acm@muc.de> - 2025-05-05 16:05 +0000
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-05 12:30 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Alan Mackenzie <acm@muc.de> - 2025-05-05 18:19 +0000
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-05 13:44 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Alan Mackenzie <acm@muc.de> - 2025-05-05 18:52 +0000
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-05 14:22 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Alan Mackenzie <acm@muc.de> - 2025-05-05 19:34 +0000
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-05 14:52 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Alan Mackenzie <acm@muc.de> - 2025-05-05 20:12 +0000
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-05 16:03 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Alan Mackenzie <acm@muc.de> - 2025-05-06 08:30 +0000
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-06 09:43 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Richard Damon <richard@damon-family.org> - 2025-05-06 21:57 -0400
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable joes <noreply@example.org> - 2025-05-06 10:04 +0000
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-06 12:14 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Richard Damon <richard@damon-family.org> - 2025-05-06 22:01 -0400
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Mikko <mikko.levanto@iki.fi> - 2025-05-07 10:52 +0300
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Richard Damon <richard@damon-family.org> - 2025-05-05 07:04 -0400
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Mr Flibble <flibble@red-dwarf.jmc.corp> - 2025-05-05 14:46 +0000
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Richard Heathfield <rjh@cpax.org.uk> - 2025-05-05 16:51 +0100
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Mr Flibble <flibble@red-dwarf.jmc.corp> - 2025-05-05 16:10 +0000
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Richard Heathfield <rjh@cpax.org.uk> - 2025-05-05 17:59 +0100
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Richard Damon <richard@damon-family.org> - 2025-05-05 21:08 -0400
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-05 10:31 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Richard Damon <richard@damon-family.org> - 2025-05-05 21:11 -0400
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-05 21:26 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Richard Damon <richard@damon-family.org> - 2025-05-06 07:16 -0400
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-05 23:27 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Alan Mackenzie <acm@muc.de> - 2025-05-06 08:17 +0000
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-06 09:36 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Alan Mackenzie <acm@muc.de> - 2025-05-06 15:38 +0000
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Richard Heathfield <rjh@cpax.org.uk> - 2025-05-06 17:16 +0100
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Ben Bacarisse <ben@bsb.me.uk> - 2025-05-07 17:01 +0100
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Richard Heathfield <rjh@cpax.org.uk> - 2025-05-07 17:22 +0100
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Mr Flibble <flibble@red-dwarf.jmc.corp> - 2025-05-07 17:11 +0000
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Richard Heathfield <rjh@cpax.org.uk> - 2025-05-07 18:51 +0100
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Richard Heathfield <rjh@cpax.org.uk> - 2025-05-07 18:59 +0100
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Ben Bacarisse <ben@bsb.me.uk> - 2025-05-09 01:58 +0100
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Richard Heathfield <rjh@cpax.org.uk> - 2025-05-09 05:43 +0100
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-07 12:55 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Richard Heathfield <rjh@cpax.org.uk> - 2025-05-07 19:14 +0100
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Mr Flibble <flibble@red-dwarf.jmc.corp> - 2025-05-07 18:17 +0000
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Richard Heathfield <rjh@cpax.org.uk> - 2025-05-07 19:32 +0100
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Mr Flibble <flibble@red-dwarf.jmc.corp> - 2025-05-07 19:11 +0000
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Richard Heathfield <rjh@cpax.org.uk> - 2025-05-07 22:23 +0100
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-07 13:31 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable dbush <dbush.mobile@gmail.com> - 2025-05-07 14:32 -0400
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Richard Heathfield <rjh@cpax.org.uk> - 2025-05-07 19:59 +0100
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-07 14:35 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Richard Heathfield <rjh@cpax.org.uk> - 2025-05-07 22:30 +0100
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-07 16:46 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable dbush <dbush.mobile@gmail.com> - 2025-05-07 17:47 -0400
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-07 16:56 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable dbush <dbush.mobile@gmail.com> - 2025-05-07 18:05 -0400
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-07 18:05 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable dbush <dbush.mobile@gmail.com> - 2025-05-07 19:10 -0400
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-07 18:16 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable dbush <dbush.mobile@gmail.com> - 2025-05-07 19:18 -0400
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-07 18:26 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable dbush <dbush.mobile@gmail.com> - 2025-05-07 19:31 -0400
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-07 18:39 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable dbush <dbush.mobile@gmail.com> - 2025-05-07 20:14 -0400
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-07 18:40 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable dbush <dbush.mobile@gmail.com> - 2025-05-07 20:15 -0400
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-07 19:19 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable dbush <dbush.mobile@gmail.com> - 2025-05-07 20:44 -0400
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-07 20:20 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable dbush <dbush.mobile@gmail.com> - 2025-05-07 21:30 -0400
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-07 20:48 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable dbush <dbush.mobile@gmail.com> - 2025-05-07 21:59 -0400
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Richard Heathfield <rjh@cpax.org.uk> - 2025-05-08 05:09 +0100
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-08 00:22 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Richard Heathfield <rjh@cpax.org.uk> - 2025-05-08 06:33 +0100
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2025-05-08 17:14 +0100
Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-08 12:00 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-08 21:04 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-08 14:42 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-08 21:01 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Mr Flibble <flibble@red-dwarf.jmc.corp> - 2025-05-08 21:35 +0000
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-08 23:12 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-08 15:26 -0700
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-08 15:31 -0700
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-08 17:47 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-08 16:45 -0700
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-08 18:53 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-08 17:00 -0700
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-08 19:14 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-08 21:07 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-08 20:33 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-08 22:11 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-08 18:54 -0700
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-09 05:50 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 00:01 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-09 06:23 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 06:52 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-09 10:41 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 10:39 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 12:50 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-10 09:39 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-08 21:02 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-08 19:23 -0700
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-08 21:28 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-08 21:18 -0700
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <news.x.richarddamon@xoxy.net> - 2025-05-08 23:01 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-08 21:22 -0700
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-08 23:56 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 07:00 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 06:59 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 10:16 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 12:52 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 09:52 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 12:57 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-10 09:59 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-09 10:47 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 10:48 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 13:00 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 14:46 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-09 21:07 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 15:15 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 17:35 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-09 22:40 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 17:18 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-09 18:31 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 19:34 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-10 01:26 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-09 20:14 -0700
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-09 19:40 -0700
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) wij <wyniijj5@gmail.com> - 2025-05-10 11:13 +0800
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 22:24 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) wij <wyniijj5@gmail.com> - 2025-05-10 11:43 +0800
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 23:18 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) wij <wyniijj5@gmail.com> - 2025-05-10 12:32 +0800
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 23:44 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) wij <wyniijj5@gmail.com> - 2025-05-10 12:51 +0800
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-10 00:06 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) wij <wyniijj5@gmail.com> - 2025-05-10 13:13 +0800
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-10 00:19 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) wij <wyniijj5@gmail.com> - 2025-05-10 13:27 +0800
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-10 00:41 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) wij <wyniijj5@gmail.com> - 2025-05-10 14:00 +0800
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-10 01:06 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) wij <wyniijj5@gmail.com> - 2025-05-10 14:19 +0800
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-10 09:51 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-10 11:01 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-10 17:14 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) wij <wyniijj5@gmail.com> - 2025-05-10 23:14 +0800
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-10 10:43 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) wij <wyniijj5@gmail.com> - 2025-05-11 00:00 +0800
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-10 11:15 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-10 12:18 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) wij <wyniijj5@gmail.com> - 2025-05-11 00:21 +0800
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-10 11:44 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-10 12:55 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-10 17:34 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-10 18:05 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-10 17:07 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-10 10:30 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-10 08:39 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-10 08:37 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-10 08:36 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-10 15:16 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-10 08:54 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-10 08:53 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 23:53 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 23:13 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-10 00:18 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-10 10:25 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-10 08:59 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-10 10:22 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 23:31 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 23:21 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-10 10:34 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-10 09:42 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-10 09:09 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 22:13 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 23:45 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-10 10:18 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-10 11:24 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 17:34 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-10 10:05 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-10 11:18 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <news.x.richarddamon@xoxy.net> - 2025-05-09 13:59 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2025-05-10 01:23 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 19:48 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 22:20 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 21:41 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-10 03:59 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 23:06 -0400
Repetitive posting [ Was: Incorrect requirements --- Computing the mapping from the input to HHH(DD)] Alan Mackenzie <acm@muc.de> - 2025-05-10 10:21 +0000
Re: Repetitive posting [ Was: Incorrect requirements --- Computing the mapping from the input to HHH(DD)] olcott <polcott333@gmail.com> - 2025-05-10 09:30 -0500
Re: Repetitive posting [ Was: Incorrect requirements --- Computing the mapping from the input to HHH(DD)] dbush <dbush.mobile@gmail.com> - 2025-05-10 10:57 -0400
Re: Repetitive posting [ Was: Incorrect requirements --- Computing the mapping from the input to HHH(DD)] "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-10 16:57 +0200
Re: Repetitive posting [ Was: Incorrect requirements --- Computing the mapping from the input to HHH(DD)] Richard Damon <richard@damon-family.org> - 2025-05-10 15:21 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-10 10:38 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-09 20:12 -0700
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 22:17 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 23:29 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 23:27 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-10 10:44 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-10 09:15 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-10 15:23 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-10 10:42 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-09 05:35 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-08 22:18 -0700
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-09 06:41 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-09 10:39 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 10:33 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) joes <noreply@example.org> - 2025-05-09 15:42 +0000
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 10:53 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 14:06 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 13:58 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-10 10:46 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 10:41 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 14:08 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-08 17:50 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-09 00:30 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-08 18:41 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-09 00:46 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-08 16:54 -0700
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-08 19:05 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-08 21:13 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-08 20:35 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-08 19:14 -0700
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-09 06:10 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-08 22:37 -0700
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-08 22:13 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-09 11:03 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 11:02 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 14:09 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-10 10:49 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-08 19:02 -0700
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-08 21:22 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-08 22:30 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Bonita Montero <Bonita.Montero@gmail.com> - 2025-05-10 14:37 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-10 09:33 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-10 16:54 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) wij <wyniijj5@gmail.com> - 2025-05-10 23:28 +0800
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-10 10:45 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) wij <wyniijj5@gmail.com> - 2025-05-11 00:06 +0800
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-10 11:19 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-10 12:21 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) wij <wyniijj5@gmail.com> - 2025-05-11 00:29 +0800
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-10 11:47 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) wij <wyniijj5@gmail.com> - 2025-05-11 01:01 +0800
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-10 12:17 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-10 13:19 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) wij <wyniijj5@gmail.com> - 2025-05-11 02:09 +0800
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-10 13:17 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-10 14:24 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) wij <wyniijj5@gmail.com> - 2025-05-11 02:37 +0800
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-10 13:47 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) wij <wyniijj5@gmail.com> - 2025-05-11 03:02 +0800
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-10 14:29 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) wij <wyniijj5@gmail.com> - 2025-05-11 05:44 +0800
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-10 17:03 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-10 18:39 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Mr Flibble <flibble@red-dwarf.jmc.corp> - 2025-05-10 22:55 +0000
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-10 19:03 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Mr Flibble <flibble@red-dwarf.jmc.corp> - 2025-05-10 23:35 +0000
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-10 18:57 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) wij <wyniijj5@gmail.com> - 2025-05-11 09:17 +0800
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-10 20:26 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-11 02:43 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) wij <wyniijj5@gmail.com> - 2025-05-11 09:44 +0800
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-10 20:56 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) wij <wyniijj5@gmail.com> - 2025-05-11 10:09 +0800
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-10 21:19 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-11 07:03 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) wij <wyniijj5@gmail.com> - 2025-05-11 22:34 +0800
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-11 10:38 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) wij <wyniijj5@gmail.com> - 2025-05-12 00:28 +0800
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-11 12:00 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) wij <wyniijj5@gmail.com> - 2025-05-12 01:21 +0800
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-11 12:40 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-11 13:44 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) wij <wyniijj5@gmail.com> - 2025-05-12 02:38 +0800
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-11 15:19 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-11 16:21 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) wij <wyniijj5@gmail.com> - 2025-05-12 04:23 +0800
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-11 15:50 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-11 15:53 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-11 17:01 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) wij <wyniijj5@gmail.com> - 2025-05-12 05:48 +0800
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-11 17:00 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-11 17:05 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) wij <wyniijj5@gmail.com> - 2025-05-12 06:11 +0800
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-11 17:30 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) wij <wyniijj5@gmail.com> - 2025-05-12 06:50 +0800
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-11 18:08 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) wij <wyniijj5@gmail.com> - 2025-05-12 08:33 +0800
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-11 19:51 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-11 21:15 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-11 20:51 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-11 21:56 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-12 22:30 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) joes <noreply@example.org> - 2025-05-16 15:38 +0000
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-16 10:50 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-16 12:04 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Mikko <mikko.levanto@iki.fi> - 2025-05-17 11:09 +0300
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-11 19:59 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) --- DOS detector olcott <polcott333@gmail.com> - 2025-05-11 19:57 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) --- DOS detector dbush <dbush.mobile@gmail.com> - 2025-05-11 21:01 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) --- DOS detector joes <noreply@example.org> - 2025-05-12 09:22 +0000
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) --- DOS detector olcott <polcott333@gmail.com> - 2025-05-12 10:58 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-11 19:34 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-11 17:06 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Mikko <mikko.levanto@iki.fi> - 2025-05-12 11:03 +0300
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-12 10:04 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-12 11:06 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-12 11:19 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-12 12:41 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-12 11:54 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-12 13:07 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-12 12:16 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-12 13:30 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-12 12:58 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-12 14:19 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-13 13:23 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Mikko <mikko.levanto@iki.fi> - 2025-05-13 13:19 +0300
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) joes <noreply@example.org> - 2025-05-12 21:29 +0000
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <Richard@Damon-Family.org> - 2025-05-12 23:10 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-11 16:25 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Ben Bacarisse <ben@bsb.me.uk> - 2025-05-12 17:46 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-12 12:23 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-12 22:38 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <Richard@Damon-Family.org> - 2025-05-12 23:11 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-10 22:12 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-10 21:54 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) joes <noreply@example.org> - 2025-05-11 11:07 +0000
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-11 11:37 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-11 16:36 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-11 16:13 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-11 19:36 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-13 13:20 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-10 18:52 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-10 15:32 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-10 15:25 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Alan Mackenzie <acm@muc.de> - 2025-05-10 18:48 +0000
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-10 13:56 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-10 15:03 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-10 15:33 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Mr Flibble <flibble@red-dwarf.jmc.corp> - 2025-05-10 18:58 +0000
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Alan Mackenzie <acm@muc.de> - 2025-05-10 20:07 +0000
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Mr Flibble <flibble@red-dwarf.jmc.corp> - 2025-05-10 20:17 +0000
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-10 15:29 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-10 18:58 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Alan Mackenzie <acm@muc.de> - 2025-05-11 10:34 +0000
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Mr Flibble <flibble@red-dwarf.jmc.corp> - 2025-05-11 11:48 +0000
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-11 12:57 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Mr Flibble <flibble@red-dwarf.jmc.corp> - 2025-05-11 12:09 +0000
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-11 13:12 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Mr Flibble <flibble@red-dwarf.jmc.corp> - 2025-05-11 12:17 +0000
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-11 13:36 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Mr Flibble <flibble@red-dwarf.jmc.corp> - 2025-05-11 12:41 +0000
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-11 14:58 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-11 10:44 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-11 16:49 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-11 16:50 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-11 10:14 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-11 16:27 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-10 15:26 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Alan Mackenzie <acm@muc.de> - 2025-05-10 20:45 +0000
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-10 15:58 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-10 17:01 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-10 19:23 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-10 19:04 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-10 21:27 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Alan Mackenzie <acm@muc.de> - 2025-05-10 20:22 +0000
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-10 15:42 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-10 16:50 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-10 19:27 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) joes <noreply@example.org> - 2025-05-11 11:13 +0000
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-11 11:44 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-11 12:52 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-11 12:35 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-11 13:43 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-13 13:10 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-11 18:11 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2025-05-12 01:38 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-11 19:48 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-11 20:58 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-11 20:05 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-11 21:07 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-11 21:40 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-11 21:11 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-12 22:39 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-11 21:27 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-11 20:56 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-11 21:59 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-11 21:14 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-11 22:28 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-11 21:36 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-11 22:38 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-11 21:46 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-11 22:49 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-11 21:56 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-11 22:57 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-11 22:00 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-11 23:03 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-11 22:36 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-11 23:39 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-11 22:50 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-11 23:54 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-11 23:11 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-12 07:46 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-12 11:32 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-12 12:45 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) joes <noreply@example.org> - 2025-05-12 21:27 +0000
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-13 13:01 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-13 13:05 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-12 22:44 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-12 22:42 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-12 02:25 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Ben Bacarisse <ben@bsb.me.uk> - 2025-05-12 18:03 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Ben Bacarisse <ben@bsb.me.uk> - 2025-05-12 18:05 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-12 19:13 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Ben Bacarisse <ben@bsb.me.uk> - 2025-05-13 01:18 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-13 03:38 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-12 19:06 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2025-05-13 03:17 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-12 21:32 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-12 22:59 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-13 12:58 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-13 03:41 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) joes <noreply@example.org> - 2025-05-13 09:01 +0000
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2025-05-13 18:46 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-13 16:04 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-13 18:45 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-13 20:58 -0400
How the requirements that Professor Sipser agreed to are exactly met olcott <polcott333@gmail.com> - 2025-05-13 20:07 -0500
Re: How the requirements that Professor Sipser agreed to are exactly met dbush <dbush.mobile@gmail.com> - 2025-05-13 21:19 -0400
Re: How the requirements that Professor Sipser agreed to are exactly met olcott <polcott333@gmail.com> - 2025-05-13 20:40 -0500
Re: How the requirements that Professor Sipser agreed to are exactly met dbush <dbush.mobile@gmail.com> - 2025-05-13 21:45 -0400
Re: How the requirements that Professor Sipser agreed to are exactly met olcott <polcott333@gmail.com> - 2025-05-13 20:55 -0500
Re: How the requirements that Professor Sipser agreed to are exactly met dbush <dbush.mobile@gmail.com> - 2025-05-13 21:58 -0400
Re: How the requirements that Professor Sipser agreed to are exactly met olcott <polcott333@gmail.com> - 2025-05-13 21:43 -0500
Re: How the requirements that Professor Sipser agreed to are exactly met dbush <dbush.mobile@gmail.com> - 2025-05-13 22:44 -0400
Re: How the requirements that Professor Sipser agreed to are exactly met olcott <polcott333@gmail.com> - 2025-05-13 22:18 -0500
Re: How the requirements that Professor Sipser agreed to are exactly met dbush <dbush.mobile@gmail.com> - 2025-05-13 23:35 -0400
Re: How the requirements that Professor Sipser agreed to are exactly met joes <noreply@example.org> - 2025-05-14 08:17 +0000
Re: How the requirements that Professor Sipser agreed to are exactly met olcott <polcott333@gmail.com> - 2025-05-14 10:06 -0500
Re: How the requirements that Professor Sipser agreed to are exactly met joes <noreply@example.org> - 2025-05-14 18:37 +0000
Re: How the requirements that Professor Sipser agreed to are exactly met olcott <polcott333@gmail.com> - 2025-05-14 13:42 -0500
Re: How the requirements that Professor Sipser agreed to are exactly met Richard Heathfield <rjh@cpax.org.uk> - 2025-05-14 19:56 +0100
Re: How the requirements that Professor Sipser agreed to are exactly met olcott <polcott333@gmail.com> - 2025-05-14 14:02 -0500
Re: How the requirements that Professor Sipser agreed to are exactly met Richard Heathfield <rjh@cpax.org.uk> - 2025-05-14 20:17 +0100
Re: How the requirements that Professor Sipser agreed to are exactly met olcott <polcott333@gmail.com> - 2025-05-14 14:21 -0500
Re: How the requirements that Professor Sipser agreed to are exactly met Richard Heathfield <rjh@cpax.org.uk> - 2025-05-14 20:49 +0100
Re: How the requirements that Professor Sipser agreed to are exactly met olcott <polcott333@gmail.com> - 2025-05-14 15:00 -0500
Re: How the requirements that Professor Sipser agreed to are exactly met Richard Heathfield <rjh@cpax.org.uk> - 2025-05-14 21:18 +0100
Re: How the requirements that Professor Sipser agreed to are exactly met olcott <polcott333@gmail.com> - 2025-05-14 15:25 -0500
Re: How the requirements that Professor Sipser agreed to are exactly met Richard Heathfield <rjh@cpax.org.uk> - 2025-05-14 21:26 +0100
Re: How the requirements that Professor Sipser agreed to are exactly met joes <noreply@example.org> - 2025-05-14 20:28 +0000
Re: How the requirements that Professor Sipser agreed to are exactly met olcott <polcott333@gmail.com> - 2025-05-14 15:40 -0500
Re: How the requirements that Professor Sipser agreed to are exactly met Richard Heathfield <rjh@cpax.org.uk> - 2025-05-14 21:54 +0100
Re: How the requirements that Professor Sipser agreed to are exactly met Richard Heathfield <rjh@cpax.org.uk> - 2025-05-14 21:51 +0100
Re: How the requirements that Professor Sipser agreed to are exactly met Ben Bacarisse <ben@bsb.me.uk> - 2025-05-14 20:20 +0100
Re: How the requirements that Professor Sipser agreed to are exactly met olcott <polcott333@gmail.com> - 2025-05-14 14:46 -0500
Re: How the requirements that Professor Sipser agreed to are exactly met dbush <dbush.mobile@gmail.com> - 2025-05-14 17:18 -0400
Re: How the requirements that Professor Sipser agreed to are exactly met Richard Damon <richard@damon-family.org> - 2025-05-14 21:51 -0400
Re: How the requirements that Professor Sipser agreed to are exactly met Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2025-05-15 00:02 +0100
Re: How the requirements that Professor Sipser agreed to are exactly met olcott <polcott333@gmail.com> - 2025-05-14 18:17 -0500
Re: How the requirements that Professor Sipser agreed to are exactly met olcott <polcott333@gmail.com> - 2025-05-14 18:27 -0500
Re: How the requirements that Professor Sipser agreed to are exactly met Ben Bacarisse <ben@bsb.me.uk> - 2025-05-15 01:02 +0100
Re: How the requirements that Professor Sipser agreed to are exactly met olcott <polcott333@gmail.com> - 2025-05-14 19:09 -0500
Re: How the requirements that Professor Sipser agreed to are exactly met Richard Damon <richard@damon-family.org> - 2025-05-14 07:46 -0400
Re: How the requirements that Professor Sipser agreed to are exactly met olcott <polcott333@gmail.com> - 2025-05-14 10:23 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) joes <noreply@example.org> - 2025-05-11 19:54 +0000
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-11 17:02 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-11 16:15 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-11 19:39 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-11 19:29 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-11 21:31 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-11 21:03 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-11 22:05 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-12 22:49 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-13 12:46 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-13 12:48 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-13 13:16 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Alan Mackenzie <acm@muc.de> - 2025-05-11 12:26 +0000
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Mr Flibble <flibble@red-dwarf.jmc.corp> - 2025-05-11 12:34 +0000
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Alan Mackenzie <acm@muc.de> - 2025-05-11 14:38 +0000
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-11 10:26 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-11 16:38 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-11 11:58 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-10 15:25 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 09:45 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 14:13 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-09 11:00 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 10:59 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 14:15 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-10 10:52 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-08 16:49 -0700
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-08 18:59 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-08 21:15 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-08 20:41 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-08 22:18 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-08 18:30 -0700
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-08 21:13 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-08 22:35 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2025-05-09 04:14 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-08 22:34 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) joes <noreply@example.org> - 2025-05-09 09:48 +0000
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 10:08 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) joes <noreply@example.org> - 2025-05-09 15:47 +0000
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 10:57 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 14:22 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 07:12 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-08 21:11 -0700
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-08 23:49 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-08 22:31 -0700
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 00:49 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-08 23:17 -0700
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 10:03 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 14:24 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 07:21 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 07:18 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 07:15 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 18:02 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 19:36 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 18:43 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 20:37 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-10 15:28 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-10 01:29 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 20:38 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-10 01:48 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 19:54 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 22:25 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 21:43 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 23:08 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 19:51 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-10 02:15 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 20:29 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-10 02:32 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 20:50 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 20:48 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-10 03:15 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 21:20 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 22:39 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 21:47 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 23:12 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 23:46 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-10 11:03 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-10 14:57 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-10 09:17 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 23:10 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-10 14:59 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 22:34 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 20:50 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-10 03:19 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 21:27 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 23:17 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) --- DOUBLE DOG DARE YOU olcott <polcott333@gmail.com> - 2025-05-09 22:29 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) --- DOUBLE DOG DARE YOU Richard Damon <richard@damon-family.org> - 2025-05-09 23:50 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) --- DOUBLE DOG DARE YOU olcott <polcott333@gmail.com> - 2025-05-09 23:05 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) --- DOUBLE DOG DARE YOU Richard Damon <richard@damon-family.org> - 2025-05-10 09:20 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-10 14:55 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 22:32 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 22:30 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 21:45 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 23:22 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-09 11:14 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 11:04 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 14:25 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-08 16:41 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-08 23:13 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-08 17:20 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 07:25 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 10:55 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 14:29 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-09 10:33 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 10:29 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 14:32 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-10 09:37 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-08 19:35 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-08 18:48 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-08 21:18 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-08 20:55 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-08 22:26 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-09 11:28 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 11:13 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 14:33 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-09 11:25 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 11:11 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 14:34 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-10 09:53 +0200
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Richard Heathfield <rjh@cpax.org.uk> - 2025-05-08 18:45 +0100
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Richard Damon <richard@damon-family.org> - 2025-05-08 07:21 -0400
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-07 18:41 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Richard Heathfield <rjh@cpax.org.uk> - 2025-05-07 22:52 +0100
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-07 16:59 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Richard Heathfield <rjh@cpax.org.uk> - 2025-05-07 23:16 +0100
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Mr Flibble <flibble@red-dwarf.jmc.corp> - 2025-05-07 22:26 +0000
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Richard Heathfield <rjh@cpax.org.uk> - 2025-05-07 23:29 +0100
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-07 18:09 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Richard Heathfield <rjh@cpax.org.uk> - 2025-05-08 03:24 +0100
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-07 21:41 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Richard Heathfield <rjh@cpax.org.uk> - 2025-05-08 05:12 +0100
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-07 21:33 -0700
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-07 23:54 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Richard Heathfield <rjh@cpax.org.uk> - 2025-05-08 06:02 +0100
Re: faithful simulations [was: Formal systems that cannot possibly be incomplete except for unknowns and unknowable] joes <noreply@example.org> - 2025-05-08 11:07 +0000
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable dbush <dbush.mobile@gmail.com> - 2025-05-07 14:18 -0400
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-07 13:35 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable dbush <dbush.mobile@gmail.com> - 2025-05-07 14:38 -0400
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-07 15:03 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable dbush <dbush.mobile@gmail.com> - 2025-05-07 16:07 -0400
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-07 15:39 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable dbush <dbush.mobile@gmail.com> - 2025-05-07 16:53 -0400
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-07 15:58 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable dbush <dbush.mobile@gmail.com> - 2025-05-07 17:03 -0400
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-07 16:24 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable dbush <dbush.mobile@gmail.com> - 2025-05-07 17:29 -0400
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-07 13:03 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Mikko <mikko.levanto@iki.fi> - 2025-05-08 11:38 +0300
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-06 12:06 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Mikko <mikko.levanto@iki.fi> - 2025-05-07 11:02 +0300
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Richard Heathfield <rjh@cpax.org.uk> - 2025-05-07 09:19 +0100
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Richard Damon <richard@damon-family.org> - 2025-05-06 22:04 -0400
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Mikko <mikko.levanto@iki.fi> - 2025-05-07 10:57 +0300
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Richard Heathfield <rjh@cpax.org.uk> - 2025-05-07 09:05 +0100
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Richard Damon <richard@damon-family.org> - 2025-05-06 07:20 -0400
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable ---ELABORATED olcott <polcott333@gmail.com> - 2025-05-06 12:46 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable ---ELABORATED Richard Damon <richard@damon-family.org> - 2025-05-06 22:07 -0400
Page 31 of 32 — ← Prev page 1 … 29 30 [31] 32 Next page →
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-07 21:41 -0500 |
| Message-ID | <vvh5ka$1gjtf$1@dont-email.me> |
| In reply to | #117971 |
On 5/7/2025 9:24 PM, Richard Heathfield wrote: > On 08/05/2025 00:09, olcott wrote: >> On 5/7/2025 5:16 PM, Richard Heathfield wrote: >>> On 07/05/2025 22:59, olcott wrote: >>>> On 5/7/2025 4:52 PM, Richard Heathfield wrote: >>>>> On 07/05/2025 22:46, olcott wrote: >>>>>> On 5/7/2025 4:30 PM, Richard Heathfield wrote: >>>>> >>>>> <snip> >>>>> >>>>>>> If the simulation can't reach code that the directly executed >>>>>>> program reaches, then it's not a faithful simulation. >>>>>>> >>>>>> >>>>>> If is was true that it is not a faithful simulation >>>>>> then you would be able to show exactly what sequence >>>>>> of instructions would be a faithful simulation. >>>>> >>>>> If it were false, you'd be able to chop out the unreachable code >>>>> without any adverse effects. Can you? >>>>> >>>>> <snip> >>>>> >>>> >>>> I already know the answer. >>> >>> Then you already know why your simulation code fails to simulate >>> correctly... >> >> When I say correctly I mean according to the >> rules of the x86 language. > > No, when you say 'correctly' my best guess would be that you mean it > fits your expectations. > >> When you say "correctly" you mean break the rules >> of the x86 language to match a misconception. > > No, when I said 'fails to simulate correctly' I meant 'fails to simulate > the behaviour it was asked to simulate'. There is such a thing as incorrect questions. The logical law of polar questions When posed to a man whom has never been married, the question: Have you stopped beating your wife? Is an incorrect polar question because neither yes nor no is a correct answer. All polar questions (including incorrect polar questions) have exactly one answer from the following: 1) No 2) Yes 3) Neither // Only applies to incorrect polar questions https://groups.google.com/g/sci.lang/c/AO5Vlupeelo/m/nxJy7N2vULwJ > You have already acknowledged > that some of the code is reachable by the program when executed directly > but not by the simulator. That's self-evidently broken. > It you would bother to pay enough attention you would see the the sequences ARE NOT THE SAME. You are essentially asking sum(3,2) to return the sum of 5 + 7. Can you see how asking sum(3,2) to return the sum of 5 + 7 is incorrect according to the rules of arithmetic? -- 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 Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2025-05-08 05:12 +0100 |
| Message-ID | <vvhb05$1hp80$2@dont-email.me> |
| In reply to | #117972 |
On 08/05/2025 03:41, olcott wrote: > > There is such a thing as incorrect questions. There's also such a thing as incorrect code. I finally took a close look at Halt7.c. Oh deary deary me. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-05-07 21:33 -0700 |
| Message-ID | <87zffnen6f.fsf@nosuchdomain.example.com> |
| In reply to | #117972 |
olcott <polcott333@gmail.com> writes:
[...]
> You are essentially asking sum(3,2) to return the
> sum of 5 + 7. Can you see how asking sum(3,2)
> to return the sum of 5 + 7 is incorrect according
> to the rules of arithmetic?
"sum" is a valid C identifier. Nothing in the rules of C says
that naming a function "sum" is incorrect, regardless of what that
function does.
This:
int sum(int x, int y) { return 12; }
is a perfectly valid C function. You might get a non-fatal warning
that the parameter values aren't used, so you could try this equally
valid C function:
int sum(int x, int y) { return x + y + 7; }
Perhaps I have three functions named "cogito()", "ergo()", and
"sum()", and they perform some operations that make sense in the
context of the application of which they're a part.
Since there was no reference to the name "sum" in the article to
which you replied, it's difficult to tell what point you're trying
to make. Try making it more directly, without pretending that the
name "sum" has some meaning in the context of C.
When you make arguments based your understanding of C, you usually
get something wrong. It creates distractions and makes it difficult
to follow your reasoning.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-07 23:54 -0500 |
| Message-ID | <vvhddg$1hom3$4@dont-email.me> |
| In reply to | #118011 |
On 5/7/2025 11:33 PM, Keith Thompson wrote:
> olcott <polcott333@gmail.com> writes:
> [...]
>> You are essentially asking sum(3,2) to return the
>> sum of 5 + 7. Can you see how asking sum(3,2)
>> to return the sum of 5 + 7 is incorrect according
>> to the rules of arithmetic?
>
> "sum" is a valid C identifier. Nothing in the rules of C says
> that naming a function "sum" is incorrect, regardless of what that
> function does.
>
I explained it better the first fifty times I said it.
> This:
>
> int sum(int x, int y) { return 12; }
>
> is a perfectly valid C function. You might get a non-fatal warning
> that the parameter values aren't used, so you could try this equally
> valid C function:
>
> int sum(int x, int y) { return x + y + 7; }
>
> Perhaps I have three functions named "cogito()", "ergo()", and
> "sum()", and they perform some operations that make sense in the
> context of the application of which they're a part.
>
> Since there was no reference to the name "sum" in the article to
> which you replied, it's difficult to tell what point you're trying
> to make. Try making it more directly, without pretending that the
> name "sum" has some meaning in the context of C.
>
> When you make arguments based your understanding of C, you usually
> get something wrong. It creates distractions and makes it difficult
> to follow your reasoning.
>
--
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 Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2025-05-08 06:02 +0100 |
| Message-ID | <vvhdt9$1hvei$2@dont-email.me> |
| In reply to | #118014 |
On 08/05/2025 05:54, olcott wrote: > On 5/7/2025 11:33 PM, Keith Thompson wrote: >> olcott <polcott333@gmail.com> writes: >> [...] >>> You are essentially asking sum(3,2) to return the >>> sum of 5 + 7. Can you see how asking sum(3,2) >>> to return the sum of 5 + 7 is incorrect according >>> to the rules of arithmetic? >> >> "sum" is a valid C identifier. Nothing in the rules of C says >> that naming a function "sum" is incorrect, regardless of what that >> function does. >> > I explained it better the first fifty times I said it. No, you didn't. Clarity is not your long suit. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | joes <noreply@example.org> |
|---|---|
| Date | 2025-05-08 11:07 +0000 |
| Subject | Re: faithful simulations [was: Formal systems that cannot possibly be incomplete except for unknowns and unknowable] |
| Message-ID | <59e6acb910e06a3117c04694b5118d3768b870b8@i2pn2.org> |
| In reply to | #117937 |
Am Wed, 07 May 2025 16:46:00 -0500 schrieb olcott: > On 5/7/2025 4:30 PM, Richard Heathfield wrote: >> On 07/05/2025 20:35, olcott wrote: >>> On 5/7/2025 1:59 PM, Richard Heathfield wrote: >>>> On 07/05/2025 19:31, olcott wrote: >>>>> I already know that the contradictory part of the counter-example >>>>> input has always been unreachable code. >>>> >>>> If the code is unreachable, it can't be part of a working program, so >>>> simply remove it. >>> >>> It is unreachable by the Halting Problem counter-example input D when >>> correctly simulated by the simulating termination analyzer H that it >>> has been defined to thwart. >> >> If the simulation can't reach code that the directly executed program >> reaches, then it's not a faithful simulation. >> > If is was true that it is not a faithful simulation then you would be > able to show exactly what sequence of instructions would be a faithful > simulation. A faithful simulation would produce the same behaviour as direct execution, as HHH1 and UTM do. -- Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math: It is not guaranteed that n+1 exists for every n.
[toc] | [prev] | [next] | [standalone]
| From | dbush <dbush.mobile@gmail.com> |
|---|---|
| Date | 2025-05-07 14:18 -0400 |
| Message-ID | <vvg86b$15i5e$8@dont-email.me> |
| In reply to | #117882 |
On 5/7/2025 1:55 PM, olcott wrote: > On 5/6/2025 11:16 AM, Richard Heathfield wrote: >> On 06/05/2025 16:38, Alan Mackenzie wrote: >>> These aren't particularly difficult things to comprehend. As I keep >>> saying, you ought to show a lot more respect for people who are >>> mathematically educated. >> >> I concur. >> >> As someone who is not particularly mathematically educated (I have an >> A- level in the subject, but that's all), I tend to steer well clear >> of mathematical debates, although I have occasionally dipped a toe. >> >> I have *enormous* respect for those who know their tensors from their >> manifolds and their conjectures from their eigenvalues, even though >> it's all Greek to me. >> >> But to understand the Turing proof requires little if any mathematical >> knowledge. It requires only the capacity for clear thinking. >> >> Having been on the receiving end of lengthy Usenet diatribes by cranks >> in my own field, I don't hold out much hope for our current culprits >> developing either the capacity for clear thought or any measure of >> respect for expertise any time soon. >> >> Nor do I believe they are capable of understanding proof by >> contradiction, which is just about the easiest kind of proof there is. >> In fact, the most surprising aspect of this whole affair is that > > >> (according to Mike) Mr Olcott seems to have (correctly) spotted a >> minor flaw in the proof published by Dr Linz. How can he get that and >> not get contradiction? Proof by contradiction is /much/ easier. >> > > When THERE IS NO CONTRADICTION then proof by contradiction fails. False. The contradiction is that HHH is found to not map the below function after it is assumed that the below function is computable and that HHH computes it: Given any algorithm (i.e. a fixed immutable sequence of instructions) X described as <X> with input Y: A solution to the halting problem is an algorithm H that computes the following mapping: (<X>,Y) maps to 1 if and only if X(Y) halts when executed directly (<X>,Y) maps to 0 if and only if X(Y) does not halt when executed directly
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-07 13:35 -0500 |
| Message-ID | <vvg963$15e69$5@dont-email.me> |
| In reply to | #117894 |
On 5/7/2025 1:18 PM, dbush wrote: > On 5/7/2025 1:55 PM, olcott wrote: >> On 5/6/2025 11:16 AM, Richard Heathfield wrote: >>> On 06/05/2025 16:38, Alan Mackenzie wrote: >>>> These aren't particularly difficult things to comprehend. As I keep >>>> saying, you ought to show a lot more respect for people who are >>>> mathematically educated. >>> >>> I concur. >>> >>> As someone who is not particularly mathematically educated (I have an >>> A- level in the subject, but that's all), I tend to steer well clear >>> of mathematical debates, although I have occasionally dipped a toe. >>> >>> I have *enormous* respect for those who know their tensors from their >>> manifolds and their conjectures from their eigenvalues, even though >>> it's all Greek to me. >>> >>> But to understand the Turing proof requires little if any >>> mathematical knowledge. It requires only the capacity for clear >>> thinking. >>> >>> Having been on the receiving end of lengthy Usenet diatribes by >>> cranks in my own field, I don't hold out much hope for our current >>> culprits developing either the capacity for clear thought or any >>> measure of respect for expertise any time soon. >>> >>> Nor do I believe they are capable of understanding proof by >>> contradiction, which is just about the easiest kind of proof there >>> is. In fact, the most surprising aspect of this whole affair is that >> >> >>> (according to Mike) Mr Olcott seems to have (correctly) spotted a >>> minor flaw in the proof published by Dr Linz. How can he get that and >>> not get contradiction? Proof by contradiction is /much/ easier. >>> >> >> When THERE IS NO CONTRADICTION then proof by contradiction fails. > > False. The contradiction is that HHH is found to not map the below > function after it is assumed that the below function is computable and > that HHH computes it: > > > Given any algorithm (i.e. a fixed immutable sequence of instructions) X > described as <X> with input Y: > > A solution to the halting problem is an algorithm H that computes the > following mapping: > > (<X>,Y) maps to 1 if and only if X(Y) halts when executed directly > (<X>,Y) maps to 0 if and only if X(Y) does not halt when executed directly > > In other words you absolutely refuse to begin to understand to notion of computing the mapping from an input. -- 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 | dbush <dbush.mobile@gmail.com> |
|---|---|
| Date | 2025-05-07 14:38 -0400 |
| Message-ID | <vvg9aq$15i5e$11@dont-email.me> |
| In reply to | #117900 |
On 5/7/2025 2:35 PM, olcott wrote: > On 5/7/2025 1:18 PM, dbush wrote: >> On 5/7/2025 1:55 PM, olcott wrote: >>> On 5/6/2025 11:16 AM, Richard Heathfield wrote: >>>> On 06/05/2025 16:38, Alan Mackenzie wrote: >>>>> These aren't particularly difficult things to comprehend. As I keep >>>>> saying, you ought to show a lot more respect for people who are >>>>> mathematically educated. >>>> >>>> I concur. >>>> >>>> As someone who is not particularly mathematically educated (I have >>>> an A- level in the subject, but that's all), I tend to steer well >>>> clear of mathematical debates, although I have occasionally dipped a >>>> toe. >>>> >>>> I have *enormous* respect for those who know their tensors from >>>> their manifolds and their conjectures from their eigenvalues, even >>>> though it's all Greek to me. >>>> >>>> But to understand the Turing proof requires little if any >>>> mathematical knowledge. It requires only the capacity for clear >>>> thinking. >>>> >>>> Having been on the receiving end of lengthy Usenet diatribes by >>>> cranks in my own field, I don't hold out much hope for our current >>>> culprits developing either the capacity for clear thought or any >>>> measure of respect for expertise any time soon. >>>> >>>> Nor do I believe they are capable of understanding proof by >>>> contradiction, which is just about the easiest kind of proof there >>>> is. In fact, the most surprising aspect of this whole affair is that >>> >>> >>>> (according to Mike) Mr Olcott seems to have (correctly) spotted a >>>> minor flaw in the proof published by Dr Linz. How can he get that >>>> and not get contradiction? Proof by contradiction is /much/ easier. >>>> >>> >>> When THERE IS NO CONTRADICTION then proof by contradiction fails. >> >> False. The contradiction is that HHH is found to not map the below >> function after it is assumed that the below function is computable and >> that HHH computes it: >> >> >> Given any algorithm (i.e. a fixed immutable sequence of instructions) >> X described as <X> with input Y: >> >> A solution to the halting problem is an algorithm H that computes the >> following mapping: >> >> (<X>,Y) maps to 1 if and only if X(Y) halts when executed directly >> (<X>,Y) maps to 0 if and only if X(Y) does not halt when executed >> directly >> >> > > In other words you absolutely refuse to begin > to understand to notion of computing the mapping > from an input. > I'll let you respond to yourself: On 10/12/2024 8:35 PM, olcott wrote: > That your rebuttals are pure bluster utterly bereft of any > supporting reasoning is clear to all having sufficient > technical understanding.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-07 15:03 -0500 |
| Message-ID | <vvge9o$15e69$11@dont-email.me> |
| In reply to | #117901 |
On 5/7/2025 1:38 PM, dbush wrote: > On 5/7/2025 2:35 PM, olcott wrote: >> On 5/7/2025 1:18 PM, dbush wrote: >>> On 5/7/2025 1:55 PM, olcott wrote: >>>> On 5/6/2025 11:16 AM, Richard Heathfield wrote: >>>>> On 06/05/2025 16:38, Alan Mackenzie wrote: >>>>>> These aren't particularly difficult things to comprehend. As I keep >>>>>> saying, you ought to show a lot more respect for people who are >>>>>> mathematically educated. >>>>> >>>>> I concur. >>>>> >>>>> As someone who is not particularly mathematically educated (I have >>>>> an A- level in the subject, but that's all), I tend to steer well >>>>> clear of mathematical debates, although I have occasionally dipped >>>>> a toe. >>>>> >>>>> I have *enormous* respect for those who know their tensors from >>>>> their manifolds and their conjectures from their eigenvalues, even >>>>> though it's all Greek to me. >>>>> >>>>> But to understand the Turing proof requires little if any >>>>> mathematical knowledge. It requires only the capacity for clear >>>>> thinking. >>>>> >>>>> Having been on the receiving end of lengthy Usenet diatribes by >>>>> cranks in my own field, I don't hold out much hope for our current >>>>> culprits developing either the capacity for clear thought or any >>>>> measure of respect for expertise any time soon. >>>>> >>>>> Nor do I believe they are capable of understanding proof by >>>>> contradiction, which is just about the easiest kind of proof there >>>>> is. In fact, the most surprising aspect of this whole affair is that >>>> >>>> >>>>> (according to Mike) Mr Olcott seems to have (correctly) spotted a >>>>> minor flaw in the proof published by Dr Linz. How can he get that >>>>> and not get contradiction? Proof by contradiction is /much/ easier. >>>>> >>>> >>>> When THERE IS NO CONTRADICTION then proof by contradiction fails. >>> >>> False. The contradiction is that HHH is found to not map the below >>> function after it is assumed that the below function is computable >>> and that HHH computes it: >>> >>> >>> Given any algorithm (i.e. a fixed immutable sequence of instructions) >>> X described as <X> with input Y: >>> >>> A solution to the halting problem is an algorithm H that computes the >>> following mapping: >>> >>> (<X>,Y) maps to 1 if and only if X(Y) halts when executed directly >>> (<X>,Y) maps to 0 if and only if X(Y) does not halt when executed >>> directly >>> >>> >> >> In other words you absolutely refuse to begin >> to understand to notion of computing the mapping >> from an input. >> > > > I'll let you respond to yourself: > > On 10/12/2024 8:35 PM, olcott wrote: > > That your rebuttals are pure bluster utterly bereft of any > > supporting reasoning is clear to all having sufficient > > technical understanding. > In other words you absolutely refuse to understand that functions computed by models of computation are only allowed to derive outputs by applying the steps of an algorithm to their actual inputs. You probably don't understand any of those words. -- 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 | dbush <dbush.mobile@gmail.com> |
|---|---|
| Date | 2025-05-07 16:07 -0400 |
| Message-ID | <vvgeh8$15i5e$14@dont-email.me> |
| In reply to | #117912 |
On 5/7/2025 4:03 PM, olcott wrote: > On 5/7/2025 1:38 PM, dbush wrote: >> On 5/7/2025 2:35 PM, olcott wrote: >>> On 5/7/2025 1:18 PM, dbush wrote: >>>> On 5/7/2025 1:55 PM, olcott wrote: >>>>> On 5/6/2025 11:16 AM, Richard Heathfield wrote: >>>>>> On 06/05/2025 16:38, Alan Mackenzie wrote: >>>>>>> These aren't particularly difficult things to comprehend. As I keep >>>>>>> saying, you ought to show a lot more respect for people who are >>>>>>> mathematically educated. >>>>>> >>>>>> I concur. >>>>>> >>>>>> As someone who is not particularly mathematically educated (I have >>>>>> an A- level in the subject, but that's all), I tend to steer well >>>>>> clear of mathematical debates, although I have occasionally dipped >>>>>> a toe. >>>>>> >>>>>> I have *enormous* respect for those who know their tensors from >>>>>> their manifolds and their conjectures from their eigenvalues, even >>>>>> though it's all Greek to me. >>>>>> >>>>>> But to understand the Turing proof requires little if any >>>>>> mathematical knowledge. It requires only the capacity for clear >>>>>> thinking. >>>>>> >>>>>> Having been on the receiving end of lengthy Usenet diatribes by >>>>>> cranks in my own field, I don't hold out much hope for our current >>>>>> culprits developing either the capacity for clear thought or any >>>>>> measure of respect for expertise any time soon. >>>>>> >>>>>> Nor do I believe they are capable of understanding proof by >>>>>> contradiction, which is just about the easiest kind of proof there >>>>>> is. In fact, the most surprising aspect of this whole affair is that >>>>> >>>>> >>>>>> (according to Mike) Mr Olcott seems to have (correctly) spotted a >>>>>> minor flaw in the proof published by Dr Linz. How can he get that >>>>>> and not get contradiction? Proof by contradiction is /much/ easier. >>>>>> >>>>> >>>>> When THERE IS NO CONTRADICTION then proof by contradiction fails. >>>> >>>> False. The contradiction is that HHH is found to not map the below >>>> function after it is assumed that the below function is computable >>>> and that HHH computes it: >>>> >>>> >>>> Given any algorithm (i.e. a fixed immutable sequence of >>>> instructions) X described as <X> with input Y: >>>> >>>> A solution to the halting problem is an algorithm H that computes >>>> the following mapping: >>>> >>>> (<X>,Y) maps to 1 if and only if X(Y) halts when executed directly >>>> (<X>,Y) maps to 0 if and only if X(Y) does not halt when executed >>>> directly >>>> >>>> >>> >>> In other words you absolutely refuse to begin >>> to understand to notion of computing the mapping >>> from an input. >>> >> >> >> I'll let you respond to yourself: >> >> On 10/12/2024 8:35 PM, olcott wrote: >> > That your rebuttals are pure bluster utterly bereft of any >> > supporting reasoning is clear to all having sufficient >> > technical understanding. >> > > In other words you absolutely refuse to understand > that functions computed by models of computation > are only allowed to derive outputs by applying > the steps of an algorithm to their actual inputs. > No, it is you that doesn't understand that there is no requirement that any mapping has an algorithm that can compute it. The halting mapping is one such mapping, as Linz and others have proved and as you have *explicitly* agreed is correct.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-07 15:39 -0500 |
| Message-ID | <vvggdn$17q6h$1@dont-email.me> |
| In reply to | #117913 |
On 5/7/2025 3:07 PM, dbush wrote:
> On 5/7/2025 4:03 PM, olcott wrote:
>> On 5/7/2025 1:38 PM, dbush wrote:
>>> On 5/7/2025 2:35 PM, olcott wrote:
>>>> On 5/7/2025 1:18 PM, dbush wrote:
>>>>> On 5/7/2025 1:55 PM, olcott wrote:
>>>>>> On 5/6/2025 11:16 AM, Richard Heathfield wrote:
>>>>>>> On 06/05/2025 16:38, Alan Mackenzie wrote:
>>>>>>>> These aren't particularly difficult things to comprehend. As I
>>>>>>>> keep
>>>>>>>> saying, you ought to show a lot more respect for people who are
>>>>>>>> mathematically educated.
>>>>>>>
>>>>>>> I concur.
>>>>>>>
>>>>>>> As someone who is not particularly mathematically educated (I
>>>>>>> have an A- level in the subject, but that's all), I tend to steer
>>>>>>> well clear of mathematical debates, although I have occasionally
>>>>>>> dipped a toe.
>>>>>>>
>>>>>>> I have *enormous* respect for those who know their tensors from
>>>>>>> their manifolds and their conjectures from their eigenvalues,
>>>>>>> even though it's all Greek to me.
>>>>>>>
>>>>>>> But to understand the Turing proof requires little if any
>>>>>>> mathematical knowledge. It requires only the capacity for clear
>>>>>>> thinking.
>>>>>>>
>>>>>>> Having been on the receiving end of lengthy Usenet diatribes by
>>>>>>> cranks in my own field, I don't hold out much hope for our
>>>>>>> current culprits developing either the capacity for clear thought
>>>>>>> or any measure of respect for expertise any time soon.
>>>>>>>
>>>>>>> Nor do I believe they are capable of understanding proof by
>>>>>>> contradiction, which is just about the easiest kind of proof
>>>>>>> there is. In fact, the most surprising aspect of this whole
>>>>>>> affair is that
>>>>>>
>>>>>>
>>>>>>> (according to Mike) Mr Olcott seems to have (correctly) spotted a
>>>>>>> minor flaw in the proof published by Dr Linz. How can he get that
>>>>>>> and not get contradiction? Proof by contradiction is /much/ easier.
>>>>>>>
>>>>>>
>>>>>> When THERE IS NO CONTRADICTION then proof by contradiction fails.
>>>>>
>>>>> False. The contradiction is that HHH is found to not map the below
>>>>> function after it is assumed that the below function is computable
>>>>> and that HHH computes it:
>>>>>
>>>>>
>>>>> Given any algorithm (i.e. a fixed immutable sequence of
>>>>> instructions) X described as <X> with input Y:
>>>>>
>>>>> A solution to the halting problem is an algorithm H that computes
>>>>> the following mapping:
>>>>>
>>>>> (<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
>>>>> (<X>,Y) maps to 0 if and only if X(Y) does not halt when executed
>>>>> directly
>>>>>
>>>>>
>>>>
>>>> In other words you absolutely refuse to begin
>>>> to understand to notion of computing the mapping
>>>> from an input.
>>>>
>>>
>>>
>>> I'll let you respond to yourself:
>>>
>>> On 10/12/2024 8:35 PM, olcott wrote:
>>> > That your rebuttals are pure bluster utterly bereft of any
>>> > supporting reasoning is clear to all having sufficient
>>> > technical understanding.
>>>
>>
>> In other words you absolutely refuse to understand
>> that functions computed by models of computation
>> are only allowed to derive outputs by applying
>> the steps of an algorithm to their actual inputs.
>>
>
> No, it is you that doesn't understand that there is no requirement that
> any mapping has an algorithm that can compute it.
I know that. What you do not seem to know
is that an incoherent requirement does not
place any limit on computation.
That calculating the radius of a square circle
cannot be computed places no actual limit on computation.
The int sum(int x, int y) { return x + y; }
Requiring HHH to report on behavior that is different
that the behavior that its actual input actually specifies
is exactly the same as requiring sum(3,2) to report on
the sum of 5 + 7.
> The halting mapping
> is one such mapping, as Linz and others have proved and as you have
> *explicitly* agreed is correct.
I said they were correct ONLY ON THE BASIS OF A THE FALSE
ASSUMPTION that an input can actually do the opposite
of whatever value that its termination analyzer reports.
THAT I AGREED THAT THEY ARE CORRECT UNDER A FALSE
ASSUMPTION IS NOT AGREEING THAT THEY ARE CORRECT (nitwit?)
--
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 | dbush <dbush.mobile@gmail.com> |
|---|---|
| Date | 2025-05-07 16:53 -0400 |
| Message-ID | <vvgh7l$15i5e$15@dont-email.me> |
| In reply to | #117916 |
On 5/7/2025 4:39 PM, olcott wrote:
> On 5/7/2025 3:07 PM, dbush wrote:
>> On 5/7/2025 4:03 PM, olcott wrote:
>>> On 5/7/2025 1:38 PM, dbush wrote:
>>>> On 5/7/2025 2:35 PM, olcott wrote:
>>>>> On 5/7/2025 1:18 PM, dbush wrote:
>>>>>> On 5/7/2025 1:55 PM, olcott wrote:
>>>>>>> On 5/6/2025 11:16 AM, Richard Heathfield wrote:
>>>>>>>> On 06/05/2025 16:38, Alan Mackenzie wrote:
>>>>>>>>> These aren't particularly difficult things to comprehend. As I
>>>>>>>>> keep
>>>>>>>>> saying, you ought to show a lot more respect for people who are
>>>>>>>>> mathematically educated.
>>>>>>>>
>>>>>>>> I concur.
>>>>>>>>
>>>>>>>> As someone who is not particularly mathematically educated (I
>>>>>>>> have an A- level in the subject, but that's all), I tend to
>>>>>>>> steer well clear of mathematical debates, although I have
>>>>>>>> occasionally dipped a toe.
>>>>>>>>
>>>>>>>> I have *enormous* respect for those who know their tensors from
>>>>>>>> their manifolds and their conjectures from their eigenvalues,
>>>>>>>> even though it's all Greek to me.
>>>>>>>>
>>>>>>>> But to understand the Turing proof requires little if any
>>>>>>>> mathematical knowledge. It requires only the capacity for clear
>>>>>>>> thinking.
>>>>>>>>
>>>>>>>> Having been on the receiving end of lengthy Usenet diatribes by
>>>>>>>> cranks in my own field, I don't hold out much hope for our
>>>>>>>> current culprits developing either the capacity for clear
>>>>>>>> thought or any measure of respect for expertise any time soon.
>>>>>>>>
>>>>>>>> Nor do I believe they are capable of understanding proof by
>>>>>>>> contradiction, which is just about the easiest kind of proof
>>>>>>>> there is. In fact, the most surprising aspect of this whole
>>>>>>>> affair is that
>>>>>>>
>>>>>>>
>>>>>>>> (according to Mike) Mr Olcott seems to have (correctly) spotted
>>>>>>>> a minor flaw in the proof published by Dr Linz. How can he get
>>>>>>>> that and not get contradiction? Proof by contradiction is /much/
>>>>>>>> easier.
>>>>>>>>
>>>>>>>
>>>>>>> When THERE IS NO CONTRADICTION then proof by contradiction fails.
>>>>>>
>>>>>> False. The contradiction is that HHH is found to not map the
>>>>>> below function after it is assumed that the below function is
>>>>>> computable and that HHH computes it:
>>>>>>
>>>>>>
>>>>>> Given any algorithm (i.e. a fixed immutable sequence of
>>>>>> instructions) X described as <X> with input Y:
>>>>>>
>>>>>> A solution to the halting problem is an algorithm H that computes
>>>>>> the following mapping:
>>>>>>
>>>>>> (<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
>>>>>> (<X>,Y) maps to 0 if and only if X(Y) does not halt when executed
>>>>>> directly
>>>>>>
>>>>>>
>>>>>
>>>>> In other words you absolutely refuse to begin
>>>>> to understand to notion of computing the mapping
>>>>> from an input.
>>>>>
>>>>
>>>>
>>>> I'll let you respond to yourself:
>>>>
>>>> On 10/12/2024 8:35 PM, olcott wrote:
>>>> > That your rebuttals are pure bluster utterly bereft of any
>>>> > supporting reasoning is clear to all having sufficient
>>>> > technical understanding.
>>>>
>>>
>>> In other words you absolutely refuse to understand
>>> that functions computed by models of computation
>>> are only allowed to derive outputs by applying
>>> the steps of an algorithm to their actual inputs.
>>>
>>
>> No, it is you that doesn't understand that there is no requirement
>> that any mapping has an algorithm that can compute it.
>
> I know that.
Then you know that when we assume the contrary for the halting function,
we get a contradiction.
> What you do not seem to know
> is that an incoherent requirement does not
> place any limit on computation.
There is nothing incoherent about the halting function:
Given any algorithm (i.e. a fixed immutable sequence of instructions) X
described as <X> with input Y:
A solution to the halting problem is an algorithm H that computes the
following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed directly
>
> That calculating the radius of a square circle
> cannot be computed places no actual limit on computation.
>
> The int sum(int x, int y) { return x + y; }
>
> Requiring HHH to report on behavior that is different
> that the behavior that its actual input actually specifies
False, as "DD" is a representation of the algorithm DD which halts when
executed directly. This is proven by UTM(DD) halting.
> is exactly the same as requiring sum(3,2) to report on
> the sum of 5 + 7.
>
>> The halting mapping is one such mapping, as Linz and others have
>> proved and as you have *explicitly* agreed is correct.
>
> I said they were correct ONLY ON THE BASIS OF A THE FALSE
> ASSUMPTION that an input can actually do the opposite
> of whatever value that its termination analyzer reports.
That is not an assumption. That is proven through a series of truth
preserving operations. This gives us a contradiction, proving the
assumption that the halting function is computable is false, as Linz and
others have proved and as you have *explicitly* agreed is correct.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-07 15:58 -0500 |
| Message-ID | <vvghhp$1867c$1@dont-email.me> |
| In reply to | #117920 |
On 5/7/2025 3:53 PM, dbush wrote:
> On 5/7/2025 4:39 PM, olcott wrote:
>> On 5/7/2025 3:07 PM, dbush wrote:
>>> On 5/7/2025 4:03 PM, olcott wrote:
>>>> On 5/7/2025 1:38 PM, dbush wrote:
>>>>> On 5/7/2025 2:35 PM, olcott wrote:
>>>>>> On 5/7/2025 1:18 PM, dbush wrote:
>>>>>>> On 5/7/2025 1:55 PM, olcott wrote:
>>>>>>>> On 5/6/2025 11:16 AM, Richard Heathfield wrote:
>>>>>>>>> On 06/05/2025 16:38, Alan Mackenzie wrote:
>>>>>>>>>> These aren't particularly difficult things to comprehend. As
>>>>>>>>>> I keep
>>>>>>>>>> saying, you ought to show a lot more respect for people who are
>>>>>>>>>> mathematically educated.
>>>>>>>>>
>>>>>>>>> I concur.
>>>>>>>>>
>>>>>>>>> As someone who is not particularly mathematically educated (I
>>>>>>>>> have an A- level in the subject, but that's all), I tend to
>>>>>>>>> steer well clear of mathematical debates, although I have
>>>>>>>>> occasionally dipped a toe.
>>>>>>>>>
>>>>>>>>> I have *enormous* respect for those who know their tensors from
>>>>>>>>> their manifolds and their conjectures from their eigenvalues,
>>>>>>>>> even though it's all Greek to me.
>>>>>>>>>
>>>>>>>>> But to understand the Turing proof requires little if any
>>>>>>>>> mathematical knowledge. It requires only the capacity for clear
>>>>>>>>> thinking.
>>>>>>>>>
>>>>>>>>> Having been on the receiving end of lengthy Usenet diatribes by
>>>>>>>>> cranks in my own field, I don't hold out much hope for our
>>>>>>>>> current culprits developing either the capacity for clear
>>>>>>>>> thought or any measure of respect for expertise any time soon.
>>>>>>>>>
>>>>>>>>> Nor do I believe they are capable of understanding proof by
>>>>>>>>> contradiction, which is just about the easiest kind of proof
>>>>>>>>> there is. In fact, the most surprising aspect of this whole
>>>>>>>>> affair is that
>>>>>>>>
>>>>>>>>
>>>>>>>>> (according to Mike) Mr Olcott seems to have (correctly) spotted
>>>>>>>>> a minor flaw in the proof published by Dr Linz. How can he get
>>>>>>>>> that and not get contradiction? Proof by contradiction is /
>>>>>>>>> much/ easier.
>>>>>>>>>
>>>>>>>>
>>>>>>>> When THERE IS NO CONTRADICTION then proof by contradiction fails.
>>>>>>>
>>>>>>> False. The contradiction is that HHH is found to not map the
>>>>>>> below function after it is assumed that the below function is
>>>>>>> computable and that HHH computes it:
>>>>>>>
>>>>>>>
>>>>>>> Given any algorithm (i.e. a fixed immutable sequence of
>>>>>>> instructions) X described as <X> with input Y:
>>>>>>>
>>>>>>> A solution to the halting problem is an algorithm H that computes
>>>>>>> the following mapping:
>>>>>>>
>>>>>>> (<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
>>>>>>> (<X>,Y) maps to 0 if and only if X(Y) does not halt when executed
>>>>>>> directly
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> In other words you absolutely refuse to begin
>>>>>> to understand to notion of computing the mapping
>>>>>> from an input.
>>>>>>
>>>>>
>>>>>
>>>>> I'll let you respond to yourself:
>>>>>
>>>>> On 10/12/2024 8:35 PM, olcott wrote:
>>>>> > That your rebuttals are pure bluster utterly bereft of any
>>>>> > supporting reasoning is clear to all having sufficient
>>>>> > technical understanding.
>>>>>
>>>>
>>>> In other words you absolutely refuse to understand
>>>> that functions computed by models of computation
>>>> are only allowed to derive outputs by applying
>>>> the steps of an algorithm to their actual inputs.
>>>>
>>>
>>> No, it is you that doesn't understand that there is no requirement
>>> that any mapping has an algorithm that can compute it.
>>
>> I know that.
>
> Then you know that when we assume the contrary for the halting function,
> we get a contradiction.
>
>> What you do not seem to know
>> is that an incoherent requirement does not
>> place any limit on computation.
>
> There is nothing incoherent about the halting function:
>
>
> Given any algorithm (i.e. a fixed immutable sequence of instructions) X
> described as <X> with input Y:
>
> A solution to the halting problem is an algorithm H that computes the
> following mapping:
>
> (<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
> (<X>,Y) maps to 0 if and only if X(Y) does not halt when executed directly
>
>
>>
>> That calculating the radius of a square circle
>> cannot be computed places no actual limit on computation.
>>
>> The int sum(int x, int y) { return x + y; }
>>
>> Requiring HHH to report on behavior that is different
>> that the behavior that its actual input actually specifies
>
> False, as "DD" is a representation of the algorithm DD which halts when
> executed directly. This is proven by UTM(DD) halting.
>
>> is exactly the same as requiring sum(3,2) to report on
>> the sum of 5 + 7.
>>
>>> The halting mapping is one such mapping, as Linz and others have
>>> proved and as you have *explicitly* agreed is correct.
>>
>> I said they were correct ONLY ON THE BASIS OF A THE FALSE
>> ASSUMPTION that an input can actually do the opposite
>> of whatever value that its termination analyzer reports.
>
> That is not an assumption. That is proven through a series of truth
> preserving operations. This gives us a contradiction, proving the
> assumption that the halting function is computable is false, as Linz and
> others have proved and as you have *explicitly* agreed is correct.
>
There never has been any contradiction when we compute
the mapping from the finite string input to the behavior
that this input actually specifies.
The contradiction only comes when we "compute" the
mapping on the basis of a quote from a text book.
--
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 | dbush <dbush.mobile@gmail.com> |
|---|---|
| Date | 2025-05-07 17:03 -0400 |
| Message-ID | <vvghqo$15i5e$19@dont-email.me> |
| In reply to | #117924 |
On 5/7/2025 4:58 PM, olcott wrote:
> On 5/7/2025 3:53 PM, dbush wrote:
>> On 5/7/2025 4:39 PM, olcott wrote:
>>> On 5/7/2025 3:07 PM, dbush wrote:
>>>> On 5/7/2025 4:03 PM, olcott wrote:
>>>>> On 5/7/2025 1:38 PM, dbush wrote:
>>>>>> On 5/7/2025 2:35 PM, olcott wrote:
>>>>>>> On 5/7/2025 1:18 PM, dbush wrote:
>>>>>>>> On 5/7/2025 1:55 PM, olcott wrote:
>>>>>>>>> On 5/6/2025 11:16 AM, Richard Heathfield wrote:
>>>>>>>>>> On 06/05/2025 16:38, Alan Mackenzie wrote:
>>>>>>>>>>> These aren't particularly difficult things to comprehend. As
>>>>>>>>>>> I keep
>>>>>>>>>>> saying, you ought to show a lot more respect for people who are
>>>>>>>>>>> mathematically educated.
>>>>>>>>>>
>>>>>>>>>> I concur.
>>>>>>>>>>
>>>>>>>>>> As someone who is not particularly mathematically educated (I
>>>>>>>>>> have an A- level in the subject, but that's all), I tend to
>>>>>>>>>> steer well clear of mathematical debates, although I have
>>>>>>>>>> occasionally dipped a toe.
>>>>>>>>>>
>>>>>>>>>> I have *enormous* respect for those who know their tensors
>>>>>>>>>> from their manifolds and their conjectures from their
>>>>>>>>>> eigenvalues, even though it's all Greek to me.
>>>>>>>>>>
>>>>>>>>>> But to understand the Turing proof requires little if any
>>>>>>>>>> mathematical knowledge. It requires only the capacity for
>>>>>>>>>> clear thinking.
>>>>>>>>>>
>>>>>>>>>> Having been on the receiving end of lengthy Usenet diatribes
>>>>>>>>>> by cranks in my own field, I don't hold out much hope for our
>>>>>>>>>> current culprits developing either the capacity for clear
>>>>>>>>>> thought or any measure of respect for expertise any time soon.
>>>>>>>>>>
>>>>>>>>>> Nor do I believe they are capable of understanding proof by
>>>>>>>>>> contradiction, which is just about the easiest kind of proof
>>>>>>>>>> there is. In fact, the most surprising aspect of this whole
>>>>>>>>>> affair is that
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> (according to Mike) Mr Olcott seems to have (correctly)
>>>>>>>>>> spotted a minor flaw in the proof published by Dr Linz. How
>>>>>>>>>> can he get that and not get contradiction? Proof by
>>>>>>>>>> contradiction is / much/ easier.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> When THERE IS NO CONTRADICTION then proof by contradiction fails.
>>>>>>>>
>>>>>>>> False. The contradiction is that HHH is found to not map the
>>>>>>>> below function after it is assumed that the below function is
>>>>>>>> computable and that HHH computes it:
>>>>>>>>
>>>>>>>>
>>>>>>>> Given any algorithm (i.e. a fixed immutable sequence of
>>>>>>>> instructions) X described as <X> with input Y:
>>>>>>>>
>>>>>>>> A solution to the halting problem is an algorithm H that
>>>>>>>> computes the following mapping:
>>>>>>>>
>>>>>>>> (<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
>>>>>>>> (<X>,Y) maps to 0 if and only if X(Y) does not halt when
>>>>>>>> executed directly
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> In other words you absolutely refuse to begin
>>>>>>> to understand to notion of computing the mapping
>>>>>>> from an input.
>>>>>>>
>>>>>>
>>>>>>
>>>>>> I'll let you respond to yourself:
>>>>>>
>>>>>> On 10/12/2024 8:35 PM, olcott wrote:
>>>>>> > That your rebuttals are pure bluster utterly bereft of any
>>>>>> > supporting reasoning is clear to all having sufficient
>>>>>> > technical understanding.
>>>>>>
>>>>>
>>>>> In other words you absolutely refuse to understand
>>>>> that functions computed by models of computation
>>>>> are only allowed to derive outputs by applying
>>>>> the steps of an algorithm to their actual inputs.
>>>>>
>>>>
>>>> No, it is you that doesn't understand that there is no requirement
>>>> that any mapping has an algorithm that can compute it.
>>>
>>> I know that.
>>
>> Then you know that when we assume the contrary for the halting
>> function, we get a contradiction.
>>
>>> What you do not seem to know
>>> is that an incoherent requirement does not
>>> place any limit on computation.
>>
>> There is nothing incoherent about the halting function:
>>
>>
>> Given any algorithm (i.e. a fixed immutable sequence of instructions)
>> X described as <X> with input Y:
>>
>> A solution to the halting problem is an algorithm H that computes the
>> following mapping:
>>
>> (<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
>> (<X>,Y) maps to 0 if and only if X(Y) does not halt when executed
>> directly
>>
>>
>>>
>>> That calculating the radius of a square circle
>>> cannot be computed places no actual limit on computation.
>>>
>>> The int sum(int x, int y) { return x + y; }
>>>
>>> Requiring HHH to report on behavior that is different
>>> that the behavior that its actual input actually specifies
>>
>> False, as "DD" is a representation of the algorithm DD which halts
>> when executed directly. This is proven by UTM(DD) halting.
>>
>>> is exactly the same as requiring sum(3,2) to report on
>>> the sum of 5 + 7.
>>>
>>>> The halting mapping is one such mapping, as Linz and others have
>>>> proved and as you have *explicitly* agreed is correct.
>>>
>>> I said they were correct ONLY ON THE BASIS OF A THE FALSE
>>> ASSUMPTION that an input can actually do the opposite
>>> of whatever value that its termination analyzer reports.
>>
>> That is not an assumption. That is proven through a series of truth
>> preserving operations. This gives us a contradiction, proving the
>> assumption that the halting function is computable is false, as Linz
>> and others have proved and as you have *explicitly* agreed is correct.
>>
>
> There never has been any contradiction when we compute
> the mapping from the finite string input to the behavior
> that this input actually specifies.
And the behavior actually specified by the input, i.e. the immutable
code of the function DD, the immutable code of the function HHH, and the
immutable code of everything HHH calls down to the OS level, is to halt
when executed directly or when actually correctly emulated by UTM.
Remember, it is assumed that the halting function is computable and that
HHH computes it, so it follows that "DD" *is* the above description.
This means the halting mapping maps "DD" to halting, i.e. 1, but
HHH(DD)==0, a contradiction.
This prove the assumption that the halting function is computable is
false, as Linz and others have proved and as you have *explicitly*
agreed is correct.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-07 16:24 -0500 |
| Message-ID | <vvgj2r$18j1i$2@dont-email.me> |
| In reply to | #117925 |
On 5/7/2025 4:03 PM, dbush wrote:
> On 5/7/2025 4:58 PM, olcott wrote:
>> On 5/7/2025 3:53 PM, dbush wrote:
>>> On 5/7/2025 4:39 PM, olcott wrote:
>>>> On 5/7/2025 3:07 PM, dbush wrote:
>>>>> On 5/7/2025 4:03 PM, olcott wrote:
>>>>>> On 5/7/2025 1:38 PM, dbush wrote:
>>>>>>> On 5/7/2025 2:35 PM, olcott wrote:
>>>>>>>> On 5/7/2025 1:18 PM, dbush wrote:
>>>>>>>>> On 5/7/2025 1:55 PM, olcott wrote:
>>>>>>>>>> On 5/6/2025 11:16 AM, Richard Heathfield wrote:
>>>>>>>>>>> On 06/05/2025 16:38, Alan Mackenzie wrote:
>>>>>>>>>>>> These aren't particularly difficult things to comprehend.
>>>>>>>>>>>> As I keep
>>>>>>>>>>>> saying, you ought to show a lot more respect for people who are
>>>>>>>>>>>> mathematically educated.
>>>>>>>>>>>
>>>>>>>>>>> I concur.
>>>>>>>>>>>
>>>>>>>>>>> As someone who is not particularly mathematically educated (I
>>>>>>>>>>> have an A- level in the subject, but that's all), I tend to
>>>>>>>>>>> steer well clear of mathematical debates, although I have
>>>>>>>>>>> occasionally dipped a toe.
>>>>>>>>>>>
>>>>>>>>>>> I have *enormous* respect for those who know their tensors
>>>>>>>>>>> from their manifolds and their conjectures from their
>>>>>>>>>>> eigenvalues, even though it's all Greek to me.
>>>>>>>>>>>
>>>>>>>>>>> But to understand the Turing proof requires little if any
>>>>>>>>>>> mathematical knowledge. It requires only the capacity for
>>>>>>>>>>> clear thinking.
>>>>>>>>>>>
>>>>>>>>>>> Having been on the receiving end of lengthy Usenet diatribes
>>>>>>>>>>> by cranks in my own field, I don't hold out much hope for our
>>>>>>>>>>> current culprits developing either the capacity for clear
>>>>>>>>>>> thought or any measure of respect for expertise any time soon.
>>>>>>>>>>>
>>>>>>>>>>> Nor do I believe they are capable of understanding proof by
>>>>>>>>>>> contradiction, which is just about the easiest kind of proof
>>>>>>>>>>> there is. In fact, the most surprising aspect of this whole
>>>>>>>>>>> affair is that
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> (according to Mike) Mr Olcott seems to have (correctly)
>>>>>>>>>>> spotted a minor flaw in the proof published by Dr Linz. How
>>>>>>>>>>> can he get that and not get contradiction? Proof by
>>>>>>>>>>> contradiction is / much/ easier.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> When THERE IS NO CONTRADICTION then proof by contradiction fails.
>>>>>>>>>
>>>>>>>>> False. The contradiction is that HHH is found to not map the
>>>>>>>>> below function after it is assumed that the below function is
>>>>>>>>> computable and that HHH computes it:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Given any algorithm (i.e. a fixed immutable sequence of
>>>>>>>>> instructions) X described as <X> with input Y:
>>>>>>>>>
>>>>>>>>> A solution to the halting problem is an algorithm H that
>>>>>>>>> computes the following mapping:
>>>>>>>>>
>>>>>>>>> (<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
>>>>>>>>> (<X>,Y) maps to 0 if and only if X(Y) does not halt when
>>>>>>>>> executed directly
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> In other words you absolutely refuse to begin
>>>>>>>> to understand to notion of computing the mapping
>>>>>>>> from an input.
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I'll let you respond to yourself:
>>>>>>>
>>>>>>> On 10/12/2024 8:35 PM, olcott wrote:
>>>>>>> > That your rebuttals are pure bluster utterly bereft of any
>>>>>>> > supporting reasoning is clear to all having sufficient
>>>>>>> > technical understanding.
>>>>>>>
>>>>>>
>>>>>> In other words you absolutely refuse to understand
>>>>>> that functions computed by models of computation
>>>>>> are only allowed to derive outputs by applying
>>>>>> the steps of an algorithm to their actual inputs.
>>>>>>
>>>>>
>>>>> No, it is you that doesn't understand that there is no requirement
>>>>> that any mapping has an algorithm that can compute it.
>>>>
>>>> I know that.
>>>
>>> Then you know that when we assume the contrary for the halting
>>> function, we get a contradiction.
>>>
>>>> What you do not seem to know
>>>> is that an incoherent requirement does not
>>>> place any limit on computation.
>>>
>>> There is nothing incoherent about the halting function:
>>>
>>>
>>> Given any algorithm (i.e. a fixed immutable sequence of instructions)
>>> X described as <X> with input Y:
>>>
>>> A solution to the halting problem is an algorithm H that computes the
>>> following mapping:
>>>
>>> (<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
>>> (<X>,Y) maps to 0 if and only if X(Y) does not halt when executed
>>> directly
>>>
>>>
>>>>
>>>> That calculating the radius of a square circle
>>>> cannot be computed places no actual limit on computation.
>>>>
>>>> The int sum(int x, int y) { return x + y; }
>>>>
>>>> Requiring HHH to report on behavior that is different
>>>> that the behavior that its actual input actually specifies
>>>
>>> False, as "DD" is a representation of the algorithm DD which halts
>>> when executed directly. This is proven by UTM(DD) halting.
>>>
>>>> is exactly the same as requiring sum(3,2) to report on
>>>> the sum of 5 + 7.
>>>>
>>>>> The halting mapping is one such mapping, as Linz and others have
>>>>> proved and as you have *explicitly* agreed is correct.
>>>>
>>>> I said they were correct ONLY ON THE BASIS OF A THE FALSE
>>>> ASSUMPTION that an input can actually do the opposite
>>>> of whatever value that its termination analyzer reports.
>>>
>>> That is not an assumption. That is proven through a series of truth
>>> preserving operations. This gives us a contradiction, proving the
>>> assumption that the halting function is computable is false, as Linz
>>> and others have proved and as you have *explicitly* agreed is correct.
>>>
>>
>> There never has been any contradiction when we compute
>> the mapping from the finite string input to the behavior
>> that this input actually specifies.
>
> And the behavior actually specified by the input, i.e. the immutable
> code of the function DD, the immutable code of the function HHH, and the
> immutable code of everything HHH calls down to the OS level, is to halt
> when executed directly or when actually correctly emulated by UTM.
>
THAT IS NOT THE BEHAVIOR THAT THE INPUT TO HHH(DD) SPECIFIES
PROVING THAT IS THE WRONG BEHAVIOR TO MEASURE.
--
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 | dbush <dbush.mobile@gmail.com> |
|---|---|
| Date | 2025-05-07 17:29 -0400 |
| Message-ID | <vvgjbi$15i5e$22@dont-email.me> |
| In reply to | #117931 |
On 5/7/2025 5:24 PM, olcott wrote:
> On 5/7/2025 4:03 PM, dbush wrote:
>> On 5/7/2025 4:58 PM, olcott wrote:
>>> On 5/7/2025 3:53 PM, dbush wrote:
>>>> On 5/7/2025 4:39 PM, olcott wrote:
>>>>> On 5/7/2025 3:07 PM, dbush wrote:
>>>>>> On 5/7/2025 4:03 PM, olcott wrote:
>>>>>>> On 5/7/2025 1:38 PM, dbush wrote:
>>>>>>>> On 5/7/2025 2:35 PM, olcott wrote:
>>>>>>>>> On 5/7/2025 1:18 PM, dbush wrote:
>>>>>>>>>> On 5/7/2025 1:55 PM, olcott wrote:
>>>>>>>>>>> On 5/6/2025 11:16 AM, Richard Heathfield wrote:
>>>>>>>>>>>> On 06/05/2025 16:38, Alan Mackenzie wrote:
>>>>>>>>>>>>> These aren't particularly difficult things to comprehend.
>>>>>>>>>>>>> As I keep
>>>>>>>>>>>>> saying, you ought to show a lot more respect for people who
>>>>>>>>>>>>> are
>>>>>>>>>>>>> mathematically educated.
>>>>>>>>>>>>
>>>>>>>>>>>> I concur.
>>>>>>>>>>>>
>>>>>>>>>>>> As someone who is not particularly mathematically educated
>>>>>>>>>>>> (I have an A- level in the subject, but that's all), I tend
>>>>>>>>>>>> to steer well clear of mathematical debates, although I have
>>>>>>>>>>>> occasionally dipped a toe.
>>>>>>>>>>>>
>>>>>>>>>>>> I have *enormous* respect for those who know their tensors
>>>>>>>>>>>> from their manifolds and their conjectures from their
>>>>>>>>>>>> eigenvalues, even though it's all Greek to me.
>>>>>>>>>>>>
>>>>>>>>>>>> But to understand the Turing proof requires little if any
>>>>>>>>>>>> mathematical knowledge. It requires only the capacity for
>>>>>>>>>>>> clear thinking.
>>>>>>>>>>>>
>>>>>>>>>>>> Having been on the receiving end of lengthy Usenet diatribes
>>>>>>>>>>>> by cranks in my own field, I don't hold out much hope for
>>>>>>>>>>>> our current culprits developing either the capacity for
>>>>>>>>>>>> clear thought or any measure of respect for expertise any
>>>>>>>>>>>> time soon.
>>>>>>>>>>>>
>>>>>>>>>>>> Nor do I believe they are capable of understanding proof by
>>>>>>>>>>>> contradiction, which is just about the easiest kind of proof
>>>>>>>>>>>> there is. In fact, the most surprising aspect of this whole
>>>>>>>>>>>> affair is that
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> (according to Mike) Mr Olcott seems to have (correctly)
>>>>>>>>>>>> spotted a minor flaw in the proof published by Dr Linz. How
>>>>>>>>>>>> can he get that and not get contradiction? Proof by
>>>>>>>>>>>> contradiction is / much/ easier.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> When THERE IS NO CONTRADICTION then proof by contradiction
>>>>>>>>>>> fails.
>>>>>>>>>>
>>>>>>>>>> False. The contradiction is that HHH is found to not map the
>>>>>>>>>> below function after it is assumed that the below function is
>>>>>>>>>> computable and that HHH computes it:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Given any algorithm (i.e. a fixed immutable sequence of
>>>>>>>>>> instructions) X described as <X> with input Y:
>>>>>>>>>>
>>>>>>>>>> A solution to the halting problem is an algorithm H that
>>>>>>>>>> computes the following mapping:
>>>>>>>>>>
>>>>>>>>>> (<X>,Y) maps to 1 if and only if X(Y) halts when executed
>>>>>>>>>> directly
>>>>>>>>>> (<X>,Y) maps to 0 if and only if X(Y) does not halt when
>>>>>>>>>> executed directly
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> In other words you absolutely refuse to begin
>>>>>>>>> to understand to notion of computing the mapping
>>>>>>>>> from an input.
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I'll let you respond to yourself:
>>>>>>>>
>>>>>>>> On 10/12/2024 8:35 PM, olcott wrote:
>>>>>>>> > That your rebuttals are pure bluster utterly bereft of any
>>>>>>>> > supporting reasoning is clear to all having sufficient
>>>>>>>> > technical understanding.
>>>>>>>>
>>>>>>>
>>>>>>> In other words you absolutely refuse to understand
>>>>>>> that functions computed by models of computation
>>>>>>> are only allowed to derive outputs by applying
>>>>>>> the steps of an algorithm to their actual inputs.
>>>>>>>
>>>>>>
>>>>>> No, it is you that doesn't understand that there is no requirement
>>>>>> that any mapping has an algorithm that can compute it.
>>>>>
>>>>> I know that.
>>>>
>>>> Then you know that when we assume the contrary for the halting
>>>> function, we get a contradiction.
>>>>
>>>>> What you do not seem to know
>>>>> is that an incoherent requirement does not
>>>>> place any limit on computation.
>>>>
>>>> There is nothing incoherent about the halting function:
>>>>
>>>>
>>>> Given any algorithm (i.e. a fixed immutable sequence of
>>>> instructions) X described as <X> with input Y:
>>>>
>>>> A solution to the halting problem is an algorithm H that computes
>>>> the following mapping:
>>>>
>>>> (<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
>>>> (<X>,Y) maps to 0 if and only if X(Y) does not halt when executed
>>>> directly
>>>>
>>>>
>>>>>
>>>>> That calculating the radius of a square circle
>>>>> cannot be computed places no actual limit on computation.
>>>>>
>>>>> The int sum(int x, int y) { return x + y; }
>>>>>
>>>>> Requiring HHH to report on behavior that is different
>>>>> that the behavior that its actual input actually specifies
>>>>
>>>> False, as "DD" is a representation of the algorithm DD which halts
>>>> when executed directly. This is proven by UTM(DD) halting.
>>>>
>>>>> is exactly the same as requiring sum(3,2) to report on
>>>>> the sum of 5 + 7.
>>>>>
>>>>>> The halting mapping is one such mapping, as Linz and others have
>>>>>> proved and as you have *explicitly* agreed is correct.
>>>>>
>>>>> I said they were correct ONLY ON THE BASIS OF A THE FALSE
>>>>> ASSUMPTION that an input can actually do the opposite
>>>>> of whatever value that its termination analyzer reports.
>>>>
>>>> That is not an assumption. That is proven through a series of truth
>>>> preserving operations. This gives us a contradiction, proving the
>>>> assumption that the halting function is computable is false, as Linz
>>>> and others have proved and as you have *explicitly* agreed is correct.
>>>>
>>>
>>> There never has been any contradiction when we compute
>>> the mapping from the finite string input to the behavior
>>> that this input actually specifies.
>>
>> And the behavior actually specified by the input, i.e. the immutable
>> code of the function DD, the immutable code of the function HHH, and
>> the immutable code of everything HHH calls down to the OS level, is to
>> halt when executed directly or when actually correctly emulated by UTM.
>>
>
> THAT IS NOT THE BEHAVIOR THAT THE INPUT TO HHH(DD) SPECIFIES
It's the same as the input to UTM(DD), which shows that it halts, so YES
that is the behavior it specifies.
>> Remember, it is assumed that the halting function is computable and that
>> HHH computes it, so it follows that "DD" *is* the above description.
Your lack of a rebuttal here is your admission that it *is* what the
input specifies.
>>
>> This means the halting mapping maps "DD" to halting, i.e. 1, but
>> HHH(DD)==0, a contradiction.
>>
>> This prove the assumption that the halting function is computable is
>> false, as Linz and others have proved and as you have *explicitly*
>> agreed is correct.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-07 13:03 -0500 |
| Message-ID | <vvg78k$15e69$2@dont-email.me> |
| In reply to | #117701 |
On 5/6/2025 11:16 AM, Richard Heathfield wrote: > On 06/05/2025 16:38, Alan Mackenzie wrote: >> These aren't particularly difficult things to comprehend. As I keep >> saying, you ought to show a lot more respect for people who are >> mathematically educated. > > I concur. > > As someone who is not particularly mathematically educated (I have an A- > level in the subject, but that's all), I tend to steer well clear of > mathematical debates, although I have occasionally dipped a toe. > > I have *enormous* respect for those who know their tensors from their > manifolds and their conjectures from their eigenvalues, even though it's > all Greek to me. > > But to understand the Turing proof requires little if any mathematical > knowledge. It requires only the capacity for clear thinking. > > Having been on the receiving end of lengthy Usenet diatribes by cranks > in my own field, I don't hold out much hope for our current culprits > developing either the capacity for clear thought or any measure of > respect for expertise any time soon. > > Nor do I believe they are capable of understanding proof by > contradiction, which is just about the easiest kind of proof there is. > In fact, the most surprising aspect of this whole affair is that > (according to Mike) Mr Olcott seems to have (correctly) spotted a minor > flaw in the proof published by Dr Linz. How can he get that and not get > contradiction? Proof by contradiction is /much/ easier. > https://www.liarparadox.org/Linz_Proof.pdf The flaw is on the top of page 3 where there are two q0 start states in the same sequence of state transitions. I encode that in this easier to understand notation. When Ĥ is applied to ⟨Ĥ⟩ Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn -- 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 | 2025-05-08 11:38 +0300 |
| Message-ID | <vvhqi7$1l7ne$1@dont-email.me> |
| In reply to | #117887 |
On 2025-05-07 18:03:00 +0000, olcott said: > On 5/6/2025 11:16 AM, Richard Heathfield wrote: >> On 06/05/2025 16:38, Alan Mackenzie wrote: >>> These aren't particularly difficult things to comprehend. As I keep >>> saying, you ought to show a lot more respect for people who are >>> mathematically educated. >> >> I concur. >> >> As someone who is not particularly mathematically educated (I have an >> A- level in the subject, but that's all), I tend to steer well clear of >> mathematical debates, although I have occasionally dipped a toe. >> >> I have *enormous* respect for those who know their tensors from their >> manifolds and their conjectures from their eigenvalues, even though >> it's all Greek to me. >> >> But to understand the Turing proof requires little if any mathematical >> knowledge. It requires only the capacity for clear thinking. >> >> Having been on the receiving end of lengthy Usenet diatribes by cranks >> in my own field, I don't hold out much hope for our current culprits >> developing either the capacity for clear thought or any measure of >> respect for expertise any time soon. >> >> Nor do I believe they are capable of understanding proof by >> contradiction, which is just about the easiest kind of proof there is. >> In fact, the most surprising aspect of this whole affair is that > >> (according to Mike) Mr Olcott seems to have (correctly) spotted a minor >> flaw in the proof published by Dr Linz. How can he get that and not get >> contradiction? Proof by contradiction is /much/ easier. >> > > https://www.liarparadox.org/Linz_Proof.pdf > The flaw is on the top of page 3 where > there are two q0 start states in the same sequence > of state transitions. There is no page 3 there, only unnumbered pages. No, there is not. Every Turing machine has only one start state and q0 is that state and no other. Once the Turing machine has started the start state is like any other state, so a Turing machine may make a transition to the start state and continue from there. But going back to the start state is not useful in this context. The presentation would be clearer if Linz had used a different start state for each Turing machine or explicitly renamed the start state of H' when constructing Ĥ. > I encode that in this easier to understand notation. > > When Ĥ is applied to ⟨Ĥ⟩ > Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ > Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn It is easy to understand that that does not encode anything. It is also easy to understand that you are trying the deception known as "fallacy fallacy". -- Mikko
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-06 12:06 -0500 |
| Message-ID | <vvdfi3$3cbpq$2@dont-email.me> |
| In reply to | #117698 |
On 5/6/2025 10:38 AM, Alan Mackenzie wrote: > olcott <polcott333@gmail.com> wrote: >> On 5/6/2025 3:17 AM, Alan Mackenzie wrote: >>> [ Followup-To: set ] > >>> In comp.theory olcott <polcott333@gmail.com> wrote: > > [ .... ] > >>>> When we begin with truth and only apply truth preserving >>>> operations then WE NECESSARILY MUST END UP WITH TRUTH. > >>> You will necessarily end up with only a subset of truth, no matter how >>> shouty you are in writing it. You'll also end up with undecidability, >>> no matter how hard you try to pretend it isn't there. > >>>> When we ALWAYS end up with TRUTH then we NEVER end up with >>>> UNDECIDABILITY. > >>> Shut your eyes, and you won't see it. > >> Try to provide one simple concrete example where we begin with truth >> and only apply truth preserving operations and end up with >> undecidability. > > There is no need to provide examples for rigorously proven mathematical > theorems, in particular for Gödel's incompleteness theorem. I don't go > around providing examples for 2 + 2 = 4 either. > This is proven completely true entirely on the basis of the meaning of its words: When True(x) is defined to mean that x can be derived by applying truth preserving operations to basic facts that are stipulated to be true ONLY TRUTH CAN BE DERIVED. Everything (including random gibberish) is divided into True(x) or ~True(x). Since the scope of this system includes all general knowledge that can be expressed using language. True(x) returns false for unknown and unknowable truths. Thus True(x) is a membership algorithm that verifies whether or not x is in the body of general knowledge that can be expressed using language. -- Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
Page 31 of 32 — ← Prev page 1 … 29 30 [31] 32 Next page →
Back to top | Article view | comp.theory
csiph-web