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 2 of 17 — ← Prev page 1 [2] 3 4 … 17 Next page →
| From | Mikko <mikko.levanto@iki.fi> |
|---|---|
| Date | 2024-06-06 11:25 +0300 |
| Subject | Re: Why does Olcott care about simulation, anyway? --- Mikes Review |
| Message-ID | <v3rrq9$1e763$1@dont-email.me> |
| In reply to | #106309 |
On 2024-06-05 13:08:19 +0000, olcott said: > On 6/5/2024 2:08 AM, Mikko wrote: >> On 2024-06-04 17:12:49 +0000, olcott said: >> >>> On 6/3/2024 9:49 PM, Richard Damon wrote: >>>> On 6/3/24 10:18 PM, olcott wrote: >>>>> On 6/3/2024 8:59 PM, Richard Damon wrote: >>>>>> On 6/3/24 9:46 PM, olcott wrote: >>>>>>> On 6/3/2024 8:38 PM, Mike Terry wrote: >>>>>>>> On 03/06/2024 18:54, olcott wrote: >>>>>>>>> On 6/3/2024 11:25 AM, Mike Terry wrote: >>>>>>>>>> On 03/06/2024 04:50, olcott wrote: >>>>>>>>>>> On 6/2/2024 10:28 PM, Mike Terry wrote: >>>>>>>>>>>> On 03/06/2024 01:16, immibis wrote: >>>>>>>>>>>>> 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. >>>>>>>>>>>> >>>>>>>>>>>> Background: >>>>>>>>>>>> >>>>>>>>>>>> PO claims to have refuted the common HP proof, e.g. as covered in the >>>>>>>>>>>> Linz book "An Introduction to Formal Languages and Automata". PO >>>>>>>>>>>> occasionally posts a link to a PDF containing an extract of the 5 or so >>>>>>>>>>>> pages of the book containing the proof, but I expect you have access to >>>>>>>>>>>> this or equivalent. >>>>>>>>>>>> >>>>>>>>>>>> In a nutshell, the proof goes: >>>>>>>>>>>> - Suppose H is a TM Halt decider that decides for any input <P><I> whether >>>>>>>>>>>> TM P run with input I on its input tape halts. >>>>>>>>>>>> [<P> is the string representation of the actual TM P, and >>>>>>>>>>>> <I> is the string representation of input tape I] >>>>>>>>>>>> - Construct from H a new TM H^ using the mechanical process described >>>>>>>>>>>> in the proof. >>>>>>>>>>>> If H exists, then its corresponding H^ also exists. >>>>>>>>>>>> - Show that the construction of H^ ensures that: >>>>>>>>>>>> - if H decides input <H^><H^> (representing H^ running with input >>>>>>>>>>>> <H^>) halts, >>>>>>>>>>>> then that implies that H^ running with input <H^> never halts >>>>>>>>>>>> - if H decides input <H^><H^> never halts, >>>>>>>>>>>> then that implies H^ running with input <H^> halts >>>>>>>>>>>> I.e. either way, H decides the specific input <H^><H^> incorrectly, >>>>>>>>>>>> contradicting >>>>>>>>>>>> the initial assumption that H is a halt decider. >>>>>>>>>>>> - So no halt decider exists. (Every proposed halt decider decides at >>>>>>>>>>>> least one input case >>>>>>>>>>>> incorrectly, viz input <H^><H^>.) >>>>>>>>>>>> >>>>>>>>>>>> PO basically claimed he had a fully coded TM H, which CORRECTLY decides >>>>>>>>>>>> its "nemesis" input <H^><H^>, contradicting the logic of the Linz proof >>>>>>>>>>>> [without pointing out any actual mistake in the Linz proof]. Given >>>>>>>>>>>> most people here understand the Linz proof well enough to see it is >>>>>>>>>>>> basically sound, people were sceptical! >>>>>>>>>>>> >>>>>>>>>>>> It turned out PO was lying about the fully coded TM, and in fact what >>>>>>>>>>>> he actually had was the idea behind a C program which would "prove" his >>>>>>>>>>>> idea. A couple of years(?) later he actually completed his C program >>>>>>>>>>>> and his x86utm.exe which would simulate the x86 code of his H and H^ to >>>>>>>>>>>> "prove" his claim. His equivalent of Linz H is his C function H or HH, >>>>>>>>>>>> and his equivalent of Linz H^ is his D or DD respectively. (They run >>>>>>>>>>>> under x86utm.exe and are not Windows/Unix executables.) >>>>>>>>>>>> >>>>>>>>>>>> H/HH use PARTIAL simulation of their input to decide >>>>>>>>>>>> halting/non-halting, returning >>>>>>>>>>>> 0 or 1 to communicate their decision. As you correctly point out, to >>>>>>>>>>>> the HP proof simulation is quite irrelevant, being just one kind of >>>>>>>>>>>> data manipulation that H may perform on its input string <P><I> before >>>>>>>>>>>> it decides the halting status. So the Linz HP proof covers such H, no >>>>>>>>>>>> problem. >>>>>>>>>>>> [I put PARTIAL in caps, just because there seems to be some confusion >>>>>>>>>>>> in recent threads as to what PO means by "simulation". He doesn't say >>>>>>>>>>>> it explicitly, despite suggestions to this effect, but he always means >>>>>>>>>>>> what might be called /partial/ simulation.] >>>>>>>>>>>> >>>>>>>>>>>> PO believes that by (partially) simulating the computation >>>>>>>>>>>> corresponding to the input <P><I> [i.e. calculating the successive x86 >>>>>>>>>>>> instruction steps of the computation P(I)] and monitoring the progress >>>>>>>>>>>> of virtual x86 state changes (like instruction address and op-code and >>>>>>>>>>>> so on) H could spot some pattern that reveals whether computation P(I) >>>>>>>>>>>> halts or not. At this point in the partial simulation, his H would >>>>>>>>>>>> stop simulating (aka "abort" the simulation) and return the appropriate >>>>>>>>>>>> halt status for input <P><I>. >>>>>>>>>>>> >>>>>>>>>>>> Nothing remarkable so far! Clearly a tight-loop in P /can/ be detected >>>>>>>>>>>> in this fashion, so /some/ <P><I> inputs /can/ be correctly determined >>>>>>>>>>>> like this. The PO claim however is that the specific input <H^><H^> is >>>>>>>>>>>> correctly decided by his H. In C terms those correspond to H(D,D) >>>>>>>>>>>> correctly returning the halt status of computation D(D). [PO would >>>>>>>>>>>> probably dispute this, because he doesn't properly understand halting >>>>>>>>>>>> or the HP generally, or in fact pretty much /any abstract concept/ ] >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 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> >>>>>>>>>>> >>>>>>>>>>> I have started working on what seem to be some computability issues >>>>>>>>>>> that you pointed out with my HH. I found that they are isolated to >>>>>>>>>>> one single element of HH. Essentially the details of how the master >>>>>>>>>>> UTM directly executed HH passes a portion of its tape to its slaves. >>>>>>>>>>> >>>>>>>>>>> Nothing else seems to have any computability issues by the measure >>>>>>>>>>> that I am using. >>>>>>>>>>> >>>>>>>>>>> Message-ID: <rLmcnQQ3-N_tvH_4nZ2dnZfqnPGdnZ2d@brightview.co.uk> >>>>>>>>>>> On 3/1/2024 12:41 PM, Mike Terry wrote: >>>>>>>>>>> > >>>>>>>>>>> > Obviously a simulator has access to the internal state >>>>>>>>>>> > (tape contents etc.) of the simulated machine. No problem there. >>>>>>>>>>> >>>>>>>>>>> Because of your above comment it seems that correcting this >>>>>>>>>>> tiny computability issue with HH is my best path forward. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> You have given the following a blatantly false review when I >>>>>>>>>>> said the same thing another way: >>>>>>>>>> >>>>>>>>>> I have no idea what you're talking about. I did not write any of what >>>>>>>>>> follows below. >>>>>>>>>> >>>>>>>>>> Also I don't believe I said anything "blatantly false". You're >>>>>>>>>> incapable of judging what other people say or are thinking - you're >>>>>>>>>> often telling people that they'er lying to you and denying >>>>>>>>>> "previously verified facts" etc. but its all rubbish - you're in no >>>>>>>>>> position to make such judgements. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Mike. >>>>>>>>>> >>>>>>>>> >>>>>>>>> You said that the execution trace that I proved is correct is >>>>>>>>> incorrect because you didn't like the way that HH was written. >>>>>>>>> You said this without looking at my proof as you are doing >>>>>>>>> here again. >>>>>>>> >>>>>>>> An execution trace that is produced by a program that is incorrect >>>>>>>> /proves/ nothing whatsoever. I don't need to look at your proof, as I >>>>>>>> was commenting on the value of your program output AS PROOF. >>>>>>>> >>>>>>> >>>>>>> I provided the execution trace that HH derives >>>>>>> *AND THE X86 SOURCE-CODE OF DD THAT PROVES THIS TRACE IS CORRECT* >>>>>>> *AND THE X86 SOURCE-CODE OF DD THAT PROVES THIS TRACE IS CORRECT* >>>>>>> *AND THE X86 SOURCE-CODE OF DD THAT PROVES THIS TRACE IS CORRECT* >>>>>> >>>>>> Then why did the trace not follow the call to H? >>>>>> >>>>> >>>>> HH(DD,DD) the trace does follow the call to HH(DD,DD) >>>>> and fully simulates itself simulating DD. >>>> >>>> So, where are the instuctions of HH shown? >>>> >>>> I guess you are just a LIAR. >>>> >>> >>> It might be good for you to quit calling me a liar, everyone here >>> knows that I am not a liar. >> >> Most people here don't care whether you are a liar or a fool. >> > > Richard understands that: > > Revelations 21:8 (KJV) > ...and all liars, shall have their part in the lake which > burneth with fire and brimstone: which is the second death. > > If Richard is calling me a liar when he knows that I believe > what I say he might be condemned to Hell, I don't want that. Discussion of that kind of things are off-topic in comp.theory. Perhaps you should ask the nearest priest. -- Mikko
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-06 08:13 -0500 |
| Subject | Re: Why does Olcott care about simulation, anyway? --- Mikes Review |
| Message-ID | <v3scm6$1gra7$5@dont-email.me> |
| In reply to | #106381 |
On 6/6/2024 3:25 AM, Mikko wrote: > On 2024-06-05 13:08:19 +0000, olcott said: > >> On 6/5/2024 2:08 AM, Mikko wrote: >>> On 2024-06-04 17:12:49 +0000, olcott said: >>> >>>> On 6/3/2024 9:49 PM, Richard Damon wrote: >>>>> On 6/3/24 10:18 PM, olcott wrote: >>>>>> On 6/3/2024 8:59 PM, Richard Damon wrote: >>>>>>> On 6/3/24 9:46 PM, olcott wrote: >>>>>>>> On 6/3/2024 8:38 PM, Mike Terry wrote: >>>>>>>>> On 03/06/2024 18:54, olcott wrote: >>>>>>>>>> On 6/3/2024 11:25 AM, Mike Terry wrote: >>>>>>>>>>> On 03/06/2024 04:50, olcott wrote: >>>>>>>>>>>> On 6/2/2024 10:28 PM, Mike Terry wrote: >>>>>>>>>>>>> On 03/06/2024 01:16, immibis wrote: >>>>>>>>>>>>>> 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. >>>>>>>>>>>>> >>>>>>>>>>>>> Background: >>>>>>>>>>>>> >>>>>>>>>>>>> PO claims to have refuted the common HP proof, e.g. as >>>>>>>>>>>>> covered in the Linz book "An Introduction to Formal >>>>>>>>>>>>> Languages and Automata". PO occasionally posts a link to a >>>>>>>>>>>>> PDF containing an extract of the 5 or so pages of the book >>>>>>>>>>>>> containing the proof, but I expect you have access to this >>>>>>>>>>>>> or equivalent. >>>>>>>>>>>>> >>>>>>>>>>>>> In a nutshell, the proof goes: >>>>>>>>>>>>> - Suppose H is a TM Halt decider that decides for any >>>>>>>>>>>>> input <P><I> whether >>>>>>>>>>>>> TM P run with input I on its input tape halts. >>>>>>>>>>>>> [<P> is the string representation of the actual TM P, and >>>>>>>>>>>>> <I> is the string representation of input tape I] >>>>>>>>>>>>> - Construct from H a new TM H^ using the mechanical >>>>>>>>>>>>> process described in the proof. >>>>>>>>>>>>> If H exists, then its corresponding H^ also exists. >>>>>>>>>>>>> - Show that the construction of H^ ensures that: >>>>>>>>>>>>> - if H decides input <H^><H^> (representing H^ running >>>>>>>>>>>>> with input <H^>) halts, >>>>>>>>>>>>> then that implies that H^ running with input <H^> >>>>>>>>>>>>> never halts >>>>>>>>>>>>> - if H decides input <H^><H^> never halts, >>>>>>>>>>>>> then that implies H^ running with input <H^> halts >>>>>>>>>>>>> I.e. either way, H decides the specific input <H^><H^> >>>>>>>>>>>>> incorrectly, contradicting >>>>>>>>>>>>> the initial assumption that H is a halt decider. >>>>>>>>>>>>> - So no halt decider exists. (Every proposed halt decider >>>>>>>>>>>>> decides at least one input case >>>>>>>>>>>>> incorrectly, viz input <H^><H^>.) >>>>>>>>>>>>> >>>>>>>>>>>>> PO basically claimed he had a fully coded TM H, which >>>>>>>>>>>>> CORRECTLY decides its "nemesis" input <H^><H^>, >>>>>>>>>>>>> contradicting the logic of the Linz proof [without pointing >>>>>>>>>>>>> out any actual mistake in the Linz proof]. Given most >>>>>>>>>>>>> people here understand the Linz proof well enough to see it >>>>>>>>>>>>> is basically sound, people were sceptical! >>>>>>>>>>>>> >>>>>>>>>>>>> It turned out PO was lying about the fully coded TM, and in >>>>>>>>>>>>> fact what he actually had was the idea behind a C program >>>>>>>>>>>>> which would "prove" his idea. A couple of years(?) later >>>>>>>>>>>>> he actually completed his C program and his x86utm.exe >>>>>>>>>>>>> which would simulate the x86 code of his H and H^ to >>>>>>>>>>>>> "prove" his claim. His equivalent of Linz H is his C >>>>>>>>>>>>> function H or HH, and his equivalent of Linz H^ is his D or >>>>>>>>>>>>> DD respectively. (They run under x86utm.exe and are not >>>>>>>>>>>>> Windows/Unix executables.) >>>>>>>>>>>>> >>>>>>>>>>>>> H/HH use PARTIAL simulation of their input to decide >>>>>>>>>>>>> halting/non-halting, returning >>>>>>>>>>>>> 0 or 1 to communicate their decision. As you correctly >>>>>>>>>>>>> point out, to the HP proof simulation is quite irrelevant, >>>>>>>>>>>>> being just one kind of data manipulation that H may perform >>>>>>>>>>>>> on its input string <P><I> before it decides the halting >>>>>>>>>>>>> status. So the Linz HP proof covers such H, no problem. >>>>>>>>>>>>> [I put PARTIAL in caps, just because there seems to be some >>>>>>>>>>>>> confusion in recent threads as to what PO means by >>>>>>>>>>>>> "simulation". He doesn't say it explicitly, despite >>>>>>>>>>>>> suggestions to this effect, but he always means what might >>>>>>>>>>>>> be called /partial/ simulation.] >>>>>>>>>>>>> >>>>>>>>>>>>> PO believes that by (partially) simulating the computation >>>>>>>>>>>>> corresponding to the input <P><I> [i.e. calculating the >>>>>>>>>>>>> successive x86 instruction steps of the computation P(I)] >>>>>>>>>>>>> and monitoring the progress of virtual x86 state changes >>>>>>>>>>>>> (like instruction address and op-code and so on) H could >>>>>>>>>>>>> spot some pattern that reveals whether computation P(I) >>>>>>>>>>>>> halts or not. At this point in the partial simulation, his >>>>>>>>>>>>> H would stop simulating (aka "abort" the simulation) and >>>>>>>>>>>>> return the appropriate halt status for input <P><I>. >>>>>>>>>>>>> >>>>>>>>>>>>> Nothing remarkable so far! Clearly a tight-loop in P /can/ >>>>>>>>>>>>> be detected in this fashion, so /some/ <P><I> inputs /can/ >>>>>>>>>>>>> be correctly determined like this. The PO claim however is >>>>>>>>>>>>> that the specific input <H^><H^> is correctly decided by >>>>>>>>>>>>> his H. In C terms those correspond to H(D,D) correctly >>>>>>>>>>>>> returning the halt status of computation D(D). [PO would >>>>>>>>>>>>> probably dispute this, because he doesn't properly >>>>>>>>>>>>> understand halting or the HP generally, or in fact pretty >>>>>>>>>>>>> much /any abstract concept/ ] >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 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> >>>>>>>>>>>> >>>>>>>>>>>> I have started working on what seem to be some computability >>>>>>>>>>>> issues >>>>>>>>>>>> that you pointed out with my HH. I found that they are >>>>>>>>>>>> isolated to >>>>>>>>>>>> one single element of HH. Essentially the details of how the >>>>>>>>>>>> master >>>>>>>>>>>> UTM directly executed HH passes a portion of its tape to its >>>>>>>>>>>> slaves. >>>>>>>>>>>> >>>>>>>>>>>> Nothing else seems to have any computability issues by the >>>>>>>>>>>> measure >>>>>>>>>>>> that I am using. >>>>>>>>>>>> >>>>>>>>>>>> Message-ID: <rLmcnQQ3-N_tvH_4nZ2dnZfqnPGdnZ2d@brightview.co.uk> >>>>>>>>>>>> On 3/1/2024 12:41 PM, Mike Terry wrote: >>>>>>>>>>>> > >>>>>>>>>>>> > Obviously a simulator has access to the internal state >>>>>>>>>>>> > (tape contents etc.) of the simulated machine. No problem >>>>>>>>>>>> there. >>>>>>>>>>>> >>>>>>>>>>>> Because of your above comment it seems that correcting this >>>>>>>>>>>> tiny computability issue with HH is my best path forward. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> You have given the following a blatantly false review when I >>>>>>>>>>>> said the same thing another way: >>>>>>>>>>> >>>>>>>>>>> I have no idea what you're talking about. I did not write >>>>>>>>>>> any of what follows below. >>>>>>>>>>> >>>>>>>>>>> Also I don't believe I said anything "blatantly false". >>>>>>>>>>> You're incapable of judging what other people say or are >>>>>>>>>>> thinking - you're often telling people that they'er lying to >>>>>>>>>>> you and denying >>>>>>>>>>> "previously verified facts" etc. but its all rubbish - you're >>>>>>>>>>> in no position to make such judgements. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Mike. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> You said that the execution trace that I proved is correct is >>>>>>>>>> incorrect because you didn't like the way that HH was written. >>>>>>>>>> You said this without looking at my proof as you are doing >>>>>>>>>> here again. >>>>>>>>> >>>>>>>>> An execution trace that is produced by a program that is >>>>>>>>> incorrect /proves/ nothing whatsoever. I don't need to look at >>>>>>>>> your proof, as I was commenting on the value of your program >>>>>>>>> output AS PROOF. >>>>>>>>> >>>>>>>> >>>>>>>> I provided the execution trace that HH derives >>>>>>>> *AND THE X86 SOURCE-CODE OF DD THAT PROVES THIS TRACE IS CORRECT* >>>>>>>> *AND THE X86 SOURCE-CODE OF DD THAT PROVES THIS TRACE IS CORRECT* >>>>>>>> *AND THE X86 SOURCE-CODE OF DD THAT PROVES THIS TRACE IS CORRECT* >>>>>>> >>>>>>> Then why did the trace not follow the call to H? >>>>>>> >>>>>> >>>>>> HH(DD,DD) the trace does follow the call to HH(DD,DD) >>>>>> and fully simulates itself simulating DD. >>>>> >>>>> So, where are the instuctions of HH shown? >>>>> >>>>> I guess you are just a LIAR. >>>>> >>>> >>>> It might be good for you to quit calling me a liar, everyone here >>>> knows that I am not a liar. >>> >>> Most people here don't care whether you are a liar or a fool. >>> >> >> Richard understands that: >> >> Revelations 21:8 (KJV) >> ...and all liars, shall have their part in the lake which >> burneth with fire and brimstone: which is the second death. >> >> If Richard is calling me a liar when he knows that I believe >> what I say he might be condemned to Hell, I don't want that. > > Discussion of that kind of things are off-topic in comp.theory. > Perhaps you should ask the nearest priest. > Alternatively it could be a defamation case. -- Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Mikko <mikko.levanto@iki.fi> |
|---|---|
| Date | 2024-06-06 18:18 +0300 |
| Subject | Re: Why does Olcott care about simulation, anyway? --- Mikes Review |
| Message-ID | <v3sjvk$1ibni$1@dont-email.me> |
| In reply to | #106394 |
On 2024-06-06 13:13:42 +0000, olcott said: > On 6/6/2024 3:25 AM, Mikko wrote: >> On 2024-06-05 13:08:19 +0000, olcott said: >> >>> On 6/5/2024 2:08 AM, Mikko wrote: >>>> On 2024-06-04 17:12:49 +0000, olcott said: >>>> >>>>> On 6/3/2024 9:49 PM, Richard Damon wrote: >>>>>> On 6/3/24 10:18 PM, olcott wrote: >>>>>>> On 6/3/2024 8:59 PM, Richard Damon wrote: >>>>>>>> On 6/3/24 9:46 PM, olcott wrote: >>>>>>>>> On 6/3/2024 8:38 PM, Mike Terry wrote: >>>>>>>>>> On 03/06/2024 18:54, olcott wrote: >>>>>>>>>>> On 6/3/2024 11:25 AM, Mike Terry wrote: >>>>>>>>>>>> On 03/06/2024 04:50, olcott wrote: >>>>>>>>>>>>> On 6/2/2024 10:28 PM, Mike Terry wrote: >>>>>>>>>>>>>> On 03/06/2024 01:16, immibis wrote: >>>>>>>>>>>>>>> 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. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Background: >>>>>>>>>>>>>> >>>>>>>>>>>>>> PO claims to have refuted the common HP proof, e.g. as covered in the >>>>>>>>>>>>>> Linz book "An Introduction to Formal Languages and Automata". PO >>>>>>>>>>>>>> occasionally posts a link to a PDF containing an extract of the 5 or so >>>>>>>>>>>>>> pages of the book containing the proof, but I expect you have access to >>>>>>>>>>>>>> this or equivalent. >>>>>>>>>>>>>> >>>>>>>>>>>>>> In a nutshell, the proof goes: >>>>>>>>>>>>>> - Suppose H is a TM Halt decider that decides for any input <P><I> whether >>>>>>>>>>>>>> TM P run with input I on its input tape halts. >>>>>>>>>>>>>> [<P> is the string representation of the actual TM P, and >>>>>>>>>>>>>> <I> is the string representation of input tape I] >>>>>>>>>>>>>> - Construct from H a new TM H^ using the mechanical process described >>>>>>>>>>>>>> in the proof. >>>>>>>>>>>>>> If H exists, then its corresponding H^ also exists. >>>>>>>>>>>>>> - Show that the construction of H^ ensures that: >>>>>>>>>>>>>> - if H decides input <H^><H^> (representing H^ running with input >>>>>>>>>>>>>> <H^>) halts, >>>>>>>>>>>>>> then that implies that H^ running with input <H^> never halts >>>>>>>>>>>>>> - if H decides input <H^><H^> never halts, >>>>>>>>>>>>>> then that implies H^ running with input <H^> halts >>>>>>>>>>>>>> I.e. either way, H decides the specific input <H^><H^> incorrectly, >>>>>>>>>>>>>> contradicting >>>>>>>>>>>>>> the initial assumption that H is a halt decider. >>>>>>>>>>>>>> - So no halt decider exists. (Every proposed halt decider decides at >>>>>>>>>>>>>> least one input case >>>>>>>>>>>>>> incorrectly, viz input <H^><H^>.) >>>>>>>>>>>>>> >>>>>>>>>>>>>> PO basically claimed he had a fully coded TM H, which CORRECTLY decides >>>>>>>>>>>>>> its "nemesis" input <H^><H^>, contradicting the logic of the Linz proof >>>>>>>>>>>>>> [without pointing out any actual mistake in the Linz proof]. Given >>>>>>>>>>>>>> most people here understand the Linz proof well enough to see it is >>>>>>>>>>>>>> basically sound, people were sceptical! >>>>>>>>>>>>>> >>>>>>>>>>>>>> It turned out PO was lying about the fully coded TM, and in fact what >>>>>>>>>>>>>> he actually had was the idea behind a C program which would "prove" his >>>>>>>>>>>>>> idea. A couple of years(?) later he actually completed his C program >>>>>>>>>>>>>> and his x86utm.exe which would simulate the x86 code of his H and H^ to >>>>>>>>>>>>>> "prove" his claim. His equivalent of Linz H is his C function H or HH, >>>>>>>>>>>>>> and his equivalent of Linz H^ is his D or DD respectively. (They run >>>>>>>>>>>>>> under x86utm.exe and are not Windows/Unix executables.) >>>>>>>>>>>>>> >>>>>>>>>>>>>> H/HH use PARTIAL simulation of their input to decide >>>>>>>>>>>>>> halting/non-halting, returning >>>>>>>>>>>>>> 0 or 1 to communicate their decision. As you correctly point out, to >>>>>>>>>>>>>> the HP proof simulation is quite irrelevant, being just one kind of >>>>>>>>>>>>>> data manipulation that H may perform on its input string <P><I> before >>>>>>>>>>>>>> it decides the halting status. So the Linz HP proof covers such H, no >>>>>>>>>>>>>> problem. >>>>>>>>>>>>>> [I put PARTIAL in caps, just because there seems to be some confusion >>>>>>>>>>>>>> in recent threads as to what PO means by "simulation". He doesn't say >>>>>>>>>>>>>> it explicitly, despite suggestions to this effect, but he always means >>>>>>>>>>>>>> what might be called /partial/ simulation.] >>>>>>>>>>>>>> >>>>>>>>>>>>>> PO believes that by (partially) simulating the computation >>>>>>>>>>>>>> corresponding to the input <P><I> [i.e. calculating the successive x86 >>>>>>>>>>>>>> instruction steps of the computation P(I)] and monitoring the progress >>>>>>>>>>>>>> of virtual x86 state changes (like instruction address and op-code and >>>>>>>>>>>>>> so on) H could spot some pattern that reveals whether computation P(I) >>>>>>>>>>>>>> halts or not. At this point in the partial simulation, his H would >>>>>>>>>>>>>> stop simulating (aka "abort" the simulation) and return the appropriate >>>>>>>>>>>>>> halt status for input <P><I>. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Nothing remarkable so far! Clearly a tight-loop in P /can/ be detected >>>>>>>>>>>>>> in this fashion, so /some/ <P><I> inputs /can/ be correctly determined >>>>>>>>>>>>>> like this. The PO claim however is that the specific input <H^><H^> is >>>>>>>>>>>>>> correctly decided by his H. In C terms those correspond to H(D,D) >>>>>>>>>>>>>> correctly returning the halt status of computation D(D). [PO would >>>>>>>>>>>>>> probably dispute this, because he doesn't properly understand halting >>>>>>>>>>>>>> or the HP generally, or in fact pretty much /any abstract concept/ ] >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 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> >>>>>>>>>>>>> >>>>>>>>>>>>> I have started working on what seem to be some computability issues >>>>>>>>>>>>> that you pointed out with my HH. I found that they are isolated to >>>>>>>>>>>>> one single element of HH. Essentially the details of how the master >>>>>>>>>>>>> UTM directly executed HH passes a portion of its tape to its slaves. >>>>>>>>>>>>> >>>>>>>>>>>>> Nothing else seems to have any computability issues by the measure >>>>>>>>>>>>> that I am using. >>>>>>>>>>>>> >>>>>>>>>>>>> Message-ID: <rLmcnQQ3-N_tvH_4nZ2dnZfqnPGdnZ2d@brightview.co.uk> >>>>>>>>>>>>> On 3/1/2024 12:41 PM, Mike Terry wrote: >>>>>>>>>>>>> > >>>>>>>>>>>>> > Obviously a simulator has access to the internal state >>>>>>>>>>>>> > (tape contents etc.) of the simulated machine. No problem there. >>>>>>>>>>>>> >>>>>>>>>>>>> Because of your above comment it seems that correcting this >>>>>>>>>>>>> tiny computability issue with HH is my best path forward. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> You have given the following a blatantly false review when I >>>>>>>>>>>>> said the same thing another way: >>>>>>>>>>>> >>>>>>>>>>>> I have no idea what you're talking about. I did not write any of what >>>>>>>>>>>> follows below. >>>>>>>>>>>> >>>>>>>>>>>> Also I don't believe I said anything "blatantly false". You're >>>>>>>>>>>> incapable of judging what other people say or are thinking - you're >>>>>>>>>>>> often telling people that they'er lying to you and denying >>>>>>>>>>>> "previously verified facts" etc. but its all rubbish - you're in no >>>>>>>>>>>> position to make such judgements. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Mike. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> You said that the execution trace that I proved is correct is >>>>>>>>>>> incorrect because you didn't like the way that HH was written. >>>>>>>>>>> You said this without looking at my proof as you are doing >>>>>>>>>>> here again. >>>>>>>>>> >>>>>>>>>> An execution trace that is produced by a program that is incorrect >>>>>>>>>> /proves/ nothing whatsoever. I don't need to look at your proof, as I >>>>>>>>>> was commenting on the value of your program output AS PROOF. >>>>>>>>>> >>>>>>>>> >>>>>>>>> I provided the execution trace that HH derives >>>>>>>>> *AND THE X86 SOURCE-CODE OF DD THAT PROVES THIS TRACE IS CORRECT* >>>>>>>>> *AND THE X86 SOURCE-CODE OF DD THAT PROVES THIS TRACE IS CORRECT* >>>>>>>>> *AND THE X86 SOURCE-CODE OF DD THAT PROVES THIS TRACE IS CORRECT* >>>>>>>> >>>>>>>> Then why did the trace not follow the call to H? >>>>>>>> >>>>>>> >>>>>>> HH(DD,DD) the trace does follow the call to HH(DD,DD) >>>>>>> and fully simulates itself simulating DD. >>>>>> >>>>>> So, where are the instuctions of HH shown? >>>>>> >>>>>> I guess you are just a LIAR. >>>>>> >>>>> >>>>> It might be good for you to quit calling me a liar, everyone here >>>>> knows that I am not a liar. >>>> >>>> Most people here don't care whether you are a liar or a fool. >>>> >>> >>> Richard understands that: >>> >>> Revelations 21:8 (KJV) >>> ...and all liars, shall have their part in the lake which >>> burneth with fire and brimstone: which is the second death. >>> >>> If Richard is calling me a liar when he knows that I believe >>> what I say he might be condemned to Hell, I don't want that. >> >> Discussion of that kind of things are off-topic in comp.theory. >> Perhaps you should ask the nearest priest. >> > > Alternatively it could be a defamation case. About that possibility you should ask a lawyer. Anyway, off topic in comp.theory. -- Mikko
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-06 10:32 -0500 |
| Subject | Re: Why does Olcott care about simulation, anyway? --- Mikes Review |
| Message-ID | <v3skr7$1iedv$2@dont-email.me> |
| In reply to | #106410 |
On 6/6/2024 10:18 AM, Mikko wrote: > On 2024-06-06 13:13:42 +0000, olcott said: > >> On 6/6/2024 3:25 AM, Mikko wrote: >>> On 2024-06-05 13:08:19 +0000, olcott said: >>> >>>> On 6/5/2024 2:08 AM, Mikko wrote: >>>>> On 2024-06-04 17:12:49 +0000, olcott said: >>>>> >>>>>> On 6/3/2024 9:49 PM, Richard Damon wrote: >>>>>>> On 6/3/24 10:18 PM, olcott wrote: >>>>>>>> On 6/3/2024 8:59 PM, Richard Damon wrote: >>>>>>>>> On 6/3/24 9:46 PM, olcott wrote: >>>>>>>>>> On 6/3/2024 8:38 PM, Mike Terry wrote: >>>>>>>>>>> On 03/06/2024 18:54, olcott wrote: >>>>>>>>>>>> On 6/3/2024 11:25 AM, Mike Terry wrote: >>>>>>>>>>>>> On 03/06/2024 04:50, olcott wrote: >>>>>>>>>>>>>> On 6/2/2024 10:28 PM, Mike Terry wrote: >>>>>>>>>>>>>>> On 03/06/2024 01:16, immibis wrote: >>>>>>>>>>>>>>>> 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. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Background: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> PO claims to have refuted the common HP proof, e.g. as >>>>>>>>>>>>>>> covered in the Linz book "An Introduction to Formal >>>>>>>>>>>>>>> Languages and Automata". PO occasionally posts a link to >>>>>>>>>>>>>>> a PDF containing an extract of the 5 or so pages of the >>>>>>>>>>>>>>> book containing the proof, but I expect you have access >>>>>>>>>>>>>>> to this or equivalent. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> In a nutshell, the proof goes: >>>>>>>>>>>>>>> - Suppose H is a TM Halt decider that decides for any >>>>>>>>>>>>>>> input <P><I> whether >>>>>>>>>>>>>>> TM P run with input I on its input tape halts. >>>>>>>>>>>>>>> [<P> is the string representation of the actual TM P, >>>>>>>>>>>>>>> and >>>>>>>>>>>>>>> <I> is the string representation of input tape I] >>>>>>>>>>>>>>> - Construct from H a new TM H^ using the mechanical >>>>>>>>>>>>>>> process described in the proof. >>>>>>>>>>>>>>> If H exists, then its corresponding H^ also exists. >>>>>>>>>>>>>>> - Show that the construction of H^ ensures that: >>>>>>>>>>>>>>> - if H decides input <H^><H^> (representing H^ >>>>>>>>>>>>>>> running with input <H^>) halts, >>>>>>>>>>>>>>> then that implies that H^ running with input <H^> >>>>>>>>>>>>>>> never halts >>>>>>>>>>>>>>> - if H decides input <H^><H^> never halts, >>>>>>>>>>>>>>> then that implies H^ running with input <H^> halts >>>>>>>>>>>>>>> I.e. either way, H decides the specific input >>>>>>>>>>>>>>> <H^><H^> incorrectly, contradicting >>>>>>>>>>>>>>> the initial assumption that H is a halt decider. >>>>>>>>>>>>>>> - So no halt decider exists. (Every proposed halt >>>>>>>>>>>>>>> decider decides at least one input case >>>>>>>>>>>>>>> incorrectly, viz input <H^><H^>.) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> PO basically claimed he had a fully coded TM H, which >>>>>>>>>>>>>>> CORRECTLY decides its "nemesis" input <H^><H^>, >>>>>>>>>>>>>>> contradicting the logic of the Linz proof [without >>>>>>>>>>>>>>> pointing out any actual mistake in the Linz proof]. >>>>>>>>>>>>>>> Given most people here understand the Linz proof well >>>>>>>>>>>>>>> enough to see it is basically sound, people were sceptical! >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> It turned out PO was lying about the fully coded TM, and >>>>>>>>>>>>>>> in fact what he actually had was the idea behind a C >>>>>>>>>>>>>>> program which would "prove" his idea. A couple of >>>>>>>>>>>>>>> years(?) later he actually completed his C program and >>>>>>>>>>>>>>> his x86utm.exe which would simulate the x86 code of his H >>>>>>>>>>>>>>> and H^ to "prove" his claim. His equivalent of Linz H is >>>>>>>>>>>>>>> his C function H or HH, and his equivalent of Linz H^ is >>>>>>>>>>>>>>> his D or DD respectively. (They run under x86utm.exe and >>>>>>>>>>>>>>> are not Windows/Unix executables.) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> H/HH use PARTIAL simulation of their input to decide >>>>>>>>>>>>>>> halting/non-halting, returning >>>>>>>>>>>>>>> 0 or 1 to communicate their decision. As you correctly >>>>>>>>>>>>>>> point out, to the HP proof simulation is quite >>>>>>>>>>>>>>> irrelevant, being just one kind of data manipulation that >>>>>>>>>>>>>>> H may perform on its input string <P><I> before it >>>>>>>>>>>>>>> decides the halting status. So the Linz HP proof covers >>>>>>>>>>>>>>> such H, no problem. >>>>>>>>>>>>>>> [I put PARTIAL in caps, just because there seems to be >>>>>>>>>>>>>>> some confusion in recent threads as to what PO means by >>>>>>>>>>>>>>> "simulation". He doesn't say it explicitly, despite >>>>>>>>>>>>>>> suggestions to this effect, but he always means what >>>>>>>>>>>>>>> might be called /partial/ simulation.] >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> PO believes that by (partially) simulating the >>>>>>>>>>>>>>> computation corresponding to the input <P><I> [i.e. >>>>>>>>>>>>>>> calculating the successive x86 instruction steps of the >>>>>>>>>>>>>>> computation P(I)] and monitoring the progress of virtual >>>>>>>>>>>>>>> x86 state changes (like instruction address and op-code >>>>>>>>>>>>>>> and so on) H could spot some pattern that reveals whether >>>>>>>>>>>>>>> computation P(I) halts or not. At this point in the >>>>>>>>>>>>>>> partial simulation, his H would stop simulating (aka >>>>>>>>>>>>>>> "abort" the simulation) and return the appropriate halt >>>>>>>>>>>>>>> status for input <P><I>. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Nothing remarkable so far! Clearly a tight-loop in P >>>>>>>>>>>>>>> /can/ be detected in this fashion, so /some/ <P><I> >>>>>>>>>>>>>>> inputs /can/ be correctly determined like this. The PO >>>>>>>>>>>>>>> claim however is that the specific input <H^><H^> is >>>>>>>>>>>>>>> correctly decided by his H. In C terms those correspond >>>>>>>>>>>>>>> to H(D,D) correctly returning the halt status of >>>>>>>>>>>>>>> computation D(D). [PO would probably dispute this, >>>>>>>>>>>>>>> because he doesn't properly understand halting or the HP >>>>>>>>>>>>>>> generally, or in fact pretty much /any abstract concept/ ] >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> 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> >>>>>>>>>>>>>> >>>>>>>>>>>>>> I have started working on what seem to be some >>>>>>>>>>>>>> computability issues >>>>>>>>>>>>>> that you pointed out with my HH. I found that they are >>>>>>>>>>>>>> isolated to >>>>>>>>>>>>>> one single element of HH. Essentially the details of how >>>>>>>>>>>>>> the master >>>>>>>>>>>>>> UTM directly executed HH passes a portion of its tape to >>>>>>>>>>>>>> its slaves. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Nothing else seems to have any computability issues by the >>>>>>>>>>>>>> measure >>>>>>>>>>>>>> that I am using. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Message-ID: >>>>>>>>>>>>>> <rLmcnQQ3-N_tvH_4nZ2dnZfqnPGdnZ2d@brightview.co.uk> >>>>>>>>>>>>>> On 3/1/2024 12:41 PM, Mike Terry wrote: >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > Obviously a simulator has access to the internal state >>>>>>>>>>>>>> > (tape contents etc.) of the simulated machine. No >>>>>>>>>>>>>> problem there. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Because of your above comment it seems that correcting this >>>>>>>>>>>>>> tiny computability issue with HH is my best path forward. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> You have given the following a blatantly false review when I >>>>>>>>>>>>>> said the same thing another way: >>>>>>>>>>>>> >>>>>>>>>>>>> I have no idea what you're talking about. I did not write >>>>>>>>>>>>> any of what follows below. >>>>>>>>>>>>> >>>>>>>>>>>>> Also I don't believe I said anything "blatantly false". >>>>>>>>>>>>> You're incapable of judging what other people say or are >>>>>>>>>>>>> thinking - you're often telling people that they'er lying >>>>>>>>>>>>> to you and denying >>>>>>>>>>>>> "previously verified facts" etc. but its all rubbish - >>>>>>>>>>>>> you're in no position to make such judgements. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Mike. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> You said that the execution trace that I proved is correct is >>>>>>>>>>>> incorrect because you didn't like the way that HH was written. >>>>>>>>>>>> You said this without looking at my proof as you are doing >>>>>>>>>>>> here again. >>>>>>>>>>> >>>>>>>>>>> An execution trace that is produced by a program that is >>>>>>>>>>> incorrect /proves/ nothing whatsoever. I don't need to look >>>>>>>>>>> at your proof, as I was commenting on the value of your >>>>>>>>>>> program output AS PROOF. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I provided the execution trace that HH derives >>>>>>>>>> *AND THE X86 SOURCE-CODE OF DD THAT PROVES THIS TRACE IS CORRECT* >>>>>>>>>> *AND THE X86 SOURCE-CODE OF DD THAT PROVES THIS TRACE IS CORRECT* >>>>>>>>>> *AND THE X86 SOURCE-CODE OF DD THAT PROVES THIS TRACE IS CORRECT* >>>>>>>>> >>>>>>>>> Then why did the trace not follow the call to H? >>>>>>>>> >>>>>>>> >>>>>>>> HH(DD,DD) the trace does follow the call to HH(DD,DD) >>>>>>>> and fully simulates itself simulating DD. >>>>>>> >>>>>>> So, where are the instuctions of HH shown? >>>>>>> >>>>>>> I guess you are just a LIAR. >>>>>>> >>>>>> >>>>>> It might be good for you to quit calling me a liar, everyone here >>>>>> knows that I am not a liar. >>>>> >>>>> Most people here don't care whether you are a liar or a fool. >>>>> >>>> >>>> Richard understands that: >>>> >>>> Revelations 21:8 (KJV) >>>> ...and all liars, shall have their part in the lake which >>>> burneth with fire and brimstone: which is the second death. >>>> >>>> If Richard is calling me a liar when he knows that I believe >>>> what I say he might be condemned to Hell, I don't want that. >>> >>> Discussion of that kind of things are off-topic in comp.theory. >>> Perhaps you should ask the nearest priest. >>> >> >> Alternatively it could be a defamation case. > > About that possibility you should ask a lawyer. > Anyway, off topic in comp.theory. > I have a close friend that is a lawyer. it <is> a defamation case. -- Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-06 22:08 -0400 |
| Subject | Re: Why does Olcott care about simulation, anyway? --- Mikes Review |
| Message-ID | <v3tq28$388rj$1@i2pn2.org> |
| In reply to | #106413 |
On 6/6/24 11:32 AM, olcott wrote: > On 6/6/2024 10:18 AM, Mikko wrote: >> On 2024-06-06 13:13:42 +0000, olcott said: >> >>> On 6/6/2024 3:25 AM, Mikko wrote: >>>> On 2024-06-05 13:08:19 +0000, olcott said: >>>> >>>>> On 6/5/2024 2:08 AM, Mikko wrote: >>>>>> On 2024-06-04 17:12:49 +0000, olcott said: >>>>>> >>>>>>> On 6/3/2024 9:49 PM, Richard Damon wrote: >>>>>>>> On 6/3/24 10:18 PM, olcott wrote: >>>>>>>>> On 6/3/2024 8:59 PM, Richard Damon wrote: >>>>>>>>>> On 6/3/24 9:46 PM, olcott wrote: >>>>>>>>>>> On 6/3/2024 8:38 PM, Mike Terry wrote: >>>>>>>>>>>> On 03/06/2024 18:54, olcott wrote: >>>>>>>>>>>>> On 6/3/2024 11:25 AM, Mike Terry wrote: >>>>>>>>>>>>>> On 03/06/2024 04:50, olcott wrote: >>>>>>>>>>>>>>> On 6/2/2024 10:28 PM, Mike Terry wrote: >>>>>>>>>>>>>>>> On 03/06/2024 01:16, immibis wrote: >>>>>>>>>>>>>>>>> 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. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Background: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> PO claims to have refuted the common HP proof, e.g. as >>>>>>>>>>>>>>>> covered in the Linz book "An Introduction to Formal >>>>>>>>>>>>>>>> Languages and Automata". PO occasionally posts a link to >>>>>>>>>>>>>>>> a PDF containing an extract of the 5 or so pages of the >>>>>>>>>>>>>>>> book containing the proof, but I expect you have access >>>>>>>>>>>>>>>> to this or equivalent. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> In a nutshell, the proof goes: >>>>>>>>>>>>>>>> - Suppose H is a TM Halt decider that decides for any >>>>>>>>>>>>>>>> input <P><I> whether >>>>>>>>>>>>>>>> TM P run with input I on its input tape halts. >>>>>>>>>>>>>>>> [<P> is the string representation of the actual TM >>>>>>>>>>>>>>>> P, and >>>>>>>>>>>>>>>> <I> is the string representation of input tape I] >>>>>>>>>>>>>>>> - Construct from H a new TM H^ using the mechanical >>>>>>>>>>>>>>>> process described in the proof. >>>>>>>>>>>>>>>> If H exists, then its corresponding H^ also exists. >>>>>>>>>>>>>>>> - Show that the construction of H^ ensures that: >>>>>>>>>>>>>>>> - if H decides input <H^><H^> (representing H^ >>>>>>>>>>>>>>>> running with input <H^>) halts, >>>>>>>>>>>>>>>> then that implies that H^ running with input <H^> >>>>>>>>>>>>>>>> never halts >>>>>>>>>>>>>>>> - if H decides input <H^><H^> never halts, >>>>>>>>>>>>>>>> then that implies H^ running with input <H^> halts >>>>>>>>>>>>>>>> I.e. either way, H decides the specific input >>>>>>>>>>>>>>>> <H^><H^> incorrectly, contradicting >>>>>>>>>>>>>>>> the initial assumption that H is a halt decider. >>>>>>>>>>>>>>>> - So no halt decider exists. (Every proposed halt >>>>>>>>>>>>>>>> decider decides at least one input case >>>>>>>>>>>>>>>> incorrectly, viz input <H^><H^>.) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> PO basically claimed he had a fully coded TM H, which >>>>>>>>>>>>>>>> CORRECTLY decides its "nemesis" input <H^><H^>, >>>>>>>>>>>>>>>> contradicting the logic of the Linz proof [without >>>>>>>>>>>>>>>> pointing out any actual mistake in the Linz proof]. >>>>>>>>>>>>>>>> Given most people here understand the Linz proof well >>>>>>>>>>>>>>>> enough to see it is basically sound, people were sceptical! >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> It turned out PO was lying about the fully coded TM, and >>>>>>>>>>>>>>>> in fact what he actually had was the idea behind a C >>>>>>>>>>>>>>>> program which would "prove" his idea. A couple of >>>>>>>>>>>>>>>> years(?) later he actually completed his C program and >>>>>>>>>>>>>>>> his x86utm.exe which would simulate the x86 code of his >>>>>>>>>>>>>>>> H and H^ to "prove" his claim. His equivalent of Linz H >>>>>>>>>>>>>>>> is his C function H or HH, and his equivalent of Linz H^ >>>>>>>>>>>>>>>> is his D or DD respectively. (They run under x86utm.exe >>>>>>>>>>>>>>>> and are not Windows/Unix executables.) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> H/HH use PARTIAL simulation of their input to decide >>>>>>>>>>>>>>>> halting/non-halting, returning >>>>>>>>>>>>>>>> 0 or 1 to communicate their decision. As you correctly >>>>>>>>>>>>>>>> point out, to the HP proof simulation is quite >>>>>>>>>>>>>>>> irrelevant, being just one kind of data manipulation >>>>>>>>>>>>>>>> that H may perform on its input string <P><I> before it >>>>>>>>>>>>>>>> decides the halting status. So the Linz HP proof covers >>>>>>>>>>>>>>>> such H, no problem. >>>>>>>>>>>>>>>> [I put PARTIAL in caps, just because there seems to be >>>>>>>>>>>>>>>> some confusion in recent threads as to what PO means by >>>>>>>>>>>>>>>> "simulation". He doesn't say it explicitly, despite >>>>>>>>>>>>>>>> suggestions to this effect, but he always means what >>>>>>>>>>>>>>>> might be called /partial/ simulation.] >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> PO believes that by (partially) simulating the >>>>>>>>>>>>>>>> computation corresponding to the input <P><I> [i.e. >>>>>>>>>>>>>>>> calculating the successive x86 instruction steps of the >>>>>>>>>>>>>>>> computation P(I)] and monitoring the progress of virtual >>>>>>>>>>>>>>>> x86 state changes (like instruction address and op-code >>>>>>>>>>>>>>>> and so on) H could spot some pattern that reveals >>>>>>>>>>>>>>>> whether computation P(I) halts or not. At this point in >>>>>>>>>>>>>>>> the partial simulation, his H would stop simulating (aka >>>>>>>>>>>>>>>> "abort" the simulation) and return the appropriate halt >>>>>>>>>>>>>>>> status for input <P><I>. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Nothing remarkable so far! Clearly a tight-loop in P >>>>>>>>>>>>>>>> /can/ be detected in this fashion, so /some/ <P><I> >>>>>>>>>>>>>>>> inputs /can/ be correctly determined like this. The PO >>>>>>>>>>>>>>>> claim however is that the specific input <H^><H^> is >>>>>>>>>>>>>>>> correctly decided by his H. In C terms those correspond >>>>>>>>>>>>>>>> to H(D,D) correctly returning the halt status of >>>>>>>>>>>>>>>> computation D(D). [PO would probably dispute this, >>>>>>>>>>>>>>>> because he doesn't properly understand halting or the HP >>>>>>>>>>>>>>>> generally, or in fact pretty much /any abstract concept/ ] >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 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> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I have started working on what seem to be some >>>>>>>>>>>>>>> computability issues >>>>>>>>>>>>>>> that you pointed out with my HH. I found that they are >>>>>>>>>>>>>>> isolated to >>>>>>>>>>>>>>> one single element of HH. Essentially the details of how >>>>>>>>>>>>>>> the master >>>>>>>>>>>>>>> UTM directly executed HH passes a portion of its tape to >>>>>>>>>>>>>>> its slaves. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Nothing else seems to have any computability issues by >>>>>>>>>>>>>>> the measure >>>>>>>>>>>>>>> that I am using. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Message-ID: >>>>>>>>>>>>>>> <rLmcnQQ3-N_tvH_4nZ2dnZfqnPGdnZ2d@brightview.co.uk> >>>>>>>>>>>>>>> On 3/1/2024 12:41 PM, Mike Terry wrote: >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > Obviously a simulator has access to the internal state >>>>>>>>>>>>>>> > (tape contents etc.) of the simulated machine. No >>>>>>>>>>>>>>> problem there. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Because of your above comment it seems that correcting this >>>>>>>>>>>>>>> tiny computability issue with HH is my best path forward. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> You have given the following a blatantly false review when I >>>>>>>>>>>>>>> said the same thing another way: >>>>>>>>>>>>>> >>>>>>>>>>>>>> I have no idea what you're talking about. I did not write >>>>>>>>>>>>>> any of what follows below. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Also I don't believe I said anything "blatantly false". >>>>>>>>>>>>>> You're incapable of judging what other people say or are >>>>>>>>>>>>>> thinking - you're often telling people that they'er lying >>>>>>>>>>>>>> to you and denying >>>>>>>>>>>>>> "previously verified facts" etc. but its all rubbish - >>>>>>>>>>>>>> you're in no position to make such judgements. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Mike. >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> You said that the execution trace that I proved is correct is >>>>>>>>>>>>> incorrect because you didn't like the way that HH was written. >>>>>>>>>>>>> You said this without looking at my proof as you are doing >>>>>>>>>>>>> here again. >>>>>>>>>>>> >>>>>>>>>>>> An execution trace that is produced by a program that is >>>>>>>>>>>> incorrect /proves/ nothing whatsoever. I don't need to look >>>>>>>>>>>> at your proof, as I was commenting on the value of your >>>>>>>>>>>> program output AS PROOF. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I provided the execution trace that HH derives >>>>>>>>>>> *AND THE X86 SOURCE-CODE OF DD THAT PROVES THIS TRACE IS >>>>>>>>>>> CORRECT* >>>>>>>>>>> *AND THE X86 SOURCE-CODE OF DD THAT PROVES THIS TRACE IS >>>>>>>>>>> CORRECT* >>>>>>>>>>> *AND THE X86 SOURCE-CODE OF DD THAT PROVES THIS TRACE IS >>>>>>>>>>> CORRECT* >>>>>>>>>> >>>>>>>>>> Then why did the trace not follow the call to H? >>>>>>>>>> >>>>>>>>> >>>>>>>>> HH(DD,DD) the trace does follow the call to HH(DD,DD) >>>>>>>>> and fully simulates itself simulating DD. >>>>>>>> >>>>>>>> So, where are the instuctions of HH shown? >>>>>>>> >>>>>>>> I guess you are just a LIAR. >>>>>>>> >>>>>>> >>>>>>> It might be good for you to quit calling me a liar, everyone here >>>>>>> knows that I am not a liar. >>>>>> >>>>>> Most people here don't care whether you are a liar or a fool. >>>>>> >>>>> >>>>> Richard understands that: >>>>> >>>>> Revelations 21:8 (KJV) >>>>> ...and all liars, shall have their part in the lake which >>>>> burneth with fire and brimstone: which is the second death. >>>>> >>>>> If Richard is calling me a liar when he knows that I believe >>>>> what I say he might be condemned to Hell, I don't want that. >>>> >>>> Discussion of that kind of things are off-topic in comp.theory. >>>> Perhaps you should ask the nearest priest. >>>> >>> >>> Alternatively it could be a defamation case. >> >> About that possibility you should ask a lawyer. >> Anyway, off topic in comp.theory. >> > > I have a close friend that is a lawyer. > it <is> a defamation case. > You willing to take the stand to present your case to a jury? And do you think your logic would stand up to the counter suit?
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-06 07:10 -0400 |
| Subject | Re: Why does Olcott care about simulation, anyway? --- Mikes Review |
| Message-ID | <v3s5g3$36git$1@i2pn2.org> |
| In reply to | #106309 |
On 6/5/24 9:08 AM, olcott wrote: > On 6/5/2024 2:08 AM, Mikko wrote: >> On 2024-06-04 17:12:49 +0000, olcott said: >> >>> On 6/3/2024 9:49 PM, Richard Damon wrote: >>>> On 6/3/24 10:18 PM, olcott wrote: >>>>> On 6/3/2024 8:59 PM, Richard Damon wrote: >>>>>> On 6/3/24 9:46 PM, olcott wrote: >>>>>>> On 6/3/2024 8:38 PM, Mike Terry wrote: >>>>>>>> On 03/06/2024 18:54, olcott wrote: >>>>>>>>> On 6/3/2024 11:25 AM, Mike Terry wrote: >>>>>>>>>> On 03/06/2024 04:50, olcott wrote: >>>>>>>>>>> On 6/2/2024 10:28 PM, Mike Terry wrote: >>>>>>>>>>>> On 03/06/2024 01:16, immibis wrote: >>>>>>>>>>>>> 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. >>>>>>>>>>>> >>>>>>>>>>>> Background: >>>>>>>>>>>> >>>>>>>>>>>> PO claims to have refuted the common HP proof, e.g. as >>>>>>>>>>>> covered in the Linz book "An Introduction to Formal >>>>>>>>>>>> Languages and Automata". PO occasionally posts a link to a >>>>>>>>>>>> PDF containing an extract of the 5 or so pages of the book >>>>>>>>>>>> containing the proof, but I expect you have access to this >>>>>>>>>>>> or equivalent. >>>>>>>>>>>> >>>>>>>>>>>> In a nutshell, the proof goes: >>>>>>>>>>>> - Suppose H is a TM Halt decider that decides for any input >>>>>>>>>>>> <P><I> whether >>>>>>>>>>>> TM P run with input I on its input tape halts. >>>>>>>>>>>> [<P> is the string representation of the actual TM P, and >>>>>>>>>>>> <I> is the string representation of input tape I] >>>>>>>>>>>> - Construct from H a new TM H^ using the mechanical process >>>>>>>>>>>> described in the proof. >>>>>>>>>>>> If H exists, then its corresponding H^ also exists. >>>>>>>>>>>> - Show that the construction of H^ ensures that: >>>>>>>>>>>> - if H decides input <H^><H^> (representing H^ running >>>>>>>>>>>> with input <H^>) halts, >>>>>>>>>>>> then that implies that H^ running with input <H^> >>>>>>>>>>>> never halts >>>>>>>>>>>> - if H decides input <H^><H^> never halts, >>>>>>>>>>>> then that implies H^ running with input <H^> halts >>>>>>>>>>>> I.e. either way, H decides the specific input <H^><H^> >>>>>>>>>>>> incorrectly, contradicting >>>>>>>>>>>> the initial assumption that H is a halt decider. >>>>>>>>>>>> - So no halt decider exists. (Every proposed halt decider >>>>>>>>>>>> decides at least one input case >>>>>>>>>>>> incorrectly, viz input <H^><H^>.) >>>>>>>>>>>> >>>>>>>>>>>> PO basically claimed he had a fully coded TM H, which >>>>>>>>>>>> CORRECTLY decides its "nemesis" input <H^><H^>, >>>>>>>>>>>> contradicting the logic of the Linz proof [without pointing >>>>>>>>>>>> out any actual mistake in the Linz proof]. Given most >>>>>>>>>>>> people here understand the Linz proof well enough to see it >>>>>>>>>>>> is basically sound, people were sceptical! >>>>>>>>>>>> >>>>>>>>>>>> It turned out PO was lying about the fully coded TM, and in >>>>>>>>>>>> fact what he actually had was the idea behind a C program >>>>>>>>>>>> which would "prove" his idea. A couple of years(?) later he >>>>>>>>>>>> actually completed his C program and his x86utm.exe which >>>>>>>>>>>> would simulate the x86 code of his H and H^ to "prove" his >>>>>>>>>>>> claim. His equivalent of Linz H is his C function H or HH, >>>>>>>>>>>> and his equivalent of Linz H^ is his D or DD respectively. >>>>>>>>>>>> (They run under x86utm.exe and are not Windows/Unix >>>>>>>>>>>> executables.) >>>>>>>>>>>> >>>>>>>>>>>> H/HH use PARTIAL simulation of their input to decide >>>>>>>>>>>> halting/non-halting, returning >>>>>>>>>>>> 0 or 1 to communicate their decision. As you correctly >>>>>>>>>>>> point out, to the HP proof simulation is quite irrelevant, >>>>>>>>>>>> being just one kind of data manipulation that H may perform >>>>>>>>>>>> on its input string <P><I> before it decides the halting >>>>>>>>>>>> status. So the Linz HP proof covers such H, no problem. >>>>>>>>>>>> [I put PARTIAL in caps, just because there seems to be some >>>>>>>>>>>> confusion in recent threads as to what PO means by >>>>>>>>>>>> "simulation". He doesn't say it explicitly, despite >>>>>>>>>>>> suggestions to this effect, but he always means what might >>>>>>>>>>>> be called /partial/ simulation.] >>>>>>>>>>>> >>>>>>>>>>>> PO believes that by (partially) simulating the computation >>>>>>>>>>>> corresponding to the input <P><I> [i.e. calculating the >>>>>>>>>>>> successive x86 instruction steps of the computation P(I)] >>>>>>>>>>>> and monitoring the progress of virtual x86 state changes >>>>>>>>>>>> (like instruction address and op-code and so on) H could >>>>>>>>>>>> spot some pattern that reveals whether computation P(I) >>>>>>>>>>>> halts or not. At this point in the partial simulation, his H >>>>>>>>>>>> would stop simulating (aka "abort" the simulation) and >>>>>>>>>>>> return the appropriate halt status for input <P><I>. >>>>>>>>>>>> >>>>>>>>>>>> Nothing remarkable so far! Clearly a tight-loop in P /can/ >>>>>>>>>>>> be detected in this fashion, so /some/ <P><I> inputs /can/ >>>>>>>>>>>> be correctly determined like this. The PO claim however is >>>>>>>>>>>> that the specific input <H^><H^> is correctly decided by his >>>>>>>>>>>> H. In C terms those correspond to H(D,D) correctly returning >>>>>>>>>>>> the halt status of computation D(D). [PO would probably >>>>>>>>>>>> dispute this, because he doesn't properly understand halting >>>>>>>>>>>> or the HP generally, or in fact pretty much /any abstract >>>>>>>>>>>> concept/ ] >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 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> >>>>>>>>>>> >>>>>>>>>>> I have started working on what seem to be some computability >>>>>>>>>>> issues >>>>>>>>>>> that you pointed out with my HH. I found that they are >>>>>>>>>>> isolated to >>>>>>>>>>> one single element of HH. Essentially the details of how the >>>>>>>>>>> master >>>>>>>>>>> UTM directly executed HH passes a portion of its tape to its >>>>>>>>>>> slaves. >>>>>>>>>>> >>>>>>>>>>> Nothing else seems to have any computability issues by the >>>>>>>>>>> measure >>>>>>>>>>> that I am using. >>>>>>>>>>> >>>>>>>>>>> Message-ID: <rLmcnQQ3-N_tvH_4nZ2dnZfqnPGdnZ2d@brightview.co.uk> >>>>>>>>>>> On 3/1/2024 12:41 PM, Mike Terry wrote: >>>>>>>>>>> > >>>>>>>>>>> > Obviously a simulator has access to the internal state >>>>>>>>>>> > (tape contents etc.) of the simulated machine. No problem >>>>>>>>>>> there. >>>>>>>>>>> >>>>>>>>>>> Because of your above comment it seems that correcting this >>>>>>>>>>> tiny computability issue with HH is my best path forward. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> You have given the following a blatantly false review when I >>>>>>>>>>> said the same thing another way: >>>>>>>>>> >>>>>>>>>> I have no idea what you're talking about. I did not write any >>>>>>>>>> of what follows below. >>>>>>>>>> >>>>>>>>>> Also I don't believe I said anything "blatantly false". >>>>>>>>>> You're incapable of judging what other people say or are >>>>>>>>>> thinking - you're often telling people that they'er lying to >>>>>>>>>> you and denying >>>>>>>>>> "previously verified facts" etc. but its all rubbish - you're >>>>>>>>>> in no position to make such judgements. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Mike. >>>>>>>>>> >>>>>>>>> >>>>>>>>> You said that the execution trace that I proved is correct is >>>>>>>>> incorrect because you didn't like the way that HH was written. >>>>>>>>> You said this without looking at my proof as you are doing >>>>>>>>> here again. >>>>>>>> >>>>>>>> An execution trace that is produced by a program that is >>>>>>>> incorrect /proves/ nothing whatsoever. I don't need to look at >>>>>>>> your proof, as I was commenting on the value of your program >>>>>>>> output AS PROOF. >>>>>>>> >>>>>>> >>>>>>> I provided the execution trace that HH derives >>>>>>> *AND THE X86 SOURCE-CODE OF DD THAT PROVES THIS TRACE IS CORRECT* >>>>>>> *AND THE X86 SOURCE-CODE OF DD THAT PROVES THIS TRACE IS CORRECT* >>>>>>> *AND THE X86 SOURCE-CODE OF DD THAT PROVES THIS TRACE IS CORRECT* >>>>>> >>>>>> Then why did the trace not follow the call to H? >>>>>> >>>>> >>>>> HH(DD,DD) the trace does follow the call to HH(DD,DD) >>>>> and fully simulates itself simulating DD. >>>> >>>> So, where are the instuctions of HH shown? >>>> >>>> I guess you are just a LIAR. >>>> >>> >>> It might be good for you to quit calling me a liar, everyone here >>> knows that I am not a liar. >> >> Most people here don't care whether you are a liar or a fool. >> > > Richard understands that: > > Revelations 21:8 (KJV) > ...and all liars, shall have their part in the lake which > burneth with fire and brimstone: which is the second death. > > If Richard is calling me a liar when he knows that I believe > what I say he might be condemned to Hell, I don't want that. > Which just shows you don't know the full definition of a liar, particularly when it has the pathological modifier. Truth is an absolute. Lies are statements that are not True, even if the speaker thinks he belives in them. This is a commom problem for you, you don't seem to care if you don't have the right definition for the word as it was being used, which means that there are many things you just don't understand, because you have attached wrong meanings to it.
[toc] | [prev] | [next] | [standalone]
| From | Mike Terry <news.dead.person.stones@darjeeling.plus.com> |
|---|---|
| Date | 2024-06-04 03:57 +0100 |
| Subject | Re: Why does Olcott care about simulation, anyway? --- Mikes Review |
| Message-ID | <7MadnQlevYc8H8P7nZ2dnZfqnPSdnZ2d@brightview.co.uk> |
| In reply to | #106211 |
On 04/06/2024 03:18, olcott wrote: > On 6/3/2024 8:59 PM, Richard Damon wrote: >> On 6/3/24 9:46 PM, olcott wrote: >>> On 6/3/2024 8:38 PM, Mike Terry wrote: >>>> On 03/06/2024 18:54, olcott wrote: >>>>> On 6/3/2024 11:25 AM, Mike Terry wrote: >>>>>> On 03/06/2024 04:50, olcott wrote: >>>>>>> On 6/2/2024 10:28 PM, Mike Terry wrote: >>>>>>>> On 03/06/2024 01:16, immibis wrote: >>>>>>>>> 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. >>>>>>>> >>>>>>>> Background: >>>>>>>> >>>>>>>> PO claims to have refuted the common HP proof, e.g. as covered in the Linz book "An >>>>>>>> Introduction to Formal Languages and Automata". PO occasionally posts a link to a PDF >>>>>>>> containing an extract of the 5 or so pages of the book containing the proof, but I expect >>>>>>>> you have access to this or equivalent. >>>>>>>> >>>>>>>> In a nutshell, the proof goes: >>>>>>>> - Suppose H is a TM Halt decider that decides for any input <P><I> whether >>>>>>>> TM P run with input I on its input tape halts. >>>>>>>> [<P> is the string representation of the actual TM P, and >>>>>>>> <I> is the string representation of input tape I] >>>>>>>> - Construct from H a new TM H^ using the mechanical process described in the proof. >>>>>>>> If H exists, then its corresponding H^ also exists. >>>>>>>> - Show that the construction of H^ ensures that: >>>>>>>> - if H decides input <H^><H^> (representing H^ running with input <H^>) halts, >>>>>>>> then that implies that H^ running with input <H^> never halts >>>>>>>> - if H decides input <H^><H^> never halts, >>>>>>>> then that implies H^ running with input <H^> halts >>>>>>>> I.e. either way, H decides the specific input <H^><H^> incorrectly, contradicting >>>>>>>> the initial assumption that H is a halt decider. >>>>>>>> - So no halt decider exists. (Every proposed halt decider decides at least one input case >>>>>>>> incorrectly, viz input <H^><H^>.) >>>>>>>> >>>>>>>> PO basically claimed he had a fully coded TM H, which CORRECTLY decides its "nemesis" input >>>>>>>> <H^><H^>, contradicting the logic of the Linz proof [without pointing out any actual mistake >>>>>>>> in the Linz proof]. Given most people here understand the Linz proof well enough to see it >>>>>>>> is basically sound, people were sceptical! >>>>>>>> >>>>>>>> It turned out PO was lying about the fully coded TM, and in fact what he actually had was >>>>>>>> the idea behind a C program which would "prove" his idea. A couple of years(?) later he >>>>>>>> actually completed his C program and his x86utm.exe which would simulate the x86 code of his >>>>>>>> H and H^ to "prove" his claim. His equivalent of Linz H is his C function H or HH, and his >>>>>>>> equivalent of Linz H^ is his D or DD respectively. (They run under x86utm.exe and are not >>>>>>>> Windows/Unix executables.) >>>>>>>> >>>>>>>> H/HH use PARTIAL simulation of their input to decide halting/non-halting, returning >>>>>>>> 0 or 1 to communicate their decision. As you correctly point out, to the HP proof >>>>>>>> simulation is quite irrelevant, being just one kind of data manipulation that H may perform >>>>>>>> on its input string <P><I> before it decides the halting status. So the Linz HP proof >>>>>>>> covers such H, no problem. >>>>>>>> [I put PARTIAL in caps, just because there seems to be some confusion in recent threads as >>>>>>>> to what PO means by "simulation". He doesn't say it explicitly, despite suggestions to this >>>>>>>> effect, but he always means what might be called /partial/ simulation.] >>>>>>>> >>>>>>>> PO believes that by (partially) simulating the computation corresponding to the input <P><I> >>>>>>>> [i.e. calculating the successive x86 instruction steps of the computation P(I)] and >>>>>>>> monitoring the progress of virtual x86 state changes (like instruction address and op-code >>>>>>>> and so on) H could spot some pattern that reveals whether computation P(I) halts or not. At >>>>>>>> this point in the partial simulation, his H would stop simulating (aka "abort" the >>>>>>>> simulation) and return the appropriate halt status for input <P><I>. >>>>>>>> >>>>>>>> Nothing remarkable so far! Clearly a tight-loop in P /can/ be detected in this fashion, so >>>>>>>> /some/ <P><I> inputs /can/ be correctly determined like this. The PO claim however is that >>>>>>>> the specific input <H^><H^> is correctly decided by his H. In C terms those correspond to >>>>>>>> H(D,D) correctly returning the halt status of computation D(D). [PO would probably dispute >>>>>>>> this, because he doesn't properly understand halting or the HP generally, or in fact pretty >>>>>>>> much /any abstract concept/ ] >>>>>>>> >>>>>>> >>>>>>> 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> >>>>>>> >>>>>>> I have started working on what seem to be some computability issues >>>>>>> that you pointed out with my HH. I found that they are isolated to >>>>>>> one single element of HH. Essentially the details of how the master >>>>>>> UTM directly executed HH passes a portion of its tape to its slaves. >>>>>>> >>>>>>> Nothing else seems to have any computability issues by the measure >>>>>>> that I am using. >>>>>>> >>>>>>> Message-ID: <rLmcnQQ3-N_tvH_4nZ2dnZfqnPGdnZ2d@brightview.co.uk> >>>>>>> On 3/1/2024 12:41 PM, Mike Terry wrote: >>>>>>> > >>>>>>> > Obviously a simulator has access to the internal state >>>>>>> > (tape contents etc.) of the simulated machine. No problem there. >>>>>>> >>>>>>> Because of your above comment it seems that correcting this >>>>>>> tiny computability issue with HH is my best path forward. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> You have given the following a blatantly false review when I >>>>>>> said the same thing another way: >>>>>> >>>>>> I have no idea what you're talking about. I did not write any of what follows below. >>>>>> >>>>>> Also I don't believe I said anything "blatantly false". You're incapable of judging what >>>>>> other people say or are thinking - you're often telling people that they'er lying to you and >>>>>> denying >>>>>> "previously verified facts" etc. but its all rubbish - you're in no position to make such >>>>>> judgements. >>>>>> >>>>>> >>>>>> Mike. >>>>>> >>>>> >>>>> You said that the execution trace that I proved is correct is >>>>> incorrect because you didn't like the way that HH was written. >>>>> You said this without looking at my proof as you are doing >>>>> here again. >>>> >>>> An execution trace that is produced by a program that is incorrect /proves/ nothing whatsoever. >>>> I don't need to look at your proof, as I was commenting on the value of your program output AS >>>> PROOF. >>>> >>> >>> I provided the execution trace that HH derives >>> *AND THE X86 SOURCE-CODE OF DD THAT PROVES THIS TRACE IS CORRECT* >>> *AND THE X86 SOURCE-CODE OF DD THAT PROVES THIS TRACE IS CORRECT* >>> *AND THE X86 SOURCE-CODE OF DD THAT PROVES THIS TRACE IS CORRECT* >> >> Then why did the trace not follow the call to H? >> > > HH(DD,DD) the trace does follow the call to HH(DD,DD) > and fully simulates itself simulating DD. Yes HH does simulate the call to HH(DD,DD) and certain instructions within HH, although because you filter those trace entries out, nobody can check that. The point is it simulates THE WRONG INSTRUCTIONS within HH as discussed in other posts. When HH simulates itself, the instructions simulated must be the actual instructions that "outer" HH would execute, because that's what simulation means. What your HH does is simulate completely different instructions inside a conditional branch that asks "Am I being simulated?". That is Simply Wrong, in a way that should be obvious without repeated explanation. Trace output from a Simply Wrong program is not evidence for your claims. Mike.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-03 22:12 -0500 |
| Subject | Re: Why does Olcott care about simulation, anyway? --- Mikes Review |
| Message-ID | <v3m0m0$8r46$2@dont-email.me> |
| In reply to | #106219 |
On 6/3/2024 9:57 PM, Mike Terry wrote: > On 04/06/2024 03:18, olcott wrote: >> On 6/3/2024 8:59 PM, Richard Damon wrote: >>> On 6/3/24 9:46 PM, olcott wrote: >>>> On 6/3/2024 8:38 PM, Mike Terry wrote: >>>>> An execution trace that is produced by a program that is incorrect >>>>> /proves/ nothing whatsoever. I don't need to look at your proof, as >>>>> I was commenting on the value of your program output AS PROOF. >>>>> >>>> >>>> I provided the execution trace that HH derives >>>> *AND THE X86 SOURCE-CODE OF DD THAT PROVES THIS TRACE IS CORRECT* >>>> *AND THE X86 SOURCE-CODE OF DD THAT PROVES THIS TRACE IS CORRECT* >>>> *AND THE X86 SOURCE-CODE OF DD THAT PROVES THIS TRACE IS CORRECT* >>> >>> Then why did the trace not follow the call to H? >>> >> >> HH(DD,DD) the trace does follow the call to HH(DD,DD) >> and fully simulates itself simulating DD. > > Yes HH does simulate the call to HH(DD,DD) and certain instructions > within HH, although because you filter those trace entries out, nobody > can check that. > > The point is it simulates THE WRONG INSTRUCTIONS within HH as discussed > in other posts. > I conclusively proved that HH correctly simulated the instructions of DD and I also proved that the simulated HH also correctly simulated the instructions of DD by the fact that the provided execution traces by both the outer and the inner nested simulations exactly matched the behavior that the x86 source code of D specifies, line-by-line. _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 > When HH simulates itself, the instructions simulated must be the actual > instructions that "outer" HH would execute, because that's what > simulation means. What your HH does is simulate completely different > instructions inside a conditional branch that asks "Am I being > simulated?". That is Simply Wrong, in a way that should be obvious > without repeated explanation. Trace output from a Simply Wrong program > is not evidence for your claims. > > > Mike. > HH(DD,DD) only gets the machine address of DD as input, that is its only basis. When DD calls HH then the outer HH simply simulates whatever this call specifies it doesn't even know that it is calling itself. With your honesty and expertise we may finally get closure on this. -- 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 23:57 -0400 |
| Subject | Re: Why does Olcott care about simulation, anyway? --- Mikes Review |
| Message-ID | <v3m3af$2uv04$19@i2pn2.org> |
| In reply to | #106222 |
On 6/3/24 11:12 PM, olcott wrote: > On 6/3/2024 9:57 PM, Mike Terry wrote: >> On 04/06/2024 03:18, olcott wrote: >>> On 6/3/2024 8:59 PM, Richard Damon wrote: >>>> On 6/3/24 9:46 PM, olcott wrote: >>>>> On 6/3/2024 8:38 PM, Mike Terry wrote: > >>>>>> An execution trace that is produced by a program that is incorrect >>>>>> /proves/ nothing whatsoever. I don't need to look at your proof, >>>>>> as I was commenting on the value of your program output AS PROOF. >>>>>> >>>>> >>>>> I provided the execution trace that HH derives >>>>> *AND THE X86 SOURCE-CODE OF DD THAT PROVES THIS TRACE IS CORRECT* >>>>> *AND THE X86 SOURCE-CODE OF DD THAT PROVES THIS TRACE IS CORRECT* >>>>> *AND THE X86 SOURCE-CODE OF DD THAT PROVES THIS TRACE IS CORRECT* >>>> >>>> Then why did the trace not follow the call to H? >>>> >>> >>> HH(DD,DD) the trace does follow the call to HH(DD,DD) >>> and fully simulates itself simulating DD. >> >> Yes HH does simulate the call to HH(DD,DD) and certain instructions >> within HH, although because you filter those trace entries out, nobody >> can check that. >> >> The point is it simulates THE WRONG INSTRUCTIONS within HH as >> discussed in other posts. >> > > I conclusively proved that HH correctly simulated the instructions of > DD and I also proved that the simulated HH also correctly simulated the > instructions of DD by the fact that the provided execution traces by > both the outer and the inner nested simulations exactly matched the > behavior that the x86 source code of D specifies, line-by-line. Nope, not that you have ever published, at least not by your current definition, as you have never to my knowledge published any trace that showed the x86 insturctions of HH (or H). And the published code for H specifically does NOT simulate the instructions of the subroutine H. So, where is your proof that you have done what you say. Note, the "inner nested simulation" is NOT actually part of the simulaition that your outer HH is doing, but an INTERPRETATION of what the HH being simulated is seeing. So, you are just proving that you don't even understand your own definitions because you are just a PATHOLOGICAL LIAR. Remember, your currect definition of the ONLY THING that can be a "correct simulation" must follow the EXACT SEQUENCE OF INSTRUCTIONS that the x86 processor would execute, in the exact order, of the program, and thus the CALL HH instruction MUST go into HH, and thus, your "input" must include those instructions and thus DD is no longer a "Template" but must be an instance of DD as built on a given HH, and thus is a DIFFERENT input for each HH, and thus we can not look at a different HH's simulation for information about what its own simulation will do. That, or you have lied about simulating 1 to and infinite number of instructions as you need to stop after only simulating 8 instructions, which is a lot less that infinity, as you don't have the next instruction to correctly simulate. > > _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 > >> When HH simulates itself, the instructions simulated must be the >> actual instructions that "outer" HH would execute, because that's what >> simulation means. What your HH does is simulate completely different >> instructions inside a conditional branch that asks "Am I being >> simulated?". That is Simply Wrong, in a way that should be obvious >> without repeated explanation. Trace output from a Simply Wrong >> program is not evidence for your claims. >> >> >> Mike. >> > > HH(DD,DD) only gets the machine address of DD as input, that > is its only basis. When DD calls HH then the outer HH simply > simulates whatever this call specifies it doesn't even know > that it is calling itself. > > With your honesty and expertise we may finally get closure on this. > If it doesn't know it is calling itself, then how does it know it should abort its simulation? From my memory, it used a static memory hack to detect that the simulated machine was itself.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-04 12:26 -0500 |
| Subject | Re: Why does Olcott care about simulation, anyway? --- Mikes Review |
| Message-ID | <v3nina$gatu$5@dont-email.me> |
| In reply to | #106223 |
On 6/3/2024 10:57 PM, Richard Damon wrote: > On 6/3/24 11:12 PM, olcott wrote: >> On 6/3/2024 9:57 PM, Mike Terry wrote: >>> On 04/06/2024 03:18, olcott wrote: >>>> On 6/3/2024 8:59 PM, Richard Damon wrote: >>>>> On 6/3/24 9:46 PM, olcott wrote: >>>>>> On 6/3/2024 8:38 PM, Mike Terry wrote: >> >>>>>>> An execution trace that is produced by a program that is >>>>>>> incorrect /proves/ nothing whatsoever. I don't need to look at >>>>>>> your proof, as I was commenting on the value of your program >>>>>>> output AS PROOF. >>>>>>> >>>>>> >>>>>> I provided the execution trace that HH derives >>>>>> *AND THE X86 SOURCE-CODE OF DD THAT PROVES THIS TRACE IS CORRECT* >>>>>> *AND THE X86 SOURCE-CODE OF DD THAT PROVES THIS TRACE IS CORRECT* >>>>>> *AND THE X86 SOURCE-CODE OF DD THAT PROVES THIS TRACE IS CORRECT* >>>>> >>>>> Then why did the trace not follow the call to H? >>>>> >>>> >>>> HH(DD,DD) the trace does follow the call to HH(DD,DD) >>>> and fully simulates itself simulating DD. >>> >>> Yes HH does simulate the call to HH(DD,DD) and certain instructions >>> within HH, although because you filter those trace entries out, >>> nobody can check that. >>> >>> The point is it simulates THE WRONG INSTRUCTIONS within HH as >>> discussed in other posts. >>> >> >> I conclusively proved that HH correctly simulated the instructions of >> DD and I also proved that the simulated HH also correctly simulated the >> instructions of DD by the fact that the provided execution traces by >> both the outer and the inner nested simulations exactly matched the >> behavior that the x86 source code of D specifies, line-by-line. > > Nope, not that you have ever published, at least not by your current > definition, as you have never to my knowledge published any trace that > showed the x86 insturctions of HH (or H). > Published hundreds of times here any other places, now publishing it again right here: On 6/4/2024 11:28 AM, olcott wrote: [Proof that executed HH(DD,DD) and simulated HH(DD,DD) simulate DD correctly -- Mike Terry] -- Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-04 21:47 -0400 |
| Subject | Re: Why does Olcott care about simulation, anyway? --- Mikes Review |
| Message-ID | <v3og4b$328ec$2@i2pn2.org> |
| In reply to | #106248 |
On 6/4/24 1:26 PM, olcott wrote: > On 6/3/2024 10:57 PM, Richard Damon wrote: >> On 6/3/24 11:12 PM, olcott wrote: >>> On 6/3/2024 9:57 PM, Mike Terry wrote: >>>> On 04/06/2024 03:18, olcott wrote: >>>>> On 6/3/2024 8:59 PM, Richard Damon wrote: >>>>>> On 6/3/24 9:46 PM, olcott wrote: >>>>>>> On 6/3/2024 8:38 PM, Mike Terry wrote: >>> >>>>>>>> An execution trace that is produced by a program that is >>>>>>>> incorrect /proves/ nothing whatsoever. I don't need to look at >>>>>>>> your proof, as I was commenting on the value of your program >>>>>>>> output AS PROOF. >>>>>>>> >>>>>>> >>>>>>> I provided the execution trace that HH derives >>>>>>> *AND THE X86 SOURCE-CODE OF DD THAT PROVES THIS TRACE IS CORRECT* >>>>>>> *AND THE X86 SOURCE-CODE OF DD THAT PROVES THIS TRACE IS CORRECT* >>>>>>> *AND THE X86 SOURCE-CODE OF DD THAT PROVES THIS TRACE IS CORRECT* >>>>>> >>>>>> Then why did the trace not follow the call to H? >>>>>> >>>>> >>>>> HH(DD,DD) the trace does follow the call to HH(DD,DD) >>>>> and fully simulates itself simulating DD. >>>> >>>> Yes HH does simulate the call to HH(DD,DD) and certain instructions >>>> within HH, although because you filter those trace entries out, >>>> nobody can check that. >>>> >>>> The point is it simulates THE WRONG INSTRUCTIONS within HH as >>>> discussed in other posts. >>>> >>> >>> I conclusively proved that HH correctly simulated the instructions of >>> DD and I also proved that the simulated HH also correctly simulated the >>> instructions of DD by the fact that the provided execution traces by >>> both the outer and the inner nested simulations exactly matched the >>> behavior that the x86 source code of D specifies, line-by-line. >> >> Nope, not that you have ever published, at least not by your current >> definition, as you have never to my knowledge published any trace that >> showed the x86 insturctions of HH (or H). >> > > Published hundreds of times here any other places, > now publishing it again right here: > > On 6/4/2024 11:28 AM, olcott wrote: > [Proof that executed HH(DD,DD) and simulated HH(DD,DD) > simulate DD correctly -- Mike Terry] > But based on the WRONG definition of "Correct" to be able to talk about the input being non-halting, so just "double speak", and essentially a LIE.
[toc] | [prev] | [next] | [standalone]
| From | immibis <news2@immibis.com> |
|---|---|
| Date | 2024-06-04 19:36 +0200 |
| Subject | Re: Why does Olcott care about simulation, anyway? --- Mikes Review |
| Message-ID | <v3njas$gt0b$1@dont-email.me> |
| In reply to | #106222 |
On 4/06/24 05:12, olcott wrote: > HH(DD,DD) only gets the machine address of DD as input, that > is its only basis. When DD calls HH then the outer HH simply > simulates whatever this call specifies This is proven as a lie by your own words. You know that the outer HH refuses to simulate the inner DebugStep.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben@bsb.me.uk> |
|---|---|
| Date | 2024-06-03 10:42 +0100 |
| Message-ID | <87h6eamkgf.fsf@bsb.me.uk> |
| In reply to | #106102 |
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. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-03 07:20 -0500 |
| Subject | Re: Why does Olcott care about simulation, anyway? --- Ben's Review |
| Message-ID | <v3kcdj$3stk9$1@dont-email.me> |
| In reply to | #106116 |
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*
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 !
--
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 | immibis <news@immibis.com> |
|---|---|
| Date | 2024-06-03 15:39 +0200 |
| Subject | Re: Why does Olcott care about simulation, anyway? --- Ben's Review |
| Message-ID | <v3kh36$3taql$2@dont-email.me> |
| In reply to | #106124 |
On 3/06/24 14:20, 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. > > *The input to HH(DD,DD) specifies non-halting behavior* The input to HH(DD,DD) is DD,DD. DD,DD is a representation of DD(DD). A halting decider returns 1 if its input is a representation of a program call which halt, and 0 if its input is a representation of a program call which doesn't halt. DD,DD is a representation of a program call which halts, so it's supposed to be mapped to 1. I think Olcott has kill-filed me, so he only responds when someone else quotes it. I don't know why it's me specifically and not any of the other people he keeps threatening to stop talking to (like Richard).
[toc] | [prev] | [next] | [standalone]
| From | Mikko <mikko.levanto@iki.fi> |
|---|---|
| Date | 2024-06-03 17:27 +0300 |
| Subject | Re: Why does Olcott care about simulation, anyway? --- Ben's Review |
| Message-ID | <v3kjs9$3u7ng$1@dont-email.me> |
| In reply to | #106124 |
On 2024-06-03 12:20:01 +0000, olcott said: > On 6/3/2024 4:42 AM, Ben Bacarisse wrote: >> Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes: >> >>> PO's D(D) halts, as illustrated in various traces that have been posted here. >>> PO's H(D,D) returns 0 : [NOT halting] also as illustrated in various traces. >>> i.e. exactly as the Linz proof claims. PO has acknowledged both these >>> results. Same for the HH/DD variants. >>> >>> You might imagine that's the end of the matter - PO failed. :) >>> >>> That's right, but PO just carries on anyway! >> >> He has quite explicitly stated that false (0) is the correct result for >> H(D,D) "even though D(D) halts". I am mystified why anyone continues to >> discuss the matter until he equally explicitly repudiates that claim. >> > > Deciders only compute the mapping *from their inputs* to their own > accept or reject state. That does not restrict what a problem statement can specify. If the computed mapping differs from the specified one the decider does not solve the problem. -- Mikko
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-03 13:14 -0500 |
| Subject | Re: Why does Olcott care about simulation, anyway? --- Ben's Review |
| Message-ID | <v3l16f$5d3$4@dont-email.me> |
| In reply to | #106142 |
On 6/3/2024 9:27 AM, Mikko wrote:
> On 2024-06-03 12:20:01 +0000, olcott said:
>
>> On 6/3/2024 4:42 AM, Ben Bacarisse wrote:
>>> Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
>>>
>>>> PO's D(D) halts, as illustrated in various traces that have been
>>>> posted here.
>>>> PO's H(D,D) returns 0 : [NOT halting] also as illustrated in various
>>>> traces.
>>>> i.e. exactly as the Linz proof claims. PO has acknowledged both these
>>>> results. Same for the HH/DD variants.
>>>>
>>>> You might imagine that's the end of the matter - PO failed. :)
>>>>
>>>> That's right, but PO just carries on anyway!
>>>
>>> He has quite explicitly stated that false (0) is the correct result for
>>> H(D,D) "even though D(D) halts". I am mystified why anyone continues to
>>> discuss the matter until he equally explicitly repudiates that claim.
>>>
>>
>> Deciders only compute the mapping *from their inputs* to their own
>> accept or reject state.
>
> That does not restrict what a problem statement can specify.
> If the computed mapping differs from the specified one the
> decider does not solve the problem.
>
int sum(int x, int y) { return x + y; }
sum(2,3) cannot return the sum of 5 + 6.
DD correctly simulated by HH does have provably
different behavior than DD(DD) so HH is is not
allowed to report on the behavior of DD(DD).
--
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:56 -0400 |
| Subject | Re: Why does Olcott care about simulation, anyway? --- Ben's Review |
| Message-ID | <v3look$2uv04$11@i2pn2.org> |
| In reply to | #106159 |
On 6/3/24 2:14 PM, olcott wrote:
> On 6/3/2024 9:27 AM, Mikko wrote:
>> On 2024-06-03 12:20:01 +0000, olcott said:
>>
>>> On 6/3/2024 4:42 AM, Ben Bacarisse wrote:
>>>> Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
>>>>
>>>>> PO's D(D) halts, as illustrated in various traces that have been
>>>>> posted here.
>>>>> PO's H(D,D) returns 0 : [NOT halting] also as illustrated in
>>>>> various traces.
>>>>> i.e. exactly as the Linz proof claims. PO has acknowledged both these
>>>>> results. Same for the HH/DD variants.
>>>>>
>>>>> You might imagine that's the end of the matter - PO failed. :)
>>>>>
>>>>> That's right, but PO just carries on anyway!
>>>>
>>>> He has quite explicitly stated that false (0) is the correct result for
>>>> H(D,D) "even though D(D) halts". I am mystified why anyone
>>>> continues to
>>>> discuss the matter until he equally explicitly repudiates that claim.
>>>>
>>>
>>> Deciders only compute the mapping *from their inputs* to their own
>>> accept or reject state.
>>
>> That does not restrict what a problem statement can specify.
>> If the computed mapping differs from the specified one the
>> decider does not solve the problem.
>>
>
> int sum(int x, int y) { return x + y; }
> sum(2,3) cannot return the sum of 5 + 6.
Because 5 and 6 are not what 2 and 3 represent
>
> DD correctly simulated by HH does have provably
> different behavior than DD(DD) so HH is is not
> allowed to report on the behavior of DD(DD).
>
Nope, it MUST report on the behavior of DD(DD) as that is what its input
SPECIFIED.
The machine described by DD *IS* DD
The input to that machine, described by DD *IS* DD
So, the input DD,DD speciefies DD(DD), just like the 2,3 to sum
specifies 2 + 3.
[toc] | [prev] | [next] | [standalone]
| From | joes <noreply@example.com> |
|---|---|
| Date | 2024-06-04 08:21 +0000 |
| Subject | Re: Why does Olcott care about simulation, anyway? --- Ben's Review |
| Message-ID | <v3miqa$303qa$2@i2pn2.org> |
| In reply to | #106159 |
Am Mon, 03 Jun 2024 13:14:39 -0500 schrieb olcott:
> On 6/3/2024 9:27 AM, Mikko wrote:
>> On 2024-06-03 12:20:01 +0000, olcott said:
>>> On 6/3/2024 4:42 AM, Ben Bacarisse wrote:
>>>> Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
>>>>
>>>> He has quite explicitly stated that false (0) is the correct result
>>>> for H(D,D) "even though D(D) halts". I am mystified why anyone
>>>> continues to discuss the matter until he equally explicitly
>>>> repudiates that claim.
>>>>
>>> Deciders only compute the mapping *from their inputs* to their own
>>> accept or reject state.
>>
>> That does not restrict what a problem statement can specify.
>> If the computed mapping differs from the specified one the decider does
>> not solve the problem.
>>
> int sum(int x, int y) { return x + y; } sum(2,3) cannot return the sum
> of 5 + 6.
>
> DD correctly simulated by HH does have provably different behavior than
> DD(DD) so HH is is not allowed to report on the behavior of DD(DD).
Huh? Then HH is not a correct simulator if it produces different
behaviour. Why is it not allowed?
--
joes
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-04 12:31 -0500 |
| Subject | Re: Why does Olcott care about simulation, anyway? --- Ben's Review |
| Message-ID | <v3nj1t$gatu$8@dont-email.me> |
| In reply to | #106227 |
On 6/4/2024 3:21 AM, joes wrote:
> Am Mon, 03 Jun 2024 13:14:39 -0500 schrieb olcott:
>> On 6/3/2024 9:27 AM, Mikko wrote:
>>> On 2024-06-03 12:20:01 +0000, olcott said:
>>>> On 6/3/2024 4:42 AM, Ben Bacarisse wrote:
>>>>> Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
>>>>>
>>>>> He has quite explicitly stated that false (0) is the correct result
>>>>> for H(D,D) "even though D(D) halts". I am mystified why anyone
>>>>> continues to discuss the matter until he equally explicitly
>>>>> repudiates that claim.
>>>>>
>>>> Deciders only compute the mapping *from their inputs* to their own
>>>> accept or reject state.
>>>
>>> That does not restrict what a problem statement can specify.
>>> If the computed mapping differs from the specified one the decider does
>>> not solve the problem.
>>>
>> int sum(int x, int y) { return x + y; } sum(2,3) cannot return the sum
>> of 5 + 6.
>>
>> DD correctly simulated by HH does have provably different behavior than
>> DD(DD) so HH is is not allowed to report on the behavior of DD(DD).
> Huh? Then HH is not a correct simulator if it produces different
> behaviour. Why is it not allowed?
>
*Not at all as I prove right here*
Published hundreds of times here any other places,
now publishing it again right here:
On 6/4/2024 11:28 AM, olcott wrote:
[Proof that executed HH(DD,DD) and simulated HH(DD,DD)
simulate DD correctly -- Mike Terry]
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
Page 2 of 17 — ← Prev page 1 [2] 3 4 … 17 Next page →
Back to top | Article view | comp.theory
csiph-web