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 17 of 32 — ← Prev page 1 … 15 16 [17] 18 19 … 32 Next page →
| From | dbush <dbush.mobile@gmail.com> |
|---|---|
| Date | 2025-05-12 14:19 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvte2m$15ceh$17@dont-email.me> |
| In reply to | #118726 |
On 5/12/2025 1:58 PM, olcott wrote: > On 5/12/2025 12:30 PM, dbush wrote: >> On 5/12/2025 1:16 PM, olcott wrote: >>> On 5/12/2025 12:07 PM, dbush wrote: >>>> On 5/12/2025 12:54 PM, olcott wrote: >>>>> On 5/12/2025 11:41 AM, dbush wrote: >>>>>> On 5/12/2025 12:19 PM, olcott wrote: >>>>>>> On 5/12/2025 10:06 AM, dbush wrote: >>>>>>>> On 5/12/2025 11:04 AM, olcott wrote: >>>>>>>>> Termination analyzers compute the mapping from their >>>>>>>>> inputs to the behavior that these inputs actually specify. >>>>>>>> >>>>>>>> False. They compute the mapping from their input to the >>>>>>>> behavior of the algorithm described by the input when executed >>>>>>>> directly, as per the requirements: >>>>>>>> >>>>>>> >>>>>>> That is easily proven stupidly wrong. >>>>>> >>>>>> >>>>>> Category error. Definitions are not proven: >>>>>> >>>>> >>>>> Definitions that contradict other definitions are refuted. >>>>> >>>> >>>> >>>> And you haven't shown a conflict with the definition of a solution >>>> to the halting problem: >>>> >>> >>> That you keep ignoring it its not >>> a matter of me never providing it. >>> >> >> In other words, you agree that no algorithm exists that can compute >> the following mapping: >> > > Likewise no algorithm exists that can compute > the square root of a dead rabbit. And as was said before: On 5/5/2025 5:39 PM, olcott wrote: > On 5/5/2025 4:31 PM, dbush wrote: >> Strawman. The square root of a dead rabbit does not exist, but the >> question of whether any arbitrary algorithm X with input Y halts when >> executed directly has a correct answer in all cases. >> > > It has a correct answer that cannot ever be computed Where you *explicitly* agreed that the Linz halting theorem is correct.
[toc] | [prev] | [next] | [standalone]
| From | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2025-05-13 13:23 +0200 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvva4e$1ov7e$6@dont-email.me> |
| In reply to | #118726 |
Op 12.mei.2025 om 19:58 schreef olcott: > On 5/12/2025 12:30 PM, dbush wrote: >> On 5/12/2025 1:16 PM, olcott wrote: >>> On 5/12/2025 12:07 PM, dbush wrote: >>>> On 5/12/2025 12:54 PM, olcott wrote: >>>>> On 5/12/2025 11:41 AM, dbush wrote: >>>>>> On 5/12/2025 12:19 PM, olcott wrote: >>>>>>> On 5/12/2025 10:06 AM, dbush wrote: >>>>>>>> On 5/12/2025 11:04 AM, olcott wrote: >>>>>>>>> Termination analyzers compute the mapping from their >>>>>>>>> inputs to the behavior that these inputs actually specify. >>>>>>>> >>>>>>>> False. They compute the mapping from their input to the >>>>>>>> behavior of the algorithm described by the input when executed >>>>>>>> directly, as per the requirements: >>>>>>>> >>>>>>> >>>>>>> That is easily proven stupidly wrong. >>>>>> >>>>>> >>>>>> Category error. Definitions are not proven: >>>>>> >>>>> >>>>> Definitions that contradict other definitions are refuted. >>>>> >>>> >>>> >>>> And you haven't shown a conflict with the definition of a solution >>>> to the halting problem: >>>> >>> >>> That you keep ignoring it its not >>> a matter of me never providing it. >>> >> >> In other words, you agree that no algorithm exists that can compute >> the following mapping: >> > > Likewise no algorithm exists that can compute > the square root of a dead rabbit. In neither > case is computation actually limited. > With the difference that the halting behaviour in direct execution exists, but the square root of a dead rabbit does not. That things that do not exist cannot be computed is not interesting. That things that exist cannot be computed is relevant.
[toc] | [prev] | [next] | [standalone]
| From | Mikko <mikko.levanto@iki.fi> |
|---|---|
| Date | 2025-05-13 13:19 +0300 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvv6b4$1olt1$1@dont-email.me> |
| In reply to | #118711 |
On 2025-05-12 16:54:33 +0000, olcott said: > On 5/12/2025 11:41 AM, dbush wrote: >> On 5/12/2025 12:19 PM, olcott wrote: >>> On 5/12/2025 10:06 AM, dbush wrote: >>>> On 5/12/2025 11:04 AM, olcott wrote: >>>>> Termination analyzers compute the mapping from their >>>>> inputs to the behavior that these inputs actually specify. >>>> >>>> False. They compute the mapping from their input to the behavior of >>>> the algorithm described by the input when executed directly, as per the >>>> requirements: >>>> >>> >>> That is easily proven stupidly wrong. >> >> >> Category error. Definitions are not proven: >> > > Definitions that contradict other definitions are refuted. That two definitions contradict does not refute either one. The contradiction just means that it is an error to use both at the same time. -- Mikko
[toc] | [prev] | [next] | [standalone]
| From | joes <noreply@example.org> |
|---|---|
| Date | 2025-05-12 21:29 +0000 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <3006bfc83c508185f1b9d370ae5993dc5332d117@i2pn2.org> |
| In reply to | #118698 |
Am Mon, 12 May 2025 11:19:50 -0500 schrieb olcott: > On 5/12/2025 10:06 AM, dbush wrote: >> On 5/12/2025 11:04 AM, olcott wrote: >>> Termination analyzers compute the mapping from their inputs to the >>> behavior that these inputs actually specify. >> >> False. They compute the mapping from their input to the behavior of >> the algorithm described by the input when executed directly, as per the >> requirements: >> > If HHH could see that the direct execution of DDD() > does halt because HHH spots the repeating pattern and aborts this > simulation and HHH did not abort on this basis then DDD() never halts, > proving that HHH was correct to abort. Likewise, if HHH reports nonhalting, DDD returns and terminates. -- 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 | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2025-05-12 23:10 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <nnzUP.260251$jny7.160592@fx48.iad> |
| In reply to | #118678 |
On 5/12/25 11:04 AM, olcott wrote:
> On 5/12/2025 3:03 AM, Mikko wrote:
>> On 2025-05-11 17:00:41 +0000, olcott said:
>>
>>> On 5/11/2025 11:28 AM, wij wrote:
>>>> On Sun, 2025-05-11 at 10:38 -0500, olcott wrote:
>>>>> On 5/11/2025 9:34 AM, wij wrote:
>>>>>> On Sat, 2025-05-10 at 21:19 -0500, olcott wrote:
>>>>>>> On 5/10/2025 9:09 PM, wij wrote:
>>>>>>>> On Sat, 2025-05-10 at 20:56 -0500, olcott wrote:
>>>>>>>>> On 5/10/2025 8:44 PM, wij wrote:
>>>>>>>>>> On Sat, 2025-05-10 at 20:26 -0500, olcott wrote:
>>>>>>>>>>> On 5/10/2025 8:17 PM, wij wrote:
>>>>>>>>>>>> On Sat, 2025-05-10 at 17:03 -0500, olcott wrote:
>>>>>>>>>>>>> On 5/10/2025 4:44 PM, wij wrote:
>>>>>>>>>>>>>> On Sat, 2025-05-10 at 14:29 -0500, olcott wrote:
>>>>>>>>>>>>>>> On 5/10/2025 2:02 PM, wij wrote:
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> You don't know the counter example in the HP proof, your D
>>>>>>>>>>>> is not the case what HP
>>>>>>>>>>>> says.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Sure I do this is it! (as correctly encoded in C)
>>>>>>>>>>>
>>>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>>> int HHH(ptr P);
>>>>>>>>>>>
>>>>>>>>>>> int DD()
>>>>>>>>>>> {
>>>>>>>>>>> int Halt_Status = HHH(DD);
>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>> return Halt_Status;
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> int main()
>>>>>>>>>>> {
>>>>>>>>>>> HHH(DD);
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Try to convert it to TM language to know you know nothing.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I spent 22 years on this. I started with the Linz text
>>>>>>>>>
>>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>> or
>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>
>>>>>>>>> (a) Ĥ copies its input ⟨Ĥ⟩
>>>>>>>>> (b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>>> (c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ ...
>>>>>>>>>
>>>>>>>>> Thus ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by embedded_H
>>>>>>>>> cannot possibly reach its simulated final halt state
>>>>>>>>> ⟨Ĥ.qn⟩
>>>>>>>>>
>>>>>>>>>> To refute the HP, you need to understand what it exactly means
>>>>>>>>>> in TM.
>>>>>>>>>
>>>>>>>>> I have known this for 22 years.
>>>>>>>>
>>>>>>>> A working TM. Build it explicitly from transition function, then
>>>>>>>> explain
>>>>>>>> your derivation. You know nothing.
>>>>>>>>
>>>>>>>
>>>>>>> That would be like examining how an operating system
>>>>>>> works entirely from its machine code.
>>>>>>
>>>>>> You are refuting a CS foundamental theorem (i.e. HP) officially.
>>>>>> So, yes, and actually MORE need to be done (beyond your imagination).
>>>>>>
>>>>>> Knowing a car or smart phone,... is far different from making one.
>>>>>> Knowing E=mc^2 is far from knowing relativity, making A-bomb
>>>>>> (actually, making
>>>>>> A-bomb don't need to know E=mc^2, people are often fooled by
>>>>>> popular saying)
>>>>>>
>>>>>> Every chapter of Linz's book, C text textbook has exercises, you
>>>>>> need to those
>>>>>> exercises AT LEAST to comment CS (and computation theory is more
>>>>>> advanced topic
>>>>>> than TM). Saying so is because we know you can't do the exercise
>>>>>> and boast lots
>>>>>> about TM stuff (and pretty much anything else from just reading
>>>>>> words), even
>>>>>> about theorem.
>>>>>>
>>>>>
>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>> or
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>
>>>>> (a) Ĥ copies its input ⟨Ĥ⟩
>>>>> (b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>> (c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>
>>>>> All that I need to know is that I proved that
>>>>> embedded_H correctly recognizes the repeating
>>>>> pattern where its correctly simulated ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>> cannot possibly reach its own simulated final
>>>>> halt state of ⟨Ĥ.qn⟩
>>>>>
>>>>> https://www.liarparadox.org/Linz_Proof.pdf
>>>>>
>>>>>>> We only have to actually know one detail:
>>>>>>> Every counter-example input encoded in any model
>>>>>>> of computation always specifies recursive simulation
>>>>>>> that never halts to its corresponding simulating
>>>>>>> termination analyzer.
>>>>>>
>>>>>> More example here that you don't understand nearly all CS terms.
>>>>>>
>>>>>
>>>>> Mere empty rhetoric entirely bereft of any supporting
>>>>> reasoning. The x86 language is comparable to a RASP
>>>>> machine that is equivalent to a Turing machine.
>>>>
>>>> Question:
>>>> 1. Do you understand that you can't do the exercises in Linz's book?
>>>
>>> Everything is 100% irrelevant besides the fact that
>>> I have shown that ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by
>>> embedded_H cannot possibly reach its own simulated
>>> final halt state ⟨Ĥ.qn⟩.
>>
>> Which is irrelevant as from that you can't infer whether the input
>> specifies a halting computation.
>>
>
> That seems to show that you do not know that a halting
> computation is defined as reaching a final halt state.
> Stopping running for any other reason does not count as
> halting.
But computations can't "stop running" except by reaching a final state.
>
> Termination analyzers compute the mapping from their
> inputs to the behavior that these inputs actually specify.
> Clearly the input to embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ specifies recursive
> simulation that does not halt.
>
Right, and that behavior is the behavior of running the program
represented by their input.
And embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ can't specify a simuation that doesn't halt
unless H ⟨Ĥ⟩ ⟨Ĥ⟩ is also a program that doens't halt, as they are (at
least supposed to be) exactly the same code.
To say they act differently just proves that you are just a liar that
doesn't know what he is talking about.
Since you H has been stipulated to abort its simulation when it reaches
the state where it thinks the input is non-halting, it turns out that
embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ will also do the same, and go to qn and thus Ĥ ⟨Ĥ⟩
will halt, proving that H was just wrong.
Your arguements just prove you think lying is ok and that you don't
understand what you are talking about.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2025-05-11 16:25 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <5e43372d40e0c1fe84d4223ffa0354505628162c@i2pn2.org> |
| In reply to | #118489 |
On 5/11/25 11:38 AM, olcott wrote:
> On 5/11/2025 9:34 AM, wij wrote:
>> On Sat, 2025-05-10 at 21:19 -0500, olcott wrote:
>>> On 5/10/2025 9:09 PM, wij wrote:
>>>> On Sat, 2025-05-10 at 20:56 -0500, olcott wrote:
>>>>> On 5/10/2025 8:44 PM, wij wrote:
>>>>>> On Sat, 2025-05-10 at 20:26 -0500, olcott wrote:
>>>>>>> On 5/10/2025 8:17 PM, wij wrote:
>>>>>>>> On Sat, 2025-05-10 at 17:03 -0500, olcott wrote:
>>>>>>>>> On 5/10/2025 4:44 PM, wij wrote:
>>>>>>>>>> On Sat, 2025-05-10 at 14:29 -0500, olcott wrote:
>>>>>>>>>>> On 5/10/2025 2:02 PM, wij wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> You don't know the counter example in the HP proof, your D is
>>>>>>>> not the case what HP says.
>>>>>>>>
>>>>>>>
>>>>>>> Sure I do this is it! (as correctly encoded in C)
>>>>>>>
>>>>>>> typedef void (*ptr)();
>>>>>>> int HHH(ptr P);
>>>>>>>
>>>>>>> int DD()
>>>>>>> {
>>>>>>> int Halt_Status = HHH(DD);
>>>>>>> if (Halt_Status)
>>>>>>> HERE: goto HERE;
>>>>>>> return Halt_Status;
>>>>>>> }
>>>>>>>
>>>>>>> int main()
>>>>>>> {
>>>>>>> HHH(DD);
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Try to convert it to TM language to know you know nothing.
>>>>>>
>>>>>
>>>>> I spent 22 years on this. I started with the Linz text
>>>>>
>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>> or
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>
>>>>> (a) Ĥ copies its input ⟨Ĥ⟩
>>>>> (b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>> (c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ ...
>>>>>
>>>>> Thus ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by embedded_H
>>>>> cannot possibly reach its simulated final halt state
>>>>> ⟨Ĥ.qn⟩
>>>>>
>>>>>> To refute the HP, you need to understand what it exactly means in TM.
>>>>>
>>>>> I have known this for 22 years.
>>>>
>>>> A working TM. Build it explicitly from transition function, then
>>>> explain
>>>> your derivation. You know nothing.
>>>>
>>>
>>> That would be like examining how an operating system
>>> works entirely from its machine code.
>>
>> You are refuting a CS foundamental theorem (i.e. HP) officially.
>> So, yes, and actually MORE need to be done (beyond your imagination).
>>
>> Knowing a car or smart phone,... is far different from making one.
>> Knowing E=mc^2 is far from knowing relativity, making A-bomb
>> (actually, making
>> A-bomb don't need to know E=mc^2, people are often fooled by popular
>> saying)
>> Every chapter of Linz's book, C text textbook has exercises, you need
>> to those
>> exercises AT LEAST to comment CS (and computation theory is more
>> advanced topic
>> than TM). Saying so is because we know you can't do the exercise and
>> boast lots
>> about TM stuff (and pretty much anything else from just reading
>> words), even
>> about theorem.
>>
>
> When Ĥ is applied to ⟨Ĥ⟩
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
> or
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
> (a) Ĥ copies its input ⟨Ĥ⟩
> (b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
> (c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
>
> All that I need to know is that I proved that
> embedded_H correctly recognizes the repeating
> pattern where its correctly simulated ⟨Ĥ⟩ ⟨Ĥ⟩
> cannot possibly reach its own simulated final
> halt state of ⟨Ĥ.qn⟩
>
> https://www.liarparadox.org/Linz_Proof.pdf
But it doesn't because neither you H or embedded_H do a correct
simulation of their inputs, and the correct simulation of that input
will halt.
>
>>> We only have to actually know one detail:
>>> Every counter-example input encoded in any model
>>> of computation always specifies recursive simulation
>>> that never halts to its corresponding simulating
>>> termination analyzer.
>>
>> More example here that you don't understand nearly all CS terms.
>>
>
> Mere empty rhetoric entirely bereft of any supporting
> reasoning. The x86 language is comparable to a RASP
> machine that is equivalent to a Turing machine.
>
That is just you projecting your own arguements.
Yes, the x86 language CAN be comparable to a Turing Machine, but only
when everything the routine uses/affects are defined as the input and
output, and when ALL the code used is included in the algorithm.
That means your function DDD is NOT a Turing Machine Equivalent, since
you have defined it not to include the code of HHH which it uses, and
HHH is not because to do its emulation, it accesses memory locations
that are not part of the input.
Sorry, youa are just showing you don't actully know what you are talking
about.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben@bsb.me.uk> |
|---|---|
| Date | 2025-05-12 17:46 +0100 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <87cycdojyq.fsf@bsb.me.uk> |
| In reply to | #118434 |
wij <wyniijj5@gmail.com> writes: > On Sat, 2025-05-10 at 20:56 -0500, olcott wrote: >> On 5/10/2025 8:44 PM, wij wrote: ... >> > Try to convert it to TM language to know you know nothing. ... >> > To refute the HP, you need to understand what it exactly means in TM. >> >> I have known this for 22 years. > > A working TM. Build it explicitly from transition function, then explain > your derivation. You know nothing. He did, in 2018, claim to have exactly such a thing: "Everyone has claimed that H on input pair (Ĥ, Ĥ) meeting the Linz specs does not exist. I now have a fully encoded pair of Turing Machines H / Ĥ proving them wrong." "I [...] encoded all of the exact TMD instructions of the Linz Turing machine H that correctly decides halting for its fully encoded input pair: (Ĥ, Ĥ)." "I provide the exact ⊢* wildcard states after the Linz H.q0 and after Ĥ.qx (Linz incorrectly uses q0 twice) showing exactly how the actual Linz H would correctly decide the actual Linz (Ĥ, Ĥ)." Of course, no such "fully encoded Turing Machines" were ever produced. He spent months rowing back this claim, eventually settling on the notion that he was using "poetic licence" rather than admit he was wrong. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-12 12:23 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvtaq5$14pca$26@dont-email.me> |
| In reply to | #118708 |
On 5/12/2025 11:46 AM, Ben Bacarisse wrote:
> wij <wyniijj5@gmail.com> writes:
>
>> On Sat, 2025-05-10 at 20:56 -0500, olcott wrote:
>>> On 5/10/2025 8:44 PM, wij wrote:
> ...
>>>> Try to convert it to TM language to know you know nothing.
> ...
>>>> To refute the HP, you need to understand what it exactly means in TM.
>>>
>>> I have known this for 22 years.
>>
>> A working TM. Build it explicitly from transition function, then explain
>> your derivation. You know nothing.
>
> He did, in 2018, claim to have exactly such a thing:
>
> "Everyone has claimed that H on input pair (Ĥ, Ĥ) meeting the Linz
> specs does not exist. I now have a fully encoded pair of Turing
> Machines H / Ĥ proving them wrong."
>
> "I [...] encoded all of the exact TMD instructions of the Linz Turing
> machine H that correctly decides halting for its fully encoded input
> pair: (Ĥ, Ĥ)."
>
> "I provide the exact ⊢* wildcard states after the Linz H.q0 and after
> Ĥ.qx (Linz incorrectly uses q0 twice) showing exactly how the actual
> Linz H would correctly decide the actual Linz (Ĥ, Ĥ)."
>
> Of course, no such "fully encoded Turing Machines" were ever produced.
> He spent months rowing back this claim, eventually settling on the
> notion that he was using "poetic licence" rather than admit he was wrong.
>
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its
input D until H correctly determines that its simulated D
would never stop running unless aborted then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
On 10/17/2022 10:23 AM, Ben Bacarisse wrote:
> ...D(D) would not halt unless H stops the simulation.
> H /can/ correctly determine this silly criterion (in this one case)...
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2025-05-12 22:38 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <8fdac931ef3b717fd740dced158a2e54a2486748@i2pn2.org> |
| In reply to | #118721 |
On 5/12/25 1:23 PM, olcott wrote: > On 5/12/2025 11:46 AM, Ben Bacarisse wrote: >> wij <wyniijj5@gmail.com> writes: >> >>> On Sat, 2025-05-10 at 20:56 -0500, olcott wrote: >>>> On 5/10/2025 8:44 PM, wij wrote: >> ... >>>>> Try to convert it to TM language to know you know nothing. >> ... >>>>> To refute the HP, you need to understand what it exactly means in TM. >>>> >>>> I have known this for 22 years. >>> >>> A working TM. Build it explicitly from transition function, then explain >>> your derivation. You know nothing. >> >> He did, in 2018, claim to have exactly such a thing: >> >> "Everyone has claimed that H on input pair (Ĥ, Ĥ) meeting the Linz >> specs does not exist. I now have a fully encoded pair of Turing >> Machines H / Ĥ proving them wrong." >> >> "I [...] encoded all of the exact TMD instructions of the Linz Turing >> machine H that correctly decides halting for its fully encoded input >> pair: (Ĥ, Ĥ)." >> >> "I provide the exact ⊢* wildcard states after the Linz H.q0 and after >> Ĥ.qx (Linz incorrectly uses q0 twice) showing exactly how the actual >> Linz H would correctly decide the actual Linz (Ĥ, Ĥ)." >> >> Of course, no such "fully encoded Turing Machines" were ever produced. >> He spent months rowing back this claim, eventually settling on the >> notion that he was using "poetic licence" rather than admit he was wrong. >> > > <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> > If simulating halt decider H correctly simulates its > input D until H correctly determines that its simulated D > would never stop running unless aborted then > > H can abort its simulation of D and correctly report that D > specifies a non-halting sequence of configurations. > </MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> > > On 10/17/2022 10:23 AM, Ben Bacarisse wrote: > > ...D(D) would not halt unless H stops the simulation. > > H /can/ correctly determine this silly criterion (in this one case)... > > Which means the correct simulation of the exact input D that was given to H, which WILL use the algorithm of that H, so if H ultimately return non-halting, as you claim is correct, then the correct emulation (which isn't done by H) will show that, and thus H is wrong. Your problem is your "D" ends up not being the required program, and neither is your H. Thus, your whole argument is based on category errors and lies.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2025-05-12 23:11 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <onzUP.260254$jny7.144686@fx48.iad> |
| In reply to | #118721 |
On 5/12/25 1:23 PM, olcott wrote: > On 5/12/2025 11:46 AM, Ben Bacarisse wrote: >> wij <wyniijj5@gmail.com> writes: >> >>> On Sat, 2025-05-10 at 20:56 -0500, olcott wrote: >>>> On 5/10/2025 8:44 PM, wij wrote: >> ... >>>>> Try to convert it to TM language to know you know nothing. >> ... >>>>> To refute the HP, you need to understand what it exactly means in TM. >>>> >>>> I have known this for 22 years. >>> >>> A working TM. Build it explicitly from transition function, then explain >>> your derivation. You know nothing. >> >> He did, in 2018, claim to have exactly such a thing: >> >> "Everyone has claimed that H on input pair (Ĥ, Ĥ) meeting the Linz >> specs does not exist. I now have a fully encoded pair of Turing >> Machines H / Ĥ proving them wrong." >> >> "I [...] encoded all of the exact TMD instructions of the Linz Turing >> machine H that correctly decides halting for its fully encoded input >> pair: (Ĥ, Ĥ)." >> >> "I provide the exact ⊢* wildcard states after the Linz H.q0 and after >> Ĥ.qx (Linz incorrectly uses q0 twice) showing exactly how the actual >> Linz H would correctly decide the actual Linz (Ĥ, Ĥ)." >> >> Of course, no such "fully encoded Turing Machines" were ever produced. >> He spent months rowing back this claim, eventually settling on the >> notion that he was using "poetic licence" rather than admit he was wrong. >> > > <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> > If simulating halt decider H correctly simulates its > input D until H correctly determines that its simulated D > would never stop running unless aborted then > > H can abort its simulation of D and correctly report that D > specifies a non-halting sequence of configurations. > </MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> > > On 10/17/2022 10:23 AM, Ben Bacarisse wrote: > > ...D(D) would not halt unless H stops the simulation. > > H /can/ correctly determine this silly criterion (in this one case)... > > Which means the correct simulation of the exact input D that was given to H, which WILL use the algorithm of that H, so if H ultimately return non-halting, as you claim is correct, then the correct emulation (which isn't done by H) will show that, and thus H is wrong. Your problem is your "D" ends up not being the required program, and neither is your H. Thus, your whole argument is based on category errors and lies.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2025-05-10 22:12 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <7806f6800c722a6f0d396e11bcc8d651ffcb3344@i2pn2.org> |
| In reply to | #118431 |
On 5/10/25 9:56 PM, olcott wrote:
> On 5/10/2025 8:44 PM, wij wrote:
>> On Sat, 2025-05-10 at 20:26 -0500, olcott wrote:
>>> On 5/10/2025 8:17 PM, wij wrote:
>>>> On Sat, 2025-05-10 at 17:03 -0500, olcott wrote:
>>>>> On 5/10/2025 4:44 PM, wij wrote:
>>>>>> On Sat, 2025-05-10 at 14:29 -0500, olcott wrote:
>>>>>>> On 5/10/2025 2:02 PM, wij wrote:
>>>
>>>>
>>>> You don't know the counter example in the HP proof, your D is not
>>>> the case what HP says.
>>>>
>>>
>>> Sure I do this is it! (as correctly encoded in C)
>>>
>>> typedef void (*ptr)();
>>> int HHH(ptr P);
>>>
>>> int DD()
>>> {
>>> int Halt_Status = HHH(DD);
>>> if (Halt_Status)
>>> HERE: goto HERE;
>>> return Halt_Status;
>>> }
>>>
>>> int main()
>>> {
>>> HHH(DD);
>>> }
>>>
>>>
>>
>> Try to convert it to TM language to know you know nothing.
>>
>
> I spent 22 years on this. I started with the Linz text
You mean you have wasted 22 years on this.
>
> When Ĥ is applied to ⟨Ĥ⟩
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Missing the qualification, if Ĥ ⟨Ĥ⟩ will halt
> or
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
Missing the qualification, if Ĥ ⟨Ĥ⟩ will not halt
And those qualifications are based on H being correct.
>
> (a) Ĥ copies its input ⟨Ĥ⟩
> (b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
> (c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ ...
>
> Thus ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by embedded_H
> cannot possibly reach its simulated final halt state
> ⟨Ĥ.qn⟩
but step (c) will stop after some finite time when embedded_H does the
exact same process as H did when it reaches it conclusion (which it
follows exactly as it is exactly the same algorithm on the same data) at
which point it will stop and go to Qn and Ĥ ⟨Ĥ⟩ will halt, thus showing
that H returned the wrong answer for H ⟨Ĥ⟩ ⟨Ĥ⟩, as in this case, to be
correct H should have ended up in Qy instead of Qn.
>
>> To refute the HP, you need to understand what it exactly means in TM.
>
> I have known this for 22 years.
No, and you still don't as far as everything you have said.
You confuse where the requirements are, and even ignore and drop them
becuase of your ignorance.
You don't seem to understand that programs are deteministic entities
that will always do the same thing on the same input.
>
>> Assembly (or C) also work, but you need to understand more details and
>> be able to map every assembly instruction or C expressions to TM
>> language.
>> The form of the DD above (in some books maybe) is for layman to
>> understand,
>> which is not exactly the case that the HP provides. Don't be silly.
>>
>
>
>
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2025-05-10 21:54 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <cad089d86ff60b33d1927d237d793b51bce2e2d2@i2pn2.org> |
| In reply to | #118424 |
On 5/10/25 9:26 PM, olcott wrote:
> On 5/10/2025 8:17 PM, wij wrote:
>> On Sat, 2025-05-10 at 17:03 -0500, olcott wrote:
>>> On 5/10/2025 4:44 PM, wij wrote:
>>>> On Sat, 2025-05-10 at 14:29 -0500, olcott wrote:
>>>>> On 5/10/2025 2:02 PM, wij wrote:
>
>>
>> You don't know the counter example in the HP proof, your D is not the
>> case what HP says.
>>
>
> Sure I do this is it! (as correctly encoded in C)
>
> typedef void (*ptr)();
> int HHH(ptr P);
>
> int DD()
> {
> int Halt_Status = HHH(DD);
> if (Halt_Status)
> HERE: goto HERE;
> return Halt_Status;
> }
>
> int main()
> {
> HHH(DD);
> }
>
>
Nope.
The D in the HP proof includes a copy of the halt decider H as part of
its code.
It is a full program, not a non-leaf function as your D is.
You are just comitting a major category error, and then trying to
expliot it to make your proof.
When you fix that error, by realizing that all the code for HHH is part
of the program DDD, then each HHH in your set each get DIFFERENT inputs,
of this DD funciton paired with those different HHHs, and thus you can't
use the behavor of one to make claims of the behavior of a different one.
Sorry, you have been told of this many times, and your refusal to listen
has just made your error a reckless disregard for the truth, and thus is
a deliberate lie. It seems you are proving that either you just have no
care about what is the truth and thus are a pathological liar, or are
just too stupid to be able to learn the material, which is just another
form of pathology that comes out as the lying.
[toc] | [prev] | [next] | [standalone]
| From | joes <noreply@example.org> |
|---|---|
| Date | 2025-05-11 11:07 +0000 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <766e4a7e81e5c70c19b646874c52b62f22438811@i2pn2.org> |
| In reply to | #118405 |
Am Sat, 10 May 2025 17:03:26 -0500 schrieb olcott: > On 5/10/2025 4:44 PM, wij wrote: >> On Sat, 2025-05-10 at 14:29 -0500, olcott wrote: >>> On 5/10/2025 2:02 PM, wij wrote: >>>> On Sat, 2025-05-10 at 13:47 -0500, olcott wrote: >>>>> On 5/10/2025 1:37 PM, wij wrote: >>>>>> On Sat, 2025-05-10 at 13:17 -0500, olcott wrote: >>>>>>> On 5/10/2025 1:09 PM, wij wrote: >>>>>>>> On Sat, 2025-05-10 at 12:17 -0500, olcott wrote: >>>>>>>>> On 5/10/2025 12:01 PM, wij wrote: >>>>>>>>>> On Sat, 2025-05-10 at 11:47 -0500, olcott wrote: >>>>>>>>>>> On 5/10/2025 11:29 AM, wij wrote: >>>>>>>>>>>> On Sat, 2025-05-10 at 11:19 -0500, olcott wrote: >>>>>>>>>>>>> On 5/10/2025 11:06 AM, wij wrote: >>>>>>>>>>>>>> On Sat, 2025-05-10 at 10:45 -0500, olcott wrote: >>>>>>>>>>>>>>> On 5/10/2025 10:28 AM, wij wrote: >>>>>>>>>>>>>>>> On Sat, 2025-05-10 at 09:33 -0500, olcott wrote: >>>>>>>>>>>>>>>>> On 5/10/2025 7:37 AM, Bonita Montero wrote: >>>>>>>>>>>>>>>>>> Am 09.05.2025 um 04:22 schrieb olcott: >>>>>>>>>>>>>>>>> It correctly determines that the halting problem's >>>>>>>>>>>>>>>>> otherwise "impossible" input is actually non halting. ...which makes it halt. >>>>>>>>>>>>> The input that has baffled computer scientists for 90 years >>>>>>>>>>>>> is merely correctly determined to be non-halting when the >>>>>>>>>>>>> behavior of this input is measured by HHH emulating this >>>>>>>>>>>>> input according to the rules of the x86 language. Nobody is baffled. It halts. >>>>>>>>>> I have no problem with that. And, you said HHH merely rejects >>>>>>>>>> it as non-halting. You had denied HHH can decide the halting >>>>>>>>>> property of any input, except DDD/DD/D.. >>>>>>>>>> >>>>>>>>> As long as HHH correctly determines the halt status of a single >>>>>>>>> input that has no inputs then HHH is a correct termination >>>>>>>>> analyzer for that input. >>>>>>>> >>>>>>>> I have no problem with that, but be noticed that the HHH inside >>>>>>>> DD is not the 'HHH' that makes the final decision (otherwise, the >>>>>>>> 'HHH' >>>>>>>> will be an infinite recursive which cannot make any decision, >>>>>>>> which you had agreed) >>> The original set theory is now called naive set theory after its >>> mistake has been corrected. Thus the original halting problem proofs >>> can now be called the naive halting problem proofs. >> Traditional logic (or the part mostly used) that won't cause confusion >> is more reliable. The HP doesn't lead to contradictions. >>> The halting problem itself remains the same, yet loses its most >>> important proof. >> >> HP is based on TM. Proof of any other kind other than TM have to be >> cautious. > Unless this is done as an actual simulating termination analyzer in a > high level language like C and it operates on a 100% complete exactingly > precise input specification such as the x86 language too many details > slip through the cracks of vagueness. TMs are concrete. What details, what vagueness? > For example no one ever even noticed that it is 100% impossible to > derive an input that actually does the opposite of whatever value that > its termination analyzer reports. Wrong, DDD calls HHH, which returns "non-halting", *and halts*. -- 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 | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-11 11:37 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvqjnf$gldn$11@dont-email.me> |
| In reply to | #118460 |
On 5/11/2025 6:07 AM, joes wrote:
> Am Sat, 10 May 2025 17:03:26 -0500 schrieb olcott:
>> On 5/10/2025 4:44 PM, wij wrote:
>>> On Sat, 2025-05-10 at 14:29 -0500, olcott wrote:
>>>> On 5/10/2025 2:02 PM, wij wrote:
>>>>> On Sat, 2025-05-10 at 13:47 -0500, olcott wrote:
>>>>>> On 5/10/2025 1:37 PM, wij wrote:
>>>>>>> On Sat, 2025-05-10 at 13:17 -0500, olcott wrote:
>>>>>>>> On 5/10/2025 1:09 PM, wij wrote:
>>>>>>>>> On Sat, 2025-05-10 at 12:17 -0500, olcott wrote:
>>>>>>>>>> On 5/10/2025 12:01 PM, wij wrote:
>>>>>>>>>>> On Sat, 2025-05-10 at 11:47 -0500, olcott wrote:
>>>>>>>>>>>> On 5/10/2025 11:29 AM, wij wrote:
>>>>>>>>>>>>> On Sat, 2025-05-10 at 11:19 -0500, olcott wrote:
>>>>>>>>>>>>>> On 5/10/2025 11:06 AM, wij wrote:
>>>>>>>>>>>>>>> On Sat, 2025-05-10 at 10:45 -0500, olcott wrote:
>>>>>>>>>>>>>>>> On 5/10/2025 10:28 AM, wij wrote:
>>>>>>>>>>>>>>>>> On Sat, 2025-05-10 at 09:33 -0500, olcott wrote:
>>>>>>>>>>>>>>>>>> On 5/10/2025 7:37 AM, Bonita Montero wrote:
>>>>>>>>>>>>>>>>>>> Am 09.05.2025 um 04:22 schrieb olcott:
>
>>>>>>>>>>>>>>>>>> It correctly determines that the halting problem's
>>>>>>>>>>>>>>>>>> otherwise "impossible" input is actually non halting.
>
> ...which makes it halt.
>
>>>>>>>>>>>>>> The input that has baffled computer scientists for 90 years
>>>>>>>>>>>>>> is merely correctly determined to be non-halting when the
>>>>>>>>>>>>>> behavior of this input is measured by HHH emulating this
>>>>>>>>>>>>>> input according to the rules of the x86 language.
>
> Nobody is baffled. It halts.
>
>>>>>>>>>>> I have no problem with that. And, you said HHH merely rejects
>>>>>>>>>>> it as non-halting. You had denied HHH can decide the halting
>>>>>>>>>>> property of any input, except DDD/DD/D..
>>>>>>>>>>>
>>>>>>>>>> As long as HHH correctly determines the halt status of a single
>>>>>>>>>> input that has no inputs then HHH is a correct termination
>>>>>>>>>> analyzer for that input.
>>>>>>>>>
>>>>>>>>> I have no problem with that, but be noticed that the HHH inside
>>>>>>>>> DD is not the 'HHH' that makes the final decision (otherwise, the
>>>>>>>>> 'HHH'
>>>>>>>>> will be an infinite recursive which cannot make any decision,
>>>>>>>>> which you had agreed)
>
>>>> The original set theory is now called naive set theory after its
>>>> mistake has been corrected. Thus the original halting problem proofs
>>>> can now be called the naive halting problem proofs.
>>> Traditional logic (or the part mostly used) that won't cause confusion
>>> is more reliable.
>
> The HP doesn't lead to contradictions.
>
>>>> The halting problem itself remains the same, yet loses its most
>>>> important proof.
>>>
>>> HP is based on TM. Proof of any other kind other than TM have to be
>>> cautious.
>> Unless this is done as an actual simulating termination analyzer in a
>> high level language like C and it operates on a 100% complete exactingly
>> precise input specification such as the x86 language too many details
>> slip through the cracks of vagueness.
>
> TMs are concrete. What details, what vagueness?
>
There isn't even a common TM language.
If there was a TM language then examining
the details of a termination analyzer would
be like reverse engineering all of the details
of how an operating system works from its
machine code. Humans really need high level
abstractions or they get totally lost.
>> For example no one ever even noticed that it is 100% impossible to
>> derive an input that actually does the opposite of whatever value that
>> its termination analyzer reports.
> Wrong, DDD calls HHH, which returns "non-halting", *and halts*.
>
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
There is no possible way for DD emulated by HHH
according to the rules of the x86 language to
receive the return value from its call to HHH(DDD).
It has been this way for 90 years.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2025-05-11 16:36 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <f8d15f9ec3c4edd0dbc59f27b4c60c7d759d5a58@i2pn2.org> |
| In reply to | #118508 |
On 5/11/25 12:37 PM, olcott wrote:
> On 5/11/2025 6:07 AM, joes wrote:
>> Am Sat, 10 May 2025 17:03:26 -0500 schrieb olcott:
>>> On 5/10/2025 4:44 PM, wij wrote:
>>>> On Sat, 2025-05-10 at 14:29 -0500, olcott wrote:
>>>>> On 5/10/2025 2:02 PM, wij wrote:
>>>>>> On Sat, 2025-05-10 at 13:47 -0500, olcott wrote:
>>>>>>> On 5/10/2025 1:37 PM, wij wrote:
>>>>>>>> On Sat, 2025-05-10 at 13:17 -0500, olcott wrote:
>>>>>>>>> On 5/10/2025 1:09 PM, wij wrote:
>>>>>>>>>> On Sat, 2025-05-10 at 12:17 -0500, olcott wrote:
>>>>>>>>>>> On 5/10/2025 12:01 PM, wij wrote:
>>>>>>>>>>>> On Sat, 2025-05-10 at 11:47 -0500, olcott wrote:
>>>>>>>>>>>>> On 5/10/2025 11:29 AM, wij wrote:
>>>>>>>>>>>>>> On Sat, 2025-05-10 at 11:19 -0500, olcott wrote:
>>>>>>>>>>>>>>> On 5/10/2025 11:06 AM, wij wrote:
>>>>>>>>>>>>>>>> On Sat, 2025-05-10 at 10:45 -0500, olcott wrote:
>>>>>>>>>>>>>>>>> On 5/10/2025 10:28 AM, wij wrote:
>>>>>>>>>>>>>>>>>> On Sat, 2025-05-10 at 09:33 -0500, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 5/10/2025 7:37 AM, Bonita Montero wrote:
>>>>>>>>>>>>>>>>>>>> Am 09.05.2025 um 04:22 schrieb olcott:
>>
>>>>>>>>>>>>>>>>>>> It correctly determines that the halting problem's
>>>>>>>>>>>>>>>>>>> otherwise "impossible" input is actually non halting.
>>
>> ...which makes it halt.
>>
>>>>>>>>>>>>>>> The input that has baffled computer scientists for 90 years
>>>>>>>>>>>>>>> is merely correctly determined to be non-halting when the
>>>>>>>>>>>>>>> behavior of this input is measured by HHH emulating this
>>>>>>>>>>>>>>> input according to the rules of the x86 language.
>>
>> Nobody is baffled. It halts.
>>
>>>>>>>>>>>> I have no problem with that. And, you said HHH merely rejects
>>>>>>>>>>>> it as non-halting. You had denied HHH can decide the halting
>>>>>>>>>>>> property of any input, except DDD/DD/D..
>>>>>>>>>>>>
>>>>>>>>>>> As long as HHH correctly determines the halt status of a single
>>>>>>>>>>> input that has no inputs then HHH is a correct termination
>>>>>>>>>>> analyzer for that input.
>>>>>>>>>>
>>>>>>>>>> I have no problem with that, but be noticed that the HHH inside
>>>>>>>>>> DD is not the 'HHH' that makes the final decision (otherwise, the
>>>>>>>>>> 'HHH'
>>>>>>>>>> will be an infinite recursive which cannot make any decision,
>>>>>>>>>> which you had agreed)
>>
>>>>> The original set theory is now called naive set theory after its
>>>>> mistake has been corrected. Thus the original halting problem proofs
>>>>> can now be called the naive halting problem proofs.
>>>> Traditional logic (or the part mostly used) that won't cause confusion
>>>> is more reliable.
>>
>> The HP doesn't lead to contradictions.
>>
>>>>> The halting problem itself remains the same, yet loses its most
>>>>> important proof.
>>>>
>>>> HP is based on TM. Proof of any other kind other than TM have to be
>>>> cautious.
>>> Unless this is done as an actual simulating termination analyzer in a
>>> high level language like C and it operates on a 100% complete exactingly
>>> precise input specification such as the x86 language too many details
>>> slip through the cracks of vagueness.
>>
>> TMs are concrete. What details, what vagueness?
>>
>
> There isn't even a common TM language.
> If there was a TM language then examining
> the details of a termination analyzer would
> be like reverse engineering all of the details
> of how an operating system works from its
> machine code. Humans really need high level
> abstractions or they get totally lost.
There is a standardize version of the Turing Machine Language.
The fact the problem is too big for you to understand just shows that
you are just too stupid to understand it.
Note, Turing Machines CAN be described at a high level, just like the
OS. And just like understanding the OS with high level code needs an
understanding of the lower level code, understanding the high level
descriptions of Turing Machines needs an understanding of the basic
operaiton of a Turing Machine.
Since you couldn't handle a Turing Machine of only a few states, that is
about like not being able to understand an assembly function of just a
small number of instructions.
>
>>> For example no one ever even noticed that it is 100% impossible to
>>> derive an input that actually does the opposite of whatever value that
>>> its termination analyzer reports.
>> Wrong, DDD calls HHH, which returns "non-halting", *and halts*.
>>
>
> int DD()
> {
> int Halt_Status = HHH(DD);
> if (Halt_Status)
> HERE: goto HERE;
> return Halt_Status;
> }
>
> There is no possible way for DD emulated by HHH
> according to the rules of the x86 language to
> receive the return value from its call to HHH(DDD).
> It has been this way for 90 years.
>
First, if that is ALL the input, HHH can't emulate past the call
instruction and be a pure function.
If it isn't a pure function, then my static local hack lets it do the
emulation.
So, the input DD needs to be defined to include the code of HHH that it
calls as part of its definition, and for you system, that must be the
same as the decider.
Yes, with tha fix there is also no possible way for a HHH that emulates
its input by that rule to be a decider and give an answer.
Once you make your HHH give up to answer, it fails to meet your initial
requrement, and it is looking at a different input then the correctly
emulating HHH, so we can't use its answer, as it is a different input.
It turns out that the correct simulation of the input DD for a DD built
on an HHH that answer 0 for HHH(DD) will reach the final state, the fact
that the only partial emulation by HHH didn't do that is irrelevent, and
the fact that the DIFFERENT DD
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-11 16:13 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvr3uf$ks69$1@dont-email.me> |
| In reply to | #118563 |
On 5/11/2025 3:36 PM, Richard Damon wrote:
> On 5/11/25 12:37 PM, olcott wrote:
>> On 5/11/2025 6:07 AM, joes wrote:
>>> Am Sat, 10 May 2025 17:03:26 -0500 schrieb olcott:
>>>> On 5/10/2025 4:44 PM, wij wrote:
>>>>> On Sat, 2025-05-10 at 14:29 -0500, olcott wrote:
>>>>>> On 5/10/2025 2:02 PM, wij wrote:
>>>>>>> On Sat, 2025-05-10 at 13:47 -0500, olcott wrote:
>>>>>>>> On 5/10/2025 1:37 PM, wij wrote:
>>>>>>>>> On Sat, 2025-05-10 at 13:17 -0500, olcott wrote:
>>>>>>>>>> On 5/10/2025 1:09 PM, wij wrote:
>>>>>>>>>>> On Sat, 2025-05-10 at 12:17 -0500, olcott wrote:
>>>>>>>>>>>> On 5/10/2025 12:01 PM, wij wrote:
>>>>>>>>>>>>> On Sat, 2025-05-10 at 11:47 -0500, olcott wrote:
>>>>>>>>>>>>>> On 5/10/2025 11:29 AM, wij wrote:
>>>>>>>>>>>>>>> On Sat, 2025-05-10 at 11:19 -0500, olcott wrote:
>>>>>>>>>>>>>>>> On 5/10/2025 11:06 AM, wij wrote:
>>>>>>>>>>>>>>>>> On Sat, 2025-05-10 at 10:45 -0500, olcott wrote:
>>>>>>>>>>>>>>>>>> On 5/10/2025 10:28 AM, wij wrote:
>>>>>>>>>>>>>>>>>>> On Sat, 2025-05-10 at 09:33 -0500, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 5/10/2025 7:37 AM, Bonita Montero wrote:
>>>>>>>>>>>>>>>>>>>>> Am 09.05.2025 um 04:22 schrieb olcott:
>>>
>>>>>>>>>>>>>>>>>>>> It correctly determines that the halting problem's
>>>>>>>>>>>>>>>>>>>> otherwise "impossible" input is actually non halting.
>>>
>>> ...which makes it halt.
>>>
>>>>>>>>>>>>>>>> The input that has baffled computer scientists for 90 years
>>>>>>>>>>>>>>>> is merely correctly determined to be non-halting when the
>>>>>>>>>>>>>>>> behavior of this input is measured by HHH emulating this
>>>>>>>>>>>>>>>> input according to the rules of the x86 language.
>>>
>>> Nobody is baffled. It halts.
>>>
>>>>>>>>>>>>> I have no problem with that. And, you said HHH merely rejects
>>>>>>>>>>>>> it as non-halting. You had denied HHH can decide the halting
>>>>>>>>>>>>> property of any input, except DDD/DD/D..
>>>>>>>>>>>>>
>>>>>>>>>>>> As long as HHH correctly determines the halt status of a single
>>>>>>>>>>>> input that has no inputs then HHH is a correct termination
>>>>>>>>>>>> analyzer for that input.
>>>>>>>>>>>
>>>>>>>>>>> I have no problem with that, but be noticed that the HHH inside
>>>>>>>>>>> DD is not the 'HHH' that makes the final decision (otherwise,
>>>>>>>>>>> the
>>>>>>>>>>> 'HHH'
>>>>>>>>>>> will be an infinite recursive which cannot make any decision,
>>>>>>>>>>> which you had agreed)
>>>
>>>>>> The original set theory is now called naive set theory after its
>>>>>> mistake has been corrected. Thus the original halting problem proofs
>>>>>> can now be called the naive halting problem proofs.
>>>>> Traditional logic (or the part mostly used) that won't cause confusion
>>>>> is more reliable.
>>>
>>> The HP doesn't lead to contradictions.
>>>
>>>>>> The halting problem itself remains the same, yet loses its most
>>>>>> important proof.
>>>>>
>>>>> HP is based on TM. Proof of any other kind other than TM have to be
>>>>> cautious.
>>>> Unless this is done as an actual simulating termination analyzer in a
>>>> high level language like C and it operates on a 100% complete
>>>> exactingly
>>>> precise input specification such as the x86 language too many details
>>>> slip through the cracks of vagueness.
>>>
>>> TMs are concrete. What details, what vagueness?
>>>
>>
>> There isn't even a common TM language.
>> If there was a TM language then examining
>> the details of a termination analyzer would
>> be like reverse engineering all of the details
>> of how an operating system works from its
>> machine code. Humans really need high level
>> abstractions or they get totally lost.
>
> There is a standardize version of the Turing Machine Language.
>
> The fact the problem is too big for you to understand just shows that
> you are just too stupid to understand it.
>
> Note, Turing Machines CAN be described at a high level, just like the
> OS. And just like understanding the OS with high level code needs an
> understanding of the lower level code, understanding the high level
> descriptions of Turing Machines needs an understanding of the basic
> operaiton of a Turing Machine.
>
> Since you couldn't handle a Turing Machine of only a few states, that is
> about like not being able to understand an assembly function of just a
> small number of instructions.
>
>>
>>>> For example no one ever even noticed that it is 100% impossible to
>>>> derive an input that actually does the opposite of whatever value that
>>>> its termination analyzer reports.
>>> Wrong, DDD calls HHH, which returns "non-halting", *and halts*.
>>>
>>
>> int DD()
>> {
>> int Halt_Status = HHH(DD);
>> if (Halt_Status)
>> HERE: goto HERE;
>> return Halt_Status;
>> }
>>
>> There is no possible way for DD emulated by HHH
>> according to the rules of the x86 language to
>> receive the return value from its call to HHH(DDD).
>> It has been this way for 90 years.
>>
>
>
> First, if that is ALL the input, HHH can't emulate past the call
> instruction and be a pure function.
>
Sure it can.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2025-05-11 19:36 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <954ba778c765e388e79f76c8c66bc0f95d176b7a@i2pn2.org> |
| In reply to | #118566 |
On 5/11/25 5:13 PM, olcott wrote:
> On 5/11/2025 3:36 PM, Richard Damon wrote:
>> On 5/11/25 12:37 PM, olcott wrote:
>>> On 5/11/2025 6:07 AM, joes wrote:
>>>> Am Sat, 10 May 2025 17:03:26 -0500 schrieb olcott:
>>>>> On 5/10/2025 4:44 PM, wij wrote:
>>>>>> On Sat, 2025-05-10 at 14:29 -0500, olcott wrote:
>>>>>>> On 5/10/2025 2:02 PM, wij wrote:
>>>>>>>> On Sat, 2025-05-10 at 13:47 -0500, olcott wrote:
>>>>>>>>> On 5/10/2025 1:37 PM, wij wrote:
>>>>>>>>>> On Sat, 2025-05-10 at 13:17 -0500, olcott wrote:
>>>>>>>>>>> On 5/10/2025 1:09 PM, wij wrote:
>>>>>>>>>>>> On Sat, 2025-05-10 at 12:17 -0500, olcott wrote:
>>>>>>>>>>>>> On 5/10/2025 12:01 PM, wij wrote:
>>>>>>>>>>>>>> On Sat, 2025-05-10 at 11:47 -0500, olcott wrote:
>>>>>>>>>>>>>>> On 5/10/2025 11:29 AM, wij wrote:
>>>>>>>>>>>>>>>> On Sat, 2025-05-10 at 11:19 -0500, olcott wrote:
>>>>>>>>>>>>>>>>> On 5/10/2025 11:06 AM, wij wrote:
>>>>>>>>>>>>>>>>>> On Sat, 2025-05-10 at 10:45 -0500, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 5/10/2025 10:28 AM, wij wrote:
>>>>>>>>>>>>>>>>>>>> On Sat, 2025-05-10 at 09:33 -0500, olcott wrote:
>>>>>>>>>>>>>>>>>>>>> On 5/10/2025 7:37 AM, Bonita Montero wrote:
>>>>>>>>>>>>>>>>>>>>>> Am 09.05.2025 um 04:22 schrieb olcott:
>>>>
>>>>>>>>>>>>>>>>>>>>> It correctly determines that the halting problem's
>>>>>>>>>>>>>>>>>>>>> otherwise "impossible" input is actually non halting.
>>>>
>>>> ...which makes it halt.
>>>>
>>>>>>>>>>>>>>>>> The input that has baffled computer scientists for 90
>>>>>>>>>>>>>>>>> years
>>>>>>>>>>>>>>>>> is merely correctly determined to be non-halting when the
>>>>>>>>>>>>>>>>> behavior of this input is measured by HHH emulating this
>>>>>>>>>>>>>>>>> input according to the rules of the x86 language.
>>>>
>>>> Nobody is baffled. It halts.
>>>>
>>>>>>>>>>>>>> I have no problem with that. And, you said HHH merely rejects
>>>>>>>>>>>>>> it as non-halting. You had denied HHH can decide the halting
>>>>>>>>>>>>>> property of any input, except DDD/DD/D..
>>>>>>>>>>>>>>
>>>>>>>>>>>>> As long as HHH correctly determines the halt status of a
>>>>>>>>>>>>> single
>>>>>>>>>>>>> input that has no inputs then HHH is a correct termination
>>>>>>>>>>>>> analyzer for that input.
>>>>>>>>>>>>
>>>>>>>>>>>> I have no problem with that, but be noticed that the HHH inside
>>>>>>>>>>>> DD is not the 'HHH' that makes the final decision
>>>>>>>>>>>> (otherwise, the
>>>>>>>>>>>> 'HHH'
>>>>>>>>>>>> will be an infinite recursive which cannot make any decision,
>>>>>>>>>>>> which you had agreed)
>>>>
>>>>>>> The original set theory is now called naive set theory after its
>>>>>>> mistake has been corrected. Thus the original halting problem proofs
>>>>>>> can now be called the naive halting problem proofs.
>>>>>> Traditional logic (or the part mostly used) that won't cause
>>>>>> confusion
>>>>>> is more reliable.
>>>>
>>>> The HP doesn't lead to contradictions.
>>>>
>>>>>>> The halting problem itself remains the same, yet loses its most
>>>>>>> important proof.
>>>>>>
>>>>>> HP is based on TM. Proof of any other kind other than TM have to be
>>>>>> cautious.
>>>>> Unless this is done as an actual simulating termination analyzer in a
>>>>> high level language like C and it operates on a 100% complete
>>>>> exactingly
>>>>> precise input specification such as the x86 language too many details
>>>>> slip through the cracks of vagueness.
>>>>
>>>> TMs are concrete. What details, what vagueness?
>>>>
>>>
>>> There isn't even a common TM language.
>>> If there was a TM language then examining
>>> the details of a termination analyzer would
>>> be like reverse engineering all of the details
>>> of how an operating system works from its
>>> machine code. Humans really need high level
>>> abstractions or they get totally lost.
>>
>> There is a standardize version of the Turing Machine Language.
>>
>> The fact the problem is too big for you to understand just shows that
>> you are just too stupid to understand it.
>>
>> Note, Turing Machines CAN be described at a high level, just like the
>> OS. And just like understanding the OS with high level code needs an
>> understanding of the lower level code, understanding the high level
>> descriptions of Turing Machines needs an understanding of the basic
>> operaiton of a Turing Machine.
>>
>> Since you couldn't handle a Turing Machine of only a few states, that
>> is about like not being able to understand an assembly function of
>> just a small number of instructions.
>>
>>>
>>>>> For example no one ever even noticed that it is 100% impossible to
>>>>> derive an input that actually does the opposite of whatever value that
>>>>> its termination analyzer reports.
>>>> Wrong, DDD calls HHH, which returns "non-halting", *and halts*.
>>>>
>>>
>>> int DD()
>>> {
>>> int Halt_Status = HHH(DD);
>>> if (Halt_Status)
>>> HERE: goto HERE;
>>> return Halt_Status;
>>> }
>>>
>>> There is no possible way for DD emulated by HHH
>>> according to the rules of the x86 language to
>>> receive the return value from its call to HHH(DDD).
>>> It has been this way for 90 years.
>>>
>>
>>
>> First, if that is ALL the input, HHH can't emulate past the call
>> instruction and be a pure function.
>>
>
> Sure it can.
>
How? By breaking its requirements to be a pure function?
I guess you are just admitting you are just a stupid liar that doesn't
know the meaning of the words he is using.
Your "proof" is now lying at the bottom of that lake of fire reserved
for liars as that is what it has been proven to be, just a pile of lies,
and you will be joining it there soon.
[toc] | [prev] | [next] | [standalone]
| From | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2025-05-13 13:20 +0200 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvv9uq$1ov7e$5@dont-email.me> |
| In reply to | #118508 |
Op 11.mei.2025 om 18:37 schreef olcott:
> On 5/11/2025 6:07 AM, joes wrote:
>> Am Sat, 10 May 2025 17:03:26 -0500 schrieb olcott:
>>> On 5/10/2025 4:44 PM, wij wrote:
>>>> On Sat, 2025-05-10 at 14:29 -0500, olcott wrote:
>>>>> On 5/10/2025 2:02 PM, wij wrote:
>>>>>> On Sat, 2025-05-10 at 13:47 -0500, olcott wrote:
>>>>>>> On 5/10/2025 1:37 PM, wij wrote:
>>>>>>>> On Sat, 2025-05-10 at 13:17 -0500, olcott wrote:
>>>>>>>>> On 5/10/2025 1:09 PM, wij wrote:
>>>>>>>>>> On Sat, 2025-05-10 at 12:17 -0500, olcott wrote:
>>>>>>>>>>> On 5/10/2025 12:01 PM, wij wrote:
>>>>>>>>>>>> On Sat, 2025-05-10 at 11:47 -0500, olcott wrote:
>>>>>>>>>>>>> On 5/10/2025 11:29 AM, wij wrote:
>>>>>>>>>>>>>> On Sat, 2025-05-10 at 11:19 -0500, olcott wrote:
>>>>>>>>>>>>>>> On 5/10/2025 11:06 AM, wij wrote:
>>>>>>>>>>>>>>>> On Sat, 2025-05-10 at 10:45 -0500, olcott wrote:
>>>>>>>>>>>>>>>>> On 5/10/2025 10:28 AM, wij wrote:
>>>>>>>>>>>>>>>>>> On Sat, 2025-05-10 at 09:33 -0500, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 5/10/2025 7:37 AM, Bonita Montero wrote:
>>>>>>>>>>>>>>>>>>>> Am 09.05.2025 um 04:22 schrieb olcott:
>>
>>>>>>>>>>>>>>>>>>> It correctly determines that the halting problem's
>>>>>>>>>>>>>>>>>>> otherwise "impossible" input is actually non halting.
>>
>> ...which makes it halt.
>>
>>>>>>>>>>>>>>> The input that has baffled computer scientists for 90 years
>>>>>>>>>>>>>>> is merely correctly determined to be non-halting when the
>>>>>>>>>>>>>>> behavior of this input is measured by HHH emulating this
>>>>>>>>>>>>>>> input according to the rules of the x86 language.
>>
>> Nobody is baffled. It halts.
>>
>>>>>>>>>>>> I have no problem with that. And, you said HHH merely rejects
>>>>>>>>>>>> it as non-halting. You had denied HHH can decide the halting
>>>>>>>>>>>> property of any input, except DDD/DD/D..
>>>>>>>>>>>>
>>>>>>>>>>> As long as HHH correctly determines the halt status of a single
>>>>>>>>>>> input that has no inputs then HHH is a correct termination
>>>>>>>>>>> analyzer for that input.
>>>>>>>>>>
>>>>>>>>>> I have no problem with that, but be noticed that the HHH inside
>>>>>>>>>> DD is not the 'HHH' that makes the final decision (otherwise, the
>>>>>>>>>> 'HHH'
>>>>>>>>>> will be an infinite recursive which cannot make any decision,
>>>>>>>>>> which you had agreed)
>>
>>>>> The original set theory is now called naive set theory after its
>>>>> mistake has been corrected. Thus the original halting problem proofs
>>>>> can now be called the naive halting problem proofs.
>>>> Traditional logic (or the part mostly used) that won't cause confusion
>>>> is more reliable.
>>
>> The HP doesn't lead to contradictions.
>>
>>>>> The halting problem itself remains the same, yet loses its most
>>>>> important proof.
>>>>
>>>> HP is based on TM. Proof of any other kind other than TM have to be
>>>> cautious.
>>> Unless this is done as an actual simulating termination analyzer in a
>>> high level language like C and it operates on a 100% complete exactingly
>>> precise input specification such as the x86 language too many details
>>> slip through the cracks of vagueness.
>>
>> TMs are concrete. What details, what vagueness?
>>
>
> There isn't even a common TM language.
> If there was a TM language then examining
> the details of a termination analyzer would
> be like reverse engineering all of the details
> of how an operating system works from its
> machine code. Humans really need high level
> abstractions or they get totally lost.
>
>>> For example no one ever even noticed that it is 100% impossible to
>>> derive an input that actually does the opposite of whatever value that
>>> its termination analyzer reports.
>> Wrong, DDD calls HHH, which returns "non-halting", *and halts*.
>>
>
> int DD()
> {
> int Halt_Status = HHH(DD);
> if (Halt_Status)
> HERE: goto HERE;
> return Halt_Status;
> }
>
> There is no possible way for DD emulated by HHH
> according to the rules of the x86 language to
> receive the return value from its call to HHH(DDD).
> It has been this way for 90 years.
>
And we all expected this failure of HHH. It is a big support for the
halting theorem.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2025-05-10 18:52 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <7c66a261a4cb446e6f8d278fe98f64681e4d7810@i2pn2.org> |
| In reply to | #118388 |
On 5/10/25 3:29 PM, olcott wrote:
> On 5/10/2025 2:02 PM, wij wrote:
>> On Sat, 2025-05-10 at 13:47 -0500, olcott wrote:
>>> On 5/10/2025 1:37 PM, wij wrote:
>>>> On Sat, 2025-05-10 at 13:17 -0500, olcott wrote:
>>>>> On 5/10/2025 1:09 PM, wij wrote:
>>>>>> On Sat, 2025-05-10 at 12:17 -0500, olcott wrote:
>>>>>>> On 5/10/2025 12:01 PM, wij wrote:
>>>>>>>> On Sat, 2025-05-10 at 11:47 -0500, olcott wrote:
>>>>>>>>> On 5/10/2025 11:29 AM, wij wrote:
>>>>>>>>>> On Sat, 2025-05-10 at 11:19 -0500, olcott wrote:
>>>>>>>>>>> On 5/10/2025 11:06 AM, wij wrote:
>>>>>>>>>>>> On Sat, 2025-05-10 at 10:45 -0500, olcott wrote:
>>>>>>>>>>>>> On 5/10/2025 10:28 AM, wij wrote:
>>>>>>>>>>>>>> On Sat, 2025-05-10 at 09:33 -0500, olcott wrote:
>>>>>>>>>>>>>>> On 5/10/2025 7:37 AM, Bonita Montero wrote:
>>>>>>>>>>>>>>>> Am 09.05.2025 um 04:22 schrieb olcott:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Look at their replies to this post.
>>>>>>>>>>>>>>>>> Not a one of them will agree that
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> void DDD()
>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>> HHH(DDD);
>>>>>>>>>>>>>>>>> return; // final halt state
>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> When 1 or more instructions of DDD are correctly
>>>>>>>>>>>>>>>>> simulated by HHH then the correctly simulated DDD cannot
>>>>>>>>>>>>>>>>> possibly reach its "return" instruction (final halt
>>>>>>>>>>>>>>>>> state).
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> They have consistently disagreed with this
>>>>>>>>>>>>>>>>> simple point for three years.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I guess that not even a professor of theoretical computer
>>>>>>>>>>>>>>>> science would spend years working on so few lines of code.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I created a whole x86utm operating system.
>>>>>>>>>>>>>>> It correctly determines that the halting problem's
>>>>>>>>>>>>>>> otherwise "impossible" input is actually non halting.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> int DD()
>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>> int Halt_Status = HHH(DD);
>>>>>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>> return Halt_Status;
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> https://github.com/plolcott/x86utm
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Nope.
>>>>>>>>>>>>>> From I know HHH(DD) decides whether the input DD is
>>>>>>>>>>>>>> "impossible" input
>>>>>>>>>>>>>> or
>>>>>>>>>>>>>> not.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> DD has the standard form of the "impossible" input.
>>>>>>>>>>>>> HHH merely rejects it as non-halting.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> You said 'merely' rejects it as non-halting.
>>>>>>>>>>>> So, POOH do not answer the input of any other function?
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The input that has baffled computer scientists for 90
>>>>>>>>>>> years is merely correctly determined to be non-halting
>>>>>>>>>>> when the behavior of this input is measured by HHH
>>>>>>>>>>> emulating this input according to the rules of the x86
>>>>>>>>>>> language.
>>>>>>>>>>>
>>>>>>>>>>> The same thing applies to the Linz proof yet cannot
>>>>>>>>>>> be understood until after HHH(DDD) and HHH(DD) are
>>>>>>>>>>> fully understood.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> HHH(DDD) (whatever) at most says DDD is a pathological/
>>>>>>>>>> midtaken input.
>>>>>>>>>> Others of what you say are your imagine and wishes, so far so
>>>>>>>>>> true.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> DDD emulated by HHH accor not the 'HHH' that makes the final
>>>>>>>>> decision
>>>>>> (otherwise, it will be an infinite recursive call which you agreed)
>>>>>>
>>>>>>>>> ding to the rules of
>>>>>>>>> the x86 language specifies recursive emulation
>>>>>>>>> that cannot possibly reach the final halt state
>>>>>>>>> of DDD.
>>>>>>>>>
>>>>>>>>
>>>>>>>> I have no problem with that. And, you said HHH merely rejects it
>>>>>>>> as non-halting.
>>>>>>>> You had denied HHH can decide the halting property of any input,
>>>>>>>> except DDD/DD/D..
>>>>>>>>
>>>>>>>
>>>>>>> As long as HHH correctly determines the halt status
>>>>>>> of a single input that has no inputs then HHH is
>>>>>>> a correct termination analyzer for that input.
>>>>>>
>>>>>> Go it, that is a stronger statement that HHH ONLY decides DD.
>>>>>> I have no problem with that, but be noticed that the HHH inside DD
>>>>>> is not the 'HHH' that makes the final decision (otherwise, the 'HHH'
>>>>>> will be an infinite recursive which cannot make any decision, which
>>>>>> you had agreed)
>>>>>>
>>>>>
>>>>> HHH(DD) correctly determines that its input specifies
>>>>> recursive emulation when this input is emulated by HHH
>>>>> HHH according to the rules of the x86 language.
>>>>
>>>> From the about, so you are talking about 'the HHH' which does not
>>>> compute the final decision.
>>>>
>>>
>>> HHH does recognize the recursive emulation pattern
>>> of DDD emulated by HHH according to the rules of
>>> the x86 language.
>>>
>>>>> *Thus exactly meets the following specification*
>>>>> <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>>>> If simulating halt decider H correctly simulates its
>>>>> input D until H correctly determines that its simulated D
>>>>> would never stop running unless aborted then
>>>>>
>>>>> H can abort its simulation of D and correctly report that D
>>>>
>>>> This H won't be the same HHH inside the DD, otherwise an infinite
>>>> recursive call happens.
>>>>
>>>
>>> It must always be the outermost HHH that does this
>>> because it has seen one entire recursive emulation
>>> more than the next inner HHH.
>>
>> No problem. H is not HHH.
>>
>
> The H is the template that Professor Sipser agreed to.
> HHH is a specific implementation of H.
>
>> This is also a pitty no one here understand POOH can help AI industry
>> and mankind, even so mini.
>>
>
> It is the same halting problem after its mistake
> has been corrected. So just like how ZFC corrected
> the error in set theory so that Russell's Paradox
> could be correctly decided, HHH corrects the error
> in the halting problem proof so that the otherwise
> impossible input is correctly decided.
What "Mistake"?
I guess you are just ADMITTING that your logic is based on the fallacy
of the strawman.
Note ZFC created a NEW set theory that the community adopted as the
standard. THEY DID NOT THEMSELVES MAKE IT THE STANDARD. It was presented
before many conferences and had several stages of development to get to
what we now use.
If you want to, you can work on FULLY DEFINING what you new theory of
programming is, and maybe with 10-20 years of work can have papers that
actualy describe it and what it can do, *IF* you are smart enough to do
that. And then you can present them to conferences, and take questions,
and try to defend your ideas .
And even if you do, you haven't "refuted" the Halting Problem, only
tried to make system where that theorem might not hold.
>
> The original set theory is now called naive set
> theory after its mistake has been corrected. Thus
> the original halting problem proofs can now be
> called the naive halting problem proofs.
Right, and the renaming was done by the community.
>
> The halting problem itself remains the same, yet
> loses its most important proof.
But only if you can define you system well enough, and show it to be
usefull enough, for the community to accept it as the "default" theory
of computation.
Since it seems you concept is that the actual behavior of a program when
run is not the defining characteristic of the program, which is what
most people are actually interested in, this may be a hard sell.
There are also a large number of inconsistancies that have been pointed
out in your system that you have yet to answer. These WILL need to be
eventually dealt with when you get to trying to actually define your system.
And, until you do, and get the general community to accept yours as the
default, you need to indicate you are talking in your private system
rather than the default. I suggest the name Peter Olcotts Other
Programing System, or POOPS for short (sort of like ZFC)
>
>>>>> specifies a non-halting sequence of configurations.
>>>>> </MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>>>>
>>>>> Professor Sipser is the best selling author of theory of
>>>>> computation textbooks.
>>>>> It is a pity that he could never take the five more minutes
>>>>> required to understand the notion of recursive emulation and
>>>>> thus see the significance of my work.
>>>>
>>>> You can cite any one, I don't know who Sipsper is.
>>>> But yes, it is also a pity that Socrites and Turing did not know POOH.
>>>>
>>>
>>> https://www.amazon.com/Introduction-Theory-Computation-Michael-
>>> Sipser/dp/113318779X
>>>
>>
>>
>
>
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2025-05-10 15:32 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <6bd4738e257fbb1b00f329b758578a3c82bdf91c@i2pn2.org> |
| In reply to | #118371 |
On 5/10/25 2:47 PM, olcott wrote:
> On 5/10/2025 1:37 PM, wij wrote:
>> On Sat, 2025-05-10 at 13:17 -0500, olcott wrote:
>>> On 5/10/2025 1:09 PM, wij wrote:
>>>> On Sat, 2025-05-10 at 12:17 -0500, olcott wrote:
>>>>> On 5/10/2025 12:01 PM, wij wrote:
>>>>>> On Sat, 2025-05-10 at 11:47 -0500, olcott wrote:
>>>>>>> On 5/10/2025 11:29 AM, wij wrote:
>>>>>>>> On Sat, 2025-05-10 at 11:19 -0500, olcott wrote:
>>>>>>>>> On 5/10/2025 11:06 AM, wij wrote:
>>>>>>>>>> On Sat, 2025-05-10 at 10:45 -0500, olcott wrote:
>>>>>>>>>>> On 5/10/2025 10:28 AM, wij wrote:
>>>>>>>>>>>> On Sat, 2025-05-10 at 09:33 -0500, olcott wrote:
>>>>>>>>>>>>> On 5/10/2025 7:37 AM, Bonita Montero wrote:
>>>>>>>>>>>>>> Am 09.05.2025 um 04:22 schrieb olcott:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Look at their replies to this post.
>>>>>>>>>>>>>>> Not a one of them will agree that
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> void DDD()
>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>> HHH(DDD);
>>>>>>>>>>>>>>> return; // final halt state
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> When 1 or more instructions of DDD are correctly
>>>>>>>>>>>>>>> simulated by HHH then the correctly simulated DDD cannot
>>>>>>>>>>>>>>> possibly reach its "return" instruction (final halt state).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> They have consistently disagreed with this
>>>>>>>>>>>>>>> simple point for three years.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I guess that not even a professor of theoretical computer
>>>>>>>>>>>>>> science would spend years working on so few lines of code.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I created a whole x86utm operating system.
>>>>>>>>>>>>> It correctly determines that the halting problem's
>>>>>>>>>>>>> otherwise "impossible" input is actually non halting.
>>>>>>>>>>>>>
>>>>>>>>>>>>> int DD()
>>>>>>>>>>>>> {
>>>>>>>>>>>>> int Halt_Status = HHH(DD);
>>>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>> return Halt_Status;
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> https://github.com/plolcott/x86utm
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Nope.
>>>>>>>>>>>> From I know HHH(DD) decides whether the input DD is
>>>>>>>>>>>> "impossible" input or
>>>>>>>>>>>> not.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> DD has the standard form of the "impossible" input.
>>>>>>>>>>> HHH merely rejects it as non-halting.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> You said 'merely' rejects it as non-halting.
>>>>>>>>>> So, POOH do not answer the input of any other function?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The input that has baffled computer scientists for 90
>>>>>>>>> years is merely correctly determined to be non-halting
>>>>>>>>> when the behavior of this input is measured by HHH
>>>>>>>>> emulating this input according to the rules of the x86
>>>>>>>>> language.
>>>>>>>>>
>>>>>>>>> The same thing applies to the Linz proof yet cannot
>>>>>>>>> be understood until after HHH(DDD) and HHH(DD) are
>>>>>>>>> fully understood.
>>>>>>>>>
>>>>>>>>
>>>>>>>> HHH(DDD) (whatever) at most says DDD is a pathological/midtaken
>>>>>>>> input.
>>>>>>>> Others of what you say are your imagine and wishes, so far so true.
>>>>>>>>
>>>>>>>
>>>>>>> DDD emulated by HHH accor not the 'HHH' that makes the final
>>>>>>> decision
>>>> (otherwise, it will be an infinite recursive call which you agreed)
>>>>
>>>>>>> ding to the rules of
>>>>>>> the x86 language specifies recursive emulation
>>>>>>> that cannot possibly reach the final halt state
>>>>>>> of DDD.
>>>>>>>
>>>>>>
>>>>>> I have no problem with that. And, you said HHH merely rejects it
>>>>>> as non-halting.
>>>>>> You had denied HHH can decide the halting property of any input,
>>>>>> except DDD/DD/D..
>>>>>>
>>>>>
>>>>> As long as HHH correctly determines the halt status
>>>>> of a single input that has no inputs then HHH is
>>>>> a correct termination analyzer for that input.
>>>>
>>>> Go it, that is a stronger statement that HHH ONLY decides DD.
>>>> I have no problem with that, but be noticed that the HHH inside DD
>>>> is not the 'HHH' that makes the final decision (otherwise, the 'HHH'
>>>> will be an infinite recursive which cannot make any decision, which
>>>> you had agreed)
>>>>
>>>
>>> HHH(DD) correctly determines that its input specifies
>>> recursive emulation when this input is emulated by HHH
>>> HHH according to the rules of the x86 language.
>>
>> From the about, so you are talking about 'the HHH' which does not
>> compute the final decision.
>>
>
> HHH does recognize the recursive emulation pattern
> of DDD emulated by HHH according to the rules of
> the x86 language.
But it isn't an infinitely recursion, as shown by the correct emulation
of DDD by the rules of the x86 langauge, which HHH doesn't do.
Your problem is that you seem to ignore that you need to talk about just
a single implementation at a time. If HHH gives an answer, because it
"recoginzed" that pattern, the pattern isn't there because your pattern
is only true *IF* HHH actually does a correct emuation by the rules of
the x86 language.
I guess you agree to the logic that
If Peter Olcott is an idiot, then Peter Olcott is an idiot.
Therefore
Peter Olcott is an idiot.
>
>>> *Thus exactly meets the following specification*
>>> <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>> If simulating halt decider H correctly simulates its
>>> input D until H correctly determines that its simulated D
>>> would never stop running unless aborted then
>>>
>>> H can abort its simulation of D and correctly report that D
>>
>> This H won't be the same HHH inside the DD, otherwise an infinite
>> recursive call happens.
>>
>
> It must always be the outermost HHH that does this
> because it has seen one entire recursive emulation
> more than the next inner HHH.
But the CORRECT emulation of ALL the layer will be exactly the same, and
show that DDD is halting, and NOT infinitely recursive.
>
>>> specifies a non-halting sequence of configurations.
>>> </MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>>
>>> Professor Sipser is the best selling author of theory of
>>> computation textbooks.
>>> It is a pity that he could never take the five more minutes
>>> required to understand the notion of recursive emulation and
>>> thus see the significance of my work.
>>
>> You can cite any one, I don't know who Sipsper is.
>> But yes, it is also a pity that Socrites and Turing did not know POOH.
>>
>
> https://www.amazon.com/Introduction-Theory-Computation-Michael-Sipser/
> dp/113318779X
>
Which it is clear you don't understand.
[toc] | [prev] | [next] | [standalone]
Page 17 of 32 — ← Prev page 1 … 15 16 [17] 18 19 … 32 Next page →
Back to top | Article view | comp.theory
csiph-web