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 10 of 17 — ← Prev page 1 … 8 9 [10] 11 12 … 17 Next page →
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-08 09:03 -0400 |
| Subject | Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis |
| Message-ID | <v41kr9$3cg3t$10@i2pn2.org> |
| In reply to | #106626 |
On 6/7/24 11:36 PM, olcott wrote:
> On 6/7/2024 10:03 PM, Richard Damon wrote:
>> On 6/7/24 10:43 PM, Mike Terry wrote:
>>> On 07/06/2024 17:34, joes wrote:
>>>> Am Fri, 07 Jun 2024 10:40:37 -0500 schrieb olcott:
>>>>> On 6/7/2024 10:32 AM, joes wrote:
>>>>>> Am Fri, 07 Jun 2024 10:20:09 -0500 schrieb olcott:
>>>>>>> On 6/7/2024 10:09 AM, Python wrote:
>>>>>>>> Le 07/06/2024 à 17:05, olcott a écrit :
>>>>>>>>> On 6/7/2024 9:55 AM, Python wrote:
>>>>>>>>>> Le 07/06/2024 à 16:47, olcott a écrit :
>>>>
>>>>>>>>>>> The issue here is that I proved that DD correctly simulated
>>>>>>>>>>> by HH
>>>>>>>>>>> has different behavior than the directly executed DD(DD) and
>>>>>>>>>>> everyone's "rebuttal" to this proof is to simply ignore it.
>>>>>>>>> When you actually try to form a rebuttal of the above you will see
>>>>>>>>> that I am correct. So far everyone simply ignores the proof that I
>>>>>>>>> am correct as their only rebuttal.
>>>>>>> A {correct simulation} means that each instruction of the above x86
>>>>>>> machine language of DD is correctly simulated by HH and simulated in
>>>>>>> the correct order.
>>>>>> And to the end. Thus it can't behave differently than direct
>>>>>> execution.
>>>>> You must not be very good at programming if you believe that
>>>>> Infinite_Recursion must be simulated "to the end"
>>>> As I said before, if there is no end the simulation can't end either.
>>>
>>> PO chooses to leave his terminology ambiguous, so we have 1000 post
>>> threads perpetuated by little more than verbal misunderstandings.
>>>
>>> All PO's "simulating halt deciders" (SHD) are actually "partial
>>> simulating partial halt deciders":
>>> They partially simulate their input computation, while monitoring the
>>> simulation state for patterns which *PO* just believes (without
>>> proof) indicate non-halting. When such a pattern is detected, the
>>> SHD abandons its simulating activity ["aborts" its simulation], and
>>> returns nonhalting. Also, PO does not claim that his SHDs decide all
>>> inputs correctly - or even that they halt for all inputs (which a
>>> decider must). He is really just interested in the H(D,D) case.
>>>
>>> PO has a couple of such rules/patterns, and at least one of them is
>>> sound: the "tight loop" pattern. If an input (P,I) contains a tight
>>> loop (like "LOOP: goto LOOP"), and assuming PO has coded the rule
>>> correctly, his H/HH will detect the tight loop while simulating the
>>> code and correctly return non-halting. In this scenario we have a
>>> non-terminating computation, but PO's /partial/ simulation obviously
>>> ends through aborting the target. THERE'S NOTHING WRONG WITH THAT.
>>> If someone wants to claim "that's not valid simulation" then right or
>>> wrong it's nothing more than a disagreement over use of terminology,
>>> and nothing is achieved by that.
>>>
>>> PO also has at least one /unsound/ rule: his "infinite recursive
>>> simulation" rule. That rule matches computations that in fact halt.
>>> Despite PO's colourful language like "...until H 'sees that the
>>> simulation will never terminate unless blah blah'" and "...DD
>>> 'specifies infinite recursion to HH'" and so on, the truth is simply
>>> that his H is applying an unsound rule, which leads to it deciding
>>> incorrectly.)
>>>
>>> And all the stuff about "correct simulations of DD by HH never
>>> reaching line nn" might be correct if suitably interpreted (as
>>> /partial simulations/ not reaching a simulated halt state, rather
>>> than the /actual computation/ being examined), but its all logically
>>> irrelevent having little to do with actual termination of a given
>>> computation.
>>>
>>> What makes the SHD work or not work is the matching of rules
>>> (patterns detected in the simulated computation states) that the SHD
>>> uses to trigger an abort. If a /sound/ rule matches, the SHD will
>>> decide correctly. If an /unsound/ rule matches it may decide
>>> incorrectly (as with PO's H(D,D)), or in other situations it might be
>>> correct "by fluke".
>>>
>>> If PO's H used only sound rules, it would not decide input (D,D)
>>> incorrectly - but unfortunately neither would it decide correctly -
>>> it would never terminate /for that input/. (I find that kind of
>>> neat...)
>>>
>>>>
>>>>>>> Anyone claiming that HH should report on the behavior of the
>>>>>>> directly
>>>>>>> executed DD(DD) is requiring a violation of the above definition of
>>>>>>> correct simulation.
>>>>>> But those are the same. How does simulating something change it?
>>>>> It seems to boil down to you just don't know enough about programming
>>>>> otherwise it would occur to you that there cannot possibly exist any
>>>>> correct rebuttal to the following:
>>>> Answer the question. Why should the simulation differ from direct
>>>> execution?
>>>
>>> [Let's assume code is properly restricted to exclude the
>>> complications of "cheating" in PO's x86utm environment through use of
>>> mutable static variables and the like.]
>>>
>>> Obviously they wouldn't, except in so far as "partial simulation"
>>> differs from "full simulation". I.e. all steps will match precisely,
>>> up to the point where the partial simulation is abandoned.
>>>
>>> And in PO's H(D,D) vs D(D) example that is exactly what the traces
>>> show: The simulated and direct traces match exactly, right up to the
>>> point where H aborts the simulation. (The full computation steps of
>>> D(D) then proceeding further until D terminates a bit later.)
>>>
>>> Even though I put the two traces side-by-side for PO, he still
>>> insists the "behaviour is different". Well, perhaps he just means
>>> that the H simulation was abandonned whereas directly executed D(D)
>>> proceeded further and eventually terminated? If so, then /so what/?
>>> I think his problem here is nothing to do with /simulations/ not
>>> reaching whatever line of code, but more the /reason/ that his H
>>> aborted - it matched his (unsound) non-halting pattern, and he just
>>> really really really really believes that pattern is sound.
>>>
>>> So now he needs to account for two "verified facts": 1) D(D)
>>> computation never halts (/his unsound pattern matched!/) 2) D(D)
>>> computation halts when run directly. That forces him to claim there
>>> are two different behaviours [/beyond/ the simple truncation of the
>>> aborted trace] for the one computation, and to come up with some
>>> Words to justify that position (like "pathological self reference",
>>> subjective questions) and then More Words to say that his other Words
>>> are "the true meaning of halting" etc. etc. All nonsense flowing
>>> from not being able to accept his rule is just wrong.
>>>
>>>
>>> Mike.
>>>
>>
>> The last time I remember him actually trying to answer, the difference
>> was that the order of who started mattered, because D(D) calling
>> H(D,D) meant that the H(D,D) that was called doesn't get stuck in the
>> loop, but recognizes the loop and gets out, while when H(D,D)
>> simulated D(D) and that first H(D,D) sees that the simulated H(D,D)
>> would just get into a loop, that incorrect decision becomes the actual
>> behavior of that simulated H(D,D).
>>
>> So it is always the first H(D,D) that returns, and the second one
>> doesn't, which just proes that is can't be a pure function, or that
>> rule doesn't apply to functions whose simulation has been aborted.
>>
>> Of course he also think that aborting th simulation mean that hte
>> machine being simulate had its plug pulled at that point, so it isn't
>> proper to look at the direct execution after that,
>>
>> He clearly doesn't seem to understand how these sorts of machines work.
>
> DD(DD) is just like infinite recursion that gets terminated at
> its second recursive call. DD(DD) halts only because HH(DD,DD)
> correctly determines that its input DOES NOT HALT.
Except a potentially infinite loop that has code that breaks out of that
loop will halt.
Since DD included HH as part of it, if that included part will stop DD
from running forever (by keeping that HH from running forever) then DD
is not a non-halting program.
The fact that the HH simulating this DD aborts isn't what makes DD
non-halting, but the presence of that does mean (since DD is built from
HH) that DD has within it the code to stop it from running forever.
>
> If HH(DD,DD) did not correctly determine that its input
> DOES NOT HALT then DD(DD) would never halt.
>
But your problem is that since HH DOES decide to abort its simulation
and return 0, that IS what it does, and that makes DD "potential"
infinite loop, finite.
Thus, when HH does abort its simulation, that makes DD Halting, and if
HH doesn't abort its simulation, it makes both DD and HH non-halting
(which makes HH not a decider).
The point you keep on missing is that HH is a specific machine, and has
made its decision by its design, and by the way DD is constructed, that
affects what DD Does.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-08 08:43 -0500 |
| Subject | Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis |
| Message-ID | <v41n5l$2kanc$7@dont-email.me> |
| In reply to | #106658 |
On 6/8/2024 8:03 AM, Richard Damon wrote:
> On 6/7/24 11:36 PM, olcott wrote:
>> On 6/7/2024 10:03 PM, Richard Damon wrote:
>>> On 6/7/24 10:43 PM, Mike Terry wrote:
>>>> On 07/06/2024 17:34, joes wrote:
>>>>> Am Fri, 07 Jun 2024 10:40:37 -0500 schrieb olcott:
>>>>>> On 6/7/2024 10:32 AM, joes wrote:
>>>>>>> Am Fri, 07 Jun 2024 10:20:09 -0500 schrieb olcott:
>>>>>>>> On 6/7/2024 10:09 AM, Python wrote:
>>>>>>>>> Le 07/06/2024 à 17:05, olcott a écrit :
>>>>>>>>>> On 6/7/2024 9:55 AM, Python wrote:
>>>>>>>>>>> Le 07/06/2024 à 16:47, olcott a écrit :
>>>>>
>>>>>>>>>>>> The issue here is that I proved that DD correctly simulated
>>>>>>>>>>>> by HH
>>>>>>>>>>>> has different behavior than the directly executed DD(DD) and
>>>>>>>>>>>> everyone's "rebuttal" to this proof is to simply ignore it.
>>>>>>>>>> When you actually try to form a rebuttal of the above you will
>>>>>>>>>> see
>>>>>>>>>> that I am correct. So far everyone simply ignores the proof
>>>>>>>>>> that I
>>>>>>>>>> am correct as their only rebuttal.
>>>>>>>> A {correct simulation} means that each instruction of the above x86
>>>>>>>> machine language of DD is correctly simulated by HH and
>>>>>>>> simulated in
>>>>>>>> the correct order.
>>>>>>> And to the end. Thus it can't behave differently than direct
>>>>>>> execution.
>>>>>> You must not be very good at programming if you believe that
>>>>>> Infinite_Recursion must be simulated "to the end"
>>>>> As I said before, if there is no end the simulation can't end either.
>>>>
>>>> PO chooses to leave his terminology ambiguous, so we have 1000 post
>>>> threads perpetuated by little more than verbal misunderstandings.
>>>>
>>>> All PO's "simulating halt deciders" (SHD) are actually "partial
>>>> simulating partial halt deciders":
>>>> They partially simulate their input computation, while monitoring
>>>> the simulation state for patterns which *PO* just believes (without
>>>> proof) indicate non-halting. When such a pattern is detected, the
>>>> SHD abandons its simulating activity ["aborts" its simulation], and
>>>> returns nonhalting. Also, PO does not claim that his SHDs decide
>>>> all inputs correctly - or even that they halt for all inputs (which
>>>> a decider must). He is really just interested in the H(D,D) case.
>>>>
>>>> PO has a couple of such rules/patterns, and at least one of them is
>>>> sound: the "tight loop" pattern. If an input (P,I) contains a tight
>>>> loop (like "LOOP: goto LOOP"), and assuming PO has coded the rule
>>>> correctly, his H/HH will detect the tight loop while simulating the
>>>> code and correctly return non-halting. In this scenario we have a
>>>> non-terminating computation, but PO's /partial/ simulation obviously
>>>> ends through aborting the target. THERE'S NOTHING WRONG WITH THAT.
>>>> If someone wants to claim "that's not valid simulation" then right
>>>> or wrong it's nothing more than a disagreement over use of
>>>> terminology, and nothing is achieved by that.
>>>>
>>>> PO also has at least one /unsound/ rule: his "infinite recursive
>>>> simulation" rule. That rule matches computations that in fact halt.
>>>> Despite PO's colourful language like "...until H 'sees that the
>>>> simulation will never terminate unless blah blah'" and "...DD
>>>> 'specifies infinite recursion to HH'" and so on, the truth is simply
>>>> that his H is applying an unsound rule, which leads to it deciding
>>>> incorrectly.)
>>>>
>>>> And all the stuff about "correct simulations of DD by HH never
>>>> reaching line nn" might be correct if suitably interpreted (as
>>>> /partial simulations/ not reaching a simulated halt state, rather
>>>> than the /actual computation/ being examined), but its all logically
>>>> irrelevent having little to do with actual termination of a given
>>>> computation.
>>>>
>>>> What makes the SHD work or not work is the matching of rules
>>>> (patterns detected in the simulated computation states) that the SHD
>>>> uses to trigger an abort. If a /sound/ rule matches, the SHD will
>>>> decide correctly. If an /unsound/ rule matches it may decide
>>>> incorrectly (as with PO's H(D,D)), or in other situations it might
>>>> be correct "by fluke".
>>>>
>>>> If PO's H used only sound rules, it would not decide input (D,D)
>>>> incorrectly - but unfortunately neither would it decide correctly -
>>>> it would never terminate /for that input/. (I find that kind of
>>>> neat...)
>>>>
>>>>>
>>>>>>>> Anyone claiming that HH should report on the behavior of the
>>>>>>>> directly
>>>>>>>> executed DD(DD) is requiring a violation of the above definition of
>>>>>>>> correct simulation.
>>>>>>> But those are the same. How does simulating something change it?
>>>>>> It seems to boil down to you just don't know enough about programming
>>>>>> otherwise it would occur to you that there cannot possibly exist any
>>>>>> correct rebuttal to the following:
>>>>> Answer the question. Why should the simulation differ from direct
>>>>> execution?
>>>>
>>>> [Let's assume code is properly restricted to exclude the
>>>> complications of "cheating" in PO's x86utm environment through use
>>>> of mutable static variables and the like.]
>>>>
>>>> Obviously they wouldn't, except in so far as "partial simulation"
>>>> differs from "full simulation". I.e. all steps will match precisely,
>>>> up to the point where the partial simulation is abandoned.
>>>>
>>>> And in PO's H(D,D) vs D(D) example that is exactly what the traces
>>>> show: The simulated and direct traces match exactly, right up to
>>>> the point where H aborts the simulation. (The full computation
>>>> steps of D(D) then proceeding further until D terminates a bit later.)
>>>>
>>>> Even though I put the two traces side-by-side for PO, he still
>>>> insists the "behaviour is different". Well, perhaps he just means
>>>> that the H simulation was abandonned whereas directly executed D(D)
>>>> proceeded further and eventually terminated? If so, then /so what/?
>>>> I think his problem here is nothing to do with /simulations/ not
>>>> reaching whatever line of code, but more the /reason/ that his H
>>>> aborted - it matched his (unsound) non-halting pattern, and he just
>>>> really really really really believes that pattern is sound.
>>>>
>>>> So now he needs to account for two "verified facts": 1) D(D)
>>>> computation never halts (/his unsound pattern matched!/) 2) D(D)
>>>> computation halts when run directly. That forces him to claim there
>>>> are two different behaviours [/beyond/ the simple truncation of the
>>>> aborted trace] for the one computation, and to come up with some
>>>> Words to justify that position (like "pathological self reference",
>>>> subjective questions) and then More Words to say that his other
>>>> Words are "the true meaning of halting" etc. etc. All nonsense
>>>> flowing from not being able to accept his rule is just wrong.
>>>>
>>>>
>>>> Mike.
>>>>
>>>
>>> The last time I remember him actually trying to answer, the
>>> difference was that the order of who started mattered, because D(D)
>>> calling H(D,D) meant that the H(D,D) that was called doesn't get
>>> stuck in the loop, but recognizes the loop and gets out, while when
>>> H(D,D) simulated D(D) and that first H(D,D) sees that the simulated
>>> H(D,D) would just get into a loop, that incorrect decision becomes
>>> the actual behavior of that simulated H(D,D).
>>>
>>> So it is always the first H(D,D) that returns, and the second one
>>> doesn't, which just proes that is can't be a pure function, or that
>>> rule doesn't apply to functions whose simulation has been aborted.
>>>
>>> Of course he also think that aborting th simulation mean that hte
>>> machine being simulate had its plug pulled at that point, so it isn't
>>> proper to look at the direct execution after that,
>>>
>>> He clearly doesn't seem to understand how these sorts of machines work.
>>
>> DD(DD) is just like infinite recursion that gets terminated at
>> its second recursive call. DD(DD) halts only because HH(DD,DD)
>> correctly determines that its input DOES NOT HALT.
>
> Except a potentially infinite loop that has code that breaks out of that
> loop will halt.
>
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its input D
until H correctly determines that its simulated D would never
stop running unless aborted then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words10/13/2022>
No you are wrong.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-08 10:05 -0400 |
| Subject | Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis |
| Message-ID | <v41oee$3cg3t$20@i2pn2.org> |
| In reply to | #106674 |
On 6/8/24 9:43 AM, olcott wrote:
> On 6/8/2024 8:03 AM, Richard Damon wrote:
>> On 6/7/24 11:36 PM, olcott wrote:
>>> On 6/7/2024 10:03 PM, Richard Damon wrote:
>>>> On 6/7/24 10:43 PM, Mike Terry wrote:
>>>>> On 07/06/2024 17:34, joes wrote:
>>>>>> Am Fri, 07 Jun 2024 10:40:37 -0500 schrieb olcott:
>>>>>>> On 6/7/2024 10:32 AM, joes wrote:
>>>>>>>> Am Fri, 07 Jun 2024 10:20:09 -0500 schrieb olcott:
>>>>>>>>> On 6/7/2024 10:09 AM, Python wrote:
>>>>>>>>>> Le 07/06/2024 à 17:05, olcott a écrit :
>>>>>>>>>>> On 6/7/2024 9:55 AM, Python wrote:
>>>>>>>>>>>> Le 07/06/2024 à 16:47, olcott a écrit :
>>>>>>
>>>>>>>>>>>>> The issue here is that I proved that DD correctly simulated
>>>>>>>>>>>>> by HH
>>>>>>>>>>>>> has different behavior than the directly executed DD(DD) and
>>>>>>>>>>>>> everyone's "rebuttal" to this proof is to simply ignore it.
>>>>>>>>>>> When you actually try to form a rebuttal of the above you
>>>>>>>>>>> will see
>>>>>>>>>>> that I am correct. So far everyone simply ignores the proof
>>>>>>>>>>> that I
>>>>>>>>>>> am correct as their only rebuttal.
>>>>>>>>> A {correct simulation} means that each instruction of the above
>>>>>>>>> x86
>>>>>>>>> machine language of DD is correctly simulated by HH and
>>>>>>>>> simulated in
>>>>>>>>> the correct order.
>>>>>>>> And to the end. Thus it can't behave differently than direct
>>>>>>>> execution.
>>>>>>> You must not be very good at programming if you believe that
>>>>>>> Infinite_Recursion must be simulated "to the end"
>>>>>> As I said before, if there is no end the simulation can't end either.
>>>>>
>>>>> PO chooses to leave his terminology ambiguous, so we have 1000 post
>>>>> threads perpetuated by little more than verbal misunderstandings.
>>>>>
>>>>> All PO's "simulating halt deciders" (SHD) are actually "partial
>>>>> simulating partial halt deciders":
>>>>> They partially simulate their input computation, while monitoring
>>>>> the simulation state for patterns which *PO* just believes (without
>>>>> proof) indicate non-halting. When such a pattern is detected, the
>>>>> SHD abandons its simulating activity ["aborts" its simulation], and
>>>>> returns nonhalting. Also, PO does not claim that his SHDs decide
>>>>> all inputs correctly - or even that they halt for all inputs (which
>>>>> a decider must). He is really just interested in the H(D,D) case.
>>>>>
>>>>> PO has a couple of such rules/patterns, and at least one of them is
>>>>> sound: the "tight loop" pattern. If an input (P,I) contains a
>>>>> tight loop (like "LOOP: goto LOOP"), and assuming PO has coded the
>>>>> rule correctly, his H/HH will detect the tight loop while
>>>>> simulating the code and correctly return non-halting. In this
>>>>> scenario we have a non-terminating computation, but PO's /partial/
>>>>> simulation obviously ends through aborting the target. THERE'S
>>>>> NOTHING WRONG WITH THAT. If someone wants to claim "that's not
>>>>> valid simulation" then right or wrong it's nothing more than a
>>>>> disagreement over use of terminology, and nothing is achieved by that.
>>>>>
>>>>> PO also has at least one /unsound/ rule: his "infinite recursive
>>>>> simulation" rule. That rule matches computations that in fact
>>>>> halt. Despite PO's colourful language like "...until H 'sees that
>>>>> the simulation will never terminate unless blah blah'" and "...DD
>>>>> 'specifies infinite recursion to HH'" and so on, the truth is
>>>>> simply that his H is applying an unsound rule, which leads to it
>>>>> deciding incorrectly.)
>>>>>
>>>>> And all the stuff about "correct simulations of DD by HH never
>>>>> reaching line nn" might be correct if suitably interpreted (as
>>>>> /partial simulations/ not reaching a simulated halt state, rather
>>>>> than the /actual computation/ being examined), but its all
>>>>> logically irrelevent having little to do with actual termination of
>>>>> a given computation.
>>>>>
>>>>> What makes the SHD work or not work is the matching of rules
>>>>> (patterns detected in the simulated computation states) that the
>>>>> SHD uses to trigger an abort. If a /sound/ rule matches, the SHD
>>>>> will decide correctly. If an /unsound/ rule matches it may decide
>>>>> incorrectly (as with PO's H(D,D)), or in other situations it might
>>>>> be correct "by fluke".
>>>>>
>>>>> If PO's H used only sound rules, it would not decide input (D,D)
>>>>> incorrectly - but unfortunately neither would it decide correctly -
>>>>> it would never terminate /for that input/. (I find that kind of
>>>>> neat...)
>>>>>
>>>>>>
>>>>>>>>> Anyone claiming that HH should report on the behavior of the
>>>>>>>>> directly
>>>>>>>>> executed DD(DD) is requiring a violation of the above
>>>>>>>>> definition of
>>>>>>>>> correct simulation.
>>>>>>>> But those are the same. How does simulating something change it?
>>>>>>> It seems to boil down to you just don't know enough about
>>>>>>> programming
>>>>>>> otherwise it would occur to you that there cannot possibly exist any
>>>>>>> correct rebuttal to the following:
>>>>>> Answer the question. Why should the simulation differ from direct
>>>>>> execution?
>>>>>
>>>>> [Let's assume code is properly restricted to exclude the
>>>>> complications of "cheating" in PO's x86utm environment through use
>>>>> of mutable static variables and the like.]
>>>>>
>>>>> Obviously they wouldn't, except in so far as "partial simulation"
>>>>> differs from "full simulation". I.e. all steps will match
>>>>> precisely, up to the point where the partial simulation is abandoned.
>>>>>
>>>>> And in PO's H(D,D) vs D(D) example that is exactly what the traces
>>>>> show: The simulated and direct traces match exactly, right up to
>>>>> the point where H aborts the simulation. (The full computation
>>>>> steps of D(D) then proceeding further until D terminates a bit later.)
>>>>>
>>>>> Even though I put the two traces side-by-side for PO, he still
>>>>> insists the "behaviour is different". Well, perhaps he just means
>>>>> that the H simulation was abandonned whereas directly executed D(D)
>>>>> proceeded further and eventually terminated? If so, then /so
>>>>> what/? I think his problem here is nothing to do with /simulations/
>>>>> not reaching whatever line of code, but more the /reason/ that his
>>>>> H aborted - it matched his (unsound) non-halting pattern, and he
>>>>> just really really really really believes that pattern is sound.
>>>>>
>>>>> So now he needs to account for two "verified facts": 1) D(D)
>>>>> computation never halts (/his unsound pattern matched!/) 2) D(D)
>>>>> computation halts when run directly. That forces him to claim
>>>>> there are two different behaviours [/beyond/ the simple truncation
>>>>> of the aborted trace] for the one computation, and to come up with
>>>>> some Words to justify that position (like "pathological self
>>>>> reference", subjective questions) and then More Words to say that
>>>>> his other Words are "the true meaning of halting" etc. etc. All
>>>>> nonsense flowing from not being able to accept his rule is just wrong.
>>>>>
>>>>>
>>>>> Mike.
>>>>>
>>>>
>>>> The last time I remember him actually trying to answer, the
>>>> difference was that the order of who started mattered, because D(D)
>>>> calling H(D,D) meant that the H(D,D) that was called doesn't get
>>>> stuck in the loop, but recognizes the loop and gets out, while when
>>>> H(D,D) simulated D(D) and that first H(D,D) sees that the simulated
>>>> H(D,D) would just get into a loop, that incorrect decision becomes
>>>> the actual behavior of that simulated H(D,D).
>>>>
>>>> So it is always the first H(D,D) that returns, and the second one
>>>> doesn't, which just proes that is can't be a pure function, or that
>>>> rule doesn't apply to functions whose simulation has been aborted.
>>>>
>>>> Of course he also think that aborting th simulation mean that hte
>>>> machine being simulate had its plug pulled at that point, so it
>>>> isn't proper to look at the direct execution after that,
>>>>
>>>> He clearly doesn't seem to understand how these sorts of machines work.
>>>
>>> DD(DD) is just like infinite recursion that gets terminated at
>>> its second recursive call. DD(DD) halts only because HH(DD,DD)
>>> correctly determines that its input DOES NOT HALT.
>>
>> Except a potentially infinite loop that has code that breaks out of
>> that loop will halt.
>>
>
> <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
> If simulating halt decider H correctly simulates its input D
> until H correctly determines that its simulated D would never
> stop running unless aborted then
>
> H can abort its simulation of D and correctly report that D
> specifies a non-halting sequence of configurations.
> </MIT Professor Sipser agreed to ONLY these verbatim words10/13/2022>
>
> No you are wrong.
>
Nope. Try to PROVE it.
of course, you don't understand how to do a proof, so that is an
impossible chalange for you.
Remember, you need to use Professor Sipser's defiition for "Correctly
Simulated", or you can't use his words.
If you think you can use your non-canonical definition for his words,
then we can reinterprete yours to use the canonical definition, and thus
your conclusiom is just proven incorrect.
[toc] | [prev] | [next] | [standalone]
| From | Mikko <mikko.levanto@iki.fi> |
|---|---|
| Date | 2024-06-09 11:15 +0300 |
| Subject | Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis |
| Message-ID | <v43oau$3b12n$1@dont-email.me> |
| In reply to | #106674 |
On 2024-06-08 13:43:17 +0000, olcott said:
> On 6/8/2024 8:03 AM, Richard Damon wrote:
>> On 6/7/24 11:36 PM, olcott wrote:
>>> On 6/7/2024 10:03 PM, Richard Damon wrote:
>>>> On 6/7/24 10:43 PM, Mike Terry wrote:
>>>>> On 07/06/2024 17:34, joes wrote:
>>>>>> Am Fri, 07 Jun 2024 10:40:37 -0500 schrieb olcott:
>>>>>>> On 6/7/2024 10:32 AM, joes wrote:
>>>>>>>> Am Fri, 07 Jun 2024 10:20:09 -0500 schrieb olcott:
>>>>>>>>> On 6/7/2024 10:09 AM, Python wrote:
>>>>>>>>>> Le 07/06/2024 à 17:05, olcott a écrit :
>>>>>>>>>>> On 6/7/2024 9:55 AM, Python wrote:
>>>>>>>>>>>> Le 07/06/2024 à 16:47, olcott a écrit :
>>>>>>
>>>>>>>>>>>>> The issue here is that I proved that DD correctly simulated by HH
>>>>>>>>>>>>> has different behavior than the directly executed DD(DD) and
>>>>>>>>>>>>> everyone's "rebuttal" to this proof is to simply ignore it.
>>>>>>>>>>> When you actually try to form a rebuttal of the above you will see
>>>>>>>>>>> that I am correct. So far everyone simply ignores the proof that I
>>>>>>>>>>> am correct as their only rebuttal.
>>>>>>>>> A {correct simulation} means that each instruction of the above x86
>>>>>>>>> machine language of DD is correctly simulated by HH and simulated in
>>>>>>>>> the correct order.
>>>>>>>> And to the end. Thus it can't behave differently than direct execution.
>>>>>>> You must not be very good at programming if you believe that
>>>>>>> Infinite_Recursion must be simulated "to the end"
>>>>>> As I said before, if there is no end the simulation can't end either.
>>>>>
>>>>> PO chooses to leave his terminology ambiguous, so we have 1000 post
>>>>> threads perpetuated by little more than verbal misunderstandings.
>>>>>
>>>>> All PO's "simulating halt deciders" (SHD) are actually "partial
>>>>> simulating partial halt deciders":
>>>>> They partially simulate their input computation, while monitoring the
>>>>> simulation state for patterns which *PO* just believes (without proof)
>>>>> indicate non-halting. When such a pattern is detected, the SHD
>>>>> abandons its simulating activity ["aborts" its simulation], and returns
>>>>> nonhalting. Also, PO does not claim that his SHDs decide all inputs
>>>>> correctly - or even that they halt for all inputs (which a decider
>>>>> must). He is really just interested in the H(D,D) case.
>>>>>
>>>>> PO has a couple of such rules/patterns, and at least one of them is
>>>>> sound: the "tight loop" pattern. If an input (P,I) contains a tight
>>>>> loop (like "LOOP: goto LOOP"), and assuming PO has coded the rule
>>>>> correctly, his H/HH will detect the tight loop while simulating the
>>>>> code and correctly return non-halting. In this scenario we have a
>>>>> non-terminating computation, but PO's /partial/ simulation obviously
>>>>> ends through aborting the target. THERE'S NOTHING WRONG WITH THAT. If
>>>>> someone wants to claim "that's not valid simulation" then right or
>>>>> wrong it's nothing more than a disagreement over use of terminology,
>>>>> and nothing is achieved by that.
>>>>>
>>>>> PO also has at least one /unsound/ rule: his "infinite recursive
>>>>> simulation" rule. That rule matches computations that in fact halt.
>>>>> Despite PO's colourful language like "...until H 'sees that the
>>>>> simulation will never terminate unless blah blah'" and "...DD
>>>>> 'specifies infinite recursion to HH'" and so on, the truth is simply
>>>>> that his H is applying an unsound rule, which leads to it deciding
>>>>> incorrectly.)
>>>>>
>>>>> And all the stuff about "correct simulations of DD by HH never reaching
>>>>> line nn" might be correct if suitably interpreted (as /partial
>>>>> simulations/ not reaching a simulated halt state, rather than the
>>>>> /actual computation/ being examined), but its all logically irrelevent
>>>>> having little to do with actual termination of a given computation.
>>>>>
>>>>> What makes the SHD work or not work is the matching of rules (patterns
>>>>> detected in the simulated computation states) that the SHD uses to
>>>>> trigger an abort. If a /sound/ rule matches, the SHD will decide
>>>>> correctly. If an /unsound/ rule matches it may decide incorrectly (as
>>>>> with PO's H(D,D)), or in other situations it might be correct "by
>>>>> fluke".
>>>>>
>>>>> If PO's H used only sound rules, it would not decide input (D,D)
>>>>> incorrectly - but unfortunately neither would it decide correctly - it
>>>>> would never terminate /for that input/. (I find that kind of neat...)
>>>>>
>>>>>>
>>>>>>>>> Anyone claiming that HH should report on the behavior of the directly
>>>>>>>>> executed DD(DD) is requiring a violation of the above definition of
>>>>>>>>> correct simulation.
>>>>>>>> But those are the same. How does simulating something change it?
>>>>>>> It seems to boil down to you just don't know enough about programming
>>>>>>> otherwise it would occur to you that there cannot possibly exist any
>>>>>>> correct rebuttal to the following:
>>>>>> Answer the question. Why should the simulation differ from direct
>>>>>> execution?
>>>>>
>>>>> [Let's assume code is properly restricted to exclude the complications
>>>>> of "cheating" in PO's x86utm environment through use of mutable static
>>>>> variables and the like.]
>>>>>
>>>>> Obviously they wouldn't, except in so far as "partial simulation"
>>>>> differs from "full simulation". I.e. all steps will match precisely, up
>>>>> to the point where the partial simulation is abandoned.
>>>>>
>>>>> And in PO's H(D,D) vs D(D) example that is exactly what the traces
>>>>> show: The simulated and direct traces match exactly, right up to the
>>>>> point where H aborts the simulation. (The full computation steps of
>>>>> D(D) then proceeding further until D terminates a bit later.)
>>>>>
>>>>> Even though I put the two traces side-by-side for PO, he still insists
>>>>> the "behaviour is different". Well, perhaps he just means that the H
>>>>> simulation was abandonned whereas directly executed D(D) proceeded
>>>>> further and eventually terminated? If so, then /so what/? I think his
>>>>> problem here is nothing to do with /simulations/ not reaching whatever
>>>>> line of code, but more the /reason/ that his H aborted - it matched his
>>>>> (unsound) non-halting pattern, and he just really really really really
>>>>> believes that pattern is sound.
>>>>>
>>>>> So now he needs to account for two "verified facts": 1) D(D)
>>>>> computation never halts (/his unsound pattern matched!/) 2) D(D)
>>>>> computation halts when run directly. That forces him to claim there
>>>>> are two different behaviours [/beyond/ the simple truncation of the
>>>>> aborted trace] for the one computation, and to come up with some Words
>>>>> to justify that position (like "pathological self reference",
>>>>> subjective questions) and then More Words to say that his other Words
>>>>> are "the true meaning of halting" etc. etc. All nonsense flowing from
>>>>> not being able to accept his rule is just wrong.
>>>>>
>>>>>
>>>>> Mike.
>>>>>
>>>>
>>>> The last time I remember him actually trying to answer, the difference
>>>> was that the order of who started mattered, because D(D) calling H(D,D)
>>>> meant that the H(D,D) that was called doesn't get stuck in the loop,
>>>> but recognizes the loop and gets out, while when H(D,D) simulated D(D)
>>>> and that first H(D,D) sees that the simulated H(D,D) would just get
>>>> into a loop, that incorrect decision becomes the actual behavior of
>>>> that simulated H(D,D).
>>>>
>>>> So it is always the first H(D,D) that returns, and the second one
>>>> doesn't, which just proes that is can't be a pure function, or that
>>>> rule doesn't apply to functions whose simulation has been aborted.
>>>>
>>>> Of course he also think that aborting th simulation mean that hte
>>>> machine being simulate had its plug pulled at that point, so it isn't
>>>> proper to look at the direct execution after that,
>>>>
>>>> He clearly doesn't seem to understand how these sorts of machines work.
>>>
>>> DD(DD) is just like infinite recursion that gets terminated at
>>> its second recursive call. DD(DD) halts only because HH(DD,DD)
>>> correctly determines that its input DOES NOT HALT.
>>
>> Except a potentially infinite loop that has code that breaks out of
>> that loop will halt.
>>
>
> <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
> If simulating halt decider H correctly simulates its input D
> until H correctly determines that its simulated D would never
> stop running unless aborted then
>
> H can abort its simulation of D and correctly report that D
> specifies a non-halting sequence of configurations.
> </MIT Professor Sipser agreed to ONLY these verbatim words10/13/2022>
>
> No you are wrong.
It does not make much sense to say "you are wrong" without saying
about what and what is right instead.
Besides, there should be either a comma after "No" or the word "not"
after "are". We may guess from context which one you meant but a
guess is only a guess.
--
Mikko
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-09 08:45 -0500 |
| Subject | Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis |
| Message-ID | <v44blp$3harn$2@dont-email.me> |
| In reply to | #106759 |
On 6/9/2024 3:15 AM, Mikko wrote:
> On 2024-06-08 13:43:17 +0000, olcott said:
>
>> On 6/8/2024 8:03 AM, Richard Damon wrote:
>>> On 6/7/24 11:36 PM, olcott wrote:
>>>>
>>>> DD(DD) is just like infinite recursion that gets terminated at
>>>> its second recursive call. DD(DD) halts only because HH(DD,DD)
>>>> correctly determines that its input DOES NOT HALT.
>>>
>>> Except a potentially infinite loop that has code that breaks out of
>>> that loop will halt.
>>>
>>
>> <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>> If simulating halt decider H correctly simulates its input D
>> until H correctly determines that its simulated D would never
>> stop running unless aborted then
>>
>> H can abort its simulation of D and correctly report that D
>> specifies a non-halting sequence of configurations.
>> </MIT Professor Sipser agreed to ONLY these verbatim words10/13/2022>
>>
>> No you are wrong.
>
> It does not make much sense to say "you are wrong" without saying
> about what and what is right instead.
>
> Besides, there should be either a comma after "No" or the word "not"
> after "are". We may guess from context which one you meant but a
> guess is only a guess.
>
*It is no mere loop it is isomorphic to this*
typedef void (*ptr)(); // pointer to void function
void HHH(ptr P, ptr I)
{
P(I);
return;
}
void DDD(int (*x)())
{
HHH(x, x);
return;
}
int main()
{
HHH(DDD,DDD);
}
In the above Neither DDD nor HHH ever reach their own return
statement thus never halt.
When HHH is a simulating halt decider then HHH sees that
DDD correctly simulated by HHH cannot possibly reach its
own return statement, AKA
simulating halt decider HHH correctly simulates its input DDD
until HHH correctly determines that its simulated DDD would never
stop running unless aborted
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-09 14:08 -0400 |
| Subject | Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis |
| Message-ID | <v44r30$3egp9$3@i2pn2.org> |
| In reply to | #106770 |
On 6/9/24 9:45 AM, olcott wrote:
> On 6/9/2024 3:15 AM, Mikko wrote:
>> On 2024-06-08 13:43:17 +0000, olcott said:
>>
>>> On 6/8/2024 8:03 AM, Richard Damon wrote:
>>>> On 6/7/24 11:36 PM, olcott wrote:
>>>>>
>>>>> DD(DD) is just like infinite recursion that gets terminated at
>>>>> its second recursive call. DD(DD) halts only because HH(DD,DD)
>>>>> correctly determines that its input DOES NOT HALT.
>>>>
>>>> Except a potentially infinite loop that has code that breaks out of
>>>> that loop will halt.
>>>>
>>>
>>> <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>> If simulating halt decider H correctly simulates its input D
>>> until H correctly determines that its simulated D would never
>>> stop running unless aborted then
>>>
>>> H can abort its simulation of D and correctly report that D
>>> specifies a non-halting sequence of configurations.
>>> </MIT Professor Sipser agreed to ONLY these verbatim words10/13/2022>
>>>
>>> No you are wrong.
>>
>> It does not make much sense to say "you are wrong" without saying
>> about what and what is right instead.
>>
>> Besides, there should be either a comma after "No" or the word "not"
>> after "are". We may guess from context which one you meant but a
>> guess is only a guess.
>>
>
> *It is no mere loop it is isomorphic to this*
>
> typedef void (*ptr)(); // pointer to void function
>
> void HHH(ptr P, ptr I)
> {
> P(I);
> return;
> }
>
> void DDD(int (*x)())
> {
> HHH(x, x);
> return;
> }
>
> int main()
> {
> HHH(DDD,DDD);
> }
>
> In the above Neither DDD nor HHH ever reach their own return
> statement thus never halt.
>
> When HHH is a simulating halt decider then HHH sees that
> DDD correctly simulated by HHH cannot possibly reach its
> own return statement, AKA
>
> simulating halt decider HHH correctly simulates its input DDD
> until HHH correctly determines that its simulated DDD would never
> stop running unless aborted
>
Except if you change the input to call a different "decider" you have a
different input, so it can behave differently.
You can only decide on actual program intances, not just the "template",
as the template doesn't have a behavior by itself.
I will note that your arguments STILL think that a call to a specific
address doesn't need to have the simulation continue at that address,
and it can reach an address again that is never actually reached.
Both of these are considered "Correct" to you even in violation of your
own definitions.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-07 22:16 -0500 |
| Subject | Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis |
| Message-ID | <v40if6$2elkd$3@dont-email.me> |
| In reply to | #106617 |
On 6/7/2024 9:43 PM, Mike Terry wrote:
> On 07/06/2024 17:34, joes wrote:
>> Am Fri, 07 Jun 2024 10:40:37 -0500 schrieb olcott:
>>> On 6/7/2024 10:32 AM, joes wrote:
>>>> Am Fri, 07 Jun 2024 10:20:09 -0500 schrieb olcott:
>>>>> On 6/7/2024 10:09 AM, Python wrote:
>>>>>> Le 07/06/2024 à 17:05, olcott a écrit :
>>>>>>> On 6/7/2024 9:55 AM, Python wrote:
>>>>>>>> Le 07/06/2024 à 16:47, olcott a écrit :
>>
>>>>>>>>> The issue here is that I proved that DD correctly simulated by HH
>>>>>>>>> has different behavior than the directly executed DD(DD) and
>>>>>>>>> everyone's "rebuttal" to this proof is to simply ignore it.
>>>>>>> When you actually try to form a rebuttal of the above you will see
>>>>>>> that I am correct. So far everyone simply ignores the proof that I
>>>>>>> am correct as their only rebuttal.
>>>>> A {correct simulation} means that each instruction of the above x86
>>>>> machine language of DD is correctly simulated by HH and simulated in
>>>>> the correct order.
>>>> And to the end. Thus it can't behave differently than direct execution.
>>> You must not be very good at programming if you believe that
>>> Infinite_Recursion must be simulated "to the end"
>> As I said before, if there is no end the simulation can't end either.
>
> PO chooses to leave his terminology ambiguous, so we have 1000 post
> threads perpetuated by little more than verbal misunderstandings.
>
> All PO's "simulating halt deciders" (SHD) are actually "partial
> simulating partial halt deciders":
> They partially simulate their input computation, while monitoring the
> simulation state for patterns which *PO* just believes (without proof)
> indicate non-halting. When such a pattern is detected, the SHD abandons
> its simulating activity ["aborts" its simulation], and returns
> nonhalting. Also, PO does not claim that his SHDs decide all inputs
> correctly - or even that they halt for all inputs (which a decider
> must). He is really just interested in the H(D,D) case.
>
> PO has a couple of such rules/patterns, and at least one of them is
> sound: the "tight loop" pattern. If an input (P,I) contains a tight
> loop (like "LOOP: goto LOOP"), and assuming PO has coded the rule
> correctly, his H/HH will detect the tight loop while simulating the code
> and correctly return non-halting. In this scenario we have a
> non-terminating computation, but PO's /partial/ simulation obviously
> ends through aborting the target. THERE'S NOTHING WRONG WITH THAT. If
> someone wants to claim "that's not valid simulation" then right or wrong
> it's nothing more than a disagreement over use of terminology, and
> nothing is achieved by that.
>
> PO also has at least one /unsound/ rule: his "infinite recursive
> simulation" rule. That rule matches computations that in fact halt.
The a sequence of configurations stops running because some
aspect of it has been abnormally terminated does not mean that
this sequence halts.
Discussing this aspect is ridiculously too complex until after
you first understand that DD is correctly simulated by HH.
We wasted three years on this because no one ever bothered
to see that I have conclusively proved that DD is correctly
simulated by HH at the x86 machine code level.
> Despite PO's colourful language like "...until H 'sees that the
> simulation will never terminate unless blah blah'" and "...DD 'specifies
> infinite recursion to HH'" and so on, the truth is simply that his H is
> applying an unsound rule, which leads to it deciding incorrectly.)
>
> And all the stuff about "correct simulations of DD by HH never reaching
> line nn" might be correct if suitably interpreted (as /partial
> simulations/ not reaching a simulated halt state, rather than the
> /actual computation/ being examined), but its all logically irrelevent
> having little to do with actual termination of a given computation.
>
> What makes the SHD work or not work is the matching of rules (patterns
> detected in the simulated computation states) that the SHD uses to
> trigger an abort. If a /sound/ rule matches, the SHD will decide
> correctly. If an /unsound/ rule matches it may decide incorrectly (as
> with PO's H(D,D)), or in other situations it might be correct "by fluke".
>
> If PO's H used only sound rules, it would not decide input (D,D)
> incorrectly - but unfortunately neither would it decide correctly - it
> would never terminate /for that input/. (I find that kind of neat...)
>
>>
>>>>> Anyone claiming that HH should report on the behavior of the directly
>>>>> executed DD(DD) is requiring a violation of the above definition of
>>>>> correct simulation.
>>>> But those are the same. How does simulating something change it?
>>> It seems to boil down to you just don't know enough about programming
>>> otherwise it would occur to you that there cannot possibly exist any
>>> correct rebuttal to the following:
>> Answer the question. Why should the simulation differ from direct
>> execution?
>
> [Let's assume code is properly restricted to exclude the complications
> of "cheating" in PO's x86utm environment through use of mutable static
> variables and the like.]
>
> Obviously they wouldn't, except in so far as "partial simulation"
> differs from "full simulation". I.e. all steps will match precisely, up
> to the point where the partial simulation is abandoned.
>
> And in PO's H(D,D) vs D(D) example that is exactly what the traces
> show: The simulated and direct traces match exactly, right up to the
> point where H aborts the simulation. (The full computation steps of
> D(D) then proceeding further until D terminates a bit later.)
>
> Even though I put the two traces side-by-side for PO, he still insists
> the "behaviour is different". Well, perhaps he just means that the H
> simulation was abandonned whereas directly executed D(D) proceeded
> further and eventually terminated? If so, then /so what/? I think his
> problem here is nothing to do with /simulations/ not reaching whatever
> line of code, but more the /reason/ that his H aborted - it matched his
> (unsound) non-halting pattern, and he just really really really really
> believes that pattern is sound.
>
I have proven that DD correctly simulated by HH cannot possibly
stop unless aborted thus meeting this criteria:
Only these verbatim words were agreed to by MIT Professor Michael Sipser
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its input D
until H correctly determines that its simulated D would never
stop running unless aborted then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words10/13/2022>
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
> I don't think that is the shell game. PO really /has/ an H
> (it's trivial to do for this one case) that correctly determines
> that P(P) *would* never stop running *unless* aborted.
> So now he needs to account for two "verified facts": 1) D(D)
> computation never halts (/his unsound pattern matched!/) 2) D(D)
> computation halts when run directly.
DD correctly simulated by HH never halts.
Directly executed DD(DD) is not the behavior
of the input that HH held accountable for.
I incorporate by reference
(a) The x86 language
(b) The notion of an x86 emulator
(c) I provide this complete function
void DDD(int (*x)())
{
HH(x, x);
}
_DDD()
[00001de2] 55 push ebp
[00001de3] 8bec mov ebp,esp
[00001de5] 8b4508 mov eax,[ebp+08]
[00001de8] 50 push eax ; push DD
[00001de9] 8b4d08 mov ecx,[ebp+08]
[00001dec] 51 push ecx ; push DD
[00001ded] e890f5ffff call 00001382 ; call HH
[00001df2] 83c408 add esp,+08
[00001df5] 5d pop ebp
[00001df6] c3 ret
Size in bytes:(0021) [00001df6]
Then I state that No DDD correctly emulated by any
x86 emulator H can possibly reach its own [00001df6]
instruction.
> That forces him to claim there are
> two different behaviours [/beyond/ the simple truncation of the aborted
> trace] for the one computation, and to come up with some Words to
> justify that position (like "pathological self reference", subjective
> questions) and then More Words to say that his other Words are "the true
> meaning of halting" etc. etc. All nonsense flowing from not being able
> to accept his rule is just wrong.
>
>
> Mike.
>
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-08 09:03 -0400 |
| Subject | Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis |
| Message-ID | <v41kr4$3cg3t$9@i2pn2.org> |
| In reply to | #106624 |
On 6/7/24 11:16 PM, olcott wrote:
> On 6/7/2024 9:43 PM, Mike Terry wrote:
>> On 07/06/2024 17:34, joes wrote:
>>> Am Fri, 07 Jun 2024 10:40:37 -0500 schrieb olcott:
>>>> On 6/7/2024 10:32 AM, joes wrote:
>>>>> Am Fri, 07 Jun 2024 10:20:09 -0500 schrieb olcott:
>>>>>> On 6/7/2024 10:09 AM, Python wrote:
>>>>>>> Le 07/06/2024 à 17:05, olcott a écrit :
>>>>>>>> On 6/7/2024 9:55 AM, Python wrote:
>>>>>>>>> Le 07/06/2024 à 16:47, olcott a écrit :
>>>
>>>>>>>>>> The issue here is that I proved that DD correctly simulated by HH
>>>>>>>>>> has different behavior than the directly executed DD(DD) and
>>>>>>>>>> everyone's "rebuttal" to this proof is to simply ignore it.
>>>>>>>> When you actually try to form a rebuttal of the above you will see
>>>>>>>> that I am correct. So far everyone simply ignores the proof that I
>>>>>>>> am correct as their only rebuttal.
>>>>>> A {correct simulation} means that each instruction of the above x86
>>>>>> machine language of DD is correctly simulated by HH and simulated in
>>>>>> the correct order.
>>>>> And to the end. Thus it can't behave differently than direct
>>>>> execution.
>>>> You must not be very good at programming if you believe that
>>>> Infinite_Recursion must be simulated "to the end"
>>> As I said before, if there is no end the simulation can't end either.
>>
>> PO chooses to leave his terminology ambiguous, so we have 1000 post
>> threads perpetuated by little more than verbal misunderstandings.
>>
>> All PO's "simulating halt deciders" (SHD) are actually "partial
>> simulating partial halt deciders":
>> They partially simulate their input computation, while monitoring the
>> simulation state for patterns which *PO* just believes (without proof)
>> indicate non-halting. When such a pattern is detected, the SHD
>> abandons its simulating activity ["aborts" its simulation], and
>> returns nonhalting. Also, PO does not claim that his SHDs decide all
>> inputs correctly - or even that they halt for all inputs (which a
>> decider must). He is really just interested in the H(D,D) case.
>>
>> PO has a couple of such rules/patterns, and at least one of them is
>> sound: the "tight loop" pattern. If an input (P,I) contains a tight
>> loop (like "LOOP: goto LOOP"), and assuming PO has coded the rule
>> correctly, his H/HH will detect the tight loop while simulating the
>> code and correctly return non-halting. In this scenario we have a
>> non-terminating computation, but PO's /partial/ simulation obviously
>> ends through aborting the target. THERE'S NOTHING WRONG WITH THAT.
>> If someone wants to claim "that's not valid simulation" then right or
>> wrong it's nothing more than a disagreement over use of terminology,
>> and nothing is achieved by that.
>>
>> PO also has at least one /unsound/ rule: his "infinite recursive
>> simulation" rule. That rule matches computations that in fact halt.
>
> The a sequence of configurations stops running because some
> aspect of it has been abnormally terminated does not mean that
> this sequence halts.
>
> Discussing this aspect is ridiculously too complex until after
> you first understand that DD is correctly simulated by HH.
>
> We wasted three years on this because no one ever bothered
> to see that I have conclusively proved that DD is correctly
> simulated by HH at the x86 machine code level.
>
>> Despite PO's colourful language like "...until H 'sees that the
>> simulation will never terminate unless blah blah'" and "...DD
>> 'specifies infinite recursion to HH'" and so on, the truth is simply
>> that his H is applying an unsound rule, which leads to it deciding
>> incorrectly.)
>>
>> And all the stuff about "correct simulations of DD by HH never
>> reaching line nn" might be correct if suitably interpreted (as
>> /partial simulations/ not reaching a simulated halt state, rather than
>> the /actual computation/ being examined), but its all logically
>> irrelevent having little to do with actual termination of a given
>> computation.
>>
>> What makes the SHD work or not work is the matching of rules (patterns
>> detected in the simulated computation states) that the SHD uses to
>> trigger an abort. If a /sound/ rule matches, the SHD will decide
>> correctly. If an /unsound/ rule matches it may decide incorrectly (as
>> with PO's H(D,D)), or in other situations it might be correct "by fluke".
>>
>> If PO's H used only sound rules, it would not decide input (D,D)
>> incorrectly - but unfortunately neither would it decide correctly - it
>> would never terminate /for that input/. (I find that kind of neat...)
>>
>>>
>>>>>> Anyone claiming that HH should report on the behavior of the directly
>>>>>> executed DD(DD) is requiring a violation of the above definition of
>>>>>> correct simulation.
>>>>> But those are the same. How does simulating something change it?
>>>> It seems to boil down to you just don't know enough about programming
>>>> otherwise it would occur to you that there cannot possibly exist any
>>>> correct rebuttal to the following:
>>> Answer the question. Why should the simulation differ from direct
>>> execution?
>>
>> [Let's assume code is properly restricted to exclude the complications
>> of "cheating" in PO's x86utm environment through use of mutable static
>> variables and the like.]
>>
>> Obviously they wouldn't, except in so far as "partial simulation"
>> differs from "full simulation". I.e. all steps will match precisely,
>> up to the point where the partial simulation is abandoned.
>>
>> And in PO's H(D,D) vs D(D) example that is exactly what the traces
>> show: The simulated and direct traces match exactly, right up to the
>> point where H aborts the simulation. (The full computation steps of
>> D(D) then proceeding further until D terminates a bit later.)
>>
>> Even though I put the two traces side-by-side for PO, he still insists
>> the "behaviour is different". Well, perhaps he just means that the H
>> simulation was abandonned whereas directly executed D(D) proceeded
>> further and eventually terminated? If so, then /so what/? I think
>> his problem here is nothing to do with /simulations/ not reaching
>> whatever line of code, but more the /reason/ that his H aborted - it
>> matched his (unsound) non-halting pattern, and he just really really
>> really really believes that pattern is sound.
>>
>
> I have proven that DD correctly simulated by HH cannot possibly
> stop unless aborted thus meeting this criteria:
No, you hve not, you have claimed and presented an argument. You have
not PROVEN anything. It seems you don't understand what a Formal Proof is.
>
> Only these verbatim words were agreed to by MIT Professor Michael Sipser
> <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
> If simulating halt decider H correctly simulates its input D
> until H correctly determines that its simulated D would never
> stop running unless aborted then
>
> H can abort its simulation of D and correctly report that D
> specifies a non-halting sequence of configurations.
> </MIT Professor Sipser agreed to ONLY these verbatim words10/13/2022>
Which is based on a DIFFERENT definition of "Correct Simulation" so its
assable to you. He means a complete simulation that doesn't stop until
it reaches a final state, which your H doesn't do (if it answer) nor
does it correcly determine that an actual correct simulation of THIS
input wouldn't halt.
Your arguement is based on thinking you are processing a template, as
opposed to a program, so the input changes when you hypothetically
change the HH processing THIS input, but the problem is NOT about
deciding on a template, but on a program, which is an instance of that
template based on a specific decider
>
> On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
> > I don't think that is the shell game. PO really /has/ an H
> > (it's trivial to do for this one case) that correctly determines
> > that P(P) *would* never stop running *unless* aborted.
>
>> So now he needs to account for two "verified facts": 1) D(D)
>> computation never halts (/his unsound pattern matched!/) 2) D(D)
>> computation halts when run directly.
>
> DD correctly simulated by HH never halts.
> Directly executed DD(DD) is not the behavior
> of the input that HH held accountable for.
But it is, if it is a Halt Decider. After all, the question a Halt
Decider is answering is:
Does the Machine/Input described by the input halt when run?
Which *IS* about the directly execute DD(DD) so that *IS* what it is
accountable for.
If you think it CAN'T do it, then you are just agreeing with the Halting
Theorem that it can't be done.
Note, the question is not can we come up with something sort of like
this that we can do, it is can we do this specific thing, that has a
desired usage.
>
> I incorporate by reference
> (a) The x86 language
> (b) The notion of an x86 emulator
>
> (c) I provide this complete function
So?
What do you do with those?
Remember, a proof builds the chain from the Truth makers to your
statement, explicitly showing the steps.
You never link from your "truths" to your conclusion.
And Proving that something doesn't happen is very hard, so claiming that
NO HH can do something needs to actually be proven and not just claimed
that since no one has found one it doesn't exist.
>
> void DDD(int (*x)())
> {
> HH(x, x);
> }
>
> _DDD()
> [00001de2] 55 push ebp
> [00001de3] 8bec mov ebp,esp
> [00001de5] 8b4508 mov eax,[ebp+08]
> [00001de8] 50 push eax ; push DD
> [00001de9] 8b4d08 mov ecx,[ebp+08]
> [00001dec] 51 push ecx ; push DD
> [00001ded] e890f5ffff call 00001382 ; call HH
> [00001df2] 83c408 add esp,+08
> [00001df5] 5d pop ebp
> [00001df6] c3 ret
> Size in bytes:(0021) [00001df6]
>
> Then I state that No DDD correctly emulated by any
> x86 emulator H can possibly reach its own [00001df6]
> instruction.
Which needs to be PROVEN, not just stated.
Remember, H isn't "Just a simulator" but is DEFINED to be a decider that
MUST return an answer.
So, your argument has it a contradiction in itself, telling you that you
have a bad assumption somewhere.
Perhaps you can prove that it is impossible for any simulator to
simulate to that point, but you also end up proving that behavior of DD
(which is what is being asked about) MUST get there if HH meets its
requirements. So, all you have done is proven that simulation can't be
an answer to the problem.
Which has been a well known fact for decades, which is why you don't see
much talk about them.
>
>
>> That forces him to claim there are two different behaviours [/beyond/
>> the simple truncation of the aborted trace] for the one computation,
>> and to come up with some Words to justify that position (like
>> "pathological self reference", subjective questions) and then More
>> Words to say that his other Words are "the true meaning of halting"
>> etc. etc. All nonsense flowing from not being able to accept his rule
>> is just wrong.
>>
>>
>> Mike.
>>
>
[toc] | [prev] | [next] | [standalone]
| From | Mikko <mikko.levanto@iki.fi> |
|---|---|
| Date | 2024-06-08 09:28 +0300 |
| Subject | Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis |
| Message-ID | <v40tlr$2gfvh$1@dont-email.me> |
| In reply to | #106617 |
On 2024-06-08 02:43:57 +0000, Mike Terry said:
> On 07/06/2024 17:34, joes wrote:
>> Am Fri, 07 Jun 2024 10:40:37 -0500 schrieb olcott:
>>> On 6/7/2024 10:32 AM, joes wrote:
>>>> Am Fri, 07 Jun 2024 10:20:09 -0500 schrieb olcott:
>>>>> On 6/7/2024 10:09 AM, Python wrote:
>>>>>> Le 07/06/2024 à 17:05, olcott a écrit :
>>>>>>> On 6/7/2024 9:55 AM, Python wrote:
>>>>>>>> Le 07/06/2024 à 16:47, olcott a écrit :
>>
>>>>>>>>> The issue here is that I proved that DD correctly simulated by HH
>>>>>>>>> has different behavior than the directly executed DD(DD) and
>>>>>>>>> everyone's "rebuttal" to this proof is to simply ignore it.
>>>>>>> When you actually try to form a rebuttal of the above you will see
>>>>>>> that I am correct. So far everyone simply ignores the proof that I
>>>>>>> am correct as their only rebuttal.
>>>>> A {correct simulation} means that each instruction of the above x86
>>>>> machine language of DD is correctly simulated by HH and simulated in
>>>>> the correct order.
>>>> And to the end. Thus it can't behave differently than direct execution.
>>> You must not be very good at programming if you believe that
>>> Infinite_Recursion must be simulated "to the end"
>> As I said before, if there is no end the simulation can't end either.
>
> PO chooses to leave his terminology ambiguous, so we have 1000 post
> threads perpetuated by little more than verbal misunderstandings.
Crackpots are sometines like that. When they start to see that they can't
convince they start to gradually replace non-convincing arguments with
trolling until, at some point, all they try to do is to troll. Unless,
of course, some external cause makes them stop.
--
Mikko
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-08 07:47 -0500 |
| Subject | Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis |
| Message-ID | <v41jse$2jqdk$7@dont-email.me> |
| In reply to | #106633 |
On 6/8/2024 1:28 AM, Mikko wrote:
> On 2024-06-08 02:43:57 +0000, Mike Terry said:
>
>> On 07/06/2024 17:34, joes wrote:
>>> Am Fri, 07 Jun 2024 10:40:37 -0500 schrieb olcott:
>>>> On 6/7/2024 10:32 AM, joes wrote:
>>>>> Am Fri, 07 Jun 2024 10:20:09 -0500 schrieb olcott:
>>>>>> On 6/7/2024 10:09 AM, Python wrote:
>>>>>>> Le 07/06/2024 à 17:05, olcott a écrit :
>>>>>>>> On 6/7/2024 9:55 AM, Python wrote:
>>>>>>>>> Le 07/06/2024 à 16:47, olcott a écrit :
>>>
>>>>>>>>>> The issue here is that I proved that DD correctly simulated by HH
>>>>>>>>>> has different behavior than the directly executed DD(DD) and
>>>>>>>>>> everyone's "rebuttal" to this proof is to simply ignore it.
>>>>>>>> When you actually try to form a rebuttal of the above you will see
>>>>>>>> that I am correct. So far everyone simply ignores the proof that I
>>>>>>>> am correct as their only rebuttal.
>>>>>> A {correct simulation} means that each instruction of the above x86
>>>>>> machine language of DD is correctly simulated by HH and simulated in
>>>>>> the correct order.
>>>>> And to the end. Thus it can't behave differently than direct
>>>>> execution.
>>>> You must not be very good at programming if you believe that
>>>> Infinite_Recursion must be simulated "to the end"
>>> As I said before, if there is no end the simulation can't end either.
>>
>> PO chooses to leave his terminology ambiguous, so we have 1000 post
>> threads perpetuated by little more than verbal misunderstandings.
>
> Crackpots are sometines like that. When they start to see that they can't
> convince they start to gradually replace non-convincing arguments with
> trolling until, at some point, all they try to do is to troll. Unless,
> of course, some external cause makes them stop.
>
*Nothing ambiguous here*
That people lack the knowledge of common technical terms does
not mean that expressions containing these terms are ambiguous.
I incorporate by reference
(a) The x86 language
(b) The notion of an x86 emulator
(c) I provide this complete function
void DDD(int (*x)())
{
HH(x, x);
}
_DDD()
[00001de2] 55 push ebp
[00001de3] 8bec mov ebp,esp
[00001de5] 8b4508 mov eax,[ebp+08]
[00001de8] 50 push eax ; push DD
[00001de9] 8b4d08 mov ecx,[ebp+08]
[00001dec] 51 push ecx ; push DD
[00001ded] e890f5ffff call 00001382 ; call HH
[00001df2] 83c408 add esp,+08
[00001df5] 5d pop ebp
[00001df6] c3 ret
Size in bytes:(0021) [00001df6]
Then I state that No DDD correctly emulated by any
x86 emulator H can possibly reach its own [00001df6]
instruction.
To anyone having this mandatory prerequisite knowledge
(perhaps not you) every x86 emulation of DDD by any
x86 emulator H continually repeats the first seven lines
of DDD until it crashes due to out-of-memory error.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-08 08:59 -0400 |
| Subject | Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis |
| Message-ID | <v41kkb$3cg3t$1@i2pn2.org> |
| In reply to | #106647 |
On 6/8/24 8:47 AM, olcott wrote:
> On 6/8/2024 1:28 AM, Mikko wrote:
>> On 2024-06-08 02:43:57 +0000, Mike Terry said:
>>
>>> On 07/06/2024 17:34, joes wrote:
>>>> Am Fri, 07 Jun 2024 10:40:37 -0500 schrieb olcott:
>>>>> On 6/7/2024 10:32 AM, joes wrote:
>>>>>> Am Fri, 07 Jun 2024 10:20:09 -0500 schrieb olcott:
>>>>>>> On 6/7/2024 10:09 AM, Python wrote:
>>>>>>>> Le 07/06/2024 à 17:05, olcott a écrit :
>>>>>>>>> On 6/7/2024 9:55 AM, Python wrote:
>>>>>>>>>> Le 07/06/2024 à 16:47, olcott a écrit :
>>>>
>>>>>>>>>>> The issue here is that I proved that DD correctly simulated
>>>>>>>>>>> by HH
>>>>>>>>>>> has different behavior than the directly executed DD(DD) and
>>>>>>>>>>> everyone's "rebuttal" to this proof is to simply ignore it.
>>>>>>>>> When you actually try to form a rebuttal of the above you will see
>>>>>>>>> that I am correct. So far everyone simply ignores the proof that I
>>>>>>>>> am correct as their only rebuttal.
>>>>>>> A {correct simulation} means that each instruction of the above x86
>>>>>>> machine language of DD is correctly simulated by HH and simulated in
>>>>>>> the correct order.
>>>>>> And to the end. Thus it can't behave differently than direct
>>>>>> execution.
>>>>> You must not be very good at programming if you believe that
>>>>> Infinite_Recursion must be simulated "to the end"
>>>> As I said before, if there is no end the simulation can't end either.
>>>
>>> PO chooses to leave his terminology ambiguous, so we have 1000 post
>>> threads perpetuated by little more than verbal misunderstandings.
>>
>> Crackpots are sometines like that. When they start to see that they can't
>> convince they start to gradually replace non-convincing arguments with
>> trolling until, at some point, all they try to do is to troll. Unless,
>> of course, some external cause makes them stop.
>>
>
> *Nothing ambiguous here*
Just not responsive.
> That people lack the knowledge of common technical terms does
> not mean that expressions containing these terms are ambiguous.
>
> I incorporate by reference
> (a) The x86 language
> (b) The notion of an x86 emulator
>
> (c) I provide this complete function
Which does nothing by itself.
>
> void DDD(int (*x)())
> {
> HH(x, x);
> }
>
> _DDD()
> [00001de2] 55 push ebp
> [00001de3] 8bec mov ebp,esp
> [00001de5] 8b4508 mov eax,[ebp+08]
> [00001de8] 50 push eax ; push DD
> [00001de9] 8b4d08 mov ecx,[ebp+08]
> [00001dec] 51 push ecx ; push DD
> [00001ded] e890f5ffff call 00001382 ; call HH
> [00001df2] 83c408 add esp,+08
> [00001df5] 5d pop ebp
> [00001df6] c3 ret
> Size in bytes:(0021) [00001df6]
>
> Then I state that No DDD correctly emulated by any
> x86 emulator H can possibly reach its own [00001df6]
> instruction.
Which just proves you don't understand what a proof is.
Since that doesn't do anything to connect the truth-makers you
referenced to the statement.
>
> To anyone having this mandatory prerequisite knowledge
> (perhaps not you) every x86 emulation of DDD by any
> x86 emulator H continually repeats the first seven lines
> of DDD until it crashes due to out-of-memory error.
>
Which means you just proved that NO HH that meets your requirements can
ever give an answer for this question.
You Claim this not to be true, so that just shows that your system is
self-contradictory.
And the apparent issue is that you are changing your definition of
"Correct Simulation" between the two.
Apparently quite intentionally, so it can be considered an act of
deception, commonly called a LIE.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-08 08:22 -0500 |
| Subject | Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis |
| Message-ID | <v41ltq$2kanc$3@dont-email.me> |
| In reply to | #106649 |
On 6/8/2024 7:59 AM, Richard Damon wrote:
> On 6/8/24 8:47 AM, olcott wrote:
>> On 6/8/2024 1:28 AM, Mikko wrote:
>>> On 2024-06-08 02:43:57 +0000, Mike Terry said:
>>>
>>>> On 07/06/2024 17:34, joes wrote:
>>>>> Am Fri, 07 Jun 2024 10:40:37 -0500 schrieb olcott:
>>>>>> On 6/7/2024 10:32 AM, joes wrote:
>>>>>>> Am Fri, 07 Jun 2024 10:20:09 -0500 schrieb olcott:
>>>>>>>> On 6/7/2024 10:09 AM, Python wrote:
>>>>>>>>> Le 07/06/2024 à 17:05, olcott a écrit :
>>>>>>>>>> On 6/7/2024 9:55 AM, Python wrote:
>>>>>>>>>>> Le 07/06/2024 à 16:47, olcott a écrit :
>>>>>
>>>>>>>>>>>> The issue here is that I proved that DD correctly simulated
>>>>>>>>>>>> by HH
>>>>>>>>>>>> has different behavior than the directly executed DD(DD) and
>>>>>>>>>>>> everyone's "rebuttal" to this proof is to simply ignore it.
>>>>>>>>>> When you actually try to form a rebuttal of the above you will
>>>>>>>>>> see
>>>>>>>>>> that I am correct. So far everyone simply ignores the proof
>>>>>>>>>> that I
>>>>>>>>>> am correct as their only rebuttal.
>>>>>>>> A {correct simulation} means that each instruction of the above x86
>>>>>>>> machine language of DD is correctly simulated by HH and
>>>>>>>> simulated in
>>>>>>>> the correct order.
>>>>>>> And to the end. Thus it can't behave differently than direct
>>>>>>> execution.
>>>>>> You must not be very good at programming if you believe that
>>>>>> Infinite_Recursion must be simulated "to the end"
>>>>> As I said before, if there is no end the simulation can't end either.
>>>>
>>>> PO chooses to leave his terminology ambiguous, so we have 1000 post
>>>> threads perpetuated by little more than verbal misunderstandings.
>>>
>>> Crackpots are sometines like that. When they start to see that they
>>> can't
>>> convince they start to gradually replace non-convincing arguments with
>>> trolling until, at some point, all they try to do is to troll. Unless,
>>> of course, some external cause makes them stop.
>>>
>>
>> *Nothing ambiguous here*
>
> Just not responsive.
>
>> That people lack the knowledge of common technical terms does
>> not mean that expressions containing these terms are ambiguous.
>>
>> I incorporate by reference
>> (a) The x86 language
>> (b) The notion of an x86 emulator
>>
>> (c) I provide this complete function
>
> Which does nothing by itself.
>
>>
>> void DDD(int (*x)())
>> {
>> HH(x, x);
>> }
>>
>> _DDD()
>> [00001de2] 55 push ebp
>> [00001de3] 8bec mov ebp,esp
>> [00001de5] 8b4508 mov eax,[ebp+08]
>> [00001de8] 50 push eax ; push DD
>> [00001de9] 8b4d08 mov ecx,[ebp+08]
>> [00001dec] 51 push ecx ; push DD
>> [00001ded] e890f5ffff call 00001382 ; call HH
>> [00001df2] 83c408 add esp,+08
>> [00001df5] 5d pop ebp
>> [00001df6] c3 ret
>> Size in bytes:(0021) [00001df6]
>>
>> Then I state that No DDD correctly emulated by any
>> x86 emulator H can possibly reach its own [00001df6]
>> instruction.
>
>
> Which just proves you don't understand what a proof is.
>
> Since that doesn't do anything to connect the truth-makers you
> referenced to the statement.
>
>>
>> To anyone having this mandatory prerequisite knowledge
>> (perhaps not you) every x86 emulation of DDD by any
>> x86 emulator H continually repeats the first seven lines
>> of DDD until it crashes due to out-of-memory error.
>>
>
> Which means you just proved that NO HH that meets your requirements can
> ever give an answer for this question.
>
There are more steps to this proof. I cannot conflate them
together and ever get closure.
The above HH is only an x86 emulator. Once it is understood
that DDD correctly simulated by any HH that can possibly
exist cannot possibly reach its own [00001df6] machine address
then we know that when HH sees the same thing that we see that
HH has its correct abort criteria.
*That is how partial simulation proves non-termination*
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-08 10:06 -0400 |
| Subject | Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis |
| Message-ID | <v41ohe$3cg3t$21@i2pn2.org> |
| In reply to | #106667 |
On 6/8/24 9:22 AM, olcott wrote:
> On 6/8/2024 7:59 AM, Richard Damon wrote:
>> On 6/8/24 8:47 AM, olcott wrote:
>>> On 6/8/2024 1:28 AM, Mikko wrote:
>>>> On 2024-06-08 02:43:57 +0000, Mike Terry said:
>>>>
>>>>> On 07/06/2024 17:34, joes wrote:
>>>>>> Am Fri, 07 Jun 2024 10:40:37 -0500 schrieb olcott:
>>>>>>> On 6/7/2024 10:32 AM, joes wrote:
>>>>>>>> Am Fri, 07 Jun 2024 10:20:09 -0500 schrieb olcott:
>>>>>>>>> On 6/7/2024 10:09 AM, Python wrote:
>>>>>>>>>> Le 07/06/2024 à 17:05, olcott a écrit :
>>>>>>>>>>> On 6/7/2024 9:55 AM, Python wrote:
>>>>>>>>>>>> Le 07/06/2024 à 16:47, olcott a écrit :
>>>>>>
>>>>>>>>>>>>> The issue here is that I proved that DD correctly simulated
>>>>>>>>>>>>> by HH
>>>>>>>>>>>>> has different behavior than the directly executed DD(DD) and
>>>>>>>>>>>>> everyone's "rebuttal" to this proof is to simply ignore it.
>>>>>>>>>>> When you actually try to form a rebuttal of the above you
>>>>>>>>>>> will see
>>>>>>>>>>> that I am correct. So far everyone simply ignores the proof
>>>>>>>>>>> that I
>>>>>>>>>>> am correct as their only rebuttal.
>>>>>>>>> A {correct simulation} means that each instruction of the above
>>>>>>>>> x86
>>>>>>>>> machine language of DD is correctly simulated by HH and
>>>>>>>>> simulated in
>>>>>>>>> the correct order.
>>>>>>>> And to the end. Thus it can't behave differently than direct
>>>>>>>> execution.
>>>>>>> You must not be very good at programming if you believe that
>>>>>>> Infinite_Recursion must be simulated "to the end"
>>>>>> As I said before, if there is no end the simulation can't end either.
>>>>>
>>>>> PO chooses to leave his terminology ambiguous, so we have 1000 post
>>>>> threads perpetuated by little more than verbal misunderstandings.
>>>>
>>>> Crackpots are sometines like that. When they start to see that they
>>>> can't
>>>> convince they start to gradually replace non-convincing arguments with
>>>> trolling until, at some point, all they try to do is to troll. Unless,
>>>> of course, some external cause makes them stop.
>>>>
>>>
>>> *Nothing ambiguous here*
>>
>> Just not responsive.
>>
>>> That people lack the knowledge of common technical terms does
>>> not mean that expressions containing these terms are ambiguous.
>>>
>>> I incorporate by reference
>>> (a) The x86 language
>>> (b) The notion of an x86 emulator
>>>
>>> (c) I provide this complete function
>>
>> Which does nothing by itself.
>>
>>>
>>> void DDD(int (*x)())
>>> {
>>> HH(x, x);
>>> }
>>>
>>> _DDD()
>>> [00001de2] 55 push ebp
>>> [00001de3] 8bec mov ebp,esp
>>> [00001de5] 8b4508 mov eax,[ebp+08]
>>> [00001de8] 50 push eax ; push DD
>>> [00001de9] 8b4d08 mov ecx,[ebp+08]
>>> [00001dec] 51 push ecx ; push DD
>>> [00001ded] e890f5ffff call 00001382 ; call HH
>>> [00001df2] 83c408 add esp,+08
>>> [00001df5] 5d pop ebp
>>> [00001df6] c3 ret
>>> Size in bytes:(0021) [00001df6]
>>>
>>> Then I state that No DDD correctly emulated by any
>>> x86 emulator H can possibly reach its own [00001df6]
>>> instruction.
>>
>>
>> Which just proves you don't understand what a proof is.
>>
>> Since that doesn't do anything to connect the truth-makers you
>> referenced to the statement.
>>
>>>
>>> To anyone having this mandatory prerequisite knowledge
>>> (perhaps not you) every x86 emulation of DDD by any
>>> x86 emulator H continually repeats the first seven lines
>>> of DDD until it crashes due to out-of-memory error.
>>>
>>
>> Which means you just proved that NO HH that meets your requirements
>> can ever give an answer for this question.
>>
>
> There are more steps to this proof. I cannot conflate them
> together and ever get closure.
But you need to in order to prove this step.
>
> The above HH is only an x86 emulator. Once it is understood
> that DDD correctly simulated by any HH that can possibly
> exist cannot possibly reach its own [00001df6] machine address
> then we know that when HH sees the same thing that we see that
> HH has its correct abort criteria.
>
> *That is how partial simulation proves non-termination*
>
So, is HH not your decider?
The DDD is not the input specified by the proof, so really why do we care?
You are moving FARTHER from the goal with your maze of straw men.
[toc] | [prev] | [next] | [standalone]
| From | Mike Terry <news.dead.person.stones@darjeeling.plus.com> |
|---|---|
| Date | 2024-06-08 17:43 +0100 |
| Subject | Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis |
| Message-ID | <UZmdnU21avjTF_n7nZ2dnZfqnPqdnZ2d@brightview.co.uk> |
| In reply to | #106633 |
On 08/06/2024 07:28, Mikko wrote:
> On 2024-06-08 02:43:57 +0000, Mike Terry said:
>
>> On 07/06/2024 17:34, joes wrote:
>>> Am Fri, 07 Jun 2024 10:40:37 -0500 schrieb olcott:
>>>> On 6/7/2024 10:32 AM, joes wrote:
>>>>> Am Fri, 07 Jun 2024 10:20:09 -0500 schrieb olcott:
>>>>>> On 6/7/2024 10:09 AM, Python wrote:
>>>>>>> Le 07/06/2024 à 17:05, olcott a écrit :
>>>>>>>> On 6/7/2024 9:55 AM, Python wrote:
>>>>>>>>> Le 07/06/2024 à 16:47, olcott a écrit :
>>>
>>>>>>>>>> The issue here is that I proved that DD correctly simulated by HH
>>>>>>>>>> has different behavior than the directly executed DD(DD) and
>>>>>>>>>> everyone's "rebuttal" to this proof is to simply ignore it.
>>>>>>>> When you actually try to form a rebuttal of the above you will see
>>>>>>>> that I am correct. So far everyone simply ignores the proof that I
>>>>>>>> am correct as their only rebuttal.
>>>>>> A {correct simulation} means that each instruction of the above x86
>>>>>> machine language of DD is correctly simulated by HH and simulated in
>>>>>> the correct order.
>>>>> And to the end. Thus it can't behave differently than direct execution.
>>>> You must not be very good at programming if you believe that
>>>> Infinite_Recursion must be simulated "to the end"
>>> As I said before, if there is no end the simulation can't end either.
>>
>> PO chooses to leave his terminology ambiguous, so we have 1000 post threads perpetuated by little
>> more than verbal misunderstandings.
>
> Crackpots are sometines like that. When they start to see that they can't
> convince they start to gradually replace non-convincing arguments with
> trolling until, at some point, all they try to do is to troll. Unless,
> of course, some external cause makes them stop.
>
I'd say you are vastly overestimating PO's capabilities. Many people suggest he is trolling, but
I've watched him for some years and I consider that he simply doesn't (/can't!/) understand the
terminology people use, or their logical reasoning. (He lacks the basic normaly abilities for
abstract thought and reasoning. He is not doing this deliberately.)
Mije.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-08 12:19 -0500 |
| Subject | Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis --- |
| Message-ID | <v423rh$2m6lc$2@dont-email.me> |
| In reply to | #106714 |
On 6/8/2024 11:43 AM, Mike Terry wrote:
> On 08/06/2024 07:28, Mikko wrote:
>> On 2024-06-08 02:43:57 +0000, Mike Terry said:
>>
>>> On 07/06/2024 17:34, joes wrote:
>>>> Am Fri, 07 Jun 2024 10:40:37 -0500 schrieb olcott:
>>>>> On 6/7/2024 10:32 AM, joes wrote:
>>>>>> Am Fri, 07 Jun 2024 10:20:09 -0500 schrieb olcott:
>>>>>>> On 6/7/2024 10:09 AM, Python wrote:
>>>>>>>> Le 07/06/2024 à 17:05, olcott a écrit :
>>>>>>>>> On 6/7/2024 9:55 AM, Python wrote:
>>>>>>>>>> Le 07/06/2024 à 16:47, olcott a écrit :
>>>>
>>>>>>>>>>> The issue here is that I proved that DD correctly simulated
>>>>>>>>>>> by HH
>>>>>>>>>>> has different behavior than the directly executed DD(DD) and
>>>>>>>>>>> everyone's "rebuttal" to this proof is to simply ignore it.
>>>>>>>>> When you actually try to form a rebuttal of the above you will see
>>>>>>>>> that I am correct. So far everyone simply ignores the proof that I
>>>>>>>>> am correct as their only rebuttal.
>>>>>>> A {correct simulation} means that each instruction of the above x86
>>>>>>> machine language of DD is correctly simulated by HH and simulated in
>>>>>>> the correct order.
>>>>>> And to the end. Thus it can't behave differently than direct
>>>>>> execution.
>>>>> You must not be very good at programming if you believe that
>>>>> Infinite_Recursion must be simulated "to the end"
>>>> As I said before, if there is no end the simulation can't end either.
>>>
>>> PO chooses to leave his terminology ambiguous, so we have 1000 post
>>> threads perpetuated by little more than verbal misunderstandings.
>>
>> Crackpots are sometines like that. When they start to see that they can't
>> convince they start to gradually replace non-convincing arguments with
>> trolling until, at some point, all they try to do is to troll. Unless,
>> of course, some external cause makes them stop.
>>
>
> I'd say you are vastly overestimating PO's capabilities. Many people
> suggest he is trolling, but I've watched him for some years and I
> consider that he simply doesn't (/can't!/) understand the terminology
> people use, or their logical reasoning. (He lacks the basic normaly
> abilities for abstract thought and reasoning. He is not doing this
> deliberately.)
>
> Mije.
>
No the whole problem is that you and others are so sure that I
must be wrong that you simply don't play close enough attention
to see that I prove that I am correct.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its input D
until H correctly determines that its simulated D would never
stop running unless aborted then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words10/13/2022>
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
> I don't think that is the shell game. PO really /has/ an H
> (it's trivial to do for this one case) that correctly determines
> that P(P) *would* never stop running *unless* aborted.
Halt deciders compute the mapping FROM THEIR INPUTS
BASED ON THE ACTUAL BEHAVIOR THAT THIS INPUT SPECIFIES.
This input specifies the behavior of DD correctly simulated by HH.
That everyone wants to avoid looking at my conclusive proof
that DD correctly simulated by HH has provably different
behavior than the directly executed DD(DD) *is dishonest*
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-08 16:33 -0400 |
| Subject | Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis --- |
| Message-ID | <v42f5u$3cg3t$30@i2pn2.org> |
| In reply to | #106716 |
On 6/8/24 1:19 PM, olcott wrote:
> On 6/8/2024 11:43 AM, Mike Terry wrote:
>> On 08/06/2024 07:28, Mikko wrote:
>>> On 2024-06-08 02:43:57 +0000, Mike Terry said:
>>>
>>>> On 07/06/2024 17:34, joes wrote:
>>>>> Am Fri, 07 Jun 2024 10:40:37 -0500 schrieb olcott:
>>>>>> On 6/7/2024 10:32 AM, joes wrote:
>>>>>>> Am Fri, 07 Jun 2024 10:20:09 -0500 schrieb olcott:
>>>>>>>> On 6/7/2024 10:09 AM, Python wrote:
>>>>>>>>> Le 07/06/2024 à 17:05, olcott a écrit :
>>>>>>>>>> On 6/7/2024 9:55 AM, Python wrote:
>>>>>>>>>>> Le 07/06/2024 à 16:47, olcott a écrit :
>>>>>
>>>>>>>>>>>> The issue here is that I proved that DD correctly simulated
>>>>>>>>>>>> by HH
>>>>>>>>>>>> has different behavior than the directly executed DD(DD) and
>>>>>>>>>>>> everyone's "rebuttal" to this proof is to simply ignore it.
>>>>>>>>>> When you actually try to form a rebuttal of the above you will
>>>>>>>>>> see
>>>>>>>>>> that I am correct. So far everyone simply ignores the proof
>>>>>>>>>> that I
>>>>>>>>>> am correct as their only rebuttal.
>>>>>>>> A {correct simulation} means that each instruction of the above x86
>>>>>>>> machine language of DD is correctly simulated by HH and
>>>>>>>> simulated in
>>>>>>>> the correct order.
>>>>>>> And to the end. Thus it can't behave differently than direct
>>>>>>> execution.
>>>>>> You must not be very good at programming if you believe that
>>>>>> Infinite_Recursion must be simulated "to the end"
>>>>> As I said before, if there is no end the simulation can't end either.
>>>>
>>>> PO chooses to leave his terminology ambiguous, so we have 1000 post
>>>> threads perpetuated by little more than verbal misunderstandings.
>>>
>>> Crackpots are sometines like that. When they start to see that they
>>> can't
>>> convince they start to gradually replace non-convincing arguments with
>>> trolling until, at some point, all they try to do is to troll. Unless,
>>> of course, some external cause makes them stop.
>>>
>>
>> I'd say you are vastly overestimating PO's capabilities. Many people
>> suggest he is trolling, but I've watched him for some years and I
>> consider that he simply doesn't (/can't!/) understand the terminology
>> people use, or their logical reasoning. (He lacks the basic normaly
>> abilities for abstract thought and reasoning. He is not doing this
>> deliberately.)
>>
>> Mije.
>>
>
> No the whole problem is that you and others are so sure that I
> must be wrong that you simply don't play close enough attention
> to see that I prove that I am correct.
Nope, YOU don't understand the basic terms youu use because you are just
parroting things you found by rote, but never actually learned what they
actually mean.
As Mike says, you have shown yourself mentally incapable of
understanding some of the abstract notions that you try to talk about.
>
> <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
> If simulating halt decider H correctly simulates its input D
> until H correctly determines that its simulated D would never
> stop running unless aborted then
>
> H can abort its simulation of D and correctly report that D
> specifies a non-halting sequence of configurations.
> </MIT Professor Sipser agreed to ONLY these verbatim words10/13/2022>
Which, since his definition of "Correct Simulation" isn't yours, you
can't actaully use.
The ONLY thing that Professor Sioser considers to be a "Correct
SImulation" is a simulation the exactly reproduces the behavior of the
directly executed code, which means a simulation that doesn't stop until
it reaches a final state (even if that takes forever).
H does NOT do that sort of simulation, nor does it correctly determine
that THIS input (and thus still calling the original H), if simulated by
that sort of simulator will not halt, so you never satisfy the
requirements, so can never claim the right of the second clause.
This has been explained to you many times, and your repeating it just
shows a reckless disregard for the truth, and could open you up to a
defamation suit by Professor Sipser. It also shows that your
understanding of what other people say needs to be kept suspect, and you
are proving yourself to be a pathological liar.
>
> On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
> > I don't think that is the shell game. PO really /has/ an H
> > (it's trivial to do for this one case) that correctly determines
> > that P(P) *would* never stop running *unless* aborted.
>
> Halt deciders compute the mapping FROM THEIR INPUTS
> BASED ON THE ACTUAL BEHAVIOR THAT THIS INPUT SPECIFIES.
> This input specifies the behavior of DD correctly simulated by HH.
>
And BY DEFINITION (a word I am not sure you understand) the actual
behavior the input specifies is the behavior of the directly executed
machine represented by the input. That can also be created by giving the
exact same input to a UTM (note, that means AFTER pairing your template
to the decider) and leting it run to completion.
> That everyone wants to avoid looking at my conclusive proof
> that DD correctly simulated by HH has provably different
> behavior than the directly executed DD(DD) *is dishonest*
>
Nope, we can see the holes in your arguments from miles aways, they are
so big.
That you can't just shows your own mental limitiation, some of which
seem to be self-inflicted by your refusal to study the materrial to knwo
what you are talking about. Your "Zeroth Principles" study of them just
doesn't cut it (You call them first principles, but that requires you to
first study the field enough to actually KNOW the fundamental properties
of the system, which it is clear you haven't done).
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-07 11:19 -0400 |
| Subject | Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis |
| Message-ID | <v3v8dm$39ri5$12@i2pn2.org> |
| In reply to | #106475 |
On 6/7/24 11:05 AM, olcott wrote: > On 6/7/2024 9:55 AM, Python wrote: >> Le 07/06/2024 à 16:47, olcott a écrit : >>> ... Turing machines can only take finite string >>> inputs thus cannot take Turing machines as inputs. >> >> WTF??? Since then a Turing machine cannot be represented >> as a finite string? >> > > Turing machines can take a finite string machine description > of the computation that contains themselves they cannot > the computation that actually contains themselves. So, you admit that H can be given the description of a machine that contains a copy of H in it to decide? And that Decider can be asked to decide on the behavior of the machine that there input represents? Note, if you deny the second, then you are just defining that Halting CAN'T be asked as a question, and thus by your definition, there are no halt deciders, even though the do exist for the partial case, so obviously we can make one Turing Machine decide on some properties of the Turing Machine described by its input. > > It anyone is paying 100% complete attention then they will > see that the there is no correct rebuttal to the following. > > Try to show how this DD correctly simulated by any HH ever > stops running without having its simulation aborted by HH. Which is just a straw man, as it has nothing to do with the question you were just talking about. > > _DD() > [00001e12] 55 push ebp > [00001e13] 8bec mov ebp,esp > [00001e15] 51 push ecx > [00001e16] 8b4508 mov eax,[ebp+08] > [00001e19] 50 push eax ; push DD > [00001e1a] 8b4d08 mov ecx,[ebp+08] > [00001e1d] 51 push ecx ; push DD > [00001e1e] e85ff5ffff call 00001382 ; call HH > > >>> The issue here is that I proved that DD correctly simulated >>> by HH has different behavior than the directly executed >>> DD(DD) and everyone's "rebuttal" to this proof is to simply >>> ignore it. >> >> "correctly simulated" has "different than directly executed" >> > > When you actually try to form a rebuttal of the above you will > see that I am correct. So far everyone simply ignores the proof > that I am correct as their only rebuttal. > >> This is dementia at the higher degree. >> >> >
[toc] | [prev] | [next] | [standalone]
| From | joes <noreply@example.com> |
|---|---|
| Date | 2024-06-07 15:27 +0000 |
| Subject | Re: How Partial Simulations incorrectly determine non-halting ---Ben's 10/2022 analysis |
| Message-ID | <v3v8tp$39q1p$3@i2pn2.org> |
| In reply to | #106475 |
Am Fri, 07 Jun 2024 10:05:11 -0500 schrieb olcott: > On 6/7/2024 9:55 AM, Python wrote: >> Le 07/06/2024 à 16:47, olcott a écrit : > Turing machines can take a finite string machine description of the > computation that contains themselves they cannot the computation that > actually contains themselves. Does not parse. Recursion can be encoded in a finite string. >>> The issue here is that I proved that DD correctly simulated by HH has >>> different behavior than the directly executed DD(DD) and everyone's >>> "rebuttal" to this proof is to simply ignore it. > When you actually try to form a rebuttal of the above you will see that > I am correct. So far everyone simply ignores the proof that I am correct > as their only rebuttal. The rebuttal is that a simulation should behave the same as the real thing. -- joes
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-07 10:30 -0500 |
| Subject | Re: How Partial Simulations incorrectly determine non-halting ---Ben's 10/2022 analysis |
| Message-ID | <v3v92q$242e9$6@dont-email.me> |
| In reply to | #106492 |
On 6/7/2024 10:27 AM, joes wrote:
> Am Fri, 07 Jun 2024 10:05:11 -0500 schrieb olcott:
>> On 6/7/2024 9:55 AM, Python wrote:
>>> Le 07/06/2024 à 16:47, olcott a écrit :
>> Turing machines can take a finite string machine description of the
>> computation that contains themselves they cannot the computation that
>> actually contains themselves.
> Does not parse.
> Recursion can be encoded in a finite string.
>
>>>> The issue here is that I proved that DD correctly simulated by HH has
>>>> different behavior than the directly executed DD(DD) and everyone's
>>>> "rebuttal" to this proof is to simply ignore it.
>> When you actually try to form a rebuttal of the above you will see that
>> I am correct. So far everyone simply ignores the proof that I am correct
>> as their only rebuttal.
> The rebuttal is that a simulation should behave the same as the real
> thing.
>
Try to show how this DD correctly simulated by any HH ever
stops running without having its simulation aborted by HH.
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD
[00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD
[00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the
above x86 machine language of DD is correctly simulated
by HH and simulated in the correct order.
Anyone claiming that HH should report on the behavior
of the directly executed DD(DD) is requiring a violation
of the above definition of correct simulation.
--
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 | news2@immibis.com |
|---|---|
| Date | 2024-06-07 17:32 +0200 |
| Subject | Re: How Partial Simulations incorrectly determine non-halting ---Ben's 10/2022 analysis |
| Message-ID | <v3v96q$1o9el$3@dont-email.me> |
| In reply to | #106495 |
On 7/06/24 17:30, olcott wrote:
>
> Try to show how this DD correctly simulated by any HH ever
> stops running without having its simulation aborted by HH.
>
> _DD()
> [00001e12] 55 push ebp
> [00001e13] 8bec mov ebp,esp
> [00001e15] 51 push ecx
> [00001e16] 8b4508 mov eax,[ebp+08]
> [00001e19] 50 push eax ; push DD
> [00001e1a] 8b4d08 mov ecx,[ebp+08]
> [00001e1d] 51 push ecx ; push DD
> [00001e1e] e85ff5ffff call 00001382 ; call HH
>
> A {correct simulation} means that each instruction of the
> above x86 machine language of DD is correctly simulated
> by HH and simulated in the correct order.
The next instruction after "call HH" - the one at address 00001382 - is
simulated incorrectly.
[toc] | [prev] | [next] | [standalone]
Page 10 of 17 — ← Prev page 1 … 8 9 [10] 11 12 … 17 Next page →
Back to top | Article view | comp.theory
csiph-web