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 16 of 17 — ← Prev page 1 … 14 15 [16] 17 Next page →
| From | Mikko <mikko.levanto@iki.fi> |
|---|---|
| Date | 2024-06-09 18:11 +0300 |
| Subject | Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis |
| Message-ID | <v44gmc$3jao9$1@dont-email.me> |
| In reply to | #106773 |
On 2024-06-09 13:59:57 +0000, olcott said: > On 6/9/2024 3:47 AM, Mikko wrote: >> On 2024-06-08 13:04:14 +0000, olcott said: >> >>> On 6/8/2024 1:42 AM, Mikko wrote: >>>> On 2024-06-07 22:26:05 +0000, olcott said: >>>> >>>>> On 6/7/2024 4:00 PM, joes wrote: >>>>>> Am Fri, 07 Jun 2024 09:47:35 -0500 schrieb olcott: >>>>>>> On 6/7/2024 1:30 AM, Mikko wrote: >>>>>>>> On 2024-06-06 15:31:36 +0000, olcott said: >>>>>>>>> On 6/6/2024 10:14 AM, Mikko wrote: >>>>>>>>>> On 2024-06-06 13:53:58 +0000, olcott said: >>>>>>>>>>> On 6/6/2024 5:15 AM, Mikko wrote: >>>>>>>>>>>> On 2024-06-05 13:29:28 +0000, olcott said: >>>>>>>>>>>>> On 6/5/2024 2:37 AM, Mikko wrote: >>>>>>>>>>>>>> On 2024-06-04 18:02:03 +0000, olcott said: >>>>>> >>>>>>> A simulating halt decider cannot report on what the behavior of a >>>>>>> non-terminating input actually is because this would take forever. >>>>>> Exactly. Didn't you say it is allowed to abort? >>>>>> >>>>>>> H is not allowed to report on any computation containing its actual self >>>>>>> because Turing machines can only take finite string inputs thus cannot >>>>>>> take Turing machines as inputs. >>>>>> Bullshit. It can take other machines just fine. It doesn't know about >>>>>> itself. >>>>>> >>>>> >>>>> No actual Turing machine can be the input to any other actual >>>>> Turing machine. Turing machines only take finite string inputs. >>>> >>>> Any finite string can be an input to some Turing machine. >>>> Can you prove that a Turing machine is not a finite string? >>>> >>> >>> By definition Turing Machines are not finite strings in the >>> conventional model. In my x86utm model of computation x86 >>> machine language <is> the input to another function written >>> in the x86 language. >> >> The definition does not say "Turing machine is not a finite string". > > The definition of puppy does not say it is not a fifteen > story office building. Therefore you must use a different kind of argumentation if you want to claim that a Turing machine is not a finite string. -- Mikko
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-09 11:09 -0500 |
| Subject | Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis |
| Message-ID | <v44k3j$3jnc8$4@dont-email.me> |
| In reply to | #106782 |
On 6/9/2024 10:11 AM, Mikko wrote: > On 2024-06-09 13:59:57 +0000, olcott said: > >> On 6/9/2024 3:47 AM, Mikko wrote: >>> On 2024-06-08 13:04:14 +0000, olcott said: >>> >>>> On 6/8/2024 1:42 AM, Mikko wrote: >>>>> On 2024-06-07 22:26:05 +0000, olcott said: >>>>> >>>>>> On 6/7/2024 4:00 PM, joes wrote: >>>>>>> Am Fri, 07 Jun 2024 09:47:35 -0500 schrieb olcott: >>>>>>>> On 6/7/2024 1:30 AM, Mikko wrote: >>>>>>>>> On 2024-06-06 15:31:36 +0000, olcott said: >>>>>>>>>> On 6/6/2024 10:14 AM, Mikko wrote: >>>>>>>>>>> On 2024-06-06 13:53:58 +0000, olcott said: >>>>>>>>>>>> On 6/6/2024 5:15 AM, Mikko wrote: >>>>>>>>>>>>> On 2024-06-05 13:29:28 +0000, olcott said: >>>>>>>>>>>>>> On 6/5/2024 2:37 AM, Mikko wrote: >>>>>>>>>>>>>>> On 2024-06-04 18:02:03 +0000, olcott said: >>>>>>> >>>>>>>> A simulating halt decider cannot report on what the behavior of a >>>>>>>> non-terminating input actually is because this would take forever. >>>>>>> Exactly. Didn't you say it is allowed to abort? >>>>>>> >>>>>>>> H is not allowed to report on any computation containing its >>>>>>>> actual self >>>>>>>> because Turing machines can only take finite string inputs thus >>>>>>>> cannot >>>>>>>> take Turing machines as inputs. >>>>>>> Bullshit. It can take other machines just fine. It doesn't know >>>>>>> about >>>>>>> itself. >>>>>>> >>>>>> >>>>>> No actual Turing machine can be the input to any other actual >>>>>> Turing machine. Turing machines only take finite string inputs. >>>>> >>>>> Any finite string can be an input to some Turing machine. >>>>> Can you prove that a Turing machine is not a finite string? >>>>> >>>> >>>> By definition Turing Machines are not finite strings in the >>>> conventional model. In my x86utm model of computation x86 >>>> machine language <is> the input to another function written >>>> in the x86 language. >>> >>> The definition does not say "Turing machine is not a finite string". >> >> The definition of puppy does not say it is not a fifteen >> story office building. > > Therefore you must use a different kind of argumentation if you want > to claim that a Turing machine is not a finite string. > It is common knowledge (that you lack) that a Turing machine <is not> a finite string. It is also common knowledge that finite strings can describe Turing machines. -- 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-09 17:50 +0000 |
| Subject | Re: How Partial Simulations correctly determine non-halting -- TM as finite string |
| Message-ID | <v44q20$3g17f$4@i2pn2.org> |
| In reply to | #106791 |
Am Sun, 09 Jun 2024 11:09:23 -0500 schrieb olcott: > On 6/9/2024 10:11 AM, Mikko wrote: >> On 2024-06-09 13:59:57 +0000, olcott said: >>> On 6/9/2024 3:47 AM, Mikko wrote: >>>> On 2024-06-08 13:04:14 +0000, olcott said: >>>>> On 6/8/2024 1:42 AM, Mikko wrote: >>>>>> On 2024-06-07 22:26:05 +0000, olcott said: >>>>>>> On 6/7/2024 4:00 PM, joes wrote: >>>>>>>> Am Fri, 07 Jun 2024 09:47:35 -0500 schrieb olcott: >>>>>>>>> On 6/7/2024 1:30 AM, Mikko wrote: >>>>>>>>>> On 2024-06-06 15:31:36 +0000, olcott said: >>>>>>>>>>> On 6/6/2024 10:14 AM, Mikko wrote: >>>>>>>>>>>> On 2024-06-06 13:53:58 +0000, olcott said: >>>>>>>>>>>>> On 6/6/2024 5:15 AM, Mikko wrote: >>>>>>>>>>>>>> On 2024-06-05 13:29:28 +0000, olcott said: >>>>>>>>>>>>>>> On 6/5/2024 2:37 AM, Mikko wrote: >>>>>>>>>>>>>>>> On 2024-06-04 18:02:03 +0000, olcott said: >>>>>> Any finite string can be an input to some Turing machine. Can you >>>>>> prove that a Turing machine is not a finite string? >>>>>> >>>>> By definition Turing Machines are not finite strings in the >>>>> conventional model. In my x86utm model of computation x86 machine >>>>> language <is> the input to another function written in the x86 >>>>> language. > It is common knowledge (that you lack) that a Turing machine <is not> a > finite string. It is also common knowledge that finite strings can > describe Turing machines. I know Turing machines as tuples, consisting of an alphabet, a tape, a state table, a final state... what did I forget? They can be described in a finite string. What's your point? -- joes
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-09 14:08 -0400 |
| Subject | Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis |
| Message-ID | <v44r3l$3egp9$9@i2pn2.org> |
| In reply to | #106791 |
On 6/9/24 12:09 PM, olcott wrote: > On 6/9/2024 10:11 AM, Mikko wrote: >> On 2024-06-09 13:59:57 +0000, olcott said: >> >>> On 6/9/2024 3:47 AM, Mikko wrote: >>>> On 2024-06-08 13:04:14 +0000, olcott said: >>>> >>>>> On 6/8/2024 1:42 AM, Mikko wrote: >>>>>> On 2024-06-07 22:26:05 +0000, olcott said: >>>>>> >>>>>>> On 6/7/2024 4:00 PM, joes wrote: >>>>>>>> Am Fri, 07 Jun 2024 09:47:35 -0500 schrieb olcott: >>>>>>>>> On 6/7/2024 1:30 AM, Mikko wrote: >>>>>>>>>> On 2024-06-06 15:31:36 +0000, olcott said: >>>>>>>>>>> On 6/6/2024 10:14 AM, Mikko wrote: >>>>>>>>>>>> On 2024-06-06 13:53:58 +0000, olcott said: >>>>>>>>>>>>> On 6/6/2024 5:15 AM, Mikko wrote: >>>>>>>>>>>>>> On 2024-06-05 13:29:28 +0000, olcott said: >>>>>>>>>>>>>>> On 6/5/2024 2:37 AM, Mikko wrote: >>>>>>>>>>>>>>>> On 2024-06-04 18:02:03 +0000, olcott said: >>>>>>>> >>>>>>>>> A simulating halt decider cannot report on what the behavior of a >>>>>>>>> non-terminating input actually is because this would take forever. >>>>>>>> Exactly. Didn't you say it is allowed to abort? >>>>>>>> >>>>>>>>> H is not allowed to report on any computation containing its >>>>>>>>> actual self >>>>>>>>> because Turing machines can only take finite string inputs thus >>>>>>>>> cannot >>>>>>>>> take Turing machines as inputs. >>>>>>>> Bullshit. It can take other machines just fine. It doesn't know >>>>>>>> about >>>>>>>> itself. >>>>>>>> >>>>>>> >>>>>>> No actual Turing machine can be the input to any other actual >>>>>>> Turing machine. Turing machines only take finite string inputs. >>>>>> >>>>>> Any finite string can be an input to some Turing machine. >>>>>> Can you prove that a Turing machine is not a finite string? >>>>>> >>>>> >>>>> By definition Turing Machines are not finite strings in the >>>>> conventional model. In my x86utm model of computation x86 >>>>> machine language <is> the input to another function written >>>>> in the x86 language. >>>> >>>> The definition does not say "Turing machine is not a finite string". >>> >>> The definition of puppy does not say it is not a fifteen >>> story office building. >> >> Therefore you must use a different kind of argumentation if you want >> to claim that a Turing machine is not a finite string. >> > > It is common knowledge (that you lack) that a Turing machine > <is not> a finite string. It is also common knowledge that > finite strings can describe Turing machines. > It is also common knowledge that "strings" don't have behavior So, since we need to look at what the string describess for the behavior, the fact that that string could be a description of a Turing Machine, that becomes a perfectly valid "behavior" for the string when you are being a bit sloppy in your language. You can't argue that HH can not be responsible for the behavior of the Turing machine described by the input, and claim it is (at least tryihg to be) a Halt Decider, since that definition provides the meaning for the input.
[toc] | [prev] | [next] | [standalone]
| From | Mikko <mikko.levanto@iki.fi> |
|---|---|
| Date | 2024-06-10 11:01 +0300 |
| Subject | Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis |
| Message-ID | <v46bss$9ibv$1@dont-email.me> |
| In reply to | #106791 |
On 2024-06-09 16:09:23 +0000, olcott said: > On 6/9/2024 10:11 AM, Mikko wrote: >> On 2024-06-09 13:59:57 +0000, olcott said: >> >>> On 6/9/2024 3:47 AM, Mikko wrote: >>>> On 2024-06-08 13:04:14 +0000, olcott said: >>>> >>>>> On 6/8/2024 1:42 AM, Mikko wrote: >>>>>> On 2024-06-07 22:26:05 +0000, olcott said: >>>>>> >>>>>>> On 6/7/2024 4:00 PM, joes wrote: >>>>>>>> Am Fri, 07 Jun 2024 09:47:35 -0500 schrieb olcott: >>>>>>>>> On 6/7/2024 1:30 AM, Mikko wrote: >>>>>>>>>> On 2024-06-06 15:31:36 +0000, olcott said: >>>>>>>>>>> On 6/6/2024 10:14 AM, Mikko wrote: >>>>>>>>>>>> On 2024-06-06 13:53:58 +0000, olcott said: >>>>>>>>>>>>> On 6/6/2024 5:15 AM, Mikko wrote: >>>>>>>>>>>>>> On 2024-06-05 13:29:28 +0000, olcott said: >>>>>>>>>>>>>>> On 6/5/2024 2:37 AM, Mikko wrote: >>>>>>>>>>>>>>>> On 2024-06-04 18:02:03 +0000, olcott said: >>>>>>>> >>>>>>>>> A simulating halt decider cannot report on what the behavior of a >>>>>>>>> non-terminating input actually is because this would take forever. >>>>>>>> Exactly. Didn't you say it is allowed to abort? >>>>>>>> >>>>>>>>> H is not allowed to report on any computation containing its actual self >>>>>>>>> because Turing machines can only take finite string inputs thus cannot >>>>>>>>> take Turing machines as inputs. >>>>>>>> Bullshit. It can take other machines just fine. It doesn't know about >>>>>>>> itself. >>>>>>>> >>>>>>> >>>>>>> No actual Turing machine can be the input to any other actual >>>>>>> Turing machine. Turing machines only take finite string inputs. >>>>>> >>>>>> Any finite string can be an input to some Turing machine. >>>>>> Can you prove that a Turing machine is not a finite string? >>>>>> >>>>> >>>>> By definition Turing Machines are not finite strings in the >>>>> conventional model. In my x86utm model of computation x86 >>>>> machine language <is> the input to another function written >>>>> in the x86 language. >>>> >>>> The definition does not say "Turing machine is not a finite string". >>> >>> The definition of puppy does not say it is not a fifteen >>> story office building. >> >> Therefore you must use a different kind of argumentation if you want >> to claim that a Turing machine is not a finite string. >> > > It is common knowledge (that you lack) that a Turing machine > <is not> a finite string. It is also common knowledge that > finite strings can describe Turing machines. A Turing machine is a term of art that means what its definition says. There are several commonly accepted definitions with unimportant differences. You may pick whichever you want as your basis of your proof that a Turing machine is not a finite string. -- Mikko
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-10 10:23 -0500 |
| Subject | Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis |
| Message-ID | <v475ps$ggn5$10@dont-email.me> |
| In reply to | #106872 |
On 6/10/2024 3:01 AM, Mikko wrote: > On 2024-06-09 16:09:23 +0000, olcott said: > >> On 6/9/2024 10:11 AM, Mikko wrote: >>> On 2024-06-09 13:59:57 +0000, olcott said: >>> >>>> On 6/9/2024 3:47 AM, Mikko wrote: >>>>> On 2024-06-08 13:04:14 +0000, olcott said: >>>>> >>>>>> On 6/8/2024 1:42 AM, Mikko wrote: >>>>>>> On 2024-06-07 22:26:05 +0000, olcott said: >>>>>>> >>>>>>>> On 6/7/2024 4:00 PM, joes wrote: >>>>>>>>> Am Fri, 07 Jun 2024 09:47:35 -0500 schrieb olcott: >>>>>>>>>> On 6/7/2024 1:30 AM, Mikko wrote: >>>>>>>>>>> On 2024-06-06 15:31:36 +0000, olcott said: >>>>>>>>>>>> On 6/6/2024 10:14 AM, Mikko wrote: >>>>>>>>>>>>> On 2024-06-06 13:53:58 +0000, olcott said: >>>>>>>>>>>>>> On 6/6/2024 5:15 AM, Mikko wrote: >>>>>>>>>>>>>>> On 2024-06-05 13:29:28 +0000, olcott said: >>>>>>>>>>>>>>>> On 6/5/2024 2:37 AM, Mikko wrote: >>>>>>>>>>>>>>>>> On 2024-06-04 18:02:03 +0000, olcott said: >>>>>>>>> >>>>>>>>>> A simulating halt decider cannot report on what the behavior of a >>>>>>>>>> non-terminating input actually is because this would take >>>>>>>>>> forever. >>>>>>>>> Exactly. Didn't you say it is allowed to abort? >>>>>>>>> >>>>>>>>>> H is not allowed to report on any computation containing its >>>>>>>>>> actual self >>>>>>>>>> because Turing machines can only take finite string inputs >>>>>>>>>> thus cannot >>>>>>>>>> take Turing machines as inputs. >>>>>>>>> Bullshit. It can take other machines just fine. It doesn't know >>>>>>>>> about >>>>>>>>> itself. >>>>>>>>> >>>>>>>> >>>>>>>> No actual Turing machine can be the input to any other actual >>>>>>>> Turing machine. Turing machines only take finite string inputs. >>>>>>> >>>>>>> Any finite string can be an input to some Turing machine. >>>>>>> Can you prove that a Turing machine is not a finite string? >>>>>>> >>>>>> >>>>>> By definition Turing Machines are not finite strings in the >>>>>> conventional model. In my x86utm model of computation x86 >>>>>> machine language <is> the input to another function written >>>>>> in the x86 language. >>>>> >>>>> The definition does not say "Turing machine is not a finite string". >>>> >>>> The definition of puppy does not say it is not a fifteen >>>> story office building. >>> >>> Therefore you must use a different kind of argumentation if you want >>> to claim that a Turing machine is not a finite string. >>> >> >> It is common knowledge (that you lack) that a Turing machine >> <is not> a finite string. It is also common knowledge that >> finite strings can describe Turing machines. > > A Turing machine is a term of art that means what its definition says. > There are several commonly accepted definitions with unimportant > differences. You may pick whichever you want as your basis of your > proof that a Turing machine is not a finite string. > It is common knowledge that a Turing machine itself is not a finite string. I will not engage your head game. -- Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Mikko <mikko.levanto@iki.fi> |
|---|---|
| Date | 2024-06-11 10:25 +0300 |
| Subject | Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis |
| Message-ID | <v48u5v$ukf3$1@dont-email.me> |
| In reply to | #106895 |
On 2024-06-10 15:23:40 +0000, olcott said: > On 6/10/2024 3:01 AM, Mikko wrote: >> On 2024-06-09 16:09:23 +0000, olcott said: >> >>> On 6/9/2024 10:11 AM, Mikko wrote: >>>> On 2024-06-09 13:59:57 +0000, olcott said: >>>> >>>>> On 6/9/2024 3:47 AM, Mikko wrote: >>>>>> On 2024-06-08 13:04:14 +0000, olcott said: >>>>>> >>>>>>> On 6/8/2024 1:42 AM, Mikko wrote: >>>>>>>> On 2024-06-07 22:26:05 +0000, olcott said: >>>>>>>> >>>>>>>>> On 6/7/2024 4:00 PM, joes wrote: >>>>>>>>>> Am Fri, 07 Jun 2024 09:47:35 -0500 schrieb olcott: >>>>>>>>>>> On 6/7/2024 1:30 AM, Mikko wrote: >>>>>>>>>>>> On 2024-06-06 15:31:36 +0000, olcott said: >>>>>>>>>>>>> On 6/6/2024 10:14 AM, Mikko wrote: >>>>>>>>>>>>>> On 2024-06-06 13:53:58 +0000, olcott said: >>>>>>>>>>>>>>> On 6/6/2024 5:15 AM, Mikko wrote: >>>>>>>>>>>>>>>> On 2024-06-05 13:29:28 +0000, olcott said: >>>>>>>>>>>>>>>>> On 6/5/2024 2:37 AM, Mikko wrote: >>>>>>>>>>>>>>>>>> On 2024-06-04 18:02:03 +0000, olcott said: >>>>>>>>>> >>>>>>>>>>> A simulating halt decider cannot report on what the behavior of a >>>>>>>>>>> non-terminating input actually is because this would take forever. >>>>>>>>>> Exactly. Didn't you say it is allowed to abort? >>>>>>>>>> >>>>>>>>>>> H is not allowed to report on any computation containing its actual self >>>>>>>>>>> because Turing machines can only take finite string inputs thus cannot >>>>>>>>>>> take Turing machines as inputs. >>>>>>>>>> Bullshit. It can take other machines just fine. It doesn't know about >>>>>>>>>> itself. >>>>>>>>>> >>>>>>>>> >>>>>>>>> No actual Turing machine can be the input to any other actual >>>>>>>>> Turing machine. Turing machines only take finite string inputs. >>>>>>>> >>>>>>>> Any finite string can be an input to some Turing machine. >>>>>>>> Can you prove that a Turing machine is not a finite string? >>>>>>>> >>>>>>> >>>>>>> By definition Turing Machines are not finite strings in the >>>>>>> conventional model. In my x86utm model of computation x86 >>>>>>> machine language <is> the input to another function written >>>>>>> in the x86 language. >>>>>> >>>>>> The definition does not say "Turing machine is not a finite string". >>>>> >>>>> The definition of puppy does not say it is not a fifteen >>>>> story office building. >>>> >>>> Therefore you must use a different kind of argumentation if you want >>>> to claim that a Turing machine is not a finite string. >>>> >>> >>> It is common knowledge (that you lack) that a Turing machine >>> <is not> a finite string. It is also common knowledge that >>> finite strings can describe Turing machines. >> >> A Turing machine is a term of art that means what its definition says. >> There are several commonly accepted definitions with unimportant >> differences. You may pick whichever you want as your basis of your >> proof that a Turing machine is not a finite string. > > It is common knowledge that a Turing machine itself is not > a finite string. I will not engage your head game. Then point where a textbook says that a Turing machine itself is not a finite string. If you cannot find that statement in a textbook it is not a common knowledge. -- Mikko
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-07 11:14 -0400 |
| Subject | Re: How Partial Simulations correctly determine non-halting ---Mike Terry Error |
| Message-ID | <v3v83u$39ri5$3@i2pn2.org> |
| In reply to | #106412 |
On 6/6/24 11:31 AM, olcott wrote: > On 6/6/2024 10:14 AM, Mikko wrote: >> On 2024-06-06 13:53:58 +0000, olcott said: >> >>> On 6/6/2024 5:15 AM, Mikko wrote: >>>> On 2024-06-05 13:29:28 +0000, olcott said: >>>> >>>>> On 6/5/2024 2:37 AM, Mikko wrote: >>>>>> On 2024-06-04 18:02:03 +0000, olcott said: >>>>>> >>>>>>> *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> >>>>>> >>>>>> It is quite clear what Professor Sipser agreed. >>>>> >>>>> Those were my verbatim words that he agreed to, no one >>>>> has ever correctly provided any alternative interpretation >>>>> that could possibly make my own HH(DD,DD)==0 incorrect. >>>> >>>> One can agree with those words because they are both clear and true. >>>> Whether they are sufficient to your purposes is another problem but >>>> that is nor relevant to their acceptablility. >>>> >>>>>> If you use those words >>>>>> as the second last part of your proof then it sould be obvious >>>>>> that we >>>>>> need to look at the other parts in order to find an error in the >>>>>> proof. >>>>> >>>>> That is slightly more than zero supporting reasoning yet mere >>>>> gibberish >>>>> when construed as any rebuttal to this: >>>> >>>> Those who disagree with you about whether something is "gibberish" may >>>> think that you are stupid. You probably don't want them to think so, >>>> regardless whether thinking so would be right or wrong. >>>> >>>>> *This unequivocally proves the behavior of DD correctly simulated >>>>> by HH* >>>>> https://liarparadox.org/DD_correctly_simulated_by_HH_is_Proven.pdf >>>> >>>> Why would anyone construe my words as any rebuttal to that? That pdf >>>> merely claims that a partucuar author (a C program) proves two >>>> particular >>>> claims, the second of which is badly formed (because of the two >>>> verbs it is hard to parse and consequently hard to be sure that the >>>> apparent meaning or apparent lack of meaning is what is intended). >>>> >>> >>> *I will dumb it down for you some more* >> >> Did you knwo that "dumb it down" does not mean 'change the topic'? >> >>> Try any show how this DD can be correctly simulated by any HH >>> such that this DD reaches past its machine address [00001dbe] >>> >>> _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 >>> >>> *That meets this criteria* >> >> It doesn't if you mean the criteria implied by the subject line. >> > > Yes it does mean that when we ourselves detect the repeating > state of DD correctly simulated by HH does meet the first part > of the following criteria: > > <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> > > That the second part <is> logically entailed by this first part. > *No one can possibly correctly disagree with that* > Yes, but you can only do the second part if you did the first part. But the first part includes the behavior of H based on what it does in the second part. So, if H WILL abort its simulation, then its simulation is NOT a "Correct Simulation" per the rules, and so you can not use it. Please note that he might have been thinking of if THIS COPY of H could look at what would happen if THIS COPY was actually a UTM, AND DOING SO DOESN'T CHANGE THE INPUT (so the D on the tape still calls the original H, not the changed hypothetical one) and if this H can correct determine that input would not halt, then H can abort. This would follow from the fact that a Halt Decider H(<M>, d) needs to decide on the behavior of M(d) which can be seen in the behavior of UTM(<M>,d), but this doesn't change the code of M as your logic tries to do, because it is just based on incorrect understanding of the problem.
[toc] | [prev] | [next] | [standalone]
| From | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2024-06-04 13:02 +0200 |
| Subject | Re: Mike Terry Reply to Fred Zwarts |
| Message-ID | <v3ms7j$chc4$2@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
>
It turns out that you do not understand what I am trying to say.
Maybe it is easier to understand what I mean with the following:
Olcott defends a simulating halt decider H. The problem with it is, that
it introduces another halting problem: The H itself does not halt when
simulated by itself. This cause false negatives: many functions are now
diagnosed by H to be non-halting only by the mere fact that they call H,
even if their direct execution does halt.
H even diagnoses itself to be non-halting, which is illustrated in the
following example (where the D that contradicts H is eliminated):
typedef int (*ptr)(); // ptr is pointer to int function in C
int H(ptr p, ptr i);
int main()
{
H(main, 0);
}
The program main does nothing but calling H. H is required to halt, so
main itself should also halt. Nevertheless H reports that main does not
halt.
Of the infinite set of H that simulate at least one step, none of them,
when simulated by H, reaches its final state. So, it follows that H
determines non-halting behaviour of H and reports that main does not
halt. This has no relation with a paradox in main. It is just a false
negative.
This illustrates that a simulating halt-decider is a bad idea, because
the decider itself does not halt and therefore its results are often
false negatives.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-03 20:56 -0400 |
| Subject | Re: Why does Olcott care about simulation, anyway? --- Ben's Review |
| Message-ID | <v3loop$2uv04$12@i2pn2.org> |
| In reply to | #106124 |
On 6/3/24 8:20 AM, olcott wrote:
> 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.
And to be an XXX decider, that mapping must be the same as the XXX function.
After all, that is the DEFINITION of what their inputs specify.
Since "Halting" is defined as the behavior of the ACTUAL MACHINE
reaching its final state (and non-halting, it not reaching such a state
after an unbounded number of step), that *IS* the behavior specifed by
the input.
>
> *The input to HH(DD,DD) specifies non-halting behavior*
Except that DD(DD), what the input to HH(DD,DD) represents. WILL HALT if
HH is a decider and returns the 0 you say it does.
So, your statement is just a lie. (not an honest mistake, as you have
been corrected on this many time, it is just a flat out DELIBERATE LIE
based on your reckless disregard for the truth).
>
> 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*
But that doesn't matter. NOTHING in the definition ask about what the
deciders simulaition of the input shows. NOTHING.
So, again, another BLANTANT LIE from you.
>
> 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.
Yes, it reaps the benefits, and thus HH needs to consider that its
input, when properly analyzed, will also reap that benefit from the HH
tha it calls.
>
> 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.
>
Because they DON'T. You are just too stupid to understand that the HH
that is simulating the input, and the HH called by DD in the simulation
are the exact same algorithm, and thus have the exact same behaivor.
You logic is based on HH having different behavior when simulated than
when run, which means you have assumed that your HH breaks the rules of
the game. Either it does, and thus isn't eligable to be a decider, or it
doesn't and your logic is just based on LIE.
>
>
> Two PhD computer science professors that I have communicated with
> agree with me that there is something wrong with the halting problem.
Because they ALSO don't understand the topic.
Arguement by authority is just a classical fallacy, showing you don't
understand how to do actual logi.c.
>
> 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*
But HH DOES abort its simulation (or fails to be a decider) and thus the
HH that DD calls WILL RETURN and thus your "infinite recursion" is just
a LIE.
> *We can see that the following DD cannot possibly halt when*
> *correctly simulated by every HH that can possibly exist*
Except that DD DOES HALT for every HH that returns the 0 answer for
HH(DD,DD)
What you actual mean to claim, is that no simulation of DD by the HH
that it calls can simulated DD to a final state.
You need all the qualifications, as some of the other HHs, the ones that
simulated enough longer than this HH, can simulate this DD (connected to
its specific HH) to that final state.
>
> 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 !
>
Nope, I have, and you havn't even TRIED to point out the errors in my
statement, but just repeat your LYING DOGMA over and over to try to
convince yourself that you must be right,
Of course, most other people see through these lies.
[toc] | [prev] | [next] | [standalone]
| From | Mike Terry <news.dead.person.stones@darjeeling.plus.com> |
|---|---|
| Date | 2024-06-03 17:58 +0100 |
| Message-ID | <B7ycneJbccrZa8D7nZ2dnZfqn_qdnZ2d@brightview.co.uk> |
| In reply to | #106116 |
On 03/06/2024 10:42, 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. > >> 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. I'd like to think that comp.theory could continue without PO. That would be great but let's face it there aren't too many people around with questions or suggestions about computing theory, and with the GG links severed there will be less new blood finding the group in future. I saw the quine thread last night, but haven't thought about it much yet. My first thought was aren't quines supposed to be about a specific programming language like C where the executable is generated purely from compiling the C code? Malcolm has presumably embedded his source folder as a binary resource in his executable, and the executable just extracts that resource and "prints" it. If that counted as a quine then quines would be pretty unchallenging, hence more thought needed (like how did his source folder get "compiled" into his quine executable? and for me, what /exactly/ is a quine? I'm not clear on that when you move beyond a single compiler to entire tool sets that produce a program... Such a toolset can simply copy the source to some location accessible to the program [like a binary resource inside the executable] and the program can just access it and print it out?). Anyway the C and C++ groups have healthy traffic regardless of PO, so will carry on - at least as long as the current crowd are around. I still think the break with GG will ultimately cut off new posters who would have encountered the group via GG, so the long term future is not good, but that's some way off. Mike.
[toc] | [prev] | [next] | [standalone]
| From | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2024-06-03 09:58 +0200 |
| Message-ID | <v3jt2s$3qblu$1@dont-email.me> |
| In reply to | #106095 |
Op 03.jun.2024 om 02:16 schreef immibis: > The halting problem says you can't find a Turing machine that tells > whether executing each other Turing machine will halt. Simulation has > nothing to do with the question. Maybe because by using simulation he can shift the attention from the pathological part of the Linz proof, to another halting problem, namely that a simulating decider does not halt because it causes infinite recursion. His own claim that D does not reach the pathological part (after line 03), displays already that the simulation is unable to process the pathological part. But the simulation introduces a new halting problem (recursive simulation), which he thinks is an answer for the original halting problem.
[toc] | [prev] | [next] | [standalone]
| From | Mike Terry <news.dead.person.stones@darjeeling.plus.com> |
|---|---|
| Date | 2024-06-03 18:36 +0100 |
| Message-ID | <HlGdnbvc3Ly_YsD7nZ2dnZfqn_adnZ2d@brightview.co.uk> |
| In reply to | #106108 |
On 03/06/2024 08:58, Fred. Zwarts wrote: > Op 03.jun.2024 om 02:16 schreef immibis: >> The halting problem says you can't find a Turing machine that tells whether executing each other >> Turing machine will halt. Simulation has nothing to do with the question. > > Maybe because by using simulation he can shift the attention from the pathological part of the Linz > proof, to another halting problem, namely that a simulating decider does not halt because it causes > infinite recursion. PO's simulating decider does not cause infinite recursion. That only occurs in the case where the decider performs a FULL simulation of its input, whereas typically for PO his H/HH/... perform PARTIAL simulations, where the decider monitors what is being simulated and breaks off the simulation when a particular condition is observed. So yes, there is recursive simulation, but not /infinite/ recursion since at each level of simulation the simulator is free to just stop simulating at any time. In practice this means that the outer simulator H will be the one to break out, since it will always be ahead of all the inner simulations of H in how far it has progressed. This situation is in contrast with direct call recursion, where the outer caller has no control to break the recursion - it only regains control once the inner calls have all returned. PO does not properly understand this distinction. > > His own claim that D does not reach the pathological part (after line 03), displays already that the > simulation is unable to process the pathological part. But the simulation introduces a new halting > problem (recursive simulation), which he thinks is an answer for the original halting problem. You're using PO's phrase "pathological" but that is a bad (misleading) term because it suggests there is something WRONG/BAD (aka sick?) in the situation. E.g. H processing input which is a description of its own source code. There is nothing whatsoever wrong with that - it's just that PO gets confused by it and so argues to ban it. Perhaps there is an alternative term that doesn't have the deliberate connotation of "sickness". Mike.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-03 13:03 -0500 |
| Message-ID | <v3l0i0$5d3$2@dont-email.me> |
| In reply to | #106155 |
On 6/3/2024 12:36 PM, Mike Terry wrote: > On 03/06/2024 08:58, Fred. Zwarts wrote: >> Op 03.jun.2024 om 02:16 schreef immibis: >>> The halting problem says you can't find a Turing machine that tells >>> whether executing each other Turing machine will halt. Simulation has >>> nothing to do with the question. >> >> Maybe because by using simulation he can shift the attention from the >> pathological part of the Linz proof, to another halting problem, >> namely that a simulating decider does not halt because it causes >> infinite recursion. > > PO's simulating decider does not cause infinite recursion. That only > occurs in the case where the decider performs a FULL simulation of its > input, whereas typically for PO his H/HH/... perform PARTIAL > simulations, where the decider monitors what is being simulated and > breaks off the simulation when a particular condition is observed. > Thanks for affirming that. You are my most technically competent and honest reviewer. > So yes, there is recursive simulation, but not /infinite/ recursion > since at each level of simulation the simulator is free to just stop > simulating at any time. In practice this means that the outer simulator > H will be the one to break out, since it will always be ahead of all the > inner simulations of H in how far it has progressed. This situation is > in contrast with direct call recursion, where the outer caller has no > control to break the recursion - it only regains control once the inner > calls have all returned. > > PO does not properly understand this distinction. > *You can keep ignoring this that does not make it go away* 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> *You can ignore the above forever, that does not make it away* >> >> His own claim that D does not reach the pathological part (after line >> 03), displays already that the simulation is unable to process the >> pathological part. But the simulation introduces a new halting problem >> (recursive simulation), which he thinks is an answer for the original >> halting problem. > > You're using PO's phrase "pathological" but that is a bad (misleading) > term because it suggests there is something WRONG/BAD (aka sick?) in the > situation. E.g. H processing input which is a description of its own > source code. There is nothing whatsoever wrong with that - it's just > that PO gets confused by it and so argues to ban it. Perhaps there is > an alternative term that doesn't have the deliberate connotation of > "sickness". > > Mike. > *Two PhD computer science professors disagree* 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 Bill Stoddart. *The Halting Paradox* 20 December 2017 https://arxiv.org/abs/1906.05340 arXiv:1906.05340 [cs.LO] *You can ignore the above forever, that does not make it away* -- 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 | Mike Terry <news.dead.person.stones@darjeeling.plus.com> |
|---|---|
| Date | 2024-06-03 19:56 +0100 |
| Message-ID | <lBmcnX-HlodbjMP7nZ2dnZfqn_idnZ2d@brightview.co.uk> |
| In reply to | #106157 |
On 03/06/2024 19:03, olcott wrote: > On 6/3/2024 12:36 PM, Mike Terry wrote: >> On 03/06/2024 08:58, Fred. Zwarts wrote: >>> Op 03.jun.2024 om 02:16 schreef immibis: >>>> The halting problem says you can't find a Turing machine that tells whether executing each other >>>> Turing machine will halt. Simulation has nothing to do with the question. >>> >>> Maybe because by using simulation he can shift the attention from the pathological part of the >>> Linz proof, to another halting problem, namely that a simulating decider does not halt because it >>> causes infinite recursion. >> >> PO's simulating decider does not cause infinite recursion. That only occurs in the case where the >> decider performs a FULL simulation of its input, whereas typically for PO his H/HH/... perform >> PARTIAL simulations, where the decider monitors what is being simulated and breaks off the >> simulation when a particular condition is observed. >> > > Thanks for affirming that. You are my most technically > competent and honest reviewer. > >> So yes, there is recursive simulation, but not /infinite/ recursion since at each level of >> simulation the simulator is free to just stop simulating at any time. In practice this means that >> the outer simulator H will be the one to break out, since it will always be ahead of all the inner >> simulations of H in how far it has progressed. This situation is in contrast with direct call >> recursion, where the outer caller has no control to break the recursion - it only regains control >> once the inner calls have all returned. >> >> PO does not properly understand this distinction. >> > > *You can keep ignoring this that does not make it go away* > > 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> > > *You can ignore the above forever, that does not make it away* I do not ignore the above. I recently posted an example of it: a simulating HD correctly reporting non-halting after detecting a tight loop in the computation represented by its input. The problem with the above is with YOU. (You misinterpret/misapply what Sipser says.) And of course your entire purpose behind quoting the above is just an appeal to authority. You know that's a fallacy, because from time to time you accuse others of doing it. > >>> >>> His own claim that D does not reach the pathological part (after line 03), displays already that >>> the simulation is unable to process the pathological part. But the simulation introduces a new >>> halting problem (recursive simulation), which he thinks is an answer for the original halting >>> problem. >> >> You're using PO's phrase "pathological" but that is a bad (misleading) term because it suggests >> there is something WRONG/BAD (aka sick?) in the situation. E.g. H processing input which is a >> description of its own source code. There is nothing whatsoever wrong with that - it's just that >> PO gets confused by it and so argues to ban it. Perhaps there is an alternative term that >> doesn't have the deliberate connotation of "sickness". >> >> Mike. >> > > *Two PhD computer science professors disagree* > > 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 > > Bill Stoddart. *The Halting Paradox* > 20 December 2017 > https://arxiv.org/abs/1906.05340 > arXiv:1906.05340 [cs.LO] > > *You can ignore the above forever, that does not make it away* > Well, it kinda DOES. This is just a blatant appeal to authority on your part, so it can rightly be ignored. I'll say again - if you have some argument to make, argue it yourself in your own words rather than attempting to shut down discussion through appeal to authority. [Perhaps Hehner/Stoddart are just idiots who got things wrong, or much more likely you've completely misinterpreted what they're saying, or you've misunderstood the context or whatever and you are the idiot. The bottom line is THEY ARE NOT HERE ARGUING ANY CASE SO WHAT YOU SAY THEY BELIEVE IS TOTALLY IRRELEVANT. And there's no need for anyone to get into discussions over whether it is Hehner/Stoddart or yourself who is confused...] Mike.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-03 14:26 -0500 |
| Subject | Re: Why does Olcott care about simulation, anyway? --- woeful ignorance |
| Message-ID | <v3l5cc$tom$2@dont-email.me> |
| In reply to | #106164 |
On 6/3/2024 1:56 PM, Mike Terry wrote: > On 03/06/2024 19:03, olcott wrote: >> On 6/3/2024 12:36 PM, Mike Terry wrote: >>> On 03/06/2024 08:58, Fred. Zwarts wrote: >>>> Op 03.jun.2024 om 02:16 schreef immibis: >>>>> The halting problem says you can't find a Turing machine that tells >>>>> whether executing each other Turing machine will halt. Simulation >>>>> has nothing to do with the question. >>>> >>>> Maybe because by using simulation he can shift the attention from >>>> the pathological part of the Linz proof, to another halting problem, >>>> namely that a simulating decider does not halt because it causes >>>> infinite recursion. >>> >>> PO's simulating decider does not cause infinite recursion. That only >>> occurs in the case where the decider performs a FULL simulation of >>> its input, whereas typically for PO his H/HH/... perform PARTIAL >>> simulations, where the decider monitors what is being simulated and >>> breaks off the simulation when a particular condition is observed. >>> >> >> Thanks for affirming that. You are my most technically >> competent and honest reviewer. >> >>> So yes, there is recursive simulation, but not /infinite/ recursion >>> since at each level of simulation the simulator is free to just stop >>> simulating at any time. In practice this means that the outer >>> simulator H will be the one to break out, since it will always be >>> ahead of all the inner simulations of H in how far it has >>> progressed. This situation is in contrast with direct call >>> recursion, where the outer caller has no control to break the >>> recursion - it only regains control once the inner calls have all >>> returned. >>> >>> PO does not properly understand this distinction. >>> >> >> *You can keep ignoring this that does not make it go away* >> >> 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> >> >> *You can ignore the above forever, that does not make it away* > > I do not ignore the above. I recently posted an example of it: a > simulating HD correctly reporting non-halting after detecting a tight > loop in the computation represented by its input. > > The problem with the above is with YOU. (You misinterpret/misapply what > Sipser says.) > > And of course your entire purpose behind quoting the above is just an > appeal to authority. You know that's a fallacy, because from time to > time you accuse others of doing it. > I knew that these exact words were exactly correct about a year before I asked professor Sipser to review them. That you say that I misinterpret them without proving the reasoning behind this give me no basis to correct your incorrect understanding. So far I have shown the error of everyone that tried to explain the details of how they believe that I misinterpreted my own words. >> >>>> >>>> His own claim that D does not reach the pathological part (after >>>> line 03), displays already that the simulation is unable to process >>>> the pathological part. But the simulation introduces a new halting >>>> problem (recursive simulation), which he thinks is an answer for the >>>> original halting problem. >>> >>> You're using PO's phrase "pathological" but that is a bad >>> (misleading) term because it suggests there is something WRONG/BAD >>> (aka sick?) in the situation. E.g. H processing input which is a >>> description of its own source code. There is nothing whatsoever >>> wrong with that - it's just that PO gets confused by it and so argues >>> to ban it. Perhaps there is an alternative term that doesn't have >>> the deliberate connotation of "sickness". >>> >>> Mike. >>> >> >> *Two PhD computer science professors disagree* >> >> 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 >> >> Bill Stoddart. *The Halting Paradox* >> 20 December 2017 >> https://arxiv.org/abs/1906.05340 >> arXiv:1906.05340 [cs.LO] >> >> *You can ignore the above forever, that does not make it away* >> > > Well, it kinda DOES. This is just a blatant appeal to authority on your > part, so it can rightly be ignored. I'll say again - if you have some > argument to make, argue it yourself in your own words rather than > attempting to shut down discussion through appeal to authority. > It proves that I am not a crackpot. > [Perhaps Hehner/Stoddart are just idiots who got things wrong, or much > more likely you've completely misinterpreted what they're saying, or > you've misunderstood the context or whatever and you are the idiot. The > bottom line is THEY ARE NOT HERE ARGUING ANY CASE SO WHAT YOU SAY THEY > BELIEVE IS TOTALLY IRRELEVANT. And there's no need for anyone to get > into discussions over whether it is Hehner/Stoddart or yourself who is > confused...] > > > Mike. > The issue that I and professor Hehner agree on is that incorrect questions have no correct answer only because the question itself is incorrect. He does not call them incorrect questions. The halting problem proof counter-example is essentially a question that has the same form as the Liar Paradox when posed to a specific machine. That this machine cannot answer this question is only because both yes and no are the wrong answer from this machine. The theory of computation is woefully ignorant of context in linguistics, thus anchored in this woeful ignorance TOC simply assumes that the context of who (which machine) is asked the (halting) question is irrelevant. Because of this woeful ignorance TOC does not notice that the halting question about an input that does the opposite of whatever value this machine returns is never construed as an incorrect question. -- 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 | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-03 19:47 -0500 |
| Message-ID | <v3lo7l$3sil$1@dont-email.me> |
| In reply to | #106164 |
On 6/3/2024 1:56 PM, Mike Terry wrote:
> On 03/06/2024 19:03, olcott wrote:
>> On 6/3/2024 12:36 PM, Mike Terry wrote:
>>> On 03/06/2024 08:58, Fred. Zwarts wrote:
>>>> Op 03.jun.2024 om 02:16 schreef immibis:
>>>>> The halting problem says you can't find a Turing machine that tells
>>>>> whether executing each other Turing machine will halt. Simulation
>>>>> has nothing to do with the question.
>>>>
>>>> Maybe because by using simulation he can shift the attention from
>>>> the pathological part of the Linz proof, to another halting problem,
>>>> namely that a simulating decider does not halt because it causes
>>>> infinite recursion.
>>>
>>> PO's simulating decider does not cause infinite recursion. That only
>>> occurs in the case where the decider performs a FULL simulation of
>>> its input, whereas typically for PO his H/HH/... perform PARTIAL
>>> simulations, where the decider monitors what is being simulated and
>>> breaks off the simulation when a particular condition is observed.
>>>
>>
>> Thanks for affirming that. You are my most technically
>> competent and honest reviewer.
>>
>>> So yes, there is recursive simulation, but not /infinite/ recursion
>>> since at each level of simulation the simulator is free to just stop
>>> simulating at any time. In practice this means that the outer
>>> simulator H will be the one to break out, since it will always be
>>> ahead of all the inner simulations of H in how far it has
>>> progressed. This situation is in contrast with direct call
>>> recursion, where the outer caller has no control to break the
>>> recursion - it only regains control once the inner calls have all
>>> returned.
>>>
>>> PO does not properly understand this distinction.
>>>
>>
>> *You can keep ignoring this that does not make it go away*
>>
>> 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>
>>
>> *You can ignore the above forever, that does not make it away*
>
> I do not ignore the above. I recently posted an example of it: a
> simulating HD correctly reporting non-halting after detecting a tight
> loop in the computation represented by its input.
>
> The problem with the above is with YOU. (You misinterpret/misapply what
> Sipser says.)
>
> And of course your entire purpose behind quoting the above is just an
> appeal to authority. You know that's a fallacy, because from time to
> time you accuse others of doing it.
>
>>
>>>>
>>>> His own claim that D does not reach the pathological part (after
>>>> line 03), displays already that the simulation is unable to process
>>>> the pathological part. But the simulation introduces a new halting
>>>> problem (recursive simulation), which he thinks is an answer for the
>>>> original halting problem.
>>>
>>> You're using PO's phrase "pathological" but that is a bad
>>> (misleading) term because it suggests there is something WRONG/BAD
>>> (aka sick?) in the situation. E.g. H processing input which is a
>>> description of its own source code. There is nothing whatsoever
>>> wrong with that - it's just that PO gets confused by it and so argues
>>> to ban it. Perhaps there is an alternative term that doesn't have
>>> the deliberate connotation of "sickness".
>>>
>>> Mike.
>>>
>>
>> *Two PhD computer science professors disagree*
>>
>> 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
>>
>> Bill Stoddart. *The Halting Paradox*
>> 20 December 2017
>> https://arxiv.org/abs/1906.05340
>> arXiv:1906.05340 [cs.LO]
>>
>> *You can ignore the above forever, that does not make it away*
>>
>
> Well, it kinda DOES. This is just a blatant appeal to authority on your
> part, so it can rightly be ignored. I'll say again - if you have some
> argument to make, argue it yourself in your own words rather than
> attempting to shut down discussion through appeal to authority.
>
*Those were my verbatim words that professor Sipser agreed to*
All the people that tried to show how I misinterpreted my own words
utterly failed.
Those that claimed Professor Sipser understood my words differently than
I did had only one basis that I remember being presented that is easily
proven false. *They tried to get away with contradicting this*
DD correctly emulated by any HH that can possibly exist DOES NOT HALT
DD correctly emulated by any HH that can possibly exist DOES NOT HALT
DD correctly emulated by any HH that can possibly exist DOES NOT HALT
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]
> [Perhaps Hehner/Stoddart are just idiots who got things wrong, or much
> more likely you've completely misinterpreted what they're saying, or
> you've misunderstood the context or whatever and you are the idiot. The
> bottom line is THEY ARE NOT HERE ARGUING ANY CASE SO WHAT YOU SAY THEY
> BELIEVE IS TOTALLY IRRELEVANT. And there's no need for anyone to get
> into discussions over whether it is Hehner/Stoddart or yourself who is
> confused...]
>
>
> Mike.
>
After many extensive conversations with professor Hehner:
His most relevant belief is that the halting problem cannot
be solved because there is something wrong with it.
Professor Hehner: Yes, I would sign that statement.
*My concise summation of the error*
The way that the halting problem is conventionally understood is that H
must correctly answer yes or no to an input that contradicts both
answers, thus H is being asked a question isomorphic to the Liar
Paradox: Is this sentence true or false: "This sentence is not true." ?
Professor Hehner got to something very much like that in his 2018 paper
with his Carol's question. 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-03 20:59 -0400 |
| Message-ID | <v3lots$2uv04$14@i2pn2.org> |
| In reply to | #106183 |
On 6/3/24 8:47 PM, olcott wrote:
> On 6/3/2024 1:56 PM, Mike Terry wrote:
>> On 03/06/2024 19:03, olcott wrote:
>>> On 6/3/2024 12:36 PM, Mike Terry wrote:
>>>> On 03/06/2024 08:58, Fred. Zwarts wrote:
>>>>> Op 03.jun.2024 om 02:16 schreef immibis:
>>>>>> The halting problem says you can't find a Turing machine that
>>>>>> tells whether executing each other Turing machine will halt.
>>>>>> Simulation has nothing to do with the question.
>>>>>
>>>>> Maybe because by using simulation he can shift the attention from
>>>>> the pathological part of the Linz proof, to another halting
>>>>> problem, namely that a simulating decider does not halt because it
>>>>> causes infinite recursion.
>>>>
>>>> PO's simulating decider does not cause infinite recursion. That
>>>> only occurs in the case where the decider performs a FULL simulation
>>>> of its input, whereas typically for PO his H/HH/... perform PARTIAL
>>>> simulations, where the decider monitors what is being simulated and
>>>> breaks off the simulation when a particular condition is observed.
>>>>
>>>
>>> Thanks for affirming that. You are my most technically
>>> competent and honest reviewer.
>>>
>>>> So yes, there is recursive simulation, but not /infinite/ recursion
>>>> since at each level of simulation the simulator is free to just stop
>>>> simulating at any time. In practice this means that the outer
>>>> simulator H will be the one to break out, since it will always be
>>>> ahead of all the inner simulations of H in how far it has
>>>> progressed. This situation is in contrast with direct call
>>>> recursion, where the outer caller has no control to break the
>>>> recursion - it only regains control once the inner calls have all
>>>> returned.
>>>>
>>>> PO does not properly understand this distinction.
>>>>
>>>
>>> *You can keep ignoring this that does not make it go away*
>>>
>>> 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>
>>>
>>> *You can ignore the above forever, that does not make it away*
>>
>> I do not ignore the above. I recently posted an example of it: a
>> simulating HD correctly reporting non-halting after detecting a tight
>> loop in the computation represented by its input.
>>
>> The problem with the above is with YOU. (You misinterpret/misapply
>> what Sipser says.)
>>
>> And of course your entire purpose behind quoting the above is just an
>> appeal to authority. You know that's a fallacy, because from time to
>> time you accuse others of doing it.
>>
>>>
>>>>>
>>>>> His own claim that D does not reach the pathological part (after
>>>>> line 03), displays already that the simulation is unable to process
>>>>> the pathological part. But the simulation introduces a new halting
>>>>> problem (recursive simulation), which he thinks is an answer for
>>>>> the original halting problem.
>>>>
>>>> You're using PO's phrase "pathological" but that is a bad
>>>> (misleading) term because it suggests there is something WRONG/BAD
>>>> (aka sick?) in the situation. E.g. H processing input which is a
>>>> description of its own source code. There is nothing whatsoever
>>>> wrong with that - it's just that PO gets confused by it and so
>>>> argues to ban it. Perhaps there is an alternative term that
>>>> doesn't have the deliberate connotation of "sickness".
>>>>
>>>> Mike.
>>>>
>>>
>>> *Two PhD computer science professors disagree*
>>>
>>> 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
>>>
>>> Bill Stoddart. *The Halting Paradox*
>>> 20 December 2017
>>> https://arxiv.org/abs/1906.05340
>>> arXiv:1906.05340 [cs.LO]
>>>
>>> *You can ignore the above forever, that does not make it away*
>>>
>>
>> Well, it kinda DOES. This is just a blatant appeal to authority on
>> your part, so it can rightly be ignored. I'll say again - if you have
>> some argument to make, argue it yourself in your own words rather than
>> attempting to shut down discussion through appeal to authority.
>>
>
> *Those were my verbatim words that professor Sipser agreed to*
> All the people that tried to show how I misinterpreted my own words
> utterly failed.
>
> Those that claimed Professor Sipser understood my words differently than
> I did had only one basis that I remember being presented that is easily
> proven false. *They tried to get away with contradicting this*
>
> DD correctly emulated by any HH that can possibly exist DOES NOT HALT
> DD correctly emulated by any HH that can possibly exist DOES NOT HALT
> DD correctly emulated by any HH that can possibly exist DOES NOT HALT
It does.
Has been proven.
You just don't know the meaning of the words you are using.
DD(DD) HALTS if HH(DD,DD) returns 0, and for your design, the only other
case is an HH that isn't a decider.
What you actually seem to be claiming is that no HH can correctly
simulate the DD built on it to a final state, or equivalently, No HH can
prove that the DD built on it will Halt.
Neither of these show that DD doesn't Halt, only that HH's simulation
can't get there.
>
> 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]
>
>> [Perhaps Hehner/Stoddart are just idiots who got things wrong, or much
>> more likely you've completely misinterpreted what they're saying, or
>> you've misunderstood the context or whatever and you are the idiot.
>> The bottom line is THEY ARE NOT HERE ARGUING ANY CASE SO WHAT YOU SAY
>> THEY BELIEVE IS TOTALLY IRRELEVANT. And there's no need for anyone to
>> get into discussions over whether it is Hehner/Stoddart or yourself
>> who is confused...]
>>
>>
>> Mike.
>>
>
> After many extensive conversations with professor Hehner:
> His most relevant belief is that the halting problem cannot
> be solved because there is something wrong with it.
>
> Professor Hehner: Yes, I would sign that statement.
>
> *My concise summation of the error*
> The way that the halting problem is conventionally understood is that H
> must correctly answer yes or no to an input that contradicts both
> answers, thus H is being asked a question isomorphic to the Liar
> Paradox: Is this sentence true or false: "This sentence is not true." ?
>
> Professor Hehner got to something very much like that in his 2018 paper
> with his Carol's question. https://www.cs.toronto.edu/~hehner/OSS.pdf
>
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-03 20:05 -0500 |
| Message-ID | <v3lp8g$43oa$2@dont-email.me> |
| In reply to | #106197 |
On 6/3/2024 7:59 PM, Richard Damon wrote:
> On 6/3/24 8:47 PM, olcott wrote:
>> On 6/3/2024 1:56 PM, Mike Terry wrote:
>>> On 03/06/2024 19:03, olcott wrote:
>>>> On 6/3/2024 12:36 PM, Mike Terry wrote:
>>>>> On 03/06/2024 08:58, Fred. Zwarts wrote:
>>>>>> Op 03.jun.2024 om 02:16 schreef immibis:
>>>>>>> The halting problem says you can't find a Turing machine that
>>>>>>> tells whether executing each other Turing machine will halt.
>>>>>>> Simulation has nothing to do with the question.
>>>>>>
>>>>>> Maybe because by using simulation he can shift the attention from
>>>>>> the pathological part of the Linz proof, to another halting
>>>>>> problem, namely that a simulating decider does not halt because it
>>>>>> causes infinite recursion.
>>>>>
>>>>> PO's simulating decider does not cause infinite recursion. That
>>>>> only occurs in the case where the decider performs a FULL
>>>>> simulation of its input, whereas typically for PO his H/HH/...
>>>>> perform PARTIAL simulations, where the decider monitors what is
>>>>> being simulated and breaks off the simulation when a particular
>>>>> condition is observed.
>>>>>
>>>>
>>>> Thanks for affirming that. You are my most technically
>>>> competent and honest reviewer.
>>>>
>>>>> So yes, there is recursive simulation, but not /infinite/ recursion
>>>>> since at each level of simulation the simulator is free to just
>>>>> stop simulating at any time. In practice this means that the outer
>>>>> simulator H will be the one to break out, since it will always be
>>>>> ahead of all the inner simulations of H in how far it has
>>>>> progressed. This situation is in contrast with direct call
>>>>> recursion, where the outer caller has no control to break the
>>>>> recursion - it only regains control once the inner calls have all
>>>>> returned.
>>>>>
>>>>> PO does not properly understand this distinction.
>>>>>
>>>>
>>>> *You can keep ignoring this that does not make it go away*
>>>>
>>>> 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>
>>>>
>>>> *You can ignore the above forever, that does not make it away*
>>>
>>> I do not ignore the above. I recently posted an example of it: a
>>> simulating HD correctly reporting non-halting after detecting a tight
>>> loop in the computation represented by its input.
>>>
>>> The problem with the above is with YOU. (You misinterpret/misapply
>>> what Sipser says.)
>>>
>>> And of course your entire purpose behind quoting the above is just an
>>> appeal to authority. You know that's a fallacy, because from time to
>>> time you accuse others of doing it.
>>>
>>>>
>>>>>>
>>>>>> His own claim that D does not reach the pathological part (after
>>>>>> line 03), displays already that the simulation is unable to
>>>>>> process the pathological part. But the simulation introduces a new
>>>>>> halting problem (recursive simulation), which he thinks is an
>>>>>> answer for the original halting problem.
>>>>>
>>>>> You're using PO's phrase "pathological" but that is a bad
>>>>> (misleading) term because it suggests there is something WRONG/BAD
>>>>> (aka sick?) in the situation. E.g. H processing input which is a
>>>>> description of its own source code. There is nothing whatsoever
>>>>> wrong with that - it's just that PO gets confused by it and so
>>>>> argues to ban it. Perhaps there is an alternative term that
>>>>> doesn't have the deliberate connotation of "sickness".
>>>>>
>>>>> Mike.
>>>>>
>>>>
>>>> *Two PhD computer science professors disagree*
>>>>
>>>> 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
>>>>
>>>> Bill Stoddart. *The Halting Paradox*
>>>> 20 December 2017
>>>> https://arxiv.org/abs/1906.05340
>>>> arXiv:1906.05340 [cs.LO]
>>>>
>>>> *You can ignore the above forever, that does not make it away*
>>>>
>>>
>>> Well, it kinda DOES. This is just a blatant appeal to authority on
>>> your part, so it can rightly be ignored. I'll say again - if you
>>> have some argument to make, argue it yourself in your own words
>>> rather than attempting to shut down discussion through appeal to
>>> authority.
>>>
>>
>> *Those were my verbatim words that professor Sipser agreed to*
>> All the people that tried to show how I misinterpreted my own words
>> utterly failed.
>>
>> Those that claimed Professor Sipser understood my words differently than
>> I did had only one basis that I remember being presented that is easily
>> proven false. *They tried to get away with contradicting this*
>>
>> DD correctly emulated by any HH that can possibly exist DOES NOT HALT
>> DD correctly emulated by any HH that can possibly exist DOES NOT HALT
>> DD correctly emulated by any HH that can possibly exist DOES NOT HALT
>
> It does.
>
> Has been proven.
>
*I say that you know you are a liar until after you show the steps*
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]
--
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-03 21:44 -0400 |
| Message-ID | <v3lrh9$2uv03$2@i2pn2.org> |
| In reply to | #106199 |
On 6/3/24 9:05 PM, olcott wrote:
> On 6/3/2024 7:59 PM, Richard Damon wrote:
>> On 6/3/24 8:47 PM, olcott wrote:
>>> On 6/3/2024 1:56 PM, Mike Terry wrote:
>>>> On 03/06/2024 19:03, olcott wrote:
>>>>> On 6/3/2024 12:36 PM, Mike Terry wrote:
>>>>>> On 03/06/2024 08:58, Fred. Zwarts wrote:
>>>>>>> Op 03.jun.2024 om 02:16 schreef immibis:
>>>>>>>> The halting problem says you can't find a Turing machine that
>>>>>>>> tells whether executing each other Turing machine will halt.
>>>>>>>> Simulation has nothing to do with the question.
>>>>>>>
>>>>>>> Maybe because by using simulation he can shift the attention from
>>>>>>> the pathological part of the Linz proof, to another halting
>>>>>>> problem, namely that a simulating decider does not halt because
>>>>>>> it causes infinite recursion.
>>>>>>
>>>>>> PO's simulating decider does not cause infinite recursion. That
>>>>>> only occurs in the case where the decider performs a FULL
>>>>>> simulation of its input, whereas typically for PO his H/HH/...
>>>>>> perform PARTIAL simulations, where the decider monitors what is
>>>>>> being simulated and breaks off the simulation when a particular
>>>>>> condition is observed.
>>>>>>
>>>>>
>>>>> Thanks for affirming that. You are my most technically
>>>>> competent and honest reviewer.
>>>>>
>>>>>> So yes, there is recursive simulation, but not /infinite/
>>>>>> recursion since at each level of simulation the simulator is free
>>>>>> to just stop simulating at any time. In practice this means that
>>>>>> the outer simulator H will be the one to break out, since it will
>>>>>> always be ahead of all the inner simulations of H in how far it
>>>>>> has progressed. This situation is in contrast with direct call
>>>>>> recursion, where the outer caller has no control to break the
>>>>>> recursion - it only regains control once the inner calls have all
>>>>>> returned.
>>>>>>
>>>>>> PO does not properly understand this distinction.
>>>>>>
>>>>>
>>>>> *You can keep ignoring this that does not make it go away*
>>>>>
>>>>> 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>
>>>>>
>>>>> *You can ignore the above forever, that does not make it away*
>>>>
>>>> I do not ignore the above. I recently posted an example of it: a
>>>> simulating HD correctly reporting non-halting after detecting a
>>>> tight loop in the computation represented by its input.
>>>>
>>>> The problem with the above is with YOU. (You misinterpret/misapply
>>>> what Sipser says.)
>>>>
>>>> And of course your entire purpose behind quoting the above is just
>>>> an appeal to authority. You know that's a fallacy, because from
>>>> time to time you accuse others of doing it.
>>>>
>>>>>
>>>>>>>
>>>>>>> His own claim that D does not reach the pathological part (after
>>>>>>> line 03), displays already that the simulation is unable to
>>>>>>> process the pathological part. But the simulation introduces a
>>>>>>> new halting problem (recursive simulation), which he thinks is an
>>>>>>> answer for the original halting problem.
>>>>>>
>>>>>> You're using PO's phrase "pathological" but that is a bad
>>>>>> (misleading) term because it suggests there is something WRONG/BAD
>>>>>> (aka sick?) in the situation. E.g. H processing input which is a
>>>>>> description of its own source code. There is nothing whatsoever
>>>>>> wrong with that - it's just that PO gets confused by it and so
>>>>>> argues to ban it. Perhaps there is an alternative term that
>>>>>> doesn't have the deliberate connotation of "sickness".
>>>>>>
>>>>>> Mike.
>>>>>>
>>>>>
>>>>> *Two PhD computer science professors disagree*
>>>>>
>>>>> 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
>>>>>
>>>>> Bill Stoddart. *The Halting Paradox*
>>>>> 20 December 2017
>>>>> https://arxiv.org/abs/1906.05340
>>>>> arXiv:1906.05340 [cs.LO]
>>>>>
>>>>> *You can ignore the above forever, that does not make it away*
>>>>>
>>>>
>>>> Well, it kinda DOES. This is just a blatant appeal to authority on
>>>> your part, so it can rightly be ignored. I'll say again - if you
>>>> have some argument to make, argue it yourself in your own words
>>>> rather than attempting to shut down discussion through appeal to
>>>> authority.
>>>>
>>>
>>> *Those were my verbatim words that professor Sipser agreed to*
>>> All the people that tried to show how I misinterpreted my own words
>>> utterly failed.
>>>
>>> Those that claimed Professor Sipser understood my words differently than
>>> I did had only one basis that I remember being presented that is easily
>>> proven false. *They tried to get away with contradicting this*
>>>
>>> DD correctly emulated by any HH that can possibly exist DOES NOT HALT
>>> DD correctly emulated by any HH that can possibly exist DOES NOT HALT
>>> DD correctly emulated by any HH that can possibly exist DOES NOT HALT
>>
>> It does.
>>
>> Has been proven.
>>
>
> *I say that you know you are a liar until after you show the steps*
DD will halt (Remember, I am not saying the somulaiton by HH, but that
DD itself will halt).
because when we get to the call HH instruction, DDs execution path will
go into HH and then after some time, since HH is defined to be a
decider, it will return the value 0 to DD and DD with then halt.
This DD calls an HH that does "correctly emulated" it per your
definition, so the conditional part of the statement is satisfied.
Remember, the DEFINITION OF HALTING is about the machine you are talking
about, in this case DD, NOT a partial simulation of it.
If you want to talk about that you need to use words that actually say that.
You are just proving how stupid you are, since you refuse to learn the
actual meaning of the word you use, and continue to INTENTIONALLY use
them wrong.
That proves you to be a PATHOLOGICAL LIAR with a reckless disregard for
the truth.
>
> 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]
>
>
[toc] | [prev] | [next] | [standalone]
Page 16 of 17 — ← Prev page 1 … 14 15 [16] 17 Next page →
Back to top | Article view | comp.theory
csiph-web