Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.theory > #106095 > unrolled thread
| Started by | immibis <news@immibis.com> |
|---|---|
| First post | 2024-06-03 02:16 +0200 |
| Last post | 2024-06-03 13:38 +0300 |
| Articles | 20 on this page of 332 — 14 participants |
Back to article view | Back to comp.theory
Why does Olcott care about simulation, anyway? immibis <news@immibis.com> - 2024-06-03 02:16 +0200
Re: Why does Olcott care about simulation, anyway? Richard Damon <richard@damon-family.org> - 2024-06-02 20:34 -0400
Re: Why does Olcott care about simulation, anyway? Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2024-06-03 04:28 +0100
Re: Why does Olcott care about simulation, anyway? --- Mikes Review olcott <polcott333@gmail.com> - 2024-06-02 22:50 -0500
Re: Why does Olcott care about simulation, anyway? --- Mikes Review Richard Damon <richard@damon-family.org> - 2024-06-03 07:14 -0400
Re: Why does Olcott care about simulation, anyway? --- Mikes Review immibis <news@immibis.com> - 2024-06-03 15:36 +0200
Re: Why does Olcott care about simulation, anyway? --- Mikes Review Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2024-06-03 17:25 +0100
Re: Why does Olcott care about simulation, anyway? --- Mikes Review olcott <polcott333@gmail.com> - 2024-06-03 12:54 -0500
Re: Why does Olcott care about simulation, anyway? --- Mikes Review Richard Damon <richard@damon-family.org> - 2024-06-03 20:57 -0400
Re: Why does Olcott care about simulation, anyway? --- Mikes Review Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2024-06-04 02:38 +0100
Re: Why does Olcott care about simulation, anyway? --- Mikes Review olcott <polcott333@gmail.com> - 2024-06-03 20:46 -0500
Re: Why does Olcott care about simulation, anyway? --- Mikes Review Richard Damon <richard@damon-family.org> - 2024-06-03 21:59 -0400
Re: Why does Olcott care about simulation, anyway? --- Mikes Review olcott <polcott333@gmail.com> - 2024-06-03 21:18 -0500
Re: Why does Olcott care about simulation, anyway? --- Mikes Review Richard Damon <richard@damon-family.org> - 2024-06-03 22:49 -0400
Re: Why does Olcott care about simulation, anyway? --- Mikes Review olcott <polcott333@gmail.com> - 2024-06-04 12:12 -0500
Re: Why does Olcott care about simulation, anyway? --- Mikes Review Richard Damon <richard@damon-family.org> - 2024-06-04 21:47 -0400
Re: Why does Olcott care about simulation, anyway? --- Mikes Review Mikko <mikko.levanto@iki.fi> - 2024-06-05 10:08 +0300
Re: Why does Olcott care about simulation, anyway? --- Mikes Review olcott <polcott333@gmail.com> - 2024-06-05 08:08 -0500
Re: Why does Olcott care about simulation, anyway? --- Mikes Review wij <wyniijj5@gmail.com> - 2024-06-05 21:47 +0800
Re: Why does Olcott care about simulation, anyway? --- Mikes Review olcott <polcott333@gmail.com> - 2024-06-05 09:10 -0500
Re: Why does Olcott care about simulation, anyway? --- Mikes Review Mikko <mikko.levanto@iki.fi> - 2024-06-06 11:25 +0300
Re: Why does Olcott care about simulation, anyway? --- Mikes Review olcott <polcott333@gmail.com> - 2024-06-06 08:13 -0500
Re: Why does Olcott care about simulation, anyway? --- Mikes Review Mikko <mikko.levanto@iki.fi> - 2024-06-06 18:18 +0300
Re: Why does Olcott care about simulation, anyway? --- Mikes Review olcott <polcott333@gmail.com> - 2024-06-06 10:32 -0500
Re: Why does Olcott care about simulation, anyway? --- Mikes Review Richard Damon <richard@damon-family.org> - 2024-06-06 22:08 -0400
Re: Why does Olcott care about simulation, anyway? --- Mikes Review Richard Damon <richard@damon-family.org> - 2024-06-06 07:10 -0400
Re: Why does Olcott care about simulation, anyway? --- Mikes Review Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2024-06-04 03:57 +0100
Re: Why does Olcott care about simulation, anyway? --- Mikes Review olcott <polcott333@gmail.com> - 2024-06-03 22:12 -0500
Re: Why does Olcott care about simulation, anyway? --- Mikes Review Richard Damon <richard@damon-family.org> - 2024-06-03 23:57 -0400
Re: Why does Olcott care about simulation, anyway? --- Mikes Review olcott <polcott333@gmail.com> - 2024-06-04 12:26 -0500
Re: Why does Olcott care about simulation, anyway? --- Mikes Review Richard Damon <richard@damon-family.org> - 2024-06-04 21:47 -0400
Re: Why does Olcott care about simulation, anyway? --- Mikes Review immibis <news2@immibis.com> - 2024-06-04 19:36 +0200
Re: Why does Olcott care about simulation, anyway? Ben Bacarisse <ben@bsb.me.uk> - 2024-06-03 10:42 +0100
Re: Why does Olcott care about simulation, anyway? --- Ben's Review olcott <polcott333@gmail.com> - 2024-06-03 07:20 -0500
Re: Why does Olcott care about simulation, anyway? --- Ben's Review immibis <news@immibis.com> - 2024-06-03 15:39 +0200
Re: Why does Olcott care about simulation, anyway? --- Ben's Review Mikko <mikko.levanto@iki.fi> - 2024-06-03 17:27 +0300
Re: Why does Olcott care about simulation, anyway? --- Ben's Review olcott <polcott333@gmail.com> - 2024-06-03 13:14 -0500
Re: Why does Olcott care about simulation, anyway? --- Ben's Review Richard Damon <richard@damon-family.org> - 2024-06-03 20:56 -0400
Re: Why does Olcott care about simulation, anyway? --- Ben's Review joes <noreply@example.com> - 2024-06-04 08:21 +0000
Re: Why does Olcott care about simulation, anyway? --- Ben's Review olcott <polcott333@gmail.com> - 2024-06-04 12:31 -0500
Re: Why does Olcott care about simulation, anyway? --- Ben's Review Mikko <mikko.levanto@iki.fi> - 2024-06-04 11:28 +0300
Halting Problem is wrong two different ways olcott <polcott333@gmail.com> - 2024-06-04 12:40 -0500
Re: Halting Problem is wrong two different ways immibis <news2@immibis.com> - 2024-06-04 20:27 +0200
Re: Halting Problem is wrong two different ways Richard Damon <richard@damon-family.org> - 2024-06-04 21:48 -0400
Re: Halting Problem is wrong two different ways olcott <polcott333@gmail.com> - 2024-06-04 21:05 -0500
Re: Halting Problem is wrong two different ways John Smith <news2@immibis.com> - 2024-06-05 04:12 +0200
Re: Halting Problem is wrong two different ways olcott <polcott333@gmail.com> - 2024-06-04 21:16 -0500
Re: Halting Problem is wrong two different ways Richard Damon <richard@damon-family.org> - 2024-06-04 22:22 -0400
Re: Halting Problem is wrong two different ways Mikko <mikko.levanto@iki.fi> - 2024-06-05 10:28 +0300
Re: Halting Problem is wrong two different ways olcott <polcott333@gmail.com> - 2024-06-05 08:24 -0500
Re: Halting Problem is wrong two different ways Richard Damon <richard@damon-family.org> - 2024-06-05 19:39 -0400
Re: Halting Problem is wrong two different ways John Smith <news2@immibis.com> - 2024-06-05 19:03 +0200
Re: Halting Problem is wrong two different ways olcott <polcott333@gmail.com> - 2024-06-05 12:09 -0500
Re: Halting Problem is wrong two different ways John Smith <news2@immibis.com> - 2024-06-05 19:29 +0200
Re: Halting Problem is wrong two different ways olcott <polcott333@gmail.com> - 2024-06-05 12:37 -0500
Re: Halting Problem is wrong two different ways joes <noreply@example.com> - 2024-06-05 18:16 +0000
Re: Halting Problem is wrong two different ways joes <noreply@example.com> - 2024-06-05 18:33 +0000
Re: Halting Problem is wrong two different ways --very stupid olcott <polcott333@gmail.com> - 2024-06-05 21:09 -0500
Re: Halting Problem is wrong two different ways --very stupid Richard Damon <richard@damon-family.org> - 2024-06-05 22:28 -0400
Re: Halting Problem is wrong two different ways --very stupid Mikko <mikko.levanto@iki.fi> - 2024-06-06 11:52 +0300
Re: Halting Problem is wrong two different ways --very stupid olcott <polcott333@gmail.com> - 2024-06-06 08:37 -0500
Re: Halting Problem is wrong two different ways --very stupid Richard Damon <richard@damon-family.org> - 2024-06-06 22:08 -0400
Re: Halting Problem is wrong two different ways Richard Damon <richard@damon-family.org> - 2024-06-05 19:42 -0400
Re: Halting Problem is wrong two different ways Mikko <mikko.levanto@iki.fi> - 2024-06-06 11:45 +0300
Re: Halting Problem is wrong two different ways olcott <polcott333@gmail.com> - 2024-06-06 08:23 -0500
Re: Halting Problem is wrong two different ways Richard Damon <richard@damon-family.org> - 2024-06-06 22:08 -0400
Re: Halting Problem is wrong two different ways Richard Damon <richard@damon-family.org> - 2024-06-04 22:22 -0400
Re: Halting Problem is wrong two different ways "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-05 10:11 +0200
Re: Halting Problem is wrong two different ways olcott <polcott333@gmail.com> - 2024-06-05 08:59 -0500
Re: Halting Problem is wrong two different ways "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-05 20:51 +0200
Re: Halting Problem is wrong two different ways olcott <polcott333@gmail.com> - 2024-06-05 17:44 -0500
Re: Halting Problem is wrong two different ways "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-06 18:01 +0200
Re: Halting Problem is wrong two different ways olcott <polcott333@gmail.com> - 2024-06-06 11:07 -0500
Re: Halting Problem is wrong two different ways "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-06 18:34 +0200
Re: Halting Problem is wrong two different ways olcott <polcott333@gmail.com> - 2024-06-06 11:44 -0500
Re: Halting Problem is wrong two different ways immibis <news2@immibis.com> - 2024-06-06 20:09 +0200
Re: Halting Problem is wrong two different ways Richard Damon <richard@damon-family.org> - 2024-06-05 19:46 -0400
Re: Halting Problem is wrong two different ways Mikko <mikko.levanto@iki.fi> - 2024-06-06 12:02 +0300
Re: Halting Problem is wrong two different ways olcott <polcott333@gmail.com> - 2024-06-06 08:41 -0500
Re: Halting Problem is wrong two different ways Mikko <mikko.levanto@iki.fi> - 2024-06-06 18:07 +0300
Re: Halting Problem is wrong two different ways olcott <polcott333@gmail.com> - 2024-06-06 10:15 -0500
Re: Halting Problem is wrong two different ways Richard Damon <richard@damon-family.org> - 2024-06-06 22:08 -0400
Re: Halting Problem is wrong two different ways Mikko <mikko.levanto@iki.fi> - 2024-06-07 09:19 +0300
Re: Halting Problem is wrong two different ways Richard Damon <richard@damon-family.org> - 2024-06-06 22:08 -0400
Re: Halting Problem is wrong two different ways Mikko <mikko.levanto@iki.fi> - 2024-06-05 10:13 +0300
Re: Halting Problem is wrong two different ways olcott <polcott333@gmail.com> - 2024-06-05 08:18 -0500
Re: Halting Problem is wrong two different ways joes <noreply@example.com> - 2024-06-05 18:25 +0000
Re: Halting Problem is wrong two different ways Richard Damon <richard@damon-family.org> - 2024-06-05 19:51 -0400
Re: Halting Problem is wrong two different ways Mikko <mikko.levanto@iki.fi> - 2024-06-06 12:34 +0300
Re: Halting Problem is wrong two different ways olcott <polcott333@gmail.com> - 2024-06-06 08:48 -0500
Re: Halting Problem is wrong two different ways Mikko <mikko.levanto@iki.fi> - 2024-06-06 18:09 +0300
Re: Halting Problem is wrong two different ways olcott <polcott333@gmail.com> - 2024-06-06 10:18 -0500
Re: Halting Problem is wrong two different ways Mikko <mikko.levanto@iki.fi> - 2024-06-07 09:22 +0300
Re: Halting Problem is wrong two different ways olcott <polcott333@gmail.com> - 2024-06-07 09:09 -0500
Re: Halting Problem is wrong two different ways Richard Damon <richard@damon-family.org> - 2024-06-07 11:14 -0400
Re: Halting Problem is wrong two different ways joes <noreply@example.com> - 2024-06-07 21:02 +0000
Re: Halting Problem is wrong two different ways olcott <polcott333@gmail.com> - 2024-06-07 17:27 -0500
Re: Halting Problem is wrong two different ways Mikko <mikko.levanto@iki.fi> - 2024-06-08 09:13 +0300
Re: Halting Problem is wrong two different ways olcott <polcott333@gmail.com> - 2024-06-08 07:42 -0500
Re: Halting Problem is wrong two different ways Richard Damon <richard@damon-family.org> - 2024-06-08 09:03 -0400
Re: Halting Problem is wrong two different ways Mikko <mikko.levanto@iki.fi> - 2024-06-09 11:09 +0300
Re: Halting Problem is wrong two different ways olcott <polcott333@gmail.com> - 2024-06-09 08:27 -0500
Re: Halting Problem is wrong two different ways Richard Damon <richard@damon-family.org> - 2024-06-09 14:08 -0400
Re: Halting Problem is wrong two different ways Mikko <mikko.levanto@iki.fi> - 2024-06-08 09:06 +0300
Re: Halting Problem is wrong two different ways olcott <polcott333@gmail.com> - 2024-06-08 07:35 -0500
Re: Halting Problem is wrong two different ways Richard Damon <richard@damon-family.org> - 2024-06-08 09:03 -0400
Re: Halting Problem is wrong two different ways immibis <news@immibis.com> - 2024-06-07 16:25 +0200
Re: Why does Olcott care about simulation, anyway? --- Ben's Review immibis <news@immibis.com> - 2024-06-04 16:38 +0200
Re: Why does Olcott care about simulation, anyway? --- Ben's Review "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-03 22:09 +0200
Mike Terry Reply to Fred Zwarts olcott <polcott333@gmail.com> - 2024-06-03 16:24 -0500
Re: Mike Terry Reply to Fred Zwarts "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-04 12:29 +0200
Re: Mike Terry Reply to Fred Zwarts "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-04 12:52 +0200
Re: Mike Terry Reply to Fred Zwarts Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2024-06-04 17:58 +0100
How Partial Simulations correctly determine non-halting ---Mike Terry Error olcott <polcott333@gmail.com> - 2024-06-04 13:02 -0500
Re: How Partial Simulations correctly determine non-halting ---Mike Terry Error joes <noreply@example.com> - 2024-06-04 21:26 +0000
Re: How Partial Simulations correctly determine non-halting ---Mike Terry Error olcott <polcott333@gmail.com> - 2024-06-04 17:16 -0500
Re: How Partial Simulations correctly determine non-halting ---Mike Terry Error Richard Damon <richard@damon-family.org> - 2024-06-04 21:48 -0400
Re: How Partial Simulations correctly determine non-halting ---Mike Terry Error "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-05 10:21 +0200
Re: How Partial Simulations correctly determine non-halting ---Mike Terry Error olcott <polcott333@gmail.com> - 2024-06-05 09:04 -0500
Re: How Partial Simulations correctly determine non-halting ---Mike Terry Error joes <noreply@example.com> - 2024-06-05 18:28 +0000
Re: How Partial Simulations correctly determine non-halting ---Mike Terry Error "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-05 20:55 +0200
Re: How Partial Simulations correctly determine non-halting ---Mike Terry Error joes <noreply@example.com> - 2024-06-05 09:32 +0000
Re: How Partial Simulations correctly determine non-halting ---Mike Terry Error olcott <polcott333@gmail.com> - 2024-06-05 07:45 -0500
Re: How Partial Simulations correctly determine non-halting ---Mike Terry Error joes <noreply@example.com> - 2024-06-05 18:05 +0000
Re: How Partial Simulations correctly determine non-halting ---Mike Terry Error John Smith <news2@immibis.com> - 2024-06-05 03:20 +0200
Re: How Partial Simulations correctly determine non-halting ---Mike Terry Error olcott <polcott333@gmail.com> - 2024-06-04 20:33 -0500
Re: How Partial Simulations correctly determine non-halting ---Mike Terry Error John Smith <news2@immibis.com> - 2024-06-05 03:39 +0200
Re: How Partial Simulations correctly determine non-halting ---Mike Terry Error olcott <polcott333@gmail.com> - 2024-06-04 21:07 -0500
Re: How Partial Simulations correctly determine non-halting ---Mike Terry Error John Smith <news2@immibis.com> - 2024-06-05 04:13 +0200
Re: How Partial Simulations correctly determine non-halting ---Mike Terry Error olcott <polcott333@gmail.com> - 2024-06-04 21:19 -0500
Re: How Partial Simulations correctly determine non-halting ---Mike Terry Error John Smith <news2@immibis.com> - 2024-06-05 17:40 +0200
Re: How Partial Simulations correctly determine non-halting ---Mike Terry Error olcott <polcott333@gmail.com> - 2024-06-05 11:51 -0500
Re: How Partial Simulations correctly determine non-halting ---Mike Terry Error joes <noreply@example.com> - 2024-06-05 18:38 +0000
Re: How Partial Simulations correctly determine non-halting ---Mike Terry Error Richard Damon <richard@damon-family.org> - 2024-06-05 19:52 -0400
Re: How Partial Simulations correctly determine non-halting ---Mike Terry Error Ben Bacarisse <ben@bsb.me.uk> - 2024-06-05 10:38 +0100
Re: How Partial Simulations correctly determine non-halting --- Ben's strawman deception olcott <polcott333@gmail.com> - 2024-06-05 07:09 -0500
Re: How Partial Simulations correctly determine non-halting --- Ben's strawman deception joes <noreply@example.com> - 2024-06-05 17:57 +0000
Re: How Partial Simulations correctly determine non-halting --- Ben's strawman deception olcon'tt <news2@immibis.com> - 2024-06-07 16:10 +0200
Re: How Partial Simulations correctly determine non-halting ---Mike Terry Error Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2024-06-05 16:55 +0100
Re: How Partial Simulations correctly determine non-halting ---Mike Terry Error olcott <polcott333@gmail.com> - 2024-06-05 11:49 -0500
Re: How Partial Simulations correctly determine non-halting ---Mike Terry Error John Smith <news2@immibis.com> - 2024-06-05 19:25 +0200
Re: How Partial Simulations correctly determine non-halting ---Mike Terry Error olcott <polcott333@gmail.com> - 2024-06-05 12:35 -0500
Re: How Partial Simulations correctly determine non-halting ---Mike Terry Error joes <noreply@example.com> - 2024-06-05 18:22 +0000
Re: How Partial Simulations correctly determine non-halting ---Mike Terry Error Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2024-06-06 00:33 +0100
Re: How Partial Simulations correctly determine non-halting ---Mike Terry Error !!! olcott <polcott333@gmail.com> - 2024-06-05 19:48 -0500
Re: How Partial Simulations correctly determine non-halting ---Mike Terry Error !!! Richard Damon <richard@damon-family.org> - 2024-06-05 21:10 -0400
Re: How Partial Simulations correctly determine non-halting ---Mike Terry Error Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2024-06-05 21:28 +0100
Re: How Partial Simulations correctly determine non-halting ---Mike Terry Error olcott <polcott333@gmail.com> - 2024-06-05 17:07 -0500
Re: How Partial Simulations incorrectly determine non-halting ---Mike Terry Error joes <noreply@example.com> - 2024-06-05 23:04 +0000
Re: How Partial Simulations correctly determine non-halting ---Mike Terry Error Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2024-06-06 22:55 +0100
Re: How Partial Simulations correctly determine non-halting ---Mike Terry Error olcott <polcott333@gmail.com> - 2024-06-06 21:53 -0500
Re: How Partial Simulations correctly determine non-halting ---Mike Terry Error Richard Damon <richard@damon-family.org> - 2024-06-06 23:29 -0400
Re: How Partial Simulations correctly determine non-halting ---Mike Terry Error joes <noreply@example.com> - 2024-06-07 14:55 +0000
Re: How Partial Simulations correctly determine non-halting ---Mike Terry Error olcott <polcott333@gmail.com> - 2024-06-07 09:59 -0500
Re: How Partial Simulations correctly determine non-halting ---Mike Terry Error Richard Damon <richard@damon-family.org> - 2024-06-07 11:14 -0400
Re: How Partial Simulations correctly determine non-halting ---Mike Terry Error joes <noreply@example.com> - 2024-06-07 15:24 +0000
Re: How Partial Simulations correctly determine non-halting ---Mike Terry Error Richard Damon <richard@damon-family.org> - 2024-06-04 21:48 -0400
Re: How Partial Simulations correctly determine non-halting ---Mike Terry Error Mikko <mikko.levanto@iki.fi> - 2024-06-05 10:37 +0300
Re: How Partial Simulations correctly determine non-halting ---Mike Terry Error olcott <polcott333@gmail.com> - 2024-06-05 08:29 -0500
Re: How Partial Simulations correctly determine non-halting ---Mike Terry Error Richard Damon <richard@damon-family.org> - 2024-06-05 19:54 -0400
Re: How Partial Simulations correctly determine non-halting ---Mike Terry Error Mikko <mikko.levanto@iki.fi> - 2024-06-06 13:15 +0300
Re: How Partial Simulations correctly determine non-halting ---Mike Terry Error olcott <polcott333@gmail.com> - 2024-06-06 08:53 -0500
Re: How Partial Simulations correctly determine non-halting ---Mike Terry Error Mikko <mikko.levanto@iki.fi> - 2024-06-06 18:14 +0300
Re: How Partial Simulations correctly determine non-halting ---Mike Terry Error olcott <polcott333@gmail.com> - 2024-06-06 10:31 -0500
Re: How Partial Simulations correctly determine non-halting ---Mike Terry Error Mikko <mikko.levanto@iki.fi> - 2024-06-07 09:30 +0300
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis olcott <polcott333@gmail.com> - 2024-06-07 09:47 -0500
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis Python <python@invalid.org> - 2024-06-07 16:55 +0200
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis olcott <polcott333@gmail.com> - 2024-06-07 10:05 -0500
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis Python <python@invalid.org> - 2024-06-07 17:09 +0200
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis olcott <polcott333@gmail.com> - 2024-06-07 10:20 -0500
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis Richard Damon <richard@damon-family.org> - 2024-06-07 11:28 -0400
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis joes <noreply@example.com> - 2024-06-07 15:32 +0000
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis olcott <polcott333@gmail.com> - 2024-06-07 10:40 -0500
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis Richard Damon <richard@damon-family.org> - 2024-06-07 11:51 -0400
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis joes <noreply@example.com> - 2024-06-07 16:34 +0000
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis olcott <polcott333@gmail.com> - 2024-06-07 11:53 -0500
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis joes <noreply@example.com> - 2024-06-07 20:40 +0000
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2024-06-08 03:43 +0100
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis Richard Damon <richard@damon-family.org> - 2024-06-07 23:03 -0400
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis olcott <polcott333@gmail.com> - 2024-06-07 22:36 -0500
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis Richard Damon <richard@damon-family.org> - 2024-06-08 09:03 -0400
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis olcott <polcott333@gmail.com> - 2024-06-08 08:43 -0500
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis Richard Damon <richard@damon-family.org> - 2024-06-08 10:05 -0400
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis Mikko <mikko.levanto@iki.fi> - 2024-06-09 11:15 +0300
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis olcott <polcott333@gmail.com> - 2024-06-09 08:45 -0500
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis Richard Damon <richard@damon-family.org> - 2024-06-09 14:08 -0400
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis olcott <polcott333@gmail.com> - 2024-06-07 22:16 -0500
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis Richard Damon <richard@damon-family.org> - 2024-06-08 09:03 -0400
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis Mikko <mikko.levanto@iki.fi> - 2024-06-08 09:28 +0300
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis olcott <polcott333@gmail.com> - 2024-06-08 07:47 -0500
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis Richard Damon <richard@damon-family.org> - 2024-06-08 08:59 -0400
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis olcott <polcott333@gmail.com> - 2024-06-08 08:22 -0500
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis Richard Damon <richard@damon-family.org> - 2024-06-08 10:06 -0400
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2024-06-08 17:43 +0100
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis --- olcott <polcott333@gmail.com> - 2024-06-08 12:19 -0500
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis --- Richard Damon <richard@damon-family.org> - 2024-06-08 16:33 -0400
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis Richard Damon <richard@damon-family.org> - 2024-06-07 11:19 -0400
Re: How Partial Simulations incorrectly determine non-halting ---Ben's 10/2022 analysis joes <noreply@example.com> - 2024-06-07 15:27 +0000
Re: How Partial Simulations incorrectly determine non-halting ---Ben's 10/2022 analysis olcott <polcott333@gmail.com> - 2024-06-07 10:30 -0500
Re: How Partial Simulations incorrectly determine non-halting ---Ben's 10/2022 analysis news2@immibis.com - 2024-06-07 17:32 +0200
Re: How Partial Simulations incorrectly determine non-halting ---Ben's 10/2022 analysis Richard Damon <richard@damon-family.org> - 2024-06-07 11:52 -0400
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis Richard Damon <richard@damon-family.org> - 2024-06-07 11:14 -0400
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis Mikko <mikko.levanto@iki.fi> - 2024-06-07 19:56 +0300
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis olcott <polcott333@gmail.com> - 2024-06-07 12:11 -0500
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis Richard Damon <richard@damon-family.org> - 2024-06-07 14:32 -0400
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis Mikko <mikko.levanto@iki.fi> - 2024-06-08 09:36 +0300
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis olcott <polcott333@gmail.com> - 2024-06-08 07:52 -0500
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis Richard Damon <richard@damon-family.org> - 2024-06-08 09:10 -0400
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis olcott <polcott333@gmail.com> - 2024-06-08 08:48 -0500
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis Richard Damon <richard@damon-family.org> - 2024-06-08 10:10 -0400
Re: How Partial Simulations correctly determine non-halting ---Should I quit Richard at this point? olcott <polcott333@gmail.com> - 2024-06-08 09:20 -0500
Re: How Partial Simulations correctly determine non-halting ---Should I quit Richard at this point? Richard Damon <richard@damon-family.org> - 2024-06-08 10:54 -0400
Re: How Partial Simulations correctly determine non-halting ---Should I quit Richard at this point? olcott <polcott333@gmail.com> - 2024-06-08 10:07 -0500
Re: How Partial Simulations correctly determine non-halting ---Should I quit Richard at this point? Richard Damon <richard@damon-family.org> - 2024-06-08 11:15 -0400
Re: How Partial Simulations correctly determine non-halting ---Should I quit Richard at this point? olcott <polcott333@gmail.com> - 2024-06-08 10:32 -0500
Re: How Partial Simulations correctly determine non-halting ---Should I quit Richard at this point? Richard Damon <richard@damon-family.org> - 2024-06-08 12:03 -0400
Re: How Partial Simulations correctly determine non-halting ---Should I quit Richard at this point? olcott <polcott333@gmail.com> - 2024-06-08 12:10 -0500
Re: How Partial Simulations correctly determine non-halting ---Should I quit Richard at this point? joes <noreply@example.com> - 2024-06-08 18:12 +0000
Re: How Partial Simulations correctly determine non-halting ---Should I quit Richard at this point? olcott <polcott333@gmail.com> - 2024-06-08 13:36 -0500
Re: How Partial Simulations correctly determine non-halting ---Should I quit Richard at this point? joes <noreply@example.com> - 2024-06-08 19:59 +0000
Re: How Partial Simulations correctly determine non-halting ---Should I quit Richard at this point? olcott <polcott333@gmail.com> - 2024-06-08 15:15 -0500
Re: How Partial Simulations correctly determine non-halting ---Should I quit Richard at this point? joes <noreply@example.com> - 2024-06-08 21:37 +0000
Re: How Partial Simulations correctly determine non-halting ---Should I quit Richard at this point? olcott <polcott333@gmail.com> - 2024-06-08 16:42 -0500
Re: How Partial Simulations correctly determine non-halting ---Should I quit Richard at this point? Richard Damon <richard@damon-family.org> - 2024-06-08 17:50 -0400
Re: How Partial Simulations correctly determine non-halting ---Should I quit Richard at this point? olcott <polcott333@gmail.com> - 2024-06-08 17:04 -0500
Re: How Partial Simulations correctly determine non-halting ---Should I quit Richard at this point? Richard Damon <richard@damon-family.org> - 2024-06-08 18:27 -0400
Re: How Partial Simulations correctly determine non-halting ---Should I quit Richard at this point? olcott <polcott333@gmail.com> - 2024-06-08 17:34 -0500
Re: How Partial Simulations correctly determine non-halting ---Should I quit Richard at this point? Richard Damon <richard@damon-family.org> - 2024-06-08 22:47 -0400
Re: How Partial Simulations correctly determine non-halting ---Should I quit Richard at this point? olcott <polcott333@gmail.com> - 2024-06-08 21:58 -0500
Re: How Partial Simulations correctly determine non-halting ---Should I quit Richard at this point? Richard Damon <richard@damon-family.org> - 2024-06-08 23:53 -0400
Re: How Partial Simulations correctly determine non-halting ---Should I quit Richard at this point? olcott <polcott333@gmail.com> - 2024-06-08 23:02 -0500
Re: How Partial Simulations correctly determine non-halting ---Should I quit Richard at this point? Richard Damon <richard@damon-family.org> - 2024-06-09 00:11 -0400
Re: How Partial Simulations correctly determine non-halting ---Should I quit Richard at this point? olcott <polcott333@gmail.com> - 2024-06-08 23:38 -0500
Re: How Partial Simulations correctly determine non-halting ---Should I quit Richard at this point? Richard Damon <richard@damon-family.org> - 2024-06-09 14:08 -0400
Re: How Partial Simulations correctly determine non-halting ---Should I quit Richard at this point? Mikko <mikko.levanto@iki.fi> - 2024-06-09 11:38 +0300
Re: How Partial Simulations correctly determine non-halting ---Should I quit Richard at this point? olcott <polcott333@gmail.com> - 2024-06-09 08:58 -0500
Re: How Partial Simulations correctly determine non-halting ---Should I quit Richard at this point? Mikko <mikko.levanto@iki.fi> - 2024-06-09 18:56 +0300
Re: How Partial Simulations correctly determine non-halting ---Should I quit Richard at this point? olcott <polcott333@gmail.com> - 2024-06-09 11:23 -0500
Re: How Partial Simulations correctly determine non-halting ---Should I quit Richard at this point? Mikko <mikko.levanto@iki.fi> - 2024-06-10 09:30 +0300
Re: How Partial Simulations correctly determine non-halting ---Should I quit Richard at this point? olcott <polcott333@gmail.com> - 2024-06-10 09:59 -0500
Re: How Partial Simulations correctly determine non-halting ---Should I quit Richard at this point? Mikko <mikko.levanto@iki.fi> - 2024-06-11 10:35 +0300
Re: How Partial Simulations correctly determine non-halting ---Should I quit Richard at this point? olcott <polcott333@gmail.com> - 2024-06-11 12:38 -0500
Re: How Partial Simulations correctly determine non-halting ---Should I quit Richard at this point? Richard Damon <richard@damon-family.org> - 2024-06-08 16:23 -0400
Re: How Partial Simulations correctly determine non-halting ---Should I quit Richard at this point? olcott <polcott333@gmail.com> - 2024-06-08 15:34 -0500
Re: How Partial Simulations correctly determine non-halting ---Should I quit Richard at this point? Richard Damon <richard@damon-family.org> - 2024-06-08 16:47 -0400
Re: How Partial Simulations correctly determine non-halting ---Should I quit Richard at this point? olcott <polcott333@gmail.com> - 2024-06-08 15:52 -0500
Re: How Partial Simulations correctly determine non-halting ---Should I quit Richard at this point? Richard Damon <richard@damon-family.org> - 2024-06-08 16:57 -0400
Re: How Partial Simulations correctly determine non-halting ---Should I quit Richard at this point? olcott <polcott333@gmail.com> - 2024-06-08 16:14 -0500
Re: How Partial Simulations correctly determine non-halting ---Should I quit Richard at this point? Richard Damon <richard@damon-family.org> - 2024-06-08 17:28 -0400
Re: How Partial Simulations correctly determine non-halting ---Should I quit Richard at this point? olcott <polcott333@gmail.com> - 2024-06-08 16:38 -0500
Re: How Partial Simulations correctly determine non-halting ---Should I quit Richard at this point? Richard Damon <richard@damon-family.org> - 2024-06-08 17:48 -0400
Re: How Partial Simulations correctly determine non-halting ---Should I quit Richard at this point? olcott <polcott333@gmail.com> - 2024-06-08 16:58 -0500
Re: How Partial Simulations correctly determine non-halting ---Should I quit Richard at this point? Richard Damon <richard@damon-family.org> - 2024-06-08 18:25 -0400
Re: How Partial Simulations correctly determine non-halting ---Should I quit Richard at this point? olcott <polcott333@gmail.com> - 2024-06-08 17:30 -0500
Re: How Partial Simulations correctly determine non-halting ---Should I quit Richard at this point? Richard Damon <richard@damon-family.org> - 2024-06-08 22:47 -0400
Re: How Partial Simulations correctly determine non-halting ---Should I quit Richard at this point? olcott <polcott333@gmail.com> - 2024-06-08 22:02 -0500
Re: How Partial Simulations correctly determine non-halting ---Should I quit Richard at this point? Richard Damon <richard@damon-family.org> - 2024-06-08 23:56 -0400
Re: How Partial Simulations correctly determine non-halting ---Should I quit Richard at this point? olcott <polcott333@gmail.com> - 2024-06-08 23:06 -0500
Re: How Partial Simulations correctly determine non-halting ---Should I quit Richard at this point? Richard Damon <richard@damon-family.org> - 2024-06-09 14:08 -0400
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis Mikko <mikko.levanto@iki.fi> - 2024-06-09 11:20 +0300
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis olcott <polcott333@gmail.com> - 2024-06-09 08:53 -0500
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis Mikko <mikko.levanto@iki.fi> - 2024-06-09 18:15 +0300
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis olcott <polcott333@gmail.com> - 2024-06-09 11:18 -0500
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis Richard Damon <richard@damon-family.org> - 2024-06-09 14:08 -0400
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis Mikko <mikko.levanto@iki.fi> - 2024-06-10 09:57 +0300
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis olcott <polcott333@gmail.com> - 2024-06-10 10:05 -0500
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis Mikko <mikko.levanto@iki.fi> - 2024-06-11 10:22 +0300
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis Mikko <mikko.levanto@iki.fi> - 2024-06-10 12:50 +0300
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis Richard Damon <richard@damon-family.org> - 2024-06-09 14:08 -0400
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis joes <noreply@example.com> - 2024-06-07 21:00 +0000
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis olcott <polcott333@gmail.com> - 2024-06-07 17:26 -0500
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis Richard Damon <richard@damon-family.org> - 2024-06-07 19:00 -0400
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis joes <noreply@example.com> - 2024-06-07 23:19 +0000
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis olcott <polcott333@gmail.com> - 2024-06-07 18:44 -0500
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis Richard Damon <richard@damon-family.org> - 2024-06-07 20:38 -0400
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis Python <python@invalid.org> - 2024-06-08 02:25 +0200
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis olcott <polcott333@gmail.com> - 2024-06-07 19:35 -0500
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis Richard Damon <richard@damon-family.org> - 2024-06-07 20:48 -0400
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis Mikko <mikko.levanto@iki.fi> - 2024-06-08 09:42 +0300
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis olcott <polcott333@gmail.com> - 2024-06-08 08:04 -0500
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-08 15:20 +0200
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis olcott <polcott333@gmail.com> - 2024-06-08 08:32 -0500
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-08 15:56 +0200
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis olcott <polcott333@gmail.com> - 2024-06-08 09:11 -0500
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis Richard Damon <richard@damon-family.org> - 2024-06-08 10:20 -0400
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis Richard Damon <richard@damon-family.org> - 2024-06-08 10:17 -0400
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis Richard Damon <richard@damon-family.org> - 2024-06-08 09:36 -0400
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis joes <noreply@example.com> - 2024-06-08 13:46 +0000
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis olcott <polcott333@gmail.com> - 2024-06-08 09:02 -0500
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis Richard Damon <richard@damon-family.org> - 2024-06-08 10:31 -0400
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis Mikko <mikko.levanto@iki.fi> - 2024-06-09 11:52 +0300
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis olcott <polcott333@gmail.com> - 2024-06-09 09:03 -0500
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis Mikko <mikko.levanto@iki.fi> - 2024-06-09 18:13 +0300
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis olcott <polcott333@gmail.com> - 2024-06-09 11:15 -0500
Re: How Partial Simulations correctly determine non-halting joes <noreply@example.com> - 2024-06-09 17:47 +0000
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis Mikko <mikko.levanto@iki.fi> - 2024-06-10 10:54 +0300
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis olcott <polcott333@gmail.com> - 2024-06-10 10:22 -0500
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis Richard Damon <richard@damon-family.org> - 2024-06-09 14:08 -0400
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis Mikko <mikko.levanto@iki.fi> - 2024-06-09 11:47 +0300
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis olcott <polcott333@gmail.com> - 2024-06-09 08:59 -0500
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis Mikko <mikko.levanto@iki.fi> - 2024-06-09 18:11 +0300
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis olcott <polcott333@gmail.com> - 2024-06-09 11:09 -0500
Re: How Partial Simulations correctly determine non-halting -- TM as finite string joes <noreply@example.com> - 2024-06-09 17:50 +0000
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis Richard Damon <richard@damon-family.org> - 2024-06-09 14:08 -0400
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis Mikko <mikko.levanto@iki.fi> - 2024-06-10 11:01 +0300
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis olcott <polcott333@gmail.com> - 2024-06-10 10:23 -0500
Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis Mikko <mikko.levanto@iki.fi> - 2024-06-11 10:25 +0300
Re: How Partial Simulations correctly determine non-halting ---Mike Terry Error Richard Damon <richard@damon-family.org> - 2024-06-07 11:14 -0400
Re: Mike Terry Reply to Fred Zwarts "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-04 13:02 +0200
Re: Why does Olcott care about simulation, anyway? --- Ben's Review Richard Damon <richard@damon-family.org> - 2024-06-03 20:56 -0400
Re: Why does Olcott care about simulation, anyway? Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2024-06-03 17:58 +0100
Re: Why does Olcott care about simulation, anyway? "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-03 09:58 +0200
Re: Why does Olcott care about simulation, anyway? Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2024-06-03 18:36 +0100
Re: Why does Olcott care about simulation, anyway? olcott <polcott333@gmail.com> - 2024-06-03 13:03 -0500
Re: Why does Olcott care about simulation, anyway? Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2024-06-03 19:56 +0100
Re: Why does Olcott care about simulation, anyway? --- woeful ignorance olcott <polcott333@gmail.com> - 2024-06-03 14:26 -0500
Re: Why does Olcott care about simulation, anyway? olcott <polcott333@gmail.com> - 2024-06-03 19:47 -0500
Re: Why does Olcott care about simulation, anyway? Richard Damon <richard@damon-family.org> - 2024-06-03 20:59 -0400
Re: Why does Olcott care about simulation, anyway? olcott <polcott333@gmail.com> - 2024-06-03 20:05 -0500
Re: Why does Olcott care about simulation, anyway? Richard Damon <richard@damon-family.org> - 2024-06-03 21:44 -0400
Re: Why does Olcott care about simulation, anyway? olcott <polcott333@gmail.com> - 2024-06-03 20:54 -0500
Re: Why does Olcott care about simulation, anyway? Richard Damon <richard@damon-family.org> - 2024-06-03 21:58 -0400
Re: Why does Olcott care about simulation, anyway? olcott <polcott333@gmail.com> - 2024-06-03 21:09 -0500
Re: Why does Olcott care about simulation, anyway? Richard Damon <richard@damon-family.org> - 2024-06-03 22:26 -0400
Re: Why does Olcott care about simulation, anyway? olcott <polcott333@gmail.com> - 2024-06-03 21:47 -0500
Re: Why does Olcott care about simulation, anyway? Richard Damon <richard@damon-family.org> - 2024-06-03 22:53 -0400
Re: Why does Olcott care about simulation, anyway? olcott <polcott333@gmail.com> - 2024-06-04 12:06 -0500
Re: Why does Olcott care about simulation, anyway? Richard Damon <richard@damon-family.org> - 2024-06-04 21:47 -0400
Re: Why does Olcott care about simulation, anyway? "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-05 10:31 +0200
Re: Why does Olcott care about simulation, anyway? olcott <polcott333@gmail.com> - 2024-06-05 09:06 -0500
Re: Why is Olcott so ignorant, anyway? immibis <news@immibis.com> - 2024-06-04 17:25 +0200
Re: Why does Olcott care about simulation, anyway? Mikko <mikko.levanto@iki.fi> - 2024-06-03 13:38 +0300
Page 6 of 17 — ← Prev page 1 … 4 5 [6] 7 8 … 17 Next page →
| From | Mikko <mikko.levanto@iki.fi> |
|---|---|
| Date | 2024-06-09 11:09 +0300 |
| Subject | Re: Halting Problem is wrong two different ways |
| Message-ID | <v43nvo$3at9r$1@dont-email.me> |
| In reply to | #106646 |
On 2024-06-08 12:42:47 +0000, olcott said: > On 6/8/2024 1:13 AM, Mikko wrote: >> On 2024-06-07 22:27:22 +0000, olcott said: >> >>> On 6/7/2024 4:02 PM, joes wrote: >>>> Am Fri, 07 Jun 2024 09:09:54 -0500 schrieb olcott: >>>>> On 6/7/2024 1:22 AM, Mikko wrote: >>>>>> On 2024-06-06 15:18:21 +0000, olcott said: >>>>>>> >>>>> All halt deciders are only allowed to report on the actual behavior of >>>>> their actual input. >>> > >>>> Required even! And if they simulate, that simulation must match the >>>> behaviour. >>>> >>> >>> The most persistent false assumption that cannot possibly >>> be corrected without expertise in the x86 programming language. >>> Some people here have that. >> >> Not true. An expert of simulation and simulators need not know >> anything about x86. If you cannot correct a false assumption >> about simulations without expertise in the x86 programming language >> then you cannot correct it with that expertise, either. > > Basically you are admitting that you don't have what it takes > and trying to incorrect get away with sating that it doesn't matter. I do know but that is not relevant to this discussion. > People that know C have been able to understand this too. I do know C, at least older versions. But that is not relevant, either. > For people that are stuck in rebuttal mode I must make it as > precise as arithmetic so rebuttal looks ridiculously foolish. Roughly so. Otherwise people who are not stuck in rebuttal mode will look ridiculously foolish. > This did work on Richard. He went from denying what I said > with the strawman deception to saying that he never said it > was incorrect. It does not really matter whether your straw man and other deceptions are incorrect. Being a deception is incorrect enough. The easiest way to avoid lying about other people is to say nothing about them. -- Mikko
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-09 08:27 -0500 |
| Subject | Re: Halting Problem is wrong two different ways |
| Message-ID | <v44aki$3harn$1@dont-email.me> |
| In reply to | #106758 |
On 6/9/2024 3:09 AM, Mikko wrote:
> On 2024-06-08 12:42:47 +0000, olcott said:
>
>> On 6/8/2024 1:13 AM, Mikko wrote:
>>> On 2024-06-07 22:27:22 +0000, olcott said:
>>>
>>>> On 6/7/2024 4:02 PM, joes wrote:
>>>>> Am Fri, 07 Jun 2024 09:09:54 -0500 schrieb olcott:
>>>>>> On 6/7/2024 1:22 AM, Mikko wrote:
>>>>>>> On 2024-06-06 15:18:21 +0000, olcott said:
>>>>>>>>
>>>>>> All halt deciders are only allowed to report on the actual
>>>>>> behavior of
>>>>>> their actual input.
>>>> >
>>>>> Required even! And if they simulate, that simulation must match the
>>>>> behaviour.
>>>>>
>>>>
>>>> The most persistent false assumption that cannot possibly
>>>> be corrected without expertise in the x86 programming language.
>>>> Some people here have that.
>>>
>>> Not true. An expert of simulation and simulators need not know
>>> anything about x86. If you cannot correct a false assumption
>>> about simulations without expertise in the x86 programming language
>>> then you cannot correct it with that expertise, either.
>>
>> Basically you are admitting that you don't have what it takes
>> and trying to incorrect get away with sating that it doesn't matter.
>
> I do know but that is not relevant to this discussion.
>
>> People that know C have been able to understand this too.
>
> I do know C, at least older versions. But that is not relevant,
> either.
>
Sure it is.
typedef void (*ptr)(); // pointer to void function
void HHH(ptr P, ptr I)
{
P(I);
}
void DDD(int (*x)())
{
HHH(x, x);
}
int main()
{
HHH(DDD,DDD);
}
If you can't tell what is going on there then you
lack the minimum required prerequisite knowledge.
>> For people that are stuck in rebuttal mode I must make it as
>> precise as arithmetic so rebuttal looks ridiculously foolish.
>
> Roughly so. Otherwise people who are not stuck in rebuttal mode
> will look ridiculously foolish.
>
>> This did work on Richard. He went from denying what I said
>> with the strawman deception to saying that he never said it
>> was incorrect.
>
> It does not really matter whether your straw man and other
> deceptions are incorrect. Being a deception is incorrect
> enough.
>
> The easiest way to avoid lying about other people is to
> say nothing about them.
>
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-09 14:08 -0400 |
| Subject | Re: Halting Problem is wrong two different ways |
| Message-ID | <v44r3n$3egp9$10@i2pn2.org> |
| In reply to | #106769 |
On 6/9/24 9:27 AM, olcott wrote:
> On 6/9/2024 3:09 AM, Mikko wrote:
>> On 2024-06-08 12:42:47 +0000, olcott said:
>>
>>> On 6/8/2024 1:13 AM, Mikko wrote:
>>>> On 2024-06-07 22:27:22 +0000, olcott said:
>>>>
>>>>> On 6/7/2024 4:02 PM, joes wrote:
>>>>>> Am Fri, 07 Jun 2024 09:09:54 -0500 schrieb olcott:
>>>>>>> On 6/7/2024 1:22 AM, Mikko wrote:
>>>>>>>> On 2024-06-06 15:18:21 +0000, olcott said:
>>>>>>>>>
>>>>>>> All halt deciders are only allowed to report on the actual
>>>>>>> behavior of
>>>>>>> their actual input.
>>>>> >
>>>>>> Required even! And if they simulate, that simulation must match the
>>>>>> behaviour.
>>>>>>
>>>>>
>>>>> The most persistent false assumption that cannot possibly
>>>>> be corrected without expertise in the x86 programming language.
>>>>> Some people here have that.
>>>>
>>>> Not true. An expert of simulation and simulators need not know
>>>> anything about x86. If you cannot correct a false assumption
>>>> about simulations without expertise in the x86 programming language
>>>> then you cannot correct it with that expertise, either.
>>>
>>> Basically you are admitting that you don't have what it takes
>>> and trying to incorrect get away with sating that it doesn't matter.
>>
>> I do know but that is not relevant to this discussion.
>>
>>> People that know C have been able to understand this too.
>>
>> I do know C, at least older versions. But that is not relevant,
>> either.
>>
>
> Sure it is.
>
> typedef void (*ptr)(); // pointer to void function
>
> void HHH(ptr P, ptr I)
> {
> P(I);
> }
>
> void DDD(int (*x)())
> {
> HHH(x, x);
> }
>
> int main()
> {
> HHH(DDD,DDD);
> }
>
> If you can't tell what is going on there then you
> lack the minimum required prerequisite knowledge.
But is irrelevent to the case described below, since your above HHH is
NOT a simulating decider.
You are just proving your logic is based on telling lies.
>
>>> For people that are stuck in rebuttal mode I must make it as
>>> precise as arithmetic so rebuttal looks ridiculously foolish.
>>
>> Roughly so. Otherwise people who are not stuck in rebuttal mode
>> will look ridiculously foolish.
>>
>>> This did work on Richard. He went from denying what I said
>>> with the strawman deception to saying that he never said it
>>> was incorrect.
>>
>> It does not really matter whether your straw man and other
>> deceptions are incorrect. Being a deception is incorrect
>> enough.
>>
>> The easiest way to avoid lying about other people is to
>> say nothing about them.
>>
>
[toc] | [prev] | [next] | [standalone]
| From | Mikko <mikko.levanto@iki.fi> |
|---|---|
| Date | 2024-06-08 09:06 +0300 |
| Subject | Re: Halting Problem is wrong two different ways |
| Message-ID | <v40sdt$2gamb$1@dont-email.me> |
| In reply to | #106467 |
On 2024-06-07 14:09:54 +0000, olcott said: > On 6/7/2024 1:22 AM, Mikko wrote: >> On 2024-06-06 15:18:21 +0000, olcott said: >>> >>> *Here is that problem statement* >>> Prove that sum(3,4) is incorrect on the basis that >>> sum(3,4) cannot and does not provide the sum of 5 + 6. >> >> That problem statement does not restrict what another >> problem statement may specify. >> > > It is an analogy. It is not analogous to anything relevant, nor was it presented as a relevant or other analog. > All halt deciders are only allowed to report on the actual > behavior of their actual input. That does not restrict what a problem statement may specify. > I have proven right here that the actual behavior of the actual > input is that it remains stuck in recursive simulation. That does not restrict what a problem statement may specify. > Try any show how this DD can be correctly simulated by any HH > such that this DD reaches past its machine address [00001dbe] Not now as, whether DD reaches past 00001dbe or not, that does not restrict what a problem statement may specify. > _DD() > [00001e12] 55 push ebp > [00001e13] 8bec mov ebp,esp > [00001e15] 51 push ecx > [00001e16] 8b4508 mov eax,[ebp+08] > [00001e19] 50 push eax ; push DD > [00001e1a] 8b4d08 mov ecx,[ebp+08] > [00001e1d] 51 push ecx ; push DD > [00001e1e] e85ff5ffff call 00001382 ; call HH > > I proved that I am correct and no one even looks > at this proof, that is NOT AN HONEST DIALOGUE. You haven't, but even if you had that would not restrict what a problem statement may specify. > The above proof proves that DD is correctly simulated by HH > and DD simulated by HH DOES MEET the Sipser approve criteria. That does not restrict what a problem statement may specify. > <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 words10/13/2022> That does not restrict what a problem statement may specify. > Professor Sipser <is> the author of the best selling theory of > computation textbook. > > *Introduction to the Theory of Computation, by Michael Sipser* > https://www.amazon.com/Introduction-Theory-Computation-Michael-Sipser/dp/113318779X/ > That book does not restrict what a problem statement may specify. But the book might be worth reading anyway. -- Mikko
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-08 07:35 -0500 |
| Subject | Re: Halting Problem is wrong two different ways |
| Message-ID | <v41j5r$2jqdk$5@dont-email.me> |
| In reply to | #106631 |
On 6/8/2024 1:06 AM, Mikko wrote: > On 2024-06-07 14:09:54 +0000, olcott said: > >> On 6/7/2024 1:22 AM, Mikko wrote: >>> On 2024-06-06 15:18:21 +0000, olcott said: >>>> >>>> *Here is that problem statement* >>>> Prove that sum(3,4) is incorrect on the basis that >>>> sum(3,4) cannot and does not provide the sum of 5 + 6. >>> >>> That problem statement does not restrict what another >>> problem statement may specify. >>> >> >> It is an analogy. > > It is not analogous to anything relevant, nor was it presented > as a relevant or other analog. > >> All halt deciders are only allowed to report on the actual >> behavior of their actual input. > > That does not restrict what a problem statement may specify. > >> I have proven right here that the actual behavior of the actual >> input is that it remains stuck in recursive simulation. > > That does not restrict what a problem statement may specify. > *It does restrict what a correct problem statement can specify* Objective and Subjective Specifications Eric C.R. Hehner Department of Computer Science, University of Toronto (6) Can Carol correctly answer “no” to this (yes/no) question? Let's ask Carol. If she says “yes”, she's saying that “no” is the correct answer for her, so “yes” is incorrect. If she says “no”, she's saying that she cannot correctly answer “no”, which is her answer. We are assuming for this and all subsequent questions that the only acceptable answers are “yes” and “no”, and in this case, both answers are incorrect. Carol cannot answer the question correctly. Now let's ask Dave. He says “no”, and he is correct because Carol cannot correctly answer “no”. So (6) is subjective because it is a consistent, satisfiable specification for some agent (anyone other than Carol), and *an inconsistent, unsatisfiable specification for some agent* (Carol). https://www.cs.toronto.edu/~hehner/OSS.pdf -- Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-08 09:03 -0400 |
| Subject | Re: Halting Problem is wrong two different ways |
| Message-ID | <v41kqp$3cg3t$7@i2pn2.org> |
| In reply to | #106644 |
On 6/8/24 8:35 AM, olcott wrote: > On 6/8/2024 1:06 AM, Mikko wrote: >> On 2024-06-07 14:09:54 +0000, olcott said: >> >>> On 6/7/2024 1:22 AM, Mikko wrote: >>>> On 2024-06-06 15:18:21 +0000, olcott said: >>>>> >>>>> *Here is that problem statement* >>>>> Prove that sum(3,4) is incorrect on the basis that >>>>> sum(3,4) cannot and does not provide the sum of 5 + 6. >>>> >>>> That problem statement does not restrict what another >>>> problem statement may specify. >>>> >>> >>> It is an analogy. >> >> It is not analogous to anything relevant, nor was it presented >> as a relevant or other analog. >> >>> All halt deciders are only allowed to report on the actual >>> behavior of their actual input. >> >> That does not restrict what a problem statement may specify. >> >>> I have proven right here that the actual behavior of the actual >>> input is that it remains stuck in recursive simulation. >> >> That does not restrict what a problem statement may specify. >> > > *It does restrict what a correct problem statement can specify* > > Objective and Subjective Specifications > Eric C.R. Hehner > Department of Computer Science, University of Toronto > > (6) Can Carol correctly answer “no” to this (yes/no) question? > Let's ask Carol. If she says “yes”, she's saying that “no” is the > correct answer for her, so “yes” is incorrect. If she says “no”, she's > saying that she cannot correctly answer “no”, which is her answer. We > are assuming for this and all subsequent questions that the only > acceptable answers are “yes” and “no”, and in this case, both answers > are incorrect. Carol cannot answer the question correctly. Now let's ask > Dave. He says “no”, and he is correct because Carol cannot correctly > answer “no”. So (6) is subjective because it is a consistent, > satisfiable specification for some agent (anyone other than Carol), and > *an inconsistent, unsatisfiable specification for some agent* (Carol). > https://www.cs.toronto.edu/~hehner/OSS.pdf > > Right, but the Halting Question isn't subjective at all. Note, there is an objective difference between asking a voltional being a question, and a deterministic machine a question.
[toc] | [prev] | [next] | [standalone]
| From | immibis <news@immibis.com> |
|---|---|
| Date | 2024-06-07 16:25 +0200 |
| Subject | Re: Halting Problem is wrong two different ways |
| Message-ID | <v3v597$1o9el$2@dont-email.me> |
| In reply to | #106310 |
On 5/06/24 15:18, olcott wrote:
> On 6/5/2024 2:13 AM, Mikko wrote:
>> On 2024-06-04 17:40:47 +0000, olcott said:
>>
>> Nice to see that you don't disagree with my observation that
>> your statement
>>
>>>>>>> Deciders only compute the mapping *from their inputs* to their own
>>>>>>> accept or reject state.
>>
>> does not restrict what a problem statement can specify.
>>
>
> Sure it does.
> int sum(int x, int y) { return x + y; }
> sum(3,4) cannot correctly return the sum of 5 + 6.
According to you, the correct simulation simulate(sum,3,4) can correctly
return the sum of 5+6.
[toc] | [prev] | [next] | [standalone]
| From | immibis <news@immibis.com> |
|---|---|
| Date | 2024-06-04 16:38 +0200 |
| Subject | Re: Why does Olcott care about simulation, anyway? --- Ben's Review |
| Message-ID | <v3n8sm$1ot7$2@dont-email.me> |
| In reply to | #106159 |
On 3/06/24 20:14, olcott wrote:
> On 6/3/2024 9:27 AM, Mikko wrote:
>> On 2024-06-03 12:20:01 +0000, olcott said:
>>
>>> On 6/3/2024 4:42 AM, Ben Bacarisse wrote:
>>>> Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
>>>>
>>>>> PO's D(D) halts, as illustrated in various traces that have been
>>>>> posted here.
>>>>> PO's H(D,D) returns 0 : [NOT halting] also as illustrated in
>>>>> various traces.
>>>>> i.e. exactly as the Linz proof claims. PO has acknowledged both these
>>>>> results. Same for the HH/DD variants.
>>>>>
>>>>> You might imagine that's the end of the matter - PO failed. :)
>>>>>
>>>>> That's right, but PO just carries on anyway!
>>>>
>>>> He has quite explicitly stated that false (0) is the correct result for
>>>> H(D,D) "even though D(D) halts". I am mystified why anyone
>>>> continues to
>>>> discuss the matter until he equally explicitly repudiates that claim.
>>>>
>>>
>>> Deciders only compute the mapping *from their inputs* to their own
>>> accept or reject state.
>>
>> That does not restrict what a problem statement can specify.
>> If the computed mapping differs from the specified one the
>> decider does not solve the problem.
>>
>
> int sum(int x, int y) { return x + y; }
> sum(2,3) cannot return the sum of 5 + 6.
>
> DD correctly simulated by HH does have provably
> different behavior than DD(DD) so HH is is not
> allowed to report on the behavior of DD(DD).
>
2+3=5, but the input to sum(2,3) specifies 5+6.
[toc] | [prev] | [next] | [standalone]
| From | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2024-06-03 22:09 +0200 |
| Subject | Re: Why does Olcott care about simulation, anyway? --- Ben's Review |
| Message-ID | <v3l7uo$13cp$8@dont-email.me> |
| In reply to | #106124 |
Op 03.jun.2024 om 14:20 schreef olcott:
> On 6/3/2024 4:42 AM, Ben Bacarisse wrote:
>> Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
>>
>>> PO's D(D) halts, as illustrated in various traces that have been
>>> posted here.
>>> PO's H(D,D) returns 0 : [NOT halting] also as illustrated in various
>>> traces.
>>> i.e. exactly as the Linz proof claims. PO has acknowledged both these
>>> results. Same for the HH/DD variants.
>>>
>>> You might imagine that's the end of the matter - PO failed. :)
>>>
>>> That's right, but PO just carries on anyway!
>>
>> He has quite explicitly stated that false (0) is the correct result for
>> H(D,D) "even though D(D) halts". I am mystified why anyone continues to
>> discuss the matter until he equally explicitly repudiates that claim.
>>
>
> Deciders only compute the mapping *from their inputs* to their own
> accept or reject state. The correct emulation of the machine code input
> to H(DD,DD) requires DD emulated by HH to emulate each x86 instruction
> of the x86 machine code of DD correctly and in the correct order.
>
> *The input to HH(DD,DD) specifies non-halting behavior*
>
> The only way to cause DD emulated by HH to have the same behavior as
> the directly executed (non input) DD(DD) is to emulate the instructions
> specified by the machine code of DD incorrectly or in the incorrect
> order. *This is not the behavior that the input to HH(DD,DD) specifies*
>
> The behavior of the directly executed DD(DD) has different behavior
> than DD correctly emulated by HH. This is because the behavior of DD(DD)
> reaps the benefits of HH having already aborted its simulation.
>
> No one ever noticed that these two behaviors could ever diverge before
> because everyone rejected the notion of a simulating halt decider out-
> of-hand without review.
>
>
>
> Two PhD computer science professors that I have communicated with
> agree with me that there is something wrong with the halting problem.
>
> Bill Stoddart. *The Halting Paradox*
> 20 December 2017
> https://arxiv.org/abs/1906.05340
> arXiv:1906.05340 [cs.LO]
>
> E C R Hehner. *Problems with the Halting Problem*, COMPUTING2011
> Symposium on 75 years of Turing Machine and Lambda-Calculus, Karlsruhe
> Germany, invited, 2011 October 20-21; Advances in Computer Science and
> Engineering v.10 n.1 p.31-60, 2013
> https://www.cs.toronto.edu/~hehner/PHP.pdf
>
> E C R Hehner. *Objective and Subjective Specifications*
> WST Workshop on Termination, Oxford. 2018 July 18.
> See https://www.cs.toronto.edu/~hehner/OSS.pdf
>
>
>
> *Introduction to the Theory of Computation, by Michael Sipser*
> https://www.amazon.com/Introduction-Theory-Computation-Michael-Sipser/dp/113318779X/
>
> On 10/13/2022 11:29:23 AM
> MIT Professor Michael Sipser agreed this verbatim paragraph is correct
> (He has neither reviewed nor agreed to anything else in this paper)
>
> <Professor Sipser agreed>
> 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.
> </Professor Sipser agreed>
>
>
>
> *DD correctly simulated by HH would never stop running unless aborted*
> *We can see that the following DD cannot possibly halt when*
> *correctly simulated by every HH that can possibly exist*
It is very clear that if the simulated HH would halt, then DD would
halt. So your claim comes down to HH not halting when simulating itself.
It also shows that the simulator does not even reach the pathological
part (lines 04, 05 and 06) of DD, where it contradicts the result of HH.
Your own claim is that these lines are not processed by the simulator.
The simulator is unable to process anything past the call to itself.
This shows that by introducing a simulation, you introduced another
non-halting problem. Every function that calls HH, even when it does not
contradict HH are suddenly non-halting. This non-halting problem is very
different from the one in the Linz proof.
>
> typedef int (*ptr)(); // ptr is pointer to int function in C
> 00 int HH(ptr p, ptr i);
> 01 int DD(ptr p)
> 02 {
> 03 int Halt_Status = HH(p, p);
> 04 if (Halt_Status)
> 05 HERE: goto HERE;
> 06 return Halt_Status;
> 07 }
>
> _DD()
> [00001c22] 55 push ebp
> [00001c23] 8bec mov ebp,esp
> [00001c25] 51 push ecx
> [00001c26] 8b4508 mov eax,[ebp+08]
> [00001c29] 50 push eax ; push DD 1c22
> [00001c2a] 8b4d08 mov ecx,[ebp+08]
> [00001c2d] 51 push ecx ; push DD 1c22
> [00001c2e] e80ff7ffff call 00001342 ; call HH
> [00001c33] 83c408 add esp,+08
> [00001c36] 8945fc mov [ebp-04],eax
> [00001c39] 837dfc00 cmp dword [ebp-04],+00
> [00001c3d] 7402 jz 00001c41
> [00001c3f] ebfe jmp 00001c3f
> [00001c41] 8b45fc mov eax,[ebp-04]
> [00001c44] 8be5 mov esp,ebp
> [00001c46] 5d pop ebp
> [00001c47] c3 ret
> Size in bytes:(0038) [00001c47]
>
>
>
>>> So really, there's no /need/ to "refute" everything he says - the end
>>> result will be exactly the same as just ignoring him, BUT WITH THE
>>> LATTER
>>> ONLY NEEDING 0.1% OF THE EFFORT and eliminating 99.9% of the posting
>>> clutter in these newsgroups. [ok, comp.theory will die pretty
>>> quickly, but
>>> it is not discussing anything useful, so that's ok for most people...
>>> (with
>>> some reluctance)]
>>
>> Do we know that? There's the start of a discussion of quines on
>> comp.lang.c that probably belongs here, but no will dare come here to
>> discuss it because of all the junk.
>>
>
> You cannot show any mistake in what I said above because all you
> have is bluster and dogma. What I am saying is just not the way
> that you memorized it !
>
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-03 16:24 -0500 |
| Subject | Mike Terry Reply to Fred Zwarts |
| Message-ID | <v3lcat$228t$3@dont-email.me> |
| In reply to | #106176 |
On 6/3/2024 3:09 PM, Fred. Zwarts wrote: > Op 03.jun.2024 om 14:20 schreef olcott: >> On 6/3/2024 4:42 AM, Ben Bacarisse wrote: >>> Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes: >>> >>>> PO's D(D) halts, as illustrated in various traces that have been >>>> posted here. >>>> PO's H(D,D) returns 0 : [NOT halting] also as illustrated in various >>>> traces. >>>> i.e. exactly as the Linz proof claims. PO has acknowledged both these >>>> results. Same for the HH/DD variants. >>>> >>>> You might imagine that's the end of the matter - PO failed. :) >>>> >>>> That's right, but PO just carries on anyway! >>> >>> He has quite explicitly stated that false (0) is the correct result for >>> H(D,D) "even though D(D) halts". I am mystified why anyone continues to >>> discuss the matter until he equally explicitly repudiates that claim. >>> >> >> Deciders only compute the mapping *from their inputs* to their own >> accept or reject state. The correct emulation of the machine code input >> to H(DD,DD) requires DD emulated by HH to emulate each x86 instruction >> of the x86 machine code of DD correctly and in the correct order. >> >> *The input to HH(DD,DD) specifies non-halting behavior* >> >> The only way to cause DD emulated by HH to have the same behavior as >> the directly executed (non input) DD(DD) is to emulate the instructions >> specified by the machine code of DD incorrectly or in the incorrect >> order. *This is not the behavior that the input to HH(DD,DD) specifies* >> >> The behavior of the directly executed DD(DD) has different behavior >> than DD correctly emulated by HH. This is because the behavior of DD(DD) >> reaps the benefits of HH having already aborted its simulation. >> >> No one ever noticed that these two behaviors could ever diverge before >> because everyone rejected the notion of a simulating halt decider out- >> of-hand without review. >> >> >> >> Two PhD computer science professors that I have communicated with >> agree with me that there is something wrong with the halting problem. >> >> Bill Stoddart. *The Halting Paradox* >> 20 December 2017 >> https://arxiv.org/abs/1906.05340 >> arXiv:1906.05340 [cs.LO] >> >> E C R Hehner. *Problems with the Halting Problem*, COMPUTING2011 >> Symposium on 75 years of Turing Machine and Lambda-Calculus, Karlsruhe >> Germany, invited, 2011 October 20-21; Advances in Computer Science and >> Engineering v.10 n.1 p.31-60, 2013 >> https://www.cs.toronto.edu/~hehner/PHP.pdf >> >> E C R Hehner. *Objective and Subjective Specifications* >> WST Workshop on Termination, Oxford. 2018 July 18. >> See https://www.cs.toronto.edu/~hehner/OSS.pdf >> >> >> >> *Introduction to the Theory of Computation, by Michael Sipser* >> https://www.amazon.com/Introduction-Theory-Computation-Michael-Sipser/dp/113318779X/ >> >> On 10/13/2022 11:29:23 AM >> MIT Professor Michael Sipser agreed this verbatim paragraph is correct >> (He has neither reviewed nor agreed to anything else in this paper) >> >> <Professor Sipser agreed> >> 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. >> </Professor Sipser agreed> >> >> >> >> *DD correctly simulated by HH would never stop running unless aborted* >> *We can see that the following DD cannot possibly halt when* >> *correctly simulated by every HH that can possibly exist* > > It is very clear that if the simulated HH would halt, then DD would > halt. So your claim comes down to HH not halting when simulating itself. > Mike Terry replied to this and explained it correctly as reply directly to you On 6/3/2024 12:36 PM, Mike Terry wrote: http://al.howardknight.net/?STYPE=msgid&MSGI=%3CHlGdnbvc3Ly_YsD7nZ2dnZfqn_adnZ2d%40brightview.co.uk%3E -- 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 | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2024-06-04 12:29 +0200 |
| Subject | Re: Mike Terry Reply to Fred Zwarts |
| Message-ID | <v3mq9j$chc3$1@dont-email.me> |
| In reply to | #106182 |
Op 03.jun.2024 om 23:24 schreef olcott: > On 6/3/2024 3:09 PM, Fred. Zwarts wrote: >> Op 03.jun.2024 om 14:20 schreef olcott: >>> On 6/3/2024 4:42 AM, Ben Bacarisse wrote: >>>> Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes: >>>> >>>>> PO's D(D) halts, as illustrated in various traces that have been >>>>> posted here. >>>>> PO's H(D,D) returns 0 : [NOT halting] also as illustrated in >>>>> various traces. >>>>> i.e. exactly as the Linz proof claims. PO has acknowledged both these >>>>> results. Same for the HH/DD variants. >>>>> >>>>> You might imagine that's the end of the matter - PO failed. :) >>>>> >>>>> That's right, but PO just carries on anyway! >>>> >>>> He has quite explicitly stated that false (0) is the correct result for >>>> H(D,D) "even though D(D) halts". I am mystified why anyone >>>> continues to >>>> discuss the matter until he equally explicitly repudiates that claim. >>>> >>> >>> Deciders only compute the mapping *from their inputs* to their own >>> accept or reject state. The correct emulation of the machine code input >>> to H(DD,DD) requires DD emulated by HH to emulate each x86 instruction >>> of the x86 machine code of DD correctly and in the correct order. >>> >>> *The input to HH(DD,DD) specifies non-halting behavior* >>> >>> The only way to cause DD emulated by HH to have the same behavior as >>> the directly executed (non input) DD(DD) is to emulate the instructions >>> specified by the machine code of DD incorrectly or in the incorrect >>> order. *This is not the behavior that the input to HH(DD,DD) specifies* >>> >>> The behavior of the directly executed DD(DD) has different behavior >>> than DD correctly emulated by HH. This is because the behavior of DD(DD) >>> reaps the benefits of HH having already aborted its simulation. >>> >>> No one ever noticed that these two behaviors could ever diverge before >>> because everyone rejected the notion of a simulating halt decider out- >>> of-hand without review. >>> >>> >>> >>> Two PhD computer science professors that I have communicated with >>> agree with me that there is something wrong with the halting problem. >>> >>> Bill Stoddart. *The Halting Paradox* >>> 20 December 2017 >>> https://arxiv.org/abs/1906.05340 >>> arXiv:1906.05340 [cs.LO] >>> >>> E C R Hehner. *Problems with the Halting Problem*, COMPUTING2011 >>> Symposium on 75 years of Turing Machine and Lambda-Calculus, >>> Karlsruhe Germany, invited, 2011 October 20-21; Advances in Computer >>> Science and Engineering v.10 n.1 p.31-60, 2013 >>> https://www.cs.toronto.edu/~hehner/PHP.pdf >>> >>> E C R Hehner. *Objective and Subjective Specifications* >>> WST Workshop on Termination, Oxford. 2018 July 18. >>> See https://www.cs.toronto.edu/~hehner/OSS.pdf >>> >>> >>> >>> *Introduction to the Theory of Computation, by Michael Sipser* >>> https://www.amazon.com/Introduction-Theory-Computation-Michael-Sipser/dp/113318779X/ >>> >>> On 10/13/2022 11:29:23 AM >>> MIT Professor Michael Sipser agreed this verbatim paragraph is correct >>> (He has neither reviewed nor agreed to anything else in this paper) >>> >>> <Professor Sipser agreed> >>> 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. >>> </Professor Sipser agreed> >>> >>> >>> >>> *DD correctly simulated by HH would never stop running unless aborted* >>> *We can see that the following DD cannot possibly halt when* >>> *correctly simulated by every HH that can possibly exist* >> >> It is very clear that if the simulated HH would halt, then DD would >> halt. So your claim comes down to HH not halting when simulating itself. >> > > Mike Terry replied to this and explained it correctly > as reply directly to you > On 6/3/2024 12:36 PM, Mike Terry wrote: > > http://al.howardknight.net/?STYPE=msgid&MSGI=%3CHlGdnbvc3Ly_YsD7nZ2dnZfqn_adnZ2d%40brightview.co.uk%3E > He says that there is no infinite recursion, because the simulation is aborted. If you want to interpret his reply in this way, then it also shows that neither HH, nor DD are involved in a recursive recursion. This implies that none of them reaches their final state. This, according to your own words means, that it is correct to report that both are non-halting.
[toc] | [prev] | [next] | [standalone]
| From | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2024-06-04 12:52 +0200 |
| Subject | Re: Mike Terry Reply to Fred Zwarts |
| Message-ID | <v3mrli$chc4$1@dont-email.me> |
| In reply to | #106234 |
Op 04.jun.2024 om 12:29 schreef Fred. Zwarts: > Op 03.jun.2024 om 23:24 schreef olcott: >> On 6/3/2024 3:09 PM, Fred. Zwarts wrote: >>> Op 03.jun.2024 om 14:20 schreef olcott: >>>> On 6/3/2024 4:42 AM, Ben Bacarisse wrote: >>>>> Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes: >>>>> >>>>>> PO's D(D) halts, as illustrated in various traces that have been >>>>>> posted here. >>>>>> PO's H(D,D) returns 0 : [NOT halting] also as illustrated in >>>>>> various traces. >>>>>> i.e. exactly as the Linz proof claims. PO has acknowledged both >>>>>> these >>>>>> results. Same for the HH/DD variants. >>>>>> >>>>>> You might imagine that's the end of the matter - PO failed. :) >>>>>> >>>>>> That's right, but PO just carries on anyway! >>>>> >>>>> He has quite explicitly stated that false (0) is the correct result >>>>> for >>>>> H(D,D) "even though D(D) halts". I am mystified why anyone >>>>> continues to >>>>> discuss the matter until he equally explicitly repudiates that claim. >>>>> >>>> >>>> Deciders only compute the mapping *from their inputs* to their own >>>> accept or reject state. The correct emulation of the machine code input >>>> to H(DD,DD) requires DD emulated by HH to emulate each x86 instruction >>>> of the x86 machine code of DD correctly and in the correct order. >>>> >>>> *The input to HH(DD,DD) specifies non-halting behavior* >>>> >>>> The only way to cause DD emulated by HH to have the same behavior as >>>> the directly executed (non input) DD(DD) is to emulate the instructions >>>> specified by the machine code of DD incorrectly or in the incorrect >>>> order. *This is not the behavior that the input to HH(DD,DD) specifies* >>>> >>>> The behavior of the directly executed DD(DD) has different behavior >>>> than DD correctly emulated by HH. This is because the behavior of >>>> DD(DD) >>>> reaps the benefits of HH having already aborted its simulation. >>>> >>>> No one ever noticed that these two behaviors could ever diverge before >>>> because everyone rejected the notion of a simulating halt decider out- >>>> of-hand without review. >>>> >>>> >>>> >>>> Two PhD computer science professors that I have communicated with >>>> agree with me that there is something wrong with the halting problem. >>>> >>>> Bill Stoddart. *The Halting Paradox* >>>> 20 December 2017 >>>> https://arxiv.org/abs/1906.05340 >>>> arXiv:1906.05340 [cs.LO] >>>> >>>> E C R Hehner. *Problems with the Halting Problem*, COMPUTING2011 >>>> Symposium on 75 years of Turing Machine and Lambda-Calculus, >>>> Karlsruhe Germany, invited, 2011 October 20-21; Advances in Computer >>>> Science and Engineering v.10 n.1 p.31-60, 2013 >>>> https://www.cs.toronto.edu/~hehner/PHP.pdf >>>> >>>> E C R Hehner. *Objective and Subjective Specifications* >>>> WST Workshop on Termination, Oxford. 2018 July 18. >>>> See https://www.cs.toronto.edu/~hehner/OSS.pdf >>>> >>>> >>>> >>>> *Introduction to the Theory of Computation, by Michael Sipser* >>>> https://www.amazon.com/Introduction-Theory-Computation-Michael-Sipser/dp/113318779X/ >>>> >>>> On 10/13/2022 11:29:23 AM >>>> MIT Professor Michael Sipser agreed this verbatim paragraph is correct >>>> (He has neither reviewed nor agreed to anything else in this paper) >>>> >>>> <Professor Sipser agreed> >>>> 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. >>>> </Professor Sipser agreed> >>>> >>>> >>>> >>>> *DD correctly simulated by HH would never stop running unless aborted* >>>> *We can see that the following DD cannot possibly halt when* >>>> *correctly simulated by every HH that can possibly exist* >>> >>> It is very clear that if the simulated HH would halt, then DD would >>> halt. So your claim comes down to HH not halting when simulating itself. >>> >> >> Mike Terry replied to this and explained it correctly >> as reply directly to you >> On 6/3/2024 12:36 PM, Mike Terry wrote: >> >> http://al.howardknight.net/?STYPE=msgid&MSGI=%3CHlGdnbvc3Ly_YsD7nZ2dnZfqn_adnZ2d%40brightview.co.uk%3E >> > > He says that there is no infinite recursion, because the simulation is > aborted. > If you want to interpret his reply in this way, then it also shows that > neither HH, nor DD are involved in a recursive recursion. This implies That should be: ... are involved in an infinite recursion, because the simulation was aborted, which implies ... > that none of them reaches their final state. This, according to your own > words means, that it is correct to report that both are non-halting.
[toc] | [prev] | [next] | [standalone]
| From | Mike Terry <news.dead.person.stones@darjeeling.plus.com> |
|---|---|
| Date | 2024-06-04 17:58 +0100 |
| Subject | Re: Mike Terry Reply to Fred Zwarts |
| Message-ID | <_gWdnbwuZPJP2sL7nZ2dnZfqn_GdnZ2d@brightview.co.uk> |
| In reply to | #106235 |
On 04/06/2024 11:52, Fred. Zwarts wrote:
> Op 04.jun.2024 om 12:29 schreef Fred. Zwarts:
>> Op 03.jun.2024 om 23:24 schreef olcott:
>>> On 6/3/2024 3:09 PM, Fred. Zwarts wrote:
>>>> Op 03.jun.2024 om 14:20 schreef olcott:
>>>>> On 6/3/2024 4:42 AM, Ben Bacarisse wrote:
>>>>>> Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
>>>>>>
>>>>>>> PO's D(D) halts, as illustrated in various traces that have been posted here.
>>>>>>> PO's H(D,D) returns 0 : [NOT halting] also as illustrated in various traces.
>>>>>>> i.e. exactly as the Linz proof claims. PO has acknowledged both these
>>>>>>> results. Same for the HH/DD variants.
>>>>>>>
>>>>>>> You might imagine that's the end of the matter - PO failed. :)
>>>>>>>
>>>>>>> That's right, but PO just carries on anyway!
>>>>>>
>>>>>> He has quite explicitly stated that false (0) is the correct result for
>>>>>> H(D,D) "even though D(D) halts". I am mystified why anyone continues to
>>>>>> discuss the matter until he equally explicitly repudiates that claim.
>>>>>>
>>>>>
>>>>> Deciders only compute the mapping *from their inputs* to their own
>>>>> accept or reject state. The correct emulation of the machine code input
>>>>> to H(DD,DD) requires DD emulated by HH to emulate each x86 instruction
>>>>> of the x86 machine code of DD correctly and in the correct order.
>>>>>
>>>>> *The input to HH(DD,DD) specifies non-halting behavior*
>>>>>
>>>>> The only way to cause DD emulated by HH to have the same behavior as
>>>>> the directly executed (non input) DD(DD) is to emulate the instructions
>>>>> specified by the machine code of DD incorrectly or in the incorrect
>>>>> order. *This is not the behavior that the input to HH(DD,DD) specifies*
>>>>>
>>>>> The behavior of the directly executed DD(DD) has different behavior
>>>>> than DD correctly emulated by HH. This is because the behavior of DD(DD)
>>>>> reaps the benefits of HH having already aborted its simulation.
>>>>>
>>>>> No one ever noticed that these two behaviors could ever diverge before
>>>>> because everyone rejected the notion of a simulating halt decider out-
>>>>> of-hand without review.
>>>>>
>>>>>
>>>>>
>>>>> Two PhD computer science professors that I have communicated with
>>>>> agree with me that there is something wrong with the halting problem.
>>>>>
>>>>> Bill Stoddart. *The Halting Paradox*
>>>>> 20 December 2017
>>>>> https://arxiv.org/abs/1906.05340
>>>>> arXiv:1906.05340 [cs.LO]
>>>>>
>>>>> E C R Hehner. *Problems with the Halting Problem*, COMPUTING2011 Symposium on 75 years of
>>>>> Turing Machine and Lambda-Calculus, Karlsruhe Germany, invited, 2011 October 20-21; Advances in
>>>>> Computer Science and Engineering v.10 n.1 p.31-60, 2013
>>>>> https://www.cs.toronto.edu/~hehner/PHP.pdf
>>>>>
>>>>> E C R Hehner. *Objective and Subjective Specifications*
>>>>> WST Workshop on Termination, Oxford. 2018 July 18.
>>>>> See https://www.cs.toronto.edu/~hehner/OSS.pdf
>>>>>
>>>>>
>>>>>
>>>>> *Introduction to the Theory of Computation, by Michael Sipser*
>>>>> https://www.amazon.com/Introduction-Theory-Computation-Michael-Sipser/dp/113318779X/
>>>>>
>>>>> On 10/13/2022 11:29:23 AM
>>>>> MIT Professor Michael Sipser agreed this verbatim paragraph is correct
>>>>> (He has neither reviewed nor agreed to anything else in this paper)
>>>>>
>>>>> <Professor Sipser agreed>
>>>>> 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.
>>>>> </Professor Sipser agreed>
>>>>>
>>>>>
>>>>>
>>>>> *DD correctly simulated by HH would never stop running unless aborted*
>>>>> *We can see that the following DD cannot possibly halt when*
>>>>> *correctly simulated by every HH that can possibly exist*
>>>>
>>>> It is very clear that if the simulated HH would halt, then DD would halt. So your claim comes
>>>> down to HH not halting when simulating itself.
>>>>
>>>
>>> Mike Terry replied to this and explained it correctly
>>> as reply directly to you
>>> On 6/3/2024 12:36 PM, Mike Terry wrote:
>>>
>>> http://al.howardknight.net/?STYPE=msgid&MSGI=%3CHlGdnbvc3Ly_YsD7nZ2dnZfqn_adnZ2d%40brightview.co.uk%3E
>>>
>>>
>>
>> He says that there is no infinite recursion, because the simulation is aborted.
>> If you want to interpret his reply in this way,
Yes, that's my intended meaning
> then it also shows that neither HH, nor DD are
>> involved in a recursive recursion. This implies
>
> That should be: ... are involved in an infinite recursion, because the simulation was aborted,
Yes. (There is finite recursive simulation, i.e. H partially simulates H etc..)
> which
> implies ...
>
>> that none of them reaches their final state.
None of their /simulations by H/ reach their final state. Obviously there's a huge distinction
between the abstract concept of a computation/halting, and a partial simulation of that computation
by some other program, and I'm surprised anyone (not you specifically) tolerates confusion on that
point.
Suppose P(I) is some computation that halts after 13422 steps. Clearly a partial simulation of P(I)
by H could be abandoned ("aborted") after 8333 steps. So the /partial simulation by H/ "does not
halt", but the computation P(I) of course halts.
I'm not trying to suggest that considering the "halting" behaviour of a partial simulation by a
specific program is a /useful/ thing to be looking at, but none the less that is what PO is doing...
In the case of PO's actual H (that supposedly refutes the Linz proof), D(D) halts, and H's partial
simulation of D(D) is aborted before D halts, with H proceeding to decide non-halting. [We have
previously had the figures for the number of steps D takes before halting, and the number of steps H
simulates before aborting. No surprise the latter is less than the former.]
There is nothing remotely mysterious or puzzling about any of this, unless you are PO and confuse
(actual) halting with what happens in partial simulations by particular programs. That is an
example of PO brain-wiring lacking the ability to understand the /abstract/ concepts of
"computation" and "halting", so he tries to replace them with some more concrete (but ultimately
incoherent) notion of "behaviour of partial simulations by some particular decider program running
in some physical machine", which he thinks is the "real/proper" definition.
The concepts of computations/simulations/halting behaviour as above must all be quite obvous to you,
maybe with alternative choice of terminology, but sometimes your wording just seems ambiguous to me.
E.g. "none of them reaches their final state" sounds like you're talking about the computation
itself rather than some simulation.
Mike.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-04 13:02 -0500 |
| Subject | How Partial Simulations correctly determine non-halting ---Mike Terry Error |
| Message-ID | <v3nkqr$h7f9$3@dont-email.me> |
| In reply to | #106245 |
On 6/4/2024 11:58 AM, Mike Terry wrote:
> On 04/06/2024 11:52, Fred. Zwarts wrote:
>> Op 04.jun.2024 om 12:29 schreef Fred. Zwarts:
>>> Op 03.jun.2024 om 23:24 schreef olcott:
>>>> On 6/3/2024 3:09 PM, Fred. Zwarts wrote:
>>>>> Op 03.jun.2024 om 14:20 schreef olcott:
>>>>>> On 6/3/2024 4:42 AM, Ben Bacarisse wrote:
>>>>>>> Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
>>>>>>>
>>>>>>>> PO's D(D) halts, as illustrated in various traces that have been
>>>>>>>> posted here.
>>>>>>>> PO's H(D,D) returns 0 : [NOT halting] also as illustrated in
>>>>>>>> various traces.
>>>>>>>> i.e. exactly as the Linz proof claims. PO has acknowledged both
>>>>>>>> these
>>>>>>>> results. Same for the HH/DD variants.
>>>>>>>>
>>>>>>>> You might imagine that's the end of the matter - PO failed. :)
>>>>>>>>
>>>>>>>> That's right, but PO just carries on anyway!
>>>>>>>
>>>>>>> He has quite explicitly stated that false (0) is the correct
>>>>>>> result for
>>>>>>> H(D,D) "even though D(D) halts". I am mystified why anyone
>>>>>>> continues to
>>>>>>> discuss the matter until he equally explicitly repudiates that
>>>>>>> claim.
>>>>>>>
>>>>>>
>>>>>> Deciders only compute the mapping *from their inputs* to their own
>>>>>> accept or reject state. The correct emulation of the machine code
>>>>>> input
>>>>>> to H(DD,DD) requires DD emulated by HH to emulate each x86
>>>>>> instruction
>>>>>> of the x86 machine code of DD correctly and in the correct order.
>>>>>>
>>>>>> *The input to HH(DD,DD) specifies non-halting behavior*
>>>>>>
>>>>>> The only way to cause DD emulated by HH to have the same behavior as
>>>>>> the directly executed (non input) DD(DD) is to emulate the
>>>>>> instructions
>>>>>> specified by the machine code of DD incorrectly or in the incorrect
>>>>>> order. *This is not the behavior that the input to HH(DD,DD)
>>>>>> specifies*
>>>>>>
>>>>>> The behavior of the directly executed DD(DD) has different behavior
>>>>>> than DD correctly emulated by HH. This is because the behavior of
>>>>>> DD(DD)
>>>>>> reaps the benefits of HH having already aborted its simulation.
>>>>>>
>>>>>> No one ever noticed that these two behaviors could ever diverge
>>>>>> before
>>>>>> because everyone rejected the notion of a simulating halt decider
>>>>>> out-
>>>>>> of-hand without review.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Two PhD computer science professors that I have communicated with
>>>>>> agree with me that there is something wrong with the halting problem.
>>>>>>
>>>>>> Bill Stoddart. *The Halting Paradox*
>>>>>> 20 December 2017
>>>>>> https://arxiv.org/abs/1906.05340
>>>>>> arXiv:1906.05340 [cs.LO]
>>>>>>
>>>>>> E C R Hehner. *Problems with the Halting Problem*, COMPUTING2011
>>>>>> Symposium on 75 years of Turing Machine and Lambda-Calculus,
>>>>>> Karlsruhe Germany, invited, 2011 October 20-21; Advances in
>>>>>> Computer Science and Engineering v.10 n.1 p.31-60, 2013
>>>>>> https://www.cs.toronto.edu/~hehner/PHP.pdf
>>>>>>
>>>>>> E C R Hehner. *Objective and Subjective Specifications*
>>>>>> WST Workshop on Termination, Oxford. 2018 July 18.
>>>>>> See https://www.cs.toronto.edu/~hehner/OSS.pdf
>>>>>>
>>>>>>
>>>>>>
>>>>>> *Introduction to the Theory of Computation, by Michael Sipser*
>>>>>> https://www.amazon.com/Introduction-Theory-Computation-Michael-Sipser/dp/113318779X/
>>>>>>
>>>>>> On 10/13/2022 11:29:23 AM
>>>>>> MIT Professor Michael Sipser agreed this verbatim paragraph is
>>>>>> correct
>>>>>> (He has neither reviewed nor agreed to anything else in this paper)
>>>>>>
>>>>>> <Professor Sipser agreed>
>>>>>> 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.
>>>>>> </Professor Sipser agreed>
>>>>>>
>>>>>>
>>>>>>
>>>>>> *DD correctly simulated by HH would never stop running unless
>>>>>> aborted*
>>>>>> *We can see that the following DD cannot possibly halt when*
>>>>>> *correctly simulated by every HH that can possibly exist*
>>>>>
>>>>> It is very clear that if the simulated HH would halt, then DD would
>>>>> halt. So your claim comes down to HH not halting when simulating
>>>>> itself.
>>>>>
>>>>
>>>> Mike Terry replied to this and explained it correctly
>>>> as reply directly to you
>>>> On 6/3/2024 12:36 PM, Mike Terry wrote:
>>>>
>>>> http://al.howardknight.net/?STYPE=msgid&MSGI=%3CHlGdnbvc3Ly_YsD7nZ2dnZfqn_adnZ2d%40brightview.co.uk%3E
>>>>
>>>
>>> He says that there is no infinite recursion, because the simulation
>>> is aborted.
>>> If you want to interpret his reply in this way,
>
> Yes, that's my intended meaning
>
>> then it also shows that neither HH, nor DD are
>>> involved in a recursive recursion. This implies
>>
>> That should be: ... are involved in an infinite recursion, because the
>> simulation was aborted,
>
> Yes. (There is finite recursive simulation, i.e. H partially simulates
> H etc..)
>
>> which implies ...
>>
>>> that none of them reaches their final state.
>
> None of their /simulations by H/ reach their final state. Obviously
> there's a huge distinction between the abstract concept of a
> computation/halting, and a partial simulation of that computation by
> some other program, and I'm surprised anyone (not you specifically)
> tolerates confusion on that point.
>
> Suppose P(I) is some computation that halts after 13422 steps. Clearly
> a partial simulation of P(I) by H could be abandoned ("aborted") after
> 8333 steps. So the /partial simulation by H/ "does not halt", but the
> computation P(I) of course halts.
>
> I'm not trying to suggest that considering the "halting" behaviour of a
> partial simulation by a specific program is a /useful/ thing to be
> looking at, but none the less that is what PO is doing...
>
The meaning of these words prove that I am correct about how partial
simulations correctly determine the halt status of their non-halting
inputs.
Those words are dead obviously correct about how a partial simulation
does correctly determine the halt status of this function:
void Infinite_Recursion2(u32 N)
{
H(Infinite_Recursion2, (ptr)N);
}
That you continue to insist that either I misinterpreted my own
words or professor Sipser interpreted them differently than their
meaning that would correctly determine the halt status of the
above example at this point seem quite disingenuous especially
when you provide zero reasoning to support this "misinterpretation"
assertion.
*HOW PARTIAL SIMULATIONS CORRECTLY DETERMINE NON-HALTING*
On 10/13/2022 11:29:23 AM
MIT Professor Michael Sipser agreed this verbatim paragraph is correct
(He has neither reviewed nor agreed to anything else in this paper)
<Professor Sipser agreed>
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.
</Professor Sipser agreed>
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | joes <noreply@example.com> |
|---|---|
| Date | 2024-06-04 21:26 +0000 |
| Subject | Re: How Partial Simulations correctly determine non-halting ---Mike Terry Error |
| Message-ID | <v3o0ph$31rmn$1@i2pn2.org> |
| In reply to | #106256 |
Am Tue, 04 Jun 2024 13:02:03 -0500 schrieb olcott:
> On 6/4/2024 11:58 AM, Mike Terry wrote:
>> On 04/06/2024 11:52, Fred. Zwarts wrote:
>>> Op 04.jun.2024 om 12:29 schreef Fred. Zwarts:
>>>> Op 03.jun.2024 om 23:24 schreef olcott:
>>>>> On 6/3/2024 3:09 PM, Fred. Zwarts wrote:
>>>>>> Op 03.jun.2024 om 14:20 schreef olcott:
>>>>>>> On 6/3/2024 4:42 AM, Ben Bacarisse wrote:
>>>>>>>> Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
>>>>>>>>
>>>>>>> *DD correctly simulated by HH would never stop running unless
>>>>>>> aborted*
>>>>>>> *We can see that the following DD cannot possibly halt when*
>>>>>>> *correctly simulated by every HH that can possibly exist*
>>>>>>
>>>>>> It is very clear that if the simulated HH would halt, then DD would
>>>>>> halt. So your claim comes down to HH not halting when simulating
>>>>>> itself.
>>>>>>
>>>>> Mike Terry replied to this and explained it correctly as reply
>>>>> directly to you On 6/3/2024 12:36 PM, Mike Terry wrote:
>>>>>
>>>>> http://al.howardknight.net/?
STYPE=msgid&MSGI=%3CHlGdnbvc3Ly_YsD7nZ2dnZfqn_adnZ2d%40brightview.co.uk%3E
>>>>>
>>>>>
>>>> He says that there is no infinite recursion, because the simulation
>>>> is aborted.
>>>> If you want to interpret his reply in this way,
>>
>> Yes, that's my intended meaning
>>
>>> then it also shows that neither HH, nor DD are
>>>> involved in a recursive recursion. This implies
>>>
>>> That should be: ... are involved in an infinite recursion, because the
>>> simulation was aborted,
>>
>> Yes. (There is finite recursive simulation, i.e. H partially simulates
>> H etc..)
>>
>>> which implies ...
>>>
>>>> that none of them reaches their final state.
>>
>> None of their /simulations by H/ reach their final state. Obviously
>> there's a huge distinction between the abstract concept of a
>> computation/halting, and a partial simulation of that computation by
>> some other program, and I'm surprised anyone (not you specifically)
>> tolerates confusion on that point.
>>
>> Suppose P(I) is some computation that halts after 13422 steps. Clearly
>> a partial simulation of P(I) by H could be abandoned ("aborted") after
>> 8333 steps. So the /partial simulation by H/ "does not halt", but the
>> computation P(I) of course halts.
>>
>> I'm not trying to suggest that considering the "halting" behaviour of a
>> partial simulation by a specific program is a /useful/ thing to be
>> looking at, but none the less that is what PO is doing...
>>
> The meaning of these words prove that I am correct about how partial
> simulations correctly determine the halt status of their non-halting
> inputs.
> <Professor Sipser agreed>
> </Professor Sipser agreed>
You completely missed the point. The simulator absolutely can keep track
of repeating states; it just can't halt if its input doesn't, because that
is a difference in behaviour which it is not allowed to have.
--
joes
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-04 17:16 -0500 |
| Subject | Re: How Partial Simulations correctly determine non-halting ---Mike Terry Error |
| Message-ID | <v3o3og$jm9q$2@dont-email.me> |
| In reply to | #106258 |
On 6/4/2024 4:26 PM, joes wrote:
> Am Tue, 04 Jun 2024 13:02:03 -0500 schrieb olcott:
>> On 6/4/2024 11:58 AM, Mike Terry wrote:
>>> On 04/06/2024 11:52, Fred. Zwarts wrote:
>>>> Op 04.jun.2024 om 12:29 schreef Fred. Zwarts:
>>>>> Op 03.jun.2024 om 23:24 schreef olcott:
>>>>>> On 6/3/2024 3:09 PM, Fred. Zwarts wrote:
>>>>>>> Op 03.jun.2024 om 14:20 schreef olcott:
>>>>>>>> On 6/3/2024 4:42 AM, Ben Bacarisse wrote:
>>>>>>>>> Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
>>>>>>>>>
>>>>>>>> *DD correctly simulated by HH would never stop running unless
>>>>>>>> aborted*
>>>>>>>> *We can see that the following DD cannot possibly halt when*
>>>>>>>> *correctly simulated by every HH that can possibly exist*
>>>>>>>
>>>>>>> It is very clear that if the simulated HH would halt, then DD would
>>>>>>> halt. So your claim comes down to HH not halting when simulating
>>>>>>> itself.
>>>>>>>
>>>>>> Mike Terry replied to this and explained it correctly as reply
>>>>>> directly to you On 6/3/2024 12:36 PM, Mike Terry wrote:
>>>>>>
>>>>>> http://al.howardknight.net/?
> STYPE=msgid&MSGI=%3CHlGdnbvc3Ly_YsD7nZ2dnZfqn_adnZ2d%40brightview.co.uk%3E
>>>>>>
>>>>>>
>>>>> He says that there is no infinite recursion, because the simulation
>>>>> is aborted.
>>>>> If you want to interpret his reply in this way,
>>>
>>> Yes, that's my intended meaning
>>>
>>>> then it also shows that neither HH, nor DD are
>>>>> involved in a recursive recursion. This implies
>>>>
>>>> That should be: ... are involved in an infinite recursion, because the
>>>> simulation was aborted,
>>>
>>> Yes. (There is finite recursive simulation, i.e. H partially simulates
>>> H etc..)
>>>
>>>> which implies ...
>>>>
>>>>> that none of them reaches their final state.
>>>
>>> None of their /simulations by H/ reach their final state. Obviously
>>> there's a huge distinction between the abstract concept of a
>>> computation/halting, and a partial simulation of that computation by
>>> some other program, and I'm surprised anyone (not you specifically)
>>> tolerates confusion on that point.
>>>
>>> Suppose P(I) is some computation that halts after 13422 steps. Clearly
>>> a partial simulation of P(I) by H could be abandoned ("aborted") after
>>> 8333 steps. So the /partial simulation by H/ "does not halt", but the
>>> computation P(I) of course halts.
>>>
>>> I'm not trying to suggest that considering the "halting" behaviour of a
>>> partial simulation by a specific program is a /useful/ thing to be
>>> looking at, but none the less that is what PO is doing...
>>>
>> The meaning of these words prove that I am correct about how partial
>> simulations correctly determine the halt status of their non-halting
>> inputs.
>> <Professor Sipser agreed>
>> </Professor Sipser agreed>
>
> You completely missed the point. The simulator absolutely can keep track
> of repeating states; it just can't halt if its input doesn't,
You don't seem to know the first thing about deciders, in that
they must always halt.
> because that
> is a difference in behaviour which it is not allowed to have.
>
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-04 21:48 -0400 |
| Subject | Re: How Partial Simulations correctly determine non-halting ---Mike Terry Error |
| Message-ID | <v3og5o$328ec$8@i2pn2.org> |
| In reply to | #106260 |
On 6/4/24 6:16 PM, olcott wrote:
> On 6/4/2024 4:26 PM, joes wrote:
>> Am Tue, 04 Jun 2024 13:02:03 -0500 schrieb olcott:
>>> On 6/4/2024 11:58 AM, Mike Terry wrote:
>>>> On 04/06/2024 11:52, Fred. Zwarts wrote:
>>>>> Op 04.jun.2024 om 12:29 schreef Fred. Zwarts:
>>>>>> Op 03.jun.2024 om 23:24 schreef olcott:
>>>>>>> On 6/3/2024 3:09 PM, Fred. Zwarts wrote:
>>>>>>>> Op 03.jun.2024 om 14:20 schreef olcott:
>>>>>>>>> On 6/3/2024 4:42 AM, Ben Bacarisse wrote:
>>>>>>>>>> Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
>>>>>>>>>>
>>>>>>>>> *DD correctly simulated by HH would never stop running unless
>>>>>>>>> aborted*
>>>>>>>>> *We can see that the following DD cannot possibly halt when*
>>>>>>>>> *correctly simulated by every HH that can possibly exist*
>>>>>>>>
>>>>>>>> It is very clear that if the simulated HH would halt, then DD would
>>>>>>>> halt. So your claim comes down to HH not halting when simulating
>>>>>>>> itself.
>>>>>>>>
>>>>>>> Mike Terry replied to this and explained it correctly as reply
>>>>>>> directly to you On 6/3/2024 12:36 PM, Mike Terry wrote:
>>>>>>>
>>>>>>> http://al.howardknight.net/?
>> STYPE=msgid&MSGI=%3CHlGdnbvc3Ly_YsD7nZ2dnZfqn_adnZ2d%40brightview.co.uk%3E
>>>>>>>
>>>>>>>
>>>>>> He says that there is no infinite recursion, because the simulation
>>>>>> is aborted.
>>>>>> If you want to interpret his reply in this way,
>>>>
>>>> Yes, that's my intended meaning
>>>>
>>>>> then it also shows that neither HH, nor DD are
>>>>>> involved in a recursive recursion. This implies
>>>>>
>>>>> That should be: ... are involved in an infinite recursion, because the
>>>>> simulation was aborted,
>>>>
>>>> Yes. (There is finite recursive simulation, i.e. H partially simulates
>>>> H etc..)
>>>>
>>>>> which implies ...
>>>>>
>>>>>> that none of them reaches their final state.
>>>>
>>>> None of their /simulations by H/ reach their final state. Obviously
>>>> there's a huge distinction between the abstract concept of a
>>>> computation/halting, and a partial simulation of that computation by
>>>> some other program, and I'm surprised anyone (not you specifically)
>>>> tolerates confusion on that point.
>>>>
>>>> Suppose P(I) is some computation that halts after 13422 steps. Clearly
>>>> a partial simulation of P(I) by H could be abandoned ("aborted") after
>>>> 8333 steps. So the /partial simulation by H/ "does not halt", but the
>>>> computation P(I) of course halts.
>>>>
>>>> I'm not trying to suggest that considering the "halting" behaviour of a
>>>> partial simulation by a specific program is a /useful/ thing to be
>>>> looking at, but none the less that is what PO is doing...
>>>>
>>> The meaning of these words prove that I am correct about how partial
>>> simulations correctly determine the halt status of their non-halting
>>> inputs.
>>> <Professor Sipser agreed>
>>> </Professor Sipser agreed>
>>
>> You completely missed the point. The simulator absolutely can keep track
>> of repeating states; it just can't halt if its input doesn't,
>
> You don't seem to know the first thing about deciders, in that
> they must always halt.
Yes, and they must give the answer to the actual question they are
supposed to be answering.
>
>> because that
>> is a difference in behaviour which it is not allowed to have.
>>
>
[toc] | [prev] | [next] | [standalone]
| From | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2024-06-05 10:21 +0200 |
| Subject | Re: How Partial Simulations correctly determine non-halting ---Mike Terry Error |
| Message-ID | <v3p761$sg73$4@dont-email.me> |
| In reply to | #106260 |
Op 05.jun.2024 om 00:16 schreef olcott:
> On 6/4/2024 4:26 PM, joes wrote:
>> Am Tue, 04 Jun 2024 13:02:03 -0500 schrieb olcott:
>>> On 6/4/2024 11:58 AM, Mike Terry wrote:
>>>> On 04/06/2024 11:52, Fred. Zwarts wrote:
>>>>> Op 04.jun.2024 om 12:29 schreef Fred. Zwarts:
>>>>>> Op 03.jun.2024 om 23:24 schreef olcott:
>>>>>>> On 6/3/2024 3:09 PM, Fred. Zwarts wrote:
>>>>>>>> Op 03.jun.2024 om 14:20 schreef olcott:
>>>>>>>>> On 6/3/2024 4:42 AM, Ben Bacarisse wrote:
>>>>>>>>>> Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
>>>>>>>>>>
>>>>>>>>> *DD correctly simulated by HH would never stop running unless
>>>>>>>>> aborted*
>>>>>>>>> *We can see that the following DD cannot possibly halt when*
>>>>>>>>> *correctly simulated by every HH that can possibly exist*
>>>>>>>>
>>>>>>>> It is very clear that if the simulated HH would halt, then DD would
>>>>>>>> halt. So your claim comes down to HH not halting when simulating
>>>>>>>> itself.
>>>>>>>>
>>>>>>> Mike Terry replied to this and explained it correctly as reply
>>>>>>> directly to you On 6/3/2024 12:36 PM, Mike Terry wrote:
>>>>>>>
>>>>>>> http://al.howardknight.net/?
>> STYPE=msgid&MSGI=%3CHlGdnbvc3Ly_YsD7nZ2dnZfqn_adnZ2d%40brightview.co.uk%3E
>>>>>>>
>>>>>>>
>>>>>> He says that there is no infinite recursion, because the simulation
>>>>>> is aborted.
>>>>>> If you want to interpret his reply in this way,
>>>>
>>>> Yes, that's my intended meaning
>>>>
>>>>> then it also shows that neither HH, nor DD are
>>>>>> involved in a recursive recursion. This implies
>>>>>
>>>>> That should be: ... are involved in an infinite recursion, because the
>>>>> simulation was aborted,
>>>>
>>>> Yes. (There is finite recursive simulation, i.e. H partially simulates
>>>> H etc..)
>>>>
>>>>> which implies ...
>>>>>
>>>>>> that none of them reaches their final state.
>>>>
>>>> None of their /simulations by H/ reach their final state. Obviously
>>>> there's a huge distinction between the abstract concept of a
>>>> computation/halting, and a partial simulation of that computation by
>>>> some other program, and I'm surprised anyone (not you specifically)
>>>> tolerates confusion on that point.
>>>>
>>>> Suppose P(I) is some computation that halts after 13422 steps. Clearly
>>>> a partial simulation of P(I) by H could be abandoned ("aborted") after
>>>> 8333 steps. So the /partial simulation by H/ "does not halt", but the
>>>> computation P(I) of course halts.
>>>>
>>>> I'm not trying to suggest that considering the "halting" behaviour of a
>>>> partial simulation by a specific program is a /useful/ thing to be
>>>> looking at, but none the less that is what PO is doing...
>>>>
>>> The meaning of these words prove that I am correct about how partial
>>> simulations correctly determine the halt status of their non-halting
>>> inputs.
>>> <Professor Sipser agreed>
>>> </Professor Sipser agreed>
>>
>> You completely missed the point. The simulator absolutely can keep track
>> of repeating states; it just can't halt if its input doesn't,
>
> You don't seem to know the first thing about deciders, in that
> they must always halt.
>
Yes. And the fact that your decider diagnoses itself as non-halting
proves that there is something wrong with your decider.
Get the cream out of your eyes!
typedef int (*ptr)(); // ptr is pointer to int function in C
int H(ptr p, ptr i);
int main()
{
H(main, 0);
}
H diagnoses this program as non-halting. The only reason is obvious: the
simulation of H by itself did not reach the final state.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-05 09:04 -0500 |
| Subject | Re: How Partial Simulations correctly determine non-halting ---Mike Terry Error |
| Message-ID | <v3pr90$1003g$4@dont-email.me> |
| In reply to | #106300 |
On 6/5/2024 3:21 AM, Fred. Zwarts wrote:
> Op 05.jun.2024 om 00:16 schreef olcott:
>> On 6/4/2024 4:26 PM, joes wrote:
>>> Am Tue, 04 Jun 2024 13:02:03 -0500 schrieb olcott:
>>>> On 6/4/2024 11:58 AM, Mike Terry wrote:
>>>>> On 04/06/2024 11:52, Fred. Zwarts wrote:
>>>>>> Op 04.jun.2024 om 12:29 schreef Fred. Zwarts:
>>>>>>> Op 03.jun.2024 om 23:24 schreef olcott:
>>>>>>>> On 6/3/2024 3:09 PM, Fred. Zwarts wrote:
>>>>>>>>> Op 03.jun.2024 om 14:20 schreef olcott:
>>>>>>>>>> On 6/3/2024 4:42 AM, Ben Bacarisse wrote:
>>>>>>>>>>> Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
>>>>>>>>>>>
>>>>>>>>>> *DD correctly simulated by HH would never stop running unless
>>>>>>>>>> aborted*
>>>>>>>>>> *We can see that the following DD cannot possibly halt when*
>>>>>>>>>> *correctly simulated by every HH that can possibly exist*
>>>>>>>>>
>>>>>>>>> It is very clear that if the simulated HH would halt, then DD
>>>>>>>>> would
>>>>>>>>> halt. So your claim comes down to HH not halting when simulating
>>>>>>>>> itself.
>>>>>>>>>
>>>>>>>> Mike Terry replied to this and explained it correctly as reply
>>>>>>>> directly to you On 6/3/2024 12:36 PM, Mike Terry wrote:
>>>>>>>>
>>>>>>>> http://al.howardknight.net/?
>>> STYPE=msgid&MSGI=%3CHlGdnbvc3Ly_YsD7nZ2dnZfqn_adnZ2d%40brightview.co.uk%3E
>>>>>>>>
>>>>>>>>
>>>>>>> He says that there is no infinite recursion, because the simulation
>>>>>>> is aborted.
>>>>>>> If you want to interpret his reply in this way,
>>>>>
>>>>> Yes, that's my intended meaning
>>>>>
>>>>>> then it also shows that neither HH, nor DD are
>>>>>>> involved in a recursive recursion. This implies
>>>>>>
>>>>>> That should be: ... are involved in an infinite recursion, because
>>>>>> the
>>>>>> simulation was aborted,
>>>>>
>>>>> Yes. (There is finite recursive simulation, i.e. H partially
>>>>> simulates
>>>>> H etc..)
>>>>>
>>>>>> which implies ...
>>>>>>
>>>>>>> that none of them reaches their final state.
>>>>>
>>>>> None of their /simulations by H/ reach their final state. Obviously
>>>>> there's a huge distinction between the abstract concept of a
>>>>> computation/halting, and a partial simulation of that computation by
>>>>> some other program, and I'm surprised anyone (not you specifically)
>>>>> tolerates confusion on that point.
>>>>>
>>>>> Suppose P(I) is some computation that halts after 13422 steps.
>>>>> Clearly
>>>>> a partial simulation of P(I) by H could be abandoned ("aborted") after
>>>>> 8333 steps. So the /partial simulation by H/ "does not halt", but the
>>>>> computation P(I) of course halts.
>>>>>
>>>>> I'm not trying to suggest that considering the "halting" behaviour
>>>>> of a
>>>>> partial simulation by a specific program is a /useful/ thing to be
>>>>> looking at, but none the less that is what PO is doing...
>>>>>
>>>> The meaning of these words prove that I am correct about how partial
>>>> simulations correctly determine the halt status of their non-halting
>>>> inputs.
>>>> <Professor Sipser agreed>
>>>> </Professor Sipser agreed>
>>>
>>> You completely missed the point. The simulator absolutely can keep track
>>> of repeating states; it just can't halt if its input doesn't,
>>
>> You don't seem to know the first thing about deciders, in that
>> they must always halt.
>>
>
> Yes. And the fact that your decider diagnoses itself as non-halting
> proves that there is something wrong with your decider.
> Get the cream out of your eyes!
>
> typedef int (*ptr)(); // ptr is pointer to int function in C
>
> int H(ptr p, ptr i);
>
> int main()
> {
> H(main, 0);
> }
>
> H diagnoses this program as non-halting. The only reason is obvious: the
> simulation of H by itself did not reach the final state.
*The simulation of H is not required to halt*
*The simulation of H is not required to halt*
*The simulation of H is not required to halt*
*The simulation of H is not required to halt*
*The simulation of H is not required to halt*
*The simulation of H is not required to halt*
*The simulation of H is not required to halt*
*The simulation of H is not required to halt*
*The simulation of H is not required to halt*
*The simulation of H is not required to halt*
I actually tried this example and it does prove that main()
halts and it also proves that the directly executed H(main, 0)
halts and correctly returns 0; I gave you all of the details
in another reply.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | joes <noreply@example.com> |
|---|---|
| Date | 2024-06-05 18:28 +0000 |
| Subject | Re: How Partial Simulations correctly determine non-halting ---Mike Terry Error |
| Message-ID | <v3qanf$34b9u$13@i2pn2.org> |
| In reply to | #106318 |
Am Wed, 05 Jun 2024 09:04:16 -0500 schrieb olcott:
> On 6/5/2024 3:21 AM, Fred. Zwarts wrote:
>> Op 05.jun.2024 om 00:16 schreef olcott:
>>> On 6/4/2024 4:26 PM, joes wrote:
>>>> Am Tue, 04 Jun 2024 13:02:03 -0500 schrieb olcott:
>>>>> On 6/4/2024 11:58 AM, Mike Terry wrote:
>>>>>> On 04/06/2024 11:52, Fred. Zwarts wrote:
>>>>>>> Op 04.jun.2024 om 12:29 schreef Fred. Zwarts:
>>>>>>>> Op 03.jun.2024 om 23:24 schreef olcott:
>>>>>>>>> On 6/3/2024 3:09 PM, Fred. Zwarts wrote:
>>>>>>>>>> Op 03.jun.2024 om 14:20 schreef olcott:
>>>>>>>>>>> On 6/3/2024 4:42 AM, Ben Bacarisse wrote:
>>>>>>>>>>>> Mike Terry <news.dead.person.stones@darjeeling.plus.com>
>>>>>>>>>>>> writes:
>> Yes. And the fact that your decider diagnoses itself as non-halting
>> proves that there is something wrong with your decider.
>> Get the cream out of your eyes!
>>
>> typedef int (*ptr)(); // ptr is pointer to int function
>> in C
>> int H(ptr p, ptr i);
>> int main()
>> {
>> H(main, 0);
>> }
>>
>> H diagnoses this program as non-halting. The only reason is obvious:
>> the simulation of H by itself did not reach the final state.
>
> *The simulation of H is not required to halt*
But you wanted a decider!
> I actually tried this example and it does prove that main() halts and it
> also proves that the directly executed H(main, 0)
> halts and correctly returns 0; I gave you all of the details in another
> reply.
--
joes
[toc] | [prev] | [next] | [standalone]
Page 6 of 17 — ← Prev page 1 … 4 5 [6] 7 8 … 17 Next page →
Back to top | Article view | comp.theory
csiph-web