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 1 of 17 [1] 2 3 … 17 Next page →
| From | immibis <news@immibis.com> |
|---|---|
| Date | 2024-06-03 02:16 +0200 |
| Subject | Why does Olcott care about simulation, anyway? |
| Message-ID | <v3j20v$3gm10$2@dont-email.me> |
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.
[toc] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-02 20:34 -0400 |
| Message-ID | <v3j320$2qu72$17@i2pn2.org> |
| In reply to | #106095 |
On 6/2/24 8:16 PM, 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. Because it looks like an out to solve the question. He doesn't actual seem to care about halting (which is why he is so ignorant about it) but cares about the fact that the Halting Theorem (or pulling the same sort of proof) can show so many other things can't be done in other fields. There ARE some principles that allow the use of a certain type of simulation, that of the UTM which is defined to just recreate the behavior of the machined described, and a simple way to do that is to build a simulator. (UTMs are not actually defined by simulation, but by results). Olcott, in his typical method of playing with things he doesn't really understand, things that by tweeking the rules on the simulation, he might be able to get something close enough to Halting and using a UTM, that he can sneek his bad proof by, trying to replace the UTM simulation forever to show non-halting to trying to invoke an "induction-like" infinte set of "related" machines to try to argue that his infinite set of "correct" (but partial) simulation is just as good the one infinite simulation in showing non-halting. Not how he needs to keep things a bit undefined to avoid making the scam to obvious, and blocking his shell game. The key of the shell game is making an H that aborts simulating a machine using it, some how "equal" to a DIFFERN machine built on a DIFFERENT H that does simulate forever, and get stuck. If he can make you think these to input are "the same" because they are based things with the same name and doing things sort of the in the same way, just one is finite and the other never halts, he can pull a switcher-roo and show that the input to his actual H, which does halt, can be argued to not-halt as it was ok to swap it with the other machine. Ultimately, this comes down to his H needs to change its behavior when the "pathological machine" uses it, which is why his H^ uses an embedded_H instead of just a copy of H, so he can try to argue it could be different.
[toc] | [prev] | [next] | [standalone]
| From | Mike Terry <news.dead.person.stones@darjeeling.plus.com> |
|---|---|
| Date | 2024-06-03 04:28 +0100 |
| Message-ID | <J_CdnTaA96jxpcD7nZ2dnZfqnPudnZ2d@brightview.co.uk> |
| In reply to | #106095 |
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/ ]
So of great interest in all this would be: what in fact is the halt status of PO's contoversial
D(D), and what in fact does his H(D,D) return as the halt status of that input, right?
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! Where 99.99% students would think "damn, where did I
go wrong" and go back over their thinking to identify their mistake [aka "learn" from the whole
episode], PO just doubles down on his original claim, modifying it to [something barely coherent and
clearly not refuting any HP proof]. I can't even bring myself to try to explain exactly what PO
claims these days. IT DOES NOT MATTER unless you really feel a need to "understand" PO and where he
goes wrong.
And while we're here, "arguing" with PO about anything is also pointless :) in so far that:
- PO is /unable/ to understand your arguments or even the definition of the
terms you use. And he is incapable of logically explaining his own position.
In the end he just believes what he thinks is right (his intuitions) regardless
of any "logic" aka "extraneous complexity" that responders employ! I put this down
to some physical brain-wiring issue that PO has, meaning he cannot cope with
abstract concepts like others can. [...but who knows at that level...]
NOTE: it's not that PO isn't concentrating, or that people aren't explaining
clearly enough. I know there's a tendancy for posters to think that the lack of
genuine communication with PO is their fault, or at least something they can address
somehow. It's not.
- So people here can't "help" him by getting him to understand his mistakes - that's
just not going to happen. PO will die firmly believing that he is an
unacknowledged genius with superior powers of concentration/reasoning to all
of us. That may seem UNJUST, but it is unavoidable, and really DOESN'T MATTER;
When PO dies (as everyone dies) the world will just carry on as it does.
- no "innocent student" is going to read PO's claims and think "aha, looks like
the Halting Problem is decideable after all! I'll use that in my exams next week
to gain extra points"! [Or if they do, they'll get what they deserve :)]
People who understand HP quickly figure out PO is just a crank, although it may take some
time for them to see the bigger picture of what PO is claiming etc. if they get that far.
Crankhood can be quickly decided due to PO's constant use of "duffer phrasing"
and general lack of coherency in everything he posts - actual geniuses don't do that.
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)]
Mike.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-02 22:50 -0500 |
| Subject | Re: Why does Olcott care about simulation, anyway? --- Mikes Review |
| Message-ID | <v3jei1$3o3a7$1@dont-email.me> |
| In reply to | #106102 |
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:
*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]
--
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 07:14 -0400 |
| Subject | Re: Why does Olcott care about simulation, anyway? --- Mikes Review |
| Message-ID | <v3k8it$2scls$1@i2pn2.org> |
| In reply to | #106103 |
On 6/2/24 11:50 PM, 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>
Right, so if can show that IF H can show that CORRECTLY SIMULTED D WOULD
NEVER STOP RUNNING UNLESS ABORTED.
THe ONLY definition of "Correctly SImulated" that Professir Sipser would
use here is that of a UTM, which would be a simulation that never stops,
so, since D, by definition, uses the actual H that is being used, which
if it avails itself of your last clause, WILL return 0 to ALL callers of
H(D,D), the correct (which is complete) simulation of D will see that
return 0 happen and D halt, so H can NEVER have "corrrectly decided"
that something that doesn't happen will happen.
This has been explained to you many times, so it can't be an "honest
mistake" so must be a reckless disregard for the truth, or you just have
a mental inability to understand the truth, either of which just makes
you a Pathological Liar.
>
> 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.
Which shows part of your issue, there need not be a "master UTM" present
at all, and a UTM can't effect the behavior of "its inputs" because the
definition of a UTM is that it exactly recreates what the machines
described by its inputs would do when they are just run.
>
> 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:
>
> *We can see that the following DD cannot possibly halt when*
> *correctly simulated by every HH that can possibly exist*
Because the statements are different.
And thus you are shown to be LYING.
>
> typedef int (*ptr)(); // ptr is pointer to int function in C
> 00 int HH(ptr p, ptr i);
> 01 int DD(ptr p)
> 02 {
> 03 int Halt_Status = HH(p, p);
> 04 if (Halt_Status)
> 05 HERE: goto HERE;
> 06 return Halt_Status;
> 07 }
>
> _DD()
> [00001c22] 55 push ebp
> [00001c23] 8bec mov ebp,esp
> [00001c25] 51 push ecx
> [00001c26] 8b4508 mov eax,[ebp+08]
> [00001c29] 50 push eax ; push DD 1c22
> [00001c2a] 8b4d08 mov ecx,[ebp+08]
> [00001c2d] 51 push ecx ; push DD 1c22
> [00001c2e] e80ff7ffff call 00001342 ; call HH
> [00001c33] 83c408 add esp,+08
> [00001c36] 8945fc mov [ebp-04],eax
> [00001c39] 837dfc00 cmp dword [ebp-04],+00
> [00001c3d] 7402 jz 00001c41
> [00001c3f] ebfe jmp 00001c3f
> [00001c41] 8b45fc mov eax,[ebp-04]
> [00001c44] 8be5 mov esp,ebp
> [00001c46] 5d pop ebp
> [00001c47] c3 ret
> Size in bytes:(0038) [00001c47]
>
>
[toc] | [prev] | [next] | [standalone]
| From | immibis <news@immibis.com> |
|---|---|
| Date | 2024-06-03 15:36 +0200 |
| Subject | Re: Why does Olcott care about simulation, anyway? --- Mikes Review |
| Message-ID | <v3kgst$3taql$1@dont-email.me> |
| In reply to | #106103 |
On 3/06/24 05: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/ ] >> > > [ignored repost of already debunked nonsense] You already posted this and it was irrelevant then and it's still irrelevant.
[toc] | [prev] | [next] | [standalone]
| From | Mike Terry <news.dead.person.stones@darjeeling.plus.com> |
|---|---|
| Date | 2024-06-03 17:25 +0100 |
| Subject | Re: Why does Olcott care about simulation, anyway? --- Mikes Review |
| Message-ID | <0xqdnd8ktrnsc8D7nZ2dnZfqnPqdnZ2d@brightview.co.uk> |
| In reply to | #106103 |
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.
>
> *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]
>
>
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-03 12:54 -0500 |
| Subject | Re: Why does Olcott care about simulation, anyway? --- Mikes Review |
| Message-ID | <v3l002$5d3$1@dont-email.me> |
| In reply to | #106152 |
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.
>
>>
>> *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]
>>
>>
--
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:57 -0400 |
| Subject | Re: Why does Olcott care about simulation, anyway? --- Mikes Review |
| Message-ID | <v3loou$2uv04$13@i2pn2.org> |
| In reply to | #106156 |
On 6/3/24 1:54 PM, 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.
>
NO, the execution traces generated are incorrect, as the call H (or HH)
should be followed by the instructions of the subroutine called.
That is your definition of "Correct Simulation", so you are agreeing
that all your old simulation, that make the call to H (or HH) result in
anouther "layer" of simulation to be just definitionally incorrect.
>>
>>>
>>> *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]
>>>
>>>
>
[toc] | [prev] | [next] | [standalone]
| From | Mike Terry <news.dead.person.stones@darjeeling.plus.com> |
|---|---|
| Date | 2024-06-04 02:38 +0100 |
| Subject | Re: Why does Olcott care about simulation, anyway? --- Mikes Review |
| Message-ID | <lZadnYLpbtuB7cP7nZ2dnZfqn_udnZ2d@brightview.co.uk> |
| In reply to | #106156 |
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.
It's like you claim you are going to write a program that proves that the sum of integers 1 to 10 is
55, and here is your program source and the output:
source:
int main ()
{
int total = 0;
for (int x = 3; x <= 10; x++) // look carefully at the range for the loop
total += x;
end;
printf ("Sum of integers from 1 to 10 is: %d\n", 55);
}
output:
Sum of integers from 1 to 10 is: 55
Well the output is correct! And my program proved it, because it wrote a true statement!!
(Um, No. Given my program output is incorrect, it proves nothing. Similarly if your program does
not correctly simulate computation DD(DD) [WHICH IT DEFINITELY DOESN'T BECAUSE IT'S SIMULATION OF HH
IS NONSENSE DUE TO MISUSE OF GLOBALS IN DD ETC.] there's no point in you trying to claim that it's
trace is correct despite the program being wrong. The point is correct or not, the trace PROVES
nothing, like my output above. Duh.
This whole situation mirrors your lack of understanding what a proof is. For you a proof is just
making lots of claims you think are true (aka your intuitions) perhaps with the rule that the last
thing you claim must be whatever you're claiming.
And it's not a case of simply "disliking the way HH is written" which trivialises the problem - like
I'm objecting to your naming conventions or something. Your HH is completely wrong in its
implementation of simulation - like my program above is wrong in its calculation, regardless of what
it outputs. HH does not actually simulate itself correctly AT ALL.
>
>>
>>>
>>> *We can see that the following DD cannot possibly halt when*
>>> *correctly simulated by every HH that can possibly exist*
.. and I don't believe I even commented on the correctness or otherwise for that claim.
Mike.
>>>
>>> typedef int (*ptr)(); // ptr is pointer to int function in C
>>> 00 int HH(ptr p, ptr i);
>>> 01 int DD(ptr p)
>>> 02 {
>>> 03 int Halt_Status = HH(p, p);
>>> 04 if (Halt_Status)
>>> 05 HERE: goto HERE;
>>> 06 return Halt_Status;
>>> 07 }
>>>
>>> _DD()
>>> [00001c22] 55 push ebp
>>> [00001c23] 8bec mov ebp,esp
>>> [00001c25] 51 push ecx
>>> [00001c26] 8b4508 mov eax,[ebp+08]
>>> [00001c29] 50 push eax ; push DD 1c22
>>> [00001c2a] 8b4d08 mov ecx,[ebp+08]
>>> [00001c2d] 51 push ecx ; push DD 1c22
>>> [00001c2e] e80ff7ffff call 00001342 ; call HH
>>> [00001c33] 83c408 add esp,+08
>>> [00001c36] 8945fc mov [ebp-04],eax
>>> [00001c39] 837dfc00 cmp dword [ebp-04],+00
>>> [00001c3d] 7402 jz 00001c41
>>> [00001c3f] ebfe jmp 00001c3f
>>> [00001c41] 8b45fc mov eax,[ebp-04]
>>> [00001c44] 8be5 mov esp,ebp
>>> [00001c46] 5d pop ebp
>>> [00001c47] c3 ret
>>> Size in bytes:(0038) [00001c47]
>>>
>>>
>
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-03 20:46 -0500 |
| Subject | Re: Why does Olcott care about simulation, anyway? --- Mikes Review |
| Message-ID | <v3lrm2$4h2j$1@dont-email.me> |
| In reply to | #106200 |
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*
http://al.howardknight.net/?STYPE=msgid&MSGI=%3CS8CcnRadHexfe8X7nZ2dnZfqnPqdnZ2d%40brightview.co.uk%3E+
Message-ID: <S8CcnRadHexfe8X7nZ2dnZfqnPqdnZ2d@brightview.co.uk>
AND YOU SAID
"It shows that the simulation is "rubbish" and any trace
produced by it can just be ignored."
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-03 21:59 -0400 |
| Subject | Re: Why does Olcott care about simulation, anyway? --- Mikes Review |
| Message-ID | <v3lsd6$2uv04$17@i2pn2.org> |
| In reply to | #106203 |
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? You have DEFINED that to be incorrect. > > http://al.howardknight.net/?STYPE=msgid&MSGI=%3CS8CcnRadHexfe8X7nZ2dnZfqnPqdnZ2d%40brightview.co.uk%3E+ > Message-ID: <S8CcnRadHexfe8X7nZ2dnZfqnPqdnZ2d@brightview.co.uk> > > AND YOU SAID > "It shows that the simulation is "rubbish" and any trace > produced by it can just be ignored." >
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-03 21:18 -0500 |
| Subject | Re: Why does Olcott care about simulation, anyway? --- Mikes Review |
| Message-ID | <v3ltij$8gjv$3@dont-email.me> |
| In reply to | #106208 |
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.
DD correctly emulated by any HH that can possibly exist DOES NOT HALT
DD correctly emulated by any HH that can possibly exist DOES NOT HALT
DD correctly emulated by any HH that can possibly exist DOES NOT HALT
typedef int (*ptr)(); // ptr is pointer to int function in C
00 int HH(ptr p, ptr i);
01 int DD(ptr p)
02 {
03 int Halt_Status = HH(p, p);
04 if (Halt_Status)
05 HERE: goto HERE;
06 return Halt_Status;
07 }
_DD()
[00001c22] 55 push ebp
[00001c23] 8bec mov ebp,esp
[00001c25] 51 push ecx
[00001c26] 8b4508 mov eax,[ebp+08]
[00001c29] 50 push eax ; push DD 1c22
[00001c2a] 8b4d08 mov ecx,[ebp+08]
[00001c2d] 51 push ecx ; push DD 1c22
[00001c2e] e80ff7ffff call 00001342 ; call HH
[00001c33] 83c408 add esp,+08
[00001c36] 8945fc mov [ebp-04],eax
[00001c39] 837dfc00 cmp dword [ebp-04],+00
[00001c3d] 7402 jz 00001c41
[00001c3f] ebfe jmp 00001c3f
[00001c41] 8b45fc mov eax,[ebp-04]
[00001c44] 8be5 mov esp,ebp
[00001c46] 5d pop ebp
[00001c47] c3 ret
Size in bytes:(0038) [00001c47]
--
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 22:49 -0400 |
| Subject | Re: Why does Olcott care about simulation, anyway? --- Mikes Review |
| Message-ID | <v3lvc6$2uv03$6@i2pn2.org> |
| In reply to | #106211 |
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.
>
> DD correctly emulated by any HH that can possibly exist DOES NOT HALT
> DD correctly emulated by any HH that can possibly exist DOES NOT HALT
> DD correctly emulated by any HH that can possibly exist DOES NOT HALT
PROVEN WRONG, and that you are just a STUPID IDIOT THAT DOESN'T KNOW THE
MEANING OF THE WORDS.
DD DOES HALT, as Halting is the behavior of the machine itself.
If you keep repeating your lie, I will just keep focusing on the error
of you not knowing the meaning of the word.
>
> typedef int (*ptr)(); // ptr is pointer to int function in C
> 00 int HH(ptr p, ptr i);
> 01 int DD(ptr p)
> 02 {
> 03 int Halt_Status = HH(p, p);
> 04 if (Halt_Status)
> 05 HERE: goto HERE;
> 06 return Halt_Status;
> 07 }
>
> _DD()
> [00001c22] 55 push ebp
> [00001c23] 8bec mov ebp,esp
> [00001c25] 51 push ecx
> [00001c26] 8b4508 mov eax,[ebp+08]
> [00001c29] 50 push eax ; push DD 1c22
> [00001c2a] 8b4d08 mov ecx,[ebp+08]
> [00001c2d] 51 push ecx ; push DD 1c22
> [00001c2e] e80ff7ffff call 00001342 ; call HH
> [00001c33] 83c408 add esp,+08
> [00001c36] 8945fc mov [ebp-04],eax
> [00001c39] 837dfc00 cmp dword [ebp-04],+00
> [00001c3d] 7402 jz 00001c41
> [00001c3f] ebfe jmp 00001c3f
> [00001c41] 8b45fc mov eax,[ebp-04]
> [00001c44] 8be5 mov esp,ebp
> [00001c46] 5d pop ebp
> [00001c47] c3 ret
> Size in bytes:(0038) [00001c47]
>
>
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-04 12:12 -0500 |
| Subject | Re: Why does Olcott care about simulation, anyway? --- Mikes Review |
| Message-ID | <v3nhuh$gatu$4@dont-email.me> |
| In reply to | #106217 |
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. I don't see how you could be so confused to believe that I do not believe what I say. If you call me a liar knowing that I do believe what I say that might possibly get you condemned to Hell and I don't want that. There is no need to show the 251 pages of the the execution trace of the simulated HH simulating DD because we can conclusively proof that HH is correctly simulating DD and the simulated DD is correctly simulating DD entirely on the basis that the execution traces provide exactly match the behavior specified by the x86 machine code of DD. *The details are 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] *I had to insert another paragraph into the original post* -- 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 | <v3og45$328ec$1@i2pn2.org> |
| In reply to | #106247 |
On 6/4/24 1:12 PM, olcott wrote: > It might be good for you to quit calling me a liar, everyone here > knows that I am not a liar. I don't see how you could be so confused > to believe that I do not believe what I say. If you call me a liar > knowing that I do believe what I say that might possibly get you > condemned to Hell and I don't want that. > But you ARE a LIAR, and I suspect you tell more lies than truth (or it might just seem that way). For instance, you keep on saying that DD doesn't halt. but it does, and you have admitted as much for at least an essentially similar machine. You CLEARLY stated that D(D) Halted since H(D,D) returned 0, but then tried to claim that for "reasons" (that you could never actually prove) H saying that a halting machine was non-halting was somehow "correct". You last couple of years have been you fumbling around with many different (and flawed) arguments to try to show a reason that the definitionally incorrect answer was correct, and the best you have done is to just admit you are working on a different problem, but that you different problem should be though of a "good enough" because it must be to save the world, even though it needs to contradict all logic to do so. > There is no need to show the 251 pages of the the execution trace of the > simulated HH simulating DD because we can conclusively proof that HH is > correctly simulating DD and the simulated DD is correctly simulating DD > entirely on the basis that the execution traces provide exactly match > the behavior specified by the x86 machine code of DD. But it IS if you want to claim that is what it actually does, and then you need to show that your proof works with THAT trace, not the non-trace that you LIE to say is a "correcct trace" when it clearly fails to meet even your definition. > > *The details are 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] > > *I had to insert another paragraph into the original post* > And why do we care about a "correct simulation" that is done by a definition that fails to meet the requirements to prove your ultimate statement?
[toc] | [prev] | [next] | [standalone]
| From | Mikko <mikko.levanto@iki.fi> |
|---|---|
| Date | 2024-06-05 10:08 +0300 |
| Subject | Re: Why does Olcott care about simulation, anyway? --- Mikes Review |
| Message-ID | <v3p2ss$s8bi$1@dont-email.me> |
| In reply to | #106247 |
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. -- Mikko
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-05 08:08 -0500 |
| Subject | Re: Why does Olcott care about simulation, anyway? --- Mikes Review |
| Message-ID | <v3po03$v133$5@dont-email.me> |
| In reply to | #106291 |
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. -- 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 | wij <wyniijj5@gmail.com> |
|---|---|
| Date | 2024-06-05 21:47 +0800 |
| Subject | Re: Why does Olcott care about simulation, anyway? --- Mikes Review |
| Message-ID | <7da0df8d345bcccfc48c6d5fcf03543530b0ac81.camel@gmail.com> |
| In reply to | #106309 |
On Wed, 2024-06-05 at 08:08 -0500, 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. Yield to my GUR. Why struggle so painfully? After so many lies these years, you finally tell the truth that your emperical fact that D behaves differently from what H reports (that is what GUR expects). You seems to have run out of excuses now to claim that the Halting Problem is wrong and still claim that you are correct. Do you expect your god support you? Don't be such silly, GUR had said your god cannot help you in this problem. If you say you will be put in the lake of fire and stoned, you will. > 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. >
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-05 09:10 -0500 |
| Subject | Re: Why does Olcott care about simulation, anyway? --- Mikes Review |
| Message-ID | <v3prjo$1003g$6@dont-email.me> |
| In reply to | #106314 |
On 6/5/2024 8:47 AM, wij wrote: > On Wed, 2024-06-05 at 08:08 -0500, 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. > > Yield to my GUR. Why struggle so painfully? > After so many lies these years, you finally tell the truth that your emperical > fact that D behaves differently from what H reports (that is what GUR expects). > You seems to have run out of excuses now to claim that the Halting Problem is > wrong and still claim that you are correct. Do you expect your god support you? > Don't be such silly, GUR had said your god cannot help you in this problem. > My reasoning is correct and no one has correctly showed any error in my reasoning with their own reasoning. They try to get away with the strawman deception of changing the subject as a fake rebuttal. *This unequivocally proves the behavior of DD correctly simulated by HH* https://liarparadox.org/DD_correctly_simulated_by_HH_is_Proven.pdf No one has ever shown otherwise all that anyone has ever provided is dogmatic assertions entirely bereft of any supporting reasoning. -- Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
Page 1 of 17 [1] 2 3 … 17 Next page →
Back to top | Article view | comp.theory
csiph-web