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 15 of 17 — ← Prev page 1 … 13 14 [15] 16 17 Next page →
| From | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2024-06-08 15:20 +0200 |
| Subject | Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis |
| Message-ID | <v41lqj$2jt63$2@dont-email.me> |
| In reply to | #106660 |
Op 08.jun.2024 om 15:04 schreef olcott:
> On 6/8/2024 1:42 AM, Mikko wrote:
>> On 2024-06-07 22:26:05 +0000, olcott said:
>>
>>> On 6/7/2024 4:00 PM, joes wrote:
>>>> Am Fri, 07 Jun 2024 09:47:35 -0500 schrieb olcott:
>>>>> On 6/7/2024 1:30 AM, Mikko wrote:
>>>>>> On 2024-06-06 15:31:36 +0000, olcott said:
>>>>>>> On 6/6/2024 10:14 AM, Mikko wrote:
>>>>>>>> On 2024-06-06 13:53:58 +0000, olcott said:
>>>>>>>>> On 6/6/2024 5:15 AM, Mikko wrote:
>>>>>>>>>> On 2024-06-05 13:29:28 +0000, olcott said:
>>>>>>>>>>> On 6/5/2024 2:37 AM, Mikko wrote:
>>>>>>>>>>>> On 2024-06-04 18:02:03 +0000, olcott said:
>>>>
>>>>> A simulating halt decider cannot report on what the behavior of a
>>>>> non-terminating input actually is because this would take forever.
>>>> Exactly. Didn't you say it is allowed to abort?
>>>>
>>>>> H is not allowed to report on any computation containing its actual
>>>>> self
>>>>> because Turing machines can only take finite string inputs thus cannot
>>>>> take Turing machines as inputs.
>>>> Bullshit. It can take other machines just fine. It doesn't know about
>>>> itself.
>>>>
>>>
>>> No actual Turing machine can be the input to any other actual
>>> Turing machine. Turing machines only take finite string inputs.
>>
>> Any finite string can be an input to some Turing machine.
>> Can you prove that a Turing machine is not a finite string?
>>
>
> By definition Turing Machines are not finite strings in the
> conventional model. In my x86utm model of computation x86
> machine language <is> the input to another function written
> in the x86 language.
>
>> Your own attempts of a conter-proof are not about Turing machines
>> but C programs. C programs are finite strings, so a C program
>> is a valid input to a C program (and a Turing machine, too).
>>
>
> They are about Turing Machines yet cannot be sufficiently understood
> with less than the 100% compete precision of the x86 language. They
> x86utm model is required to prove that false assumptions about the
> nature of correct simulation are false assumptions.
>
> void DDD(int (*x)())
> {
> HH(x, x);
> }
>
> DDD correctly simulated by any HH cannot possibly stop running
> without being aborted. When this is understood and accepted then
>
> When Ĥ is applied to ⟨Ĥ⟩
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
> ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by any embedded_H is understood
> to not possibly stop running until aborted.
>
> I have all of the details of the machine code and C code for HH and DDD.
> I can't to the same thing for embedded_H and ⟨Ĥ⟩ ⟨Ĥ⟩ so we have to learn
> by analogy.
>
>>>>> This means that H is not allowed to report on the behavior of the
>>>>> directly executed P(P).
>>>> So on which program does it report then?
>>
>
> 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 >
> If HH(DD,DD) did not correctly determine that its input
> DOES NOT HALT then DD(DD) would never halt.
>
>
Indeed, *only if*. if HH does not halt, then DD does not halt. But your
claim is that HH halts, because of that DD(DD) *DOES* halt. You cannot
base a conclusion on something that does not happen.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-08 08:32 -0500 |
| Subject | Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis |
| Message-ID | <v41mho$2kanc$4@dont-email.me> |
| In reply to | #106666 |
On 6/8/2024 8:20 AM, Fred. Zwarts wrote:
> Op 08.jun.2024 om 15:04 schreef olcott:
>> On 6/8/2024 1:42 AM, Mikko wrote:
>>> On 2024-06-07 22:26:05 +0000, olcott said:
>>>
>>>> On 6/7/2024 4:00 PM, joes wrote:
>>>>> Am Fri, 07 Jun 2024 09:47:35 -0500 schrieb olcott:
>>>>>> On 6/7/2024 1:30 AM, Mikko wrote:
>>>>>>> On 2024-06-06 15:31:36 +0000, olcott said:
>>>>>>>> On 6/6/2024 10:14 AM, Mikko wrote:
>>>>>>>>> On 2024-06-06 13:53:58 +0000, olcott said:
>>>>>>>>>> On 6/6/2024 5:15 AM, Mikko wrote:
>>>>>>>>>>> On 2024-06-05 13:29:28 +0000, olcott said:
>>>>>>>>>>>> On 6/5/2024 2:37 AM, Mikko wrote:
>>>>>>>>>>>>> On 2024-06-04 18:02:03 +0000, olcott said:
>>>>>
>>>>>> A simulating halt decider cannot report on what the behavior of a
>>>>>> non-terminating input actually is because this would take forever.
>>>>> Exactly. Didn't you say it is allowed to abort?
>>>>>
>>>>>> H is not allowed to report on any computation containing its
>>>>>> actual self
>>>>>> because Turing machines can only take finite string inputs thus
>>>>>> cannot
>>>>>> take Turing machines as inputs.
>>>>> Bullshit. It can take other machines just fine. It doesn't know about
>>>>> itself.
>>>>>
>>>>
>>>> No actual Turing machine can be the input to any other actual
>>>> Turing machine. Turing machines only take finite string inputs.
>>>
>>> Any finite string can be an input to some Turing machine.
>>> Can you prove that a Turing machine is not a finite string?
>>>
>>
>> By definition Turing Machines are not finite strings in the
>> conventional model. In my x86utm model of computation x86
>> machine language <is> the input to another function written
>> in the x86 language.
>>
>>> Your own attempts of a conter-proof are not about Turing machines
>>> but C programs. C programs are finite strings, so a C program
>>> is a valid input to a C program (and a Turing machine, too).
>>>
>>
>> They are about Turing Machines yet cannot be sufficiently understood
>> with less than the 100% compete precision of the x86 language. They
>> x86utm model is required to prove that false assumptions about the
>> nature of correct simulation are false assumptions.
>>
>> void DDD(int (*x)())
>> {
>> HH(x, x);
>> }
>>
>> DDD correctly simulated by any HH cannot possibly stop running
>> without being aborted. When this is understood and accepted then
>>
>> When Ĥ is applied to ⟨Ĥ⟩
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>
>> ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by any embedded_H is understood
>> to not possibly stop running until aborted.
>>
>> I have all of the details of the machine code and C code for HH and DDD.
>> I can't to the same thing for embedded_H and ⟨Ĥ⟩ ⟨Ĥ⟩ so we have to learn
>> by analogy.
>>
>>>>>> This means that H is not allowed to report on the behavior of the
>>>>>> directly executed P(P).
>>>>> So on which program does it report then?
>>>
>>
>> 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 >
>> If HH(DD,DD) did not correctly determine that its input
>> DOES NOT HALT then DD(DD) would never halt.
>>
>>
>
> Indeed, *only if*. if HH does not halt, then DD does not halt. But your
> claim is that HH halts, because of that DD(DD) *DOES* halt. You cannot
> base a conclusion on something that does not happen.
You are twisting the meaning of my words.
*Verified facts* (some may be beyond your technical competence)
(1) The input to HH DOES NOT HALT.
(2) HH correctly recognizes that its input DOES NOT HALT.
(3) HH is only accountable for the behavior of its input
because halt deciders COMPUTE THE MAPPING FROM THEIR INPUTS
(4) DD(DD) only halts because HH correctly rejected its
input as non-halting.
(5) HH is not accountable for the behavior of DD(DD)
that provably differs from the behavior of DD
correctly simulated by HH
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2024-06-08 15:56 +0200 |
| Subject | Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis |
| Message-ID | <v41nv5$2jt63$4@dont-email.me> |
| In reply to | #106668 |
Op 08.jun.2024 om 15:32 schreef olcott:
> On 6/8/2024 8:20 AM, Fred. Zwarts wrote:
>> Op 08.jun.2024 om 15:04 schreef olcott:
>>> On 6/8/2024 1:42 AM, Mikko wrote:
>>>> On 2024-06-07 22:26:05 +0000, olcott said:
>>>>
>>>>> On 6/7/2024 4:00 PM, joes wrote:
>>>>>> Am Fri, 07 Jun 2024 09:47:35 -0500 schrieb olcott:
>>>>>>> On 6/7/2024 1:30 AM, Mikko wrote:
>>>>>>>> On 2024-06-06 15:31:36 +0000, olcott said:
>>>>>>>>> On 6/6/2024 10:14 AM, Mikko wrote:
>>>>>>>>>> On 2024-06-06 13:53:58 +0000, olcott said:
>>>>>>>>>>> On 6/6/2024 5:15 AM, Mikko wrote:
>>>>>>>>>>>> On 2024-06-05 13:29:28 +0000, olcott said:
>>>>>>>>>>>>> On 6/5/2024 2:37 AM, Mikko wrote:
>>>>>>>>>>>>>> On 2024-06-04 18:02:03 +0000, olcott said:
>>>>>>
>>>>>>> A simulating halt decider cannot report on what the behavior of a
>>>>>>> non-terminating input actually is because this would take forever.
>>>>>> Exactly. Didn't you say it is allowed to abort?
>>>>>>
>>>>>>> H is not allowed to report on any computation containing its
>>>>>>> actual self
>>>>>>> because Turing machines can only take finite string inputs thus
>>>>>>> cannot
>>>>>>> take Turing machines as inputs.
>>>>>> Bullshit. It can take other machines just fine. It doesn't know about
>>>>>> itself.
>>>>>>
>>>>>
>>>>> No actual Turing machine can be the input to any other actual
>>>>> Turing machine. Turing machines only take finite string inputs.
>>>>
>>>> Any finite string can be an input to some Turing machine.
>>>> Can you prove that a Turing machine is not a finite string?
>>>>
>>>
>>> By definition Turing Machines are not finite strings in the
>>> conventional model. In my x86utm model of computation x86
>>> machine language <is> the input to another function written
>>> in the x86 language.
>>>
>>>> Your own attempts of a conter-proof are not about Turing machines
>>>> but C programs. C programs are finite strings, so a C program
>>>> is a valid input to a C program (and a Turing machine, too).
>>>>
>>>
>>> They are about Turing Machines yet cannot be sufficiently understood
>>> with less than the 100% compete precision of the x86 language. They
>>> x86utm model is required to prove that false assumptions about the
>>> nature of correct simulation are false assumptions.
>>>
>>> void DDD(int (*x)())
>>> {
>>> HH(x, x);
>>> }
>>>
>>> DDD correctly simulated by any HH cannot possibly stop running
>>> without being aborted. When this is understood and accepted then
>>>
>>> When Ĥ is applied to ⟨Ĥ⟩
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>
>>> ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by any embedded_H is understood
>>> to not possibly stop running until aborted.
>>>
>>> I have all of the details of the machine code and C code for HH and DDD.
>>> I can't to the same thing for embedded_H and ⟨Ĥ⟩ ⟨Ĥ⟩ so we have to learn
>>> by analogy.
>>>
>>>>>>> This means that H is not allowed to report on the behavior of the
>>>>>>> directly executed P(P).
>>>>>> So on which program does it report then?
>>>>
>>>
>>> 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 >
>>> If HH(DD,DD) did not correctly determine that its input
>>> DOES NOT HALT then DD(DD) would never halt.
>>>
>>>
>>
>> Indeed, *only if*. if HH does not halt, then DD does not halt. But
>> your claim is that HH halts, because of that DD(DD) *DOES* halt. You
>> cannot base a conclusion on something that does not happen.
>
> You are twisting the meaning of my words.
No, your are twisting your own words.
> *Verified facts* (some may be beyond your technical competence)
Up to now, your have not been able to tell how they were verified. It
seems beyond your competence to see the difference between verified
facts and wishes. That is twisting the meaning of words.
> (1) The input to HH DOES NOT HALT.
Only if HH (as part of the input) does not halt.
You even proved that this conclusion is a false negative on 05.jun.2024
at 15:59 (CET)
>
> (2) HH correctly recognizes that its input DOES NOT HALT.
Only if HH would not abort, but it does abort. So, a premature conclusion.
You even proved that this conclusion is a false negative on 05.jun.2024
at 15:59 (CET)
>
> (3) HH is only accountable for the behavior of its input
> because halt deciders COMPUTE THE MAPPING FROM THEIR INPUTS
And a correct simulation up to the point where HH aborts would show the
real behaviour.
>
> (4) DD(DD) only halts because HH correctly rejected its
> input as non-halting.
>
Indeed, DD halts, and the conclusion that this input does not halt is
incorrect.
> (5) HH is not accountable for the behavior of DD(DD)
> that provably differs from the behavior of DD
> correctly simulated by HH
But HH is accountable for doing an incorrect simulation, because it is
unable to simulate up to the point where the simulated HH aborts and
returns.
Try to think.
The conclusion is based on the assumption that HH does not abort the
simulation.
You can't base a conclusion on something that does not happen.
So, HH only reports that it concluded that its simulation does not halt.
That does not say anything about the validity of that conclusion. But
the fact that it concluded so is correct.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-08 09:11 -0500 |
| Subject | Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis |
| Message-ID | <v41oq5$2kanc$14@dont-email.me> |
| In reply to | #106682 |
On 6/8/2024 8:56 AM, Fred. Zwarts wrote:
> Op 08.jun.2024 om 15:32 schreef olcott:
>> On 6/8/2024 8:20 AM, Fred. Zwarts wrote:
>>> Op 08.jun.2024 om 15:04 schreef olcott:
>>>> On 6/8/2024 1:42 AM, Mikko wrote:
>>>>> On 2024-06-07 22:26:05 +0000, olcott said:
>>>>>
>>>>>> On 6/7/2024 4:00 PM, joes wrote:
>>>>>>> Am Fri, 07 Jun 2024 09:47:35 -0500 schrieb olcott:
>>>>>>>> On 6/7/2024 1:30 AM, Mikko wrote:
>>>>>>>>> On 2024-06-06 15:31:36 +0000, olcott said:
>>>>>>>>>> On 6/6/2024 10:14 AM, Mikko wrote:
>>>>>>>>>>> On 2024-06-06 13:53:58 +0000, olcott said:
>>>>>>>>>>>> On 6/6/2024 5:15 AM, Mikko wrote:
>>>>>>>>>>>>> On 2024-06-05 13:29:28 +0000, olcott said:
>>>>>>>>>>>>>> On 6/5/2024 2:37 AM, Mikko wrote:
>>>>>>>>>>>>>>> On 2024-06-04 18:02:03 +0000, olcott said:
>>>>>>>
>>>>>>>> A simulating halt decider cannot report on what the behavior of a
>>>>>>>> non-terminating input actually is because this would take forever.
>>>>>>> Exactly. Didn't you say it is allowed to abort?
>>>>>>>
>>>>>>>> H is not allowed to report on any computation containing its
>>>>>>>> actual self
>>>>>>>> because Turing machines can only take finite string inputs thus
>>>>>>>> cannot
>>>>>>>> take Turing machines as inputs.
>>>>>>> Bullshit. It can take other machines just fine. It doesn't know
>>>>>>> about
>>>>>>> itself.
>>>>>>>
>>>>>>
>>>>>> No actual Turing machine can be the input to any other actual
>>>>>> Turing machine. Turing machines only take finite string inputs.
>>>>>
>>>>> Any finite string can be an input to some Turing machine.
>>>>> Can you prove that a Turing machine is not a finite string?
>>>>>
>>>>
>>>> By definition Turing Machines are not finite strings in the
>>>> conventional model. In my x86utm model of computation x86
>>>> machine language <is> the input to another function written
>>>> in the x86 language.
>>>>
>>>>> Your own attempts of a conter-proof are not about Turing machines
>>>>> but C programs. C programs are finite strings, so a C program
>>>>> is a valid input to a C program (and a Turing machine, too).
>>>>>
>>>>
>>>> They are about Turing Machines yet cannot be sufficiently understood
>>>> with less than the 100% compete precision of the x86 language. They
>>>> x86utm model is required to prove that false assumptions about the
>>>> nature of correct simulation are false assumptions.
>>>>
>>>> void DDD(int (*x)())
>>>> {
>>>> HH(x, x);
>>>> }
>>>>
>>>> DDD correctly simulated by any HH cannot possibly stop running
>>>> without being aborted. When this is understood and accepted then
>>>>
>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>
>>>> ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by any embedded_H is understood
>>>> to not possibly stop running until aborted.
>>>>
>>>> I have all of the details of the machine code and C code for HH and
>>>> DDD.
>>>> I can't to the same thing for embedded_H and ⟨Ĥ⟩ ⟨Ĥ⟩ so we have to
>>>> learn
>>>> by analogy.
>>>>
>>>>>>>> This means that H is not allowed to report on the behavior of the
>>>>>>>> directly executed P(P).
>>>>>>> So on which program does it report then?
>>>>>
>>>>
>>>> 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 >
>>>> If HH(DD,DD) did not correctly determine that its input
>>>> DOES NOT HALT then DD(DD) would never halt.
>>>>
>>>>
>>>
>>> Indeed, *only if*. if HH does not halt, then DD does not halt. But
>>> your claim is that HH halts, because of that DD(DD) *DOES* halt. You
>>> cannot base a conclusion on something that does not happen.
>>
>> You are twisting the meaning of my words.
>
> No, your are twisting your own words.
>
>> *Verified facts* (some may be beyond your technical competence)
>
> Up to now, your have not been able to tell how they were verified. It
> seems beyond your competence to see the difference between verified
> facts and wishes. That is twisting the meaning of words.
>
>> (1) The input to HH DOES NOT HALT.
>
> Only if HH (as part of the input) does not halt.
> You even proved that this conclusion is a false negative on 05.jun.2024
> at 15:59 (CET)
>
>>
>> (2) HH correctly recognizes that its input DOES NOT HALT.
>
> Only if HH would not abort, but it does abort.
<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>
I stop at the first big mistake so that we can focus on correcting
this big mistake.
When
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.
--
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:20 -0400 |
| Subject | Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis |
| Message-ID | <v41pbg$3cg3t$24@i2pn2.org> |
| In reply to | #106693 |
On 6/8/24 10:11 AM, olcott wrote:
> On 6/8/2024 8:56 AM, Fred. Zwarts wrote:
>> Op 08.jun.2024 om 15:32 schreef olcott:
>>> On 6/8/2024 8:20 AM, Fred. Zwarts wrote:
>>>> Op 08.jun.2024 om 15:04 schreef olcott:
>>>>> On 6/8/2024 1:42 AM, Mikko wrote:
>>>>>> On 2024-06-07 22:26:05 +0000, olcott said:
>>>>>>
>>>>>>> On 6/7/2024 4:00 PM, joes wrote:
>>>>>>>> Am Fri, 07 Jun 2024 09:47:35 -0500 schrieb olcott:
>>>>>>>>> On 6/7/2024 1:30 AM, Mikko wrote:
>>>>>>>>>> On 2024-06-06 15:31:36 +0000, olcott said:
>>>>>>>>>>> On 6/6/2024 10:14 AM, Mikko wrote:
>>>>>>>>>>>> On 2024-06-06 13:53:58 +0000, olcott said:
>>>>>>>>>>>>> On 6/6/2024 5:15 AM, Mikko wrote:
>>>>>>>>>>>>>> On 2024-06-05 13:29:28 +0000, olcott said:
>>>>>>>>>>>>>>> On 6/5/2024 2:37 AM, Mikko wrote:
>>>>>>>>>>>>>>>> On 2024-06-04 18:02:03 +0000, olcott said:
>>>>>>>>
>>>>>>>>> A simulating halt decider cannot report on what the behavior of a
>>>>>>>>> non-terminating input actually is because this would take forever.
>>>>>>>> Exactly. Didn't you say it is allowed to abort?
>>>>>>>>
>>>>>>>>> H is not allowed to report on any computation containing its
>>>>>>>>> actual self
>>>>>>>>> because Turing machines can only take finite string inputs thus
>>>>>>>>> cannot
>>>>>>>>> take Turing machines as inputs.
>>>>>>>> Bullshit. It can take other machines just fine. It doesn't know
>>>>>>>> about
>>>>>>>> itself.
>>>>>>>>
>>>>>>>
>>>>>>> No actual Turing machine can be the input to any other actual
>>>>>>> Turing machine. Turing machines only take finite string inputs.
>>>>>>
>>>>>> Any finite string can be an input to some Turing machine.
>>>>>> Can you prove that a Turing machine is not a finite string?
>>>>>>
>>>>>
>>>>> By definition Turing Machines are not finite strings in the
>>>>> conventional model. In my x86utm model of computation x86
>>>>> machine language <is> the input to another function written
>>>>> in the x86 language.
>>>>>
>>>>>> Your own attempts of a conter-proof are not about Turing machines
>>>>>> but C programs. C programs are finite strings, so a C program
>>>>>> is a valid input to a C program (and a Turing machine, too).
>>>>>>
>>>>>
>>>>> They are about Turing Machines yet cannot be sufficiently understood
>>>>> with less than the 100% compete precision of the x86 language. They
>>>>> x86utm model is required to prove that false assumptions about the
>>>>> nature of correct simulation are false assumptions.
>>>>>
>>>>> void DDD(int (*x)())
>>>>> {
>>>>> HH(x, x);
>>>>> }
>>>>>
>>>>> DDD correctly simulated by any HH cannot possibly stop running
>>>>> without being aborted. When this is understood and accepted then
>>>>>
>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>
>>>>> ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by any embedded_H is understood
>>>>> to not possibly stop running until aborted.
>>>>>
>>>>> I have all of the details of the machine code and C code for HH and
>>>>> DDD.
>>>>> I can't to the same thing for embedded_H and ⟨Ĥ⟩ ⟨Ĥ⟩ so we have to
>>>>> learn
>>>>> by analogy.
>>>>>
>>>>>>>>> This means that H is not allowed to report on the behavior of the
>>>>>>>>> directly executed P(P).
>>>>>>>> So on which program does it report then?
>>>>>>
>>>>>
>>>>> 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 >
>>>>> If HH(DD,DD) did not correctly determine that its input
>>>>> DOES NOT HALT then DD(DD) would never halt.
>>>>>
>>>>>
>>>>
>>>> Indeed, *only if*. if HH does not halt, then DD does not halt. But
>>>> your claim is that HH halts, because of that DD(DD) *DOES* halt. You
>>>> cannot base a conclusion on something that does not happen.
>>>
>>> You are twisting the meaning of my words.
>>
>> No, your are twisting your own words.
>>
>>> *Verified facts* (some may be beyond your technical competence)
>>
>> Up to now, your have not been able to tell how they were verified. It
>> seems beyond your competence to see the difference between verified
>> facts and wishes. That is twisting the meaning of words.
>>
>>> (1) The input to HH DOES NOT HALT.
>>
>> Only if HH (as part of the input) does not halt.
>> You even proved that this conclusion is a false negative on
>> 05.jun.2024 at 15:59 (CET)
>>
>>>
>>> (2) HH correctly recognizes that its input DOES NOT HALT.
>>
>> Only if HH would not abort, but it does abort.
>
> <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>
>
> I stop at the first big mistake so that we can focus on correcting
> this big mistake.
>
> When
> 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.
>
>
>
And since H doesn't do a "Correct Simulation" per the meaning that
Professor Sipser uses, you can't use that clause.
You are just caught in your own deception. You forget that all Hs in the
problem are the same and all will do the same thing and thus if H thinks
it can abort, then the input naturally becomes halting, so H is wrong.
This is the power of Computations to include copies of other
computations, and the fact that the input is created after the decider
so it can use its code to confound it.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-08 10:17 -0400 |
| Subject | Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis |
| Message-ID | <v41p6d$3cg3t$23@i2pn2.org> |
| In reply to | #106668 |
On 6/8/24 9:32 AM, olcott wrote:
> On 6/8/2024 8:20 AM, Fred. Zwarts wrote:
>> Op 08.jun.2024 om 15:04 schreef olcott:
>>> On 6/8/2024 1:42 AM, Mikko wrote:
>>>> On 2024-06-07 22:26:05 +0000, olcott said:
>>>>
>>>>> On 6/7/2024 4:00 PM, joes wrote:
>>>>>> Am Fri, 07 Jun 2024 09:47:35 -0500 schrieb olcott:
>>>>>>> On 6/7/2024 1:30 AM, Mikko wrote:
>>>>>>>> On 2024-06-06 15:31:36 +0000, olcott said:
>>>>>>>>> On 6/6/2024 10:14 AM, Mikko wrote:
>>>>>>>>>> On 2024-06-06 13:53:58 +0000, olcott said:
>>>>>>>>>>> On 6/6/2024 5:15 AM, Mikko wrote:
>>>>>>>>>>>> On 2024-06-05 13:29:28 +0000, olcott said:
>>>>>>>>>>>>> On 6/5/2024 2:37 AM, Mikko wrote:
>>>>>>>>>>>>>> On 2024-06-04 18:02:03 +0000, olcott said:
>>>>>>
>>>>>>> A simulating halt decider cannot report on what the behavior of a
>>>>>>> non-terminating input actually is because this would take forever.
>>>>>> Exactly. Didn't you say it is allowed to abort?
>>>>>>
>>>>>>> H is not allowed to report on any computation containing its
>>>>>>> actual self
>>>>>>> because Turing machines can only take finite string inputs thus
>>>>>>> cannot
>>>>>>> take Turing machines as inputs.
>>>>>> Bullshit. It can take other machines just fine. It doesn't know about
>>>>>> itself.
>>>>>>
>>>>>
>>>>> No actual Turing machine can be the input to any other actual
>>>>> Turing machine. Turing machines only take finite string inputs.
>>>>
>>>> Any finite string can be an input to some Turing machine.
>>>> Can you prove that a Turing machine is not a finite string?
>>>>
>>>
>>> By definition Turing Machines are not finite strings in the
>>> conventional model. In my x86utm model of computation x86
>>> machine language <is> the input to another function written
>>> in the x86 language.
>>>
>>>> Your own attempts of a conter-proof are not about Turing machines
>>>> but C programs. C programs are finite strings, so a C program
>>>> is a valid input to a C program (and a Turing machine, too).
>>>>
>>>
>>> They are about Turing Machines yet cannot be sufficiently understood
>>> with less than the 100% compete precision of the x86 language. They
>>> x86utm model is required to prove that false assumptions about the
>>> nature of correct simulation are false assumptions.
>>>
>>> void DDD(int (*x)())
>>> {
>>> HH(x, x);
>>> }
>>>
>>> DDD correctly simulated by any HH cannot possibly stop running
>>> without being aborted. When this is understood and accepted then
>>>
>>> When Ĥ is applied to ⟨Ĥ⟩
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>
>>> ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by any embedded_H is understood
>>> to not possibly stop running until aborted.
>>>
>>> I have all of the details of the machine code and C code for HH and DDD.
>>> I can't to the same thing for embedded_H and ⟨Ĥ⟩ ⟨Ĥ⟩ so we have to learn
>>> by analogy.
>>>
>>>>>>> This means that H is not allowed to report on the behavior of the
>>>>>>> directly executed P(P).
>>>>>> So on which program does it report then?
>>>>
>>>
>>> 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 >
>>> If HH(DD,DD) did not correctly determine that its input
>>> DOES NOT HALT then DD(DD) would never halt.
>>>
>>>
>>
>> Indeed, *only if*. if HH does not halt, then DD does not halt. But
>> your claim is that HH halts, because of that DD(DD) *DOES* halt. You
>> cannot base a conclusion on something that does not happen.
>
> You are twisting the meaning of my words.
> *Verified facts* (some may be beyond your technical competence)
> (1) The input to HH DOES NOT HALT.
But you admit it (4) that it halts, because the HH that it calls will
also think it can correctly reject its input as non-halting.
Your logic is just proving it is self-contradictory.
>
> (2) HH correctly recognizes that its input DOES NOT HALT.
Except that since (1) was false, (2) isn't true either, HH only THINKS
it correctly recognizes that its input doessn;t halt
>
> (3) HH is only accountable for the behavior of its input
> because halt deciders COMPUTE THE MAPPING FROM THEIR INPUTS
And, for a halt decider, that behavior is DEFINED to be the behavior of
the machine described by the input, that is the direct execution of
DD(DD) in this case.
>
> (4) DD(DD) only halts because HH correctly rejected its
> input as non-halting.
But the direct exectution DOES Halt, because the HH that it calls does
that same thing and returns 0.
>
> (5) HH is not accountable for the behavior of DD(DD)
> that provably differs from the behavior of DD
> correctly simulated by HH
>
Wrong,
Your claim is in violation of (3) where you call HH a Halt Decider.
Halt Decider decide on the behavior of the direct execution of the
machine represented by their inputs.
If HH's simulation differs from this, then it is NOT a correct
simulation by the definition that allows the replacement of the direct
exectution wiht a correct simulation, so you grounds are incorrect.
Sorry, you are just showing how little you understand of what you are
talking about. The problem is you never learned the facts, and have
gaslite yourself with your own misconceptions that you fail to
understand what is actually true.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-08 09:36 -0400 |
| Subject | Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis |
| Message-ID | <v41mot$3cg3t$13@i2pn2.org> |
| In reply to | #106660 |
On 6/8/24 9:04 AM, olcott wrote:
> On 6/8/2024 1:42 AM, Mikko wrote:
>> On 2024-06-07 22:26:05 +0000, olcott said:
>>
>>> On 6/7/2024 4:00 PM, joes wrote:
>>>> Am Fri, 07 Jun 2024 09:47:35 -0500 schrieb olcott:
>>>>> On 6/7/2024 1:30 AM, Mikko wrote:
>>>>>> On 2024-06-06 15:31:36 +0000, olcott said:
>>>>>>> On 6/6/2024 10:14 AM, Mikko wrote:
>>>>>>>> On 2024-06-06 13:53:58 +0000, olcott said:
>>>>>>>>> On 6/6/2024 5:15 AM, Mikko wrote:
>>>>>>>>>> On 2024-06-05 13:29:28 +0000, olcott said:
>>>>>>>>>>> On 6/5/2024 2:37 AM, Mikko wrote:
>>>>>>>>>>>> On 2024-06-04 18:02:03 +0000, olcott said:
>>>>
>>>>> A simulating halt decider cannot report on what the behavior of a
>>>>> non-terminating input actually is because this would take forever.
>>>> Exactly. Didn't you say it is allowed to abort?
>>>>
>>>>> H is not allowed to report on any computation containing its actual
>>>>> self
>>>>> because Turing machines can only take finite string inputs thus cannot
>>>>> take Turing machines as inputs.
>>>> Bullshit. It can take other machines just fine. It doesn't know about
>>>> itself.
>>>>
>>>
>>> No actual Turing machine can be the input to any other actual
>>> Turing machine. Turing machines only take finite string inputs.
>>
>> Any finite string can be an input to some Turing machine.
>> Can you prove that a Turing machine is not a finite string?
>>
>
> By definition Turing Machines are not finite strings in the
> conventional model. In my x86utm model of computation x86
> machine language <is> the input to another function written
> in the x86 language.
So?
Turing Machines can be fully represented by a finite string.
And, your x86utm takes the input as machine code, but you talk about it
deciding on the FUNCTION DD, which isn't that machine code, but the
machine code is just a REPRESENTATION of that function.
Just like what was done to a Turing Machine.
>
>> Your own attempts of a conter-proof are not about Turing machines
>> but C programs. C programs are finite strings, so a C program
>> is a valid input to a C program (and a Turing machine, too).
>>
>
> They are about Turing Machines yet cannot be sufficiently understood
> with less than the 100% compete precision of the x86 language. They
> x86utm model is required to prove that false assumptions about the
> nature of correct simulation are false assumptions.
>
> void DDD(int (*x)())
Why did we jump to DDD now?
> {
> HH(x, x);
> }
>
> DDD correctly simulated by any HH cannot possibly stop running
> without being aborted. When this is understood and accepted then
>
> When Ĥ is applied to ⟨Ĥ⟩
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
> ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by any embedded_H is understood
> to not possibly stop running until aborted.
But the problem doesn't ask about H^ applied to (H^) correctly simulated
by embedded_H, but about the behavior of H^ applied to (H^) when run.
>
> I have all of the details of the machine code and C code for HH and DDD.
> I can't to the same thing for embedded_H and ⟨Ĥ⟩ ⟨Ĥ⟩ so we have to learn
> by analogy.
>
>>>>> This means that H is not allowed to report on the behavior of the
>>>>> directly executed P(P).
>>>> So on which program does it report then?
>>
>
> 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.
You switched back to DD, which isn't defined here, just by your previous
context as just like DDD
You just admitted to using lying with double speak, by admitting that
DDs execution, which first looks to be an infinite recursion WILL STOP
ITSELF by the HH that DD calls deciding to abort its simulation and
returning to DD, and thus your claim "infinite recursion" isn't.
You try to conveniently forget that what ever you make your outer HH do
that is deciding on DD, because that DD was built on the HH that you end
up claiming to be correct, its HH will also do.
>
> If HH(DD,DD) did not correctly determine that its input
> DOES NOT HALT then DD(DD) would never halt.
>
>
Right, but that is a DIFFERENT HH. You don't seem to understand that a
program is the program that it is, and not the program that it isn't.
Programs are not like people, with a choice of what they will do, but
are deterministic entities whose behavior is fully fixed at their
creation by their programming.
Perhaps your problem is that you gave up your free will for something,
and have gotten stuck in your own deterministic hell.
[toc] | [prev] | [next] | [standalone]
| From | joes <noreply@example.com> |
|---|---|
| Date | 2024-06-08 13:46 +0000 |
| Subject | Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis |
| Message-ID | <v41nav$3crhv$1@i2pn2.org> |
| In reply to | #106660 |
Am Sat, 08 Jun 2024 08:04:14 -0500 schrieb olcott: > On 6/8/2024 1:42 AM, Mikko wrote: >> On 2024-06-07 22:26:05 +0000, olcott said: >>> On 6/7/2024 4:00 PM, joes wrote: >>>> Am Fri, 07 Jun 2024 09:47:35 -0500 schrieb olcott: >>>>> On 6/7/2024 1:30 AM, Mikko wrote: >>>>>> On 2024-06-06 15:31:36 +0000, olcott said: >>>>>>> On 6/6/2024 10:14 AM, Mikko wrote: >>>>>>>> On 2024-06-06 13:53:58 +0000, olcott said: >>>>>>>>> On 6/6/2024 5:15 AM, Mikko wrote: >>>>>>>>>> On 2024-06-05 13:29:28 +0000, olcott said: >>>>>>>>>>> On 6/5/2024 2:37 AM, Mikko wrote: >>>>>>>>>>>> On 2024-06-04 18:02:03 +0000, olcott said: >> Any finite string can be an input to some Turing machine. >> Can you prove that a Turing machine is not a finite string? > By definition Turing Machines are not finite strings in the conventional > model. In my x86utm model of computation x86 machine language <is> the > input to another function written in the x86 language. In your model, the machine code is also finite. >> Your own attempts of a conter-proof are not about Turing machines but C >> programs. C programs are finite strings, so a C program is a valid >> input to a C program (and a Turing machine, too). > They are about Turing Machines yet cannot be sufficiently understood > with less than the 100% compete precision of the x86 language. They > x86utm model is required to prove that false assumptions about the > nature of correct simulation are false assumptions. You can't hide behind an x86 implementation. The same arguments hold. Which assumptions are false? > I have all of the details of the machine code and C code for HH and DDD. > I can't to the same thing for embedded_H and ⟨Ĥ⟩ ⟨Ĥ⟩ so we have to learn > by analogy. Why can't you do that? The simulator can simulate itself. >>>>> This means that H is not allowed to report on the behavior of the >>>>> directly executed P(P). >>>> So on which program does it report then? > 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. > If HH(DD,DD) did not correctly determine that its input DOES NOT HALT > then DD(DD) would never halt. That doesn't make sense. The function halts because a simulator says it doesn't? -- joes
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-08 09:02 -0500 |
| Subject | Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis |
| Message-ID | <v41o9b$2kanc$11@dont-email.me> |
| In reply to | #106675 |
On 6/8/2024 8:46 AM, joes wrote:
> Am Sat, 08 Jun 2024 08:04:14 -0500 schrieb olcott:
>> On 6/8/2024 1:42 AM, Mikko wrote:
>>> On 2024-06-07 22:26:05 +0000, olcott said:
>>>> On 6/7/2024 4:00 PM, joes wrote:
>>>>> Am Fri, 07 Jun 2024 09:47:35 -0500 schrieb olcott:
>>>>>> On 6/7/2024 1:30 AM, Mikko wrote:
>>>>>>> On 2024-06-06 15:31:36 +0000, olcott said:
>>>>>>>> On 6/6/2024 10:14 AM, Mikko wrote:
>>>>>>>>> On 2024-06-06 13:53:58 +0000, olcott said:
>>>>>>>>>> On 6/6/2024 5:15 AM, Mikko wrote:
>>>>>>>>>>> On 2024-06-05 13:29:28 +0000, olcott said:
>>>>>>>>>>>> On 6/5/2024 2:37 AM, Mikko wrote:
>>>>>>>>>>>>> On 2024-06-04 18:02:03 +0000, olcott said:
>
>>> Any finite string can be an input to some Turing machine.
>>> Can you prove that a Turing machine is not a finite string?
>> By definition Turing Machines are not finite strings in the conventional
>> model. In my x86utm model of computation x86 machine language <is> the
>> input to another function written in the x86 language.
> In your model, the machine code is also finite.
>
*That is correct so I rewrote my proof to fully account for that*
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.
>>> Your own attempts of a conter-proof are not about Turing machines but C
The C code forms an isomorphism to the peter Linz Turing machine
proof that cannot even be understood to be an isomorphism until
after the x86utm code is 100% fully understood.
>>> programs. C programs are finite strings, so a C program is a valid
>>> input to a C program (and a Turing machine, too).
>> They are about Turing Machines yet cannot be sufficiently understood
>> with less than the 100% compete precision of the x86 language. They
>> x86utm model is required to prove that false assumptions about the
>> nature of correct simulation are false assumptions.
> You can't hide behind an x86 implementation. The same arguments hold.
> Which assumptions are false?
>
>> I have all of the details of the machine code and C code for HH and DDD.
>> I can't to the same thing for embedded_H and ⟨Ĥ⟩ ⟨Ĥ⟩ so we have to learn
>> by analogy.
> Why can't you do that? The simulator can simulate itself.
>
>>>>>> This means that H is not allowed to report on the behavior of the
>>>>>> directly executed P(P).
>>>>> So on which program does it report then?
>> 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.
>> If HH(DD,DD) did not correctly determine that its input DOES NOT HALT
>> then DD(DD) would never halt.
> That doesn't make sense. The function halts because a simulator says it
> doesn't?
>
It is a verified iff (if and only if) you have the required
prerequisite knowledge of (a) and (b) and carefully study
what the possible execution traces are for DDD correctly
simulated by any x86 emulator HH.
Saying that I am wrong without this mandatory prerequisite
knowledge or saying that I am wrong without carefully studying
my proof <is> defamation: a reckless disregard for the truth.
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 10:31 -0400 |
| Subject | Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis |
| Message-ID | <v41q0v$3cg3s$1@i2pn2.org> |
| In reply to | #106686 |
On 6/8/24 10:02 AM, olcott wrote:
> On 6/8/2024 8:46 AM, joes wrote:
>> Am Sat, 08 Jun 2024 08:04:14 -0500 schrieb olcott:
>>> On 6/8/2024 1:42 AM, Mikko wrote:
>>>> On 2024-06-07 22:26:05 +0000, olcott said:
>>>>> On 6/7/2024 4:00 PM, joes wrote:
>>>>>> Am Fri, 07 Jun 2024 09:47:35 -0500 schrieb olcott:
>>>>>>> On 6/7/2024 1:30 AM, Mikko wrote:
>>>>>>>> On 2024-06-06 15:31:36 +0000, olcott said:
>>>>>>>>> On 6/6/2024 10:14 AM, Mikko wrote:
>>>>>>>>>> On 2024-06-06 13:53:58 +0000, olcott said:
>>>>>>>>>>> On 6/6/2024 5:15 AM, Mikko wrote:
>>>>>>>>>>>> On 2024-06-05 13:29:28 +0000, olcott said:
>>>>>>>>>>>>> On 6/5/2024 2:37 AM, Mikko wrote:
>>>>>>>>>>>>>> On 2024-06-04 18:02:03 +0000, olcott said:
>>
>>>> Any finite string can be an input to some Turing machine.
>>>> Can you prove that a Turing machine is not a finite string?
>>> By definition Turing Machines are not finite strings in the conventional
>>> model. In my x86utm model of computation x86 machine language <is> the
>>> input to another function written in the x86 language.
>> In your model, the machine code is also finite.
>>
>
> *That is correct so I rewrote my proof to fully account for that*
>
> 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.
Which isn't a proof, but a cla
>
> 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.
No, a correct x86 emulator will follow the call HH into HH.
Now you are mixing H and HH was that intentional?
Remever the input is supposed to be calling the decider that you are
going to claim is correct, have you gone farther down your stram man path?
>
>>>> Your own attempts of a conter-proof are not about Turing machines but C
>
> The C code forms an isomorphism to the peter Linz Turing machine
> proof that cannot even be understood to be an isomorphism until
> after the x86utm code is 100% fully understood.
Nope.
The problem is that the Linz Turing Machines have H and H^ as two
totally independent machines.
Your C code is ONE Program interacting with itself.
A correct equivalent should have H take a description of the input that
it loads into a isolated virtual memory space that can't reference
anything outside it, and then H simulates that program in that virtual
memory space.
>
>>>> programs. C programs are finite strings, so a C program is a valid
>>>> input to a C program (and a Turing machine, too).
>>> They are about Turing Machines yet cannot be sufficiently understood
>>> with less than the 100% compete precision of the x86 language. They
>>> x86utm model is required to prove that false assumptions about the
>>> nature of correct simulation are false assumptions.
>> You can't hide behind an x86 implementation. The same arguments hold.
>> Which assumptions are false?
>>
>>> I have all of the details of the machine code and C code for HH and DDD.
>>> I can't to the same thing for embedded_H and ⟨Ĥ⟩ ⟨Ĥ⟩ so we have to learn
>>> by analogy.
>> Why can't you do that? The simulator can simulate itself.
>>
>>>>>>> This means that H is not allowed to report on the behavior of the
>>>>>>> directly executed P(P).
>>>>>> So on which program does it report then?
>>> 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.
>>> If HH(DD,DD) did not correctly determine that its input DOES NOT HALT
>>> then DD(DD) would never halt.
>> That doesn't make sense. The function halts because a simulator says it
>> doesn't?
>>
>
> It is a verified iff (if and only if) you have the required
> prerequisite knowledge of (a) and (b) and carefully study
> what the possible execution traces are for DDD correctly
> simulated by any x86 emulator HH.
Nope. No one has "verified it"
>
> Saying that I am wrong without this mandatory prerequisite
> knowledge or saying that I am wrong without carefully studying
> my proof <is> defamation: a reckless disregard for the truth.
>
> 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.
Which isn't a "Proof" but a claim.
To prove this, you need to state the sequence of truth-perserving
operations that take you from your "facts" above to that claim.
>
> 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.
>
>
Nope, it can't becuase the correct 86 emulation of DDD must go into the
instructions of HH and will NEVER return to the begining of DDD again,
only the simulation of those instructions. That is the actual behavior
the x86 instructions presented simulated in the order presented to the
simulator. The fact you haven't shown the code for HH either says we
can't actually DO the simulation, or to do so, we first pair the DDD
with a specific HH that simulates it, and every HH is doing a different
simulation.
And, it seems your HH has lost its definition of being the decider that
D was supposed to be refuting, so it seems you have gone farther down
the straw man path.
[toc] | [prev] | [next] | [standalone]
| From | Mikko <mikko.levanto@iki.fi> |
|---|---|
| Date | 2024-06-09 11:52 +0300 |
| Subject | Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis |
| Message-ID | <v43qfj$3bnt7$1@dont-email.me> |
| In reply to | #106675 |
On 2024-06-08 13:46:07 +0000, joes said: > Am Sat, 08 Jun 2024 08:04:14 -0500 schrieb olcott: >> On 6/8/2024 1:42 AM, Mikko wrote: >>> On 2024-06-07 22:26:05 +0000, olcott said: >>>> On 6/7/2024 4:00 PM, joes wrote: >>>>> Am Fri, 07 Jun 2024 09:47:35 -0500 schrieb olcott: >>>>>> On 6/7/2024 1:30 AM, Mikko wrote: >>>>>>> On 2024-06-06 15:31:36 +0000, olcott said: >>>>>>>> On 6/6/2024 10:14 AM, Mikko wrote: >>>>>>>>> On 2024-06-06 13:53:58 +0000, olcott said: >>>>>>>>>> On 6/6/2024 5:15 AM, Mikko wrote: >>>>>>>>>>> On 2024-06-05 13:29:28 +0000, olcott said: >>>>>>>>>>>> On 6/5/2024 2:37 AM, Mikko wrote: >>>>>>>>>>>>> On 2024-06-04 18:02:03 +0000, olcott said: > >>> Any finite string can be an input to some Turing machine. >>> Can you prove that a Turing machine is not a finite string? >> By definition Turing Machines are not finite strings in the conventional >> model. In my x86utm model of computation x86 machine language <is> the >> input to another function written in the x86 language. > In your model, the machine code is also finite. > >>> Your own attempts of a conter-proof are not about Turing machines but C >>> programs. C programs are finite strings, so a C program is a valid >>> input to a C program (and a Turing machine, too). >> They are about Turing Machines yet cannot be sufficiently understood >> with less than the 100% compete precision of the x86 language. They >> x86utm model is required to prove that false assumptions about the >> nature of correct simulation are false assumptions. > You can't hide behind an x86 implementation. The same arguments hold. > Which assumptions are false? > >> I have all of the details of the machine code and C code for HH and DDD. >> I can't to the same thing for embedded_H and ⟨Ĥ⟩ ⟨Ĥ⟩ so we have to learn >> by analogy. > Why can't you do that? The simulator can simulate itself. > >>>>>> This means that H is not allowed to report on the behavior of the >>>>>> directly executed P(P). >>>>> So on which program does it report then? >> 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. >> If HH(DD,DD) did not correctly determine that its input DOES NOT HALT >> then DD(DD) would never halt. > That doesn't make sense. The function halts because a simulator says it > doesn't? You missed an important point: The function halts because a simulator CORRECTLY says it doesn't. -- Mikko
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-09 09:03 -0500 |
| Subject | Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis |
| Message-ID | <v44cms$3harn$6@dont-email.me> |
| In reply to | #106763 |
On 6/9/2024 3:52 AM, Mikko wrote: > On 2024-06-08 13:46:07 +0000, joes said: > >> Am Sat, 08 Jun 2024 08:04:14 -0500 schrieb olcott: >>> On 6/8/2024 1:42 AM, Mikko wrote: >>>> On 2024-06-07 22:26:05 +0000, olcott said: >>>>> On 6/7/2024 4:00 PM, joes wrote: >>>>>> Am Fri, 07 Jun 2024 09:47:35 -0500 schrieb olcott: >>>>>>> On 6/7/2024 1:30 AM, Mikko wrote: >>>>>>>> On 2024-06-06 15:31:36 +0000, olcott said: >>>>>>>>> On 6/6/2024 10:14 AM, Mikko wrote: >>>>>>>>>> On 2024-06-06 13:53:58 +0000, olcott said: >>>>>>>>>>> On 6/6/2024 5:15 AM, Mikko wrote: >>>>>>>>>>>> On 2024-06-05 13:29:28 +0000, olcott said: >>>>>>>>>>>>> On 6/5/2024 2:37 AM, Mikko wrote: >>>>>>>>>>>>>> On 2024-06-04 18:02:03 +0000, olcott said: >> >>>> Any finite string can be an input to some Turing machine. >>>> Can you prove that a Turing machine is not a finite string? >>> By definition Turing Machines are not finite strings in the conventional >>> model. In my x86utm model of computation x86 machine language <is> the >>> input to another function written in the x86 language. >> In your model, the machine code is also finite. >> >>>> Your own attempts of a conter-proof are not about Turing machines but C >>>> programs. C programs are finite strings, so a C program is a valid >>>> input to a C program (and a Turing machine, too). >>> They are about Turing Machines yet cannot be sufficiently understood >>> with less than the 100% compete precision of the x86 language. They >>> x86utm model is required to prove that false assumptions about the >>> nature of correct simulation are false assumptions. >> You can't hide behind an x86 implementation. The same arguments hold. >> Which assumptions are false? >> >>> I have all of the details of the machine code and C code for HH and DDD. >>> I can't to the same thing for embedded_H and ⟨Ĥ⟩ ⟨Ĥ⟩ so we have to learn >>> by analogy. >> Why can't you do that? The simulator can simulate itself. >> >>>>>>> This means that H is not allowed to report on the behavior of the >>>>>>> directly executed P(P). >>>>>> So on which program does it report then? >>> 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. >>> If HH(DD,DD) did not correctly determine that its input DOES NOT HALT >>> then DD(DD) would never halt. >> That doesn't make sense. The function halts because a simulator says it >> doesn't? > > You missed an important point: The function halts because a simulator > CORRECTLY says it doesn't. > The first recursive call halts because the second recursive call has been aborted. That the second recursive call had to be aborted proves that the entire computation is non-halting. 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. If HH(DD,DD) did not correctly determine that its input DOES NOT HALT then DD(DD) would never halt. -- Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Mikko <mikko.levanto@iki.fi> |
|---|---|
| Date | 2024-06-09 18:13 +0300 |
| Subject | Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis |
| Message-ID | <v44gq7$3jbv3$1@dont-email.me> |
| In reply to | #106774 |
On 2024-06-09 14:03:08 +0000, olcott said: > On 6/9/2024 3:52 AM, Mikko wrote: >> On 2024-06-08 13:46:07 +0000, joes said: >> >>> Am Sat, 08 Jun 2024 08:04:14 -0500 schrieb olcott: >>>> On 6/8/2024 1:42 AM, Mikko wrote: >>>>> On 2024-06-07 22:26:05 +0000, olcott said: >>>>>> On 6/7/2024 4:00 PM, joes wrote: >>>>>>> Am Fri, 07 Jun 2024 09:47:35 -0500 schrieb olcott: >>>>>>>> On 6/7/2024 1:30 AM, Mikko wrote: >>>>>>>>> On 2024-06-06 15:31:36 +0000, olcott said: >>>>>>>>>> On 6/6/2024 10:14 AM, Mikko wrote: >>>>>>>>>>> On 2024-06-06 13:53:58 +0000, olcott said: >>>>>>>>>>>> On 6/6/2024 5:15 AM, Mikko wrote: >>>>>>>>>>>>> On 2024-06-05 13:29:28 +0000, olcott said: >>>>>>>>>>>>>> On 6/5/2024 2:37 AM, Mikko wrote: >>>>>>>>>>>>>>> On 2024-06-04 18:02:03 +0000, olcott said: >>> >>>>> Any finite string can be an input to some Turing machine. >>>>> Can you prove that a Turing machine is not a finite string? >>>> By definition Turing Machines are not finite strings in the conventional >>>> model. In my x86utm model of computation x86 machine language <is> the >>>> input to another function written in the x86 language. >>> In your model, the machine code is also finite. >>> >>>>> Your own attempts of a conter-proof are not about Turing machines but C >>>>> programs. C programs are finite strings, so a C program is a valid >>>>> input to a C program (and a Turing machine, too). >>>> They are about Turing Machines yet cannot be sufficiently understood >>>> with less than the 100% compete precision of the x86 language. They >>>> x86utm model is required to prove that false assumptions about the >>>> nature of correct simulation are false assumptions. >>> You can't hide behind an x86 implementation. The same arguments hold. >>> Which assumptions are false? >>> >>>> I have all of the details of the machine code and C code for HH and DDD. >>>> I can't to the same thing for embedded_H and ⟨Ĥ⟩ ⟨Ĥ⟩ so we have to learn >>>> by analogy. >>> Why can't you do that? The simulator can simulate itself. >>> >>>>>>>> This means that H is not allowed to report on the behavior of the >>>>>>>> directly executed P(P). >>>>>>> So on which program does it report then? >>>> 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. >>>> If HH(DD,DD) did not correctly determine that its input DOES NOT HALT >>>> then DD(DD) would never halt. >>> That doesn't make sense. The function halts because a simulator says it >>> doesn't? >> >> You missed an important point: The function halts because a simulator >> CORRECTLY says it doesn't. >> > > The first recursive call halts because the second recursive > call has been aborted. That the second recursive call had to > be aborted proves that the entire computation is non-halting. > > 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. > > If HH(DD,DD) did not correctly determine that its input > DOES NOT HALT then DD(DD) would never halt. Nice to see that you don't disagree with my silly remark. -- Mikko
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-09 11:15 -0500 |
| Subject | Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis |
| Message-ID | <v44kec$3jnc8$6@dont-email.me> |
| In reply to | #106784 |
On 6/9/2024 10:13 AM, Mikko wrote: > On 2024-06-09 14:03:08 +0000, olcott said: > >> On 6/9/2024 3:52 AM, Mikko wrote: >>> On 2024-06-08 13:46:07 +0000, joes said: >>> >>>> Am Sat, 08 Jun 2024 08:04:14 -0500 schrieb olcott: >>>>> On 6/8/2024 1:42 AM, Mikko wrote: >>>>>> On 2024-06-07 22:26:05 +0000, olcott said: >>>>>>> On 6/7/2024 4:00 PM, joes wrote: >>>>>>>> Am Fri, 07 Jun 2024 09:47:35 -0500 schrieb olcott: >>>>>>>>> On 6/7/2024 1:30 AM, Mikko wrote: >>>>>>>>>> On 2024-06-06 15:31:36 +0000, olcott said: >>>>>>>>>>> On 6/6/2024 10:14 AM, Mikko wrote: >>>>>>>>>>>> On 2024-06-06 13:53:58 +0000, olcott said: >>>>>>>>>>>>> On 6/6/2024 5:15 AM, Mikko wrote: >>>>>>>>>>>>>> On 2024-06-05 13:29:28 +0000, olcott said: >>>>>>>>>>>>>>> On 6/5/2024 2:37 AM, Mikko wrote: >>>>>>>>>>>>>>>> On 2024-06-04 18:02:03 +0000, olcott said: >>>> >>>>>> Any finite string can be an input to some Turing machine. >>>>>> Can you prove that a Turing machine is not a finite string? >>>>> By definition Turing Machines are not finite strings in the >>>>> conventional >>>>> model. In my x86utm model of computation x86 machine language <is> the >>>>> input to another function written in the x86 language. >>>> In your model, the machine code is also finite. >>>> >>>>>> Your own attempts of a conter-proof are not about Turing machines >>>>>> but C >>>>>> programs. C programs are finite strings, so a C program is a valid >>>>>> input to a C program (and a Turing machine, too). >>>>> They are about Turing Machines yet cannot be sufficiently understood >>>>> with less than the 100% compete precision of the x86 language. They >>>>> x86utm model is required to prove that false assumptions about the >>>>> nature of correct simulation are false assumptions. >>>> You can't hide behind an x86 implementation. The same arguments hold. >>>> Which assumptions are false? >>>> >>>>> I have all of the details of the machine code and C code for HH and >>>>> DDD. >>>>> I can't to the same thing for embedded_H and ⟨Ĥ⟩ ⟨Ĥ⟩ so we have to >>>>> learn >>>>> by analogy. >>>> Why can't you do that? The simulator can simulate itself. >>>> >>>>>>>>> This means that H is not allowed to report on the behavior of the >>>>>>>>> directly executed P(P). >>>>>>>> So on which program does it report then? >>>>> 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. >>>>> If HH(DD,DD) did not correctly determine that its input DOES NOT HALT >>>>> then DD(DD) would never halt. >>>> That doesn't make sense. The function halts because a simulator says it >>>> doesn't? >>> >>> You missed an important point: The function halts because a simulator >>> CORRECTLY says it doesn't. >>> >> >> The first recursive call halts because the second recursive >> call has been aborted. That the second recursive call had to >> be aborted proves that the entire computation is non-halting. >> >> 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. >> >> If HH(DD,DD) did not correctly determine that its input >> DOES NOT HALT then DD(DD) would never halt. > > Nice to see that you don't disagree with my silly remark. > Directly executed DD(DD) and DD correctly simulated by HH are two different sequences of configurations and HH is only held accountable for the latter. The everyone disagrees with this verified fact that HH correctly simulated by DD DOES NOT HALT is less than no rebuttal at all. -- Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | joes <noreply@example.com> |
|---|---|
| Date | 2024-06-09 17:47 +0000 |
| Subject | Re: How Partial Simulations correctly determine non-halting |
| Message-ID | <v44ps5$3g17f$3@i2pn2.org> |
| In reply to | #106793 |
Am Sun, 09 Jun 2024 11:15:08 -0500 schrieb olcott: > On 6/9/2024 10:13 AM, Mikko wrote: >> On 2024-06-09 14:03:08 +0000, olcott said: >>> On 6/9/2024 3:52 AM, Mikko wrote: >>>> On 2024-06-08 13:46:07 +0000, joes said: >>>>> Am Sat, 08 Jun 2024 08:04:14 -0500 schrieb olcott: >>>>>> On 6/8/2024 1:42 AM, Mikko wrote: >>>>>>> On 2024-06-07 22:26:05 +0000, olcott said: >>>>>>>> On 6/7/2024 4:00 PM, joes wrote: >>>>>>>>> Am Fri, 07 Jun 2024 09:47:35 -0500 schrieb olcott: >>>>>>>>>> On 6/7/2024 1:30 AM, Mikko wrote: >>>>>>>>>>> On 2024-06-06 15:31:36 +0000, olcott said: >>>>>>>>>>>> On 6/6/2024 10:14 AM, Mikko wrote: >>>>>>>>>>>>> On 2024-06-06 13:53:58 +0000, olcott said: >>>>>>>>>>>>>> On 6/6/2024 5:15 AM, Mikko wrote: >>>>>>>>>>>>>>> On 2024-06-05 13:29:28 +0000, olcott said: >>>>>>>>>>>>>>>> On 6/5/2024 2:37 AM, Mikko wrote: >>>>>>>>>>>>>>>>> On 2024-06-04 18:02:03 +0000, olcott said: > Directly executed DD(DD) and DD correctly simulated by HH are two > different sequences of configurations and HH is only held accountable > for the latter. As a simulator, HH must simulate the same sequence. > The everyone disagrees with this verified fact that HH correctly > simulated by DD DOES NOT HALT is less than no rebuttal at all. If the simulated DD doesn't halt, its direct execution can't halt either. -- joes
[toc] | [prev] | [next] | [standalone]
| From | Mikko <mikko.levanto@iki.fi> |
|---|---|
| Date | 2024-06-10 10:54 +0300 |
| Subject | Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis |
| Message-ID | <v46bfb$9dj2$1@dont-email.me> |
| In reply to | #106793 |
On 2024-06-09 16:15:08 +0000, olcott said: > On 6/9/2024 10:13 AM, Mikko wrote: >> On 2024-06-09 14:03:08 +0000, olcott said: >> >>> On 6/9/2024 3:52 AM, Mikko wrote: >>>> On 2024-06-08 13:46:07 +0000, joes said: >>>> >>>>> Am Sat, 08 Jun 2024 08:04:14 -0500 schrieb olcott: >>>>>> On 6/8/2024 1:42 AM, Mikko wrote: >>>>>>> On 2024-06-07 22:26:05 +0000, olcott said: >>>>>>>> On 6/7/2024 4:00 PM, joes wrote: >>>>>>>>> Am Fri, 07 Jun 2024 09:47:35 -0500 schrieb olcott: >>>>>>>>>> On 6/7/2024 1:30 AM, Mikko wrote: >>>>>>>>>>> On 2024-06-06 15:31:36 +0000, olcott said: >>>>>>>>>>>> On 6/6/2024 10:14 AM, Mikko wrote: >>>>>>>>>>>>> On 2024-06-06 13:53:58 +0000, olcott said: >>>>>>>>>>>>>> On 6/6/2024 5:15 AM, Mikko wrote: >>>>>>>>>>>>>>> On 2024-06-05 13:29:28 +0000, olcott said: >>>>>>>>>>>>>>>> On 6/5/2024 2:37 AM, Mikko wrote: >>>>>>>>>>>>>>>>> On 2024-06-04 18:02:03 +0000, olcott said: >>>>> >>>>>>> Any finite string can be an input to some Turing machine. >>>>>>> Can you prove that a Turing machine is not a finite string? >>>>>> By definition Turing Machines are not finite strings in the conventional >>>>>> model. In my x86utm model of computation x86 machine language <is> the >>>>>> input to another function written in the x86 language. >>>>> In your model, the machine code is also finite. >>>>> >>>>>>> Your own attempts of a conter-proof are not about Turing machines but C >>>>>>> programs. C programs are finite strings, so a C program is a valid >>>>>>> input to a C program (and a Turing machine, too). >>>>>> They are about Turing Machines yet cannot be sufficiently understood >>>>>> with less than the 100% compete precision of the x86 language. They >>>>>> x86utm model is required to prove that false assumptions about the >>>>>> nature of correct simulation are false assumptions. >>>>> You can't hide behind an x86 implementation. The same arguments hold. >>>>> Which assumptions are false? >>>>> >>>>>> I have all of the details of the machine code and C code for HH and DDD. >>>>>> I can't to the same thing for embedded_H and ⟨Ĥ⟩ ⟨Ĥ⟩ so we have to learn >>>>>> by analogy. >>>>> Why can't you do that? The simulator can simulate itself. >>>>> >>>>>>>>>> This means that H is not allowed to report on the behavior of the >>>>>>>>>> directly executed P(P). >>>>>>>>> So on which program does it report then? >>>>>> 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. >>>>>> If HH(DD,DD) did not correctly determine that its input DOES NOT HALT >>>>>> then DD(DD) would never halt. >>>>> That doesn't make sense. The function halts because a simulator says it >>>>> doesn't? >>>> >>>> You missed an important point: The function halts because a simulator >>>> CORRECTLY says it doesn't. >>>> >>> >>> The first recursive call halts because the second recursive >>> call has been aborted. That the second recursive call had to >>> be aborted proves that the entire computation is non-halting. >>> >>> 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. >>> >>> If HH(DD,DD) did not correctly determine that its input >>> DOES NOT HALT then DD(DD) would never halt. >> >> Nice to see that you don't disagree with my silly remark. >> > > Directly executed DD(DD) and DD correctly simulated by HH are > two different sequences of configurations and HH is only held > accountable for the latter. > > The everyone disagrees with this verified fact that > HH correctly simulated by DD DOES NOT HALT is less > than no rebuttal at all. Still nice to see that you don't disagree with my silly remark. Though might get boring at some point. Perhaps I should post another silly remark before that. -- Mikko
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-10 10:22 -0500 |
| Subject | Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis |
| Message-ID | <v475mt$ggn5$9@dont-email.me> |
| In reply to | #106871 |
On 6/10/2024 2:54 AM, Mikko wrote: > On 2024-06-09 16:15:08 +0000, olcott said: > >> On 6/9/2024 10:13 AM, Mikko wrote: >>> On 2024-06-09 14:03:08 +0000, olcott said: >>> >>>> On 6/9/2024 3:52 AM, Mikko wrote: >>>>> On 2024-06-08 13:46:07 +0000, joes said: >>>>> >>>>>> Am Sat, 08 Jun 2024 08:04:14 -0500 schrieb olcott: >>>>>>> On 6/8/2024 1:42 AM, Mikko wrote: >>>>>>>> On 2024-06-07 22:26:05 +0000, olcott said: >>>>>>>>> On 6/7/2024 4:00 PM, joes wrote: >>>>>>>>>> Am Fri, 07 Jun 2024 09:47:35 -0500 schrieb olcott: >>>>>>>>>>> On 6/7/2024 1:30 AM, Mikko wrote: >>>>>>>>>>>> On 2024-06-06 15:31:36 +0000, olcott said: >>>>>>>>>>>>> On 6/6/2024 10:14 AM, Mikko wrote: >>>>>>>>>>>>>> On 2024-06-06 13:53:58 +0000, olcott said: >>>>>>>>>>>>>>> On 6/6/2024 5:15 AM, Mikko wrote: >>>>>>>>>>>>>>>> On 2024-06-05 13:29:28 +0000, olcott said: >>>>>>>>>>>>>>>>> On 6/5/2024 2:37 AM, Mikko wrote: >>>>>>>>>>>>>>>>>> On 2024-06-04 18:02:03 +0000, olcott said: >>>>>> >>>>>>>> Any finite string can be an input to some Turing machine. >>>>>>>> Can you prove that a Turing machine is not a finite string? >>>>>>> By definition Turing Machines are not finite strings in the >>>>>>> conventional >>>>>>> model. In my x86utm model of computation x86 machine language >>>>>>> <is> the >>>>>>> input to another function written in the x86 language. >>>>>> In your model, the machine code is also finite. >>>>>> >>>>>>>> Your own attempts of a conter-proof are not about Turing >>>>>>>> machines but C >>>>>>>> programs. C programs are finite strings, so a C program is a valid >>>>>>>> input to a C program (and a Turing machine, too). >>>>>>> They are about Turing Machines yet cannot be sufficiently understood >>>>>>> with less than the 100% compete precision of the x86 language. They >>>>>>> x86utm model is required to prove that false assumptions about the >>>>>>> nature of correct simulation are false assumptions. >>>>>> You can't hide behind an x86 implementation. The same arguments hold. >>>>>> Which assumptions are false? >>>>>> >>>>>>> I have all of the details of the machine code and C code for HH >>>>>>> and DDD. >>>>>>> I can't to the same thing for embedded_H and ⟨Ĥ⟩ ⟨Ĥ⟩ so we have >>>>>>> to learn >>>>>>> by analogy. >>>>>> Why can't you do that? The simulator can simulate itself. >>>>>> >>>>>>>>>>> This means that H is not allowed to report on the behavior of >>>>>>>>>>> the >>>>>>>>>>> directly executed P(P). >>>>>>>>>> So on which program does it report then? >>>>>>> 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. >>>>>>> If HH(DD,DD) did not correctly determine that its input DOES NOT >>>>>>> HALT >>>>>>> then DD(DD) would never halt. >>>>>> That doesn't make sense. The function halts because a simulator >>>>>> says it >>>>>> doesn't? >>>>> >>>>> You missed an important point: The function halts because a simulator >>>>> CORRECTLY says it doesn't. >>>>> >>>> >>>> The first recursive call halts because the second recursive >>>> call has been aborted. That the second recursive call had to >>>> be aborted proves that the entire computation is non-halting. >>>> >>>> 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. >>>> >>>> If HH(DD,DD) did not correctly determine that its input >>>> DOES NOT HALT then DD(DD) would never halt. >>> >>> Nice to see that you don't disagree with my silly remark. >>> >> >> Directly executed DD(DD) and DD correctly simulated by HH are >> two different sequences of configurations and HH is only held >> accountable for the latter. >> >> The everyone disagrees with this verified fact that >> HH correctly simulated by DD DOES NOT HALT is less >> than no rebuttal at all. > > Still nice to see that you don't disagree with my silly remark. > Though might get boring at some point. Perhaps I should post > another silly remark before that. > When I conclusively prove that DD correctly simulated by HH has non-halting behavior then we know that HH(DD,DD) is correct to reject DD as non-halting. Simulating Halt Decider HH computes the mapping FROM ITS INPUT DD to its own accept or reject on the basis of the behavior that DD correctly simulated by HH specifies. People that say HH must report on the provably different behavior the non input of directly executed DD(DD) simply don't have a clue that deciders are not allowed to do this. Prior to Pythagoras there was a universal consensus that the Earth was flat. A consensus of ignoring how deciders actually work is this same sort of 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-09 14:08 -0400 |
| Subject | Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis |
| Message-ID | <v44r3j$3egp9$8@i2pn2.org> |
| In reply to | #106774 |
On 6/9/24 10:03 AM, olcott wrote: > On 6/9/2024 3:52 AM, Mikko wrote: >> On 2024-06-08 13:46:07 +0000, joes said: >> >>> Am Sat, 08 Jun 2024 08:04:14 -0500 schrieb olcott: >>>> On 6/8/2024 1:42 AM, Mikko wrote: >>>>> On 2024-06-07 22:26:05 +0000, olcott said: >>>>>> On 6/7/2024 4:00 PM, joes wrote: >>>>>>> Am Fri, 07 Jun 2024 09:47:35 -0500 schrieb olcott: >>>>>>>> On 6/7/2024 1:30 AM, Mikko wrote: >>>>>>>>> On 2024-06-06 15:31:36 +0000, olcott said: >>>>>>>>>> On 6/6/2024 10:14 AM, Mikko wrote: >>>>>>>>>>> On 2024-06-06 13:53:58 +0000, olcott said: >>>>>>>>>>>> On 6/6/2024 5:15 AM, Mikko wrote: >>>>>>>>>>>>> On 2024-06-05 13:29:28 +0000, olcott said: >>>>>>>>>>>>>> On 6/5/2024 2:37 AM, Mikko wrote: >>>>>>>>>>>>>>> On 2024-06-04 18:02:03 +0000, olcott said: >>> >>>>> Any finite string can be an input to some Turing machine. >>>>> Can you prove that a Turing machine is not a finite string? >>>> By definition Turing Machines are not finite strings in the >>>> conventional >>>> model. In my x86utm model of computation x86 machine language <is> the >>>> input to another function written in the x86 language. >>> In your model, the machine code is also finite. >>> >>>>> Your own attempts of a conter-proof are not about Turing machines >>>>> but C >>>>> programs. C programs are finite strings, so a C program is a valid >>>>> input to a C program (and a Turing machine, too). >>>> They are about Turing Machines yet cannot be sufficiently understood >>>> with less than the 100% compete precision of the x86 language. They >>>> x86utm model is required to prove that false assumptions about the >>>> nature of correct simulation are false assumptions. >>> You can't hide behind an x86 implementation. The same arguments hold. >>> Which assumptions are false? >>> >>>> I have all of the details of the machine code and C code for HH and >>>> DDD. >>>> I can't to the same thing for embedded_H and ⟨Ĥ⟩ ⟨Ĥ⟩ so we have to >>>> learn >>>> by analogy. >>> Why can't you do that? The simulator can simulate itself. >>> >>>>>>>> This means that H is not allowed to report on the behavior of the >>>>>>>> directly executed P(P). >>>>>>> So on which program does it report then? >>>> 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. >>>> If HH(DD,DD) did not correctly determine that its input DOES NOT HALT >>>> then DD(DD) would never halt. >>> That doesn't make sense. The function halts because a simulator says it >>> doesn't? >> >> You missed an important point: The function halts because a simulator >> CORRECTLY says it doesn't. >> > > The first recursive call halts because the second recursive > call has been aborted. That the second recursive call had to > be aborted proves that the entire computation is non-halting. Except that the second recursive call didn't actually need to be aborted, as the actual correct simulation of the input to the first machines input would have halted when the third recursive call was simulated > > 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. Nope, Remember, you have redefined DD to be a template, and thus it CAN have multiple behaviors based oh what it is instantiated on. DD(DD) will have infinite recursion if the HH it is built on never aborts its simulation. DD(DD) will have finite execution if the HH it is built on will abort its simulation, but that finite execution is longer than the period that that HH simulates for, so it can not see it. > > If HH(DD,DD) did not correctly determine that its input > DOES NOT HALT then DD(DD) would never halt. > So? Yes, if HH fails to be a decider, the input is non-halting, but HH fails to be a decider. But, if HH decides to abort its simulation and return 0, then the direct exectuition of the input, which is what Halting is DEFINED to be, will reach the final state. All you have done is proven the HH was a correct POOP decider for that input, but no one cares about your POOP. It is just a LIE to use the wrong criteria for the problem.
[toc] | [prev] | [next] | [standalone]
| From | Mikko <mikko.levanto@iki.fi> |
|---|---|
| Date | 2024-06-09 11:47 +0300 |
| Subject | Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis |
| Message-ID | <v43q7v$3bkup$1@dont-email.me> |
| In reply to | #106660 |
On 2024-06-08 13:04:14 +0000, olcott said: > On 6/8/2024 1:42 AM, Mikko wrote: >> On 2024-06-07 22:26:05 +0000, olcott said: >> >>> On 6/7/2024 4:00 PM, joes wrote: >>>> Am Fri, 07 Jun 2024 09:47:35 -0500 schrieb olcott: >>>>> On 6/7/2024 1:30 AM, Mikko wrote: >>>>>> On 2024-06-06 15:31:36 +0000, olcott said: >>>>>>> On 6/6/2024 10:14 AM, Mikko wrote: >>>>>>>> On 2024-06-06 13:53:58 +0000, olcott said: >>>>>>>>> On 6/6/2024 5:15 AM, Mikko wrote: >>>>>>>>>> On 2024-06-05 13:29:28 +0000, olcott said: >>>>>>>>>>> On 6/5/2024 2:37 AM, Mikko wrote: >>>>>>>>>>>> On 2024-06-04 18:02:03 +0000, olcott said: >>>> >>>>> A simulating halt decider cannot report on what the behavior of a >>>>> non-terminating input actually is because this would take forever. >>>> Exactly. Didn't you say it is allowed to abort? >>>> >>>>> H is not allowed to report on any computation containing its actual self >>>>> because Turing machines can only take finite string inputs thus cannot >>>>> take Turing machines as inputs. >>>> Bullshit. It can take other machines just fine. It doesn't know about >>>> itself. >>>> >>> >>> No actual Turing machine can be the input to any other actual >>> Turing machine. Turing machines only take finite string inputs. >> >> Any finite string can be an input to some Turing machine. >> Can you prove that a Turing machine is not a finite string? >> > > By definition Turing Machines are not finite strings in the > conventional model. In my x86utm model of computation x86 > machine language <is> the input to another function written > in the x86 language. The definition does not say "Turing machine is not a finite string". -- Mikko
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-09 08:59 -0500 |
| Subject | Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis |
| Message-ID | <v44cgt$3harn$5@dont-email.me> |
| In reply to | #106762 |
On 6/9/2024 3:47 AM, Mikko wrote: > On 2024-06-08 13:04:14 +0000, olcott said: > >> On 6/8/2024 1:42 AM, Mikko wrote: >>> On 2024-06-07 22:26:05 +0000, olcott said: >>> >>>> On 6/7/2024 4:00 PM, joes wrote: >>>>> Am Fri, 07 Jun 2024 09:47:35 -0500 schrieb olcott: >>>>>> On 6/7/2024 1:30 AM, Mikko wrote: >>>>>>> On 2024-06-06 15:31:36 +0000, olcott said: >>>>>>>> On 6/6/2024 10:14 AM, Mikko wrote: >>>>>>>>> On 2024-06-06 13:53:58 +0000, olcott said: >>>>>>>>>> On 6/6/2024 5:15 AM, Mikko wrote: >>>>>>>>>>> On 2024-06-05 13:29:28 +0000, olcott said: >>>>>>>>>>>> On 6/5/2024 2:37 AM, Mikko wrote: >>>>>>>>>>>>> On 2024-06-04 18:02:03 +0000, olcott said: >>>>> >>>>>> A simulating halt decider cannot report on what the behavior of a >>>>>> non-terminating input actually is because this would take forever. >>>>> Exactly. Didn't you say it is allowed to abort? >>>>> >>>>>> H is not allowed to report on any computation containing its >>>>>> actual self >>>>>> because Turing machines can only take finite string inputs thus >>>>>> cannot >>>>>> take Turing machines as inputs. >>>>> Bullshit. It can take other machines just fine. It doesn't know about >>>>> itself. >>>>> >>>> >>>> No actual Turing machine can be the input to any other actual >>>> Turing machine. Turing machines only take finite string inputs. >>> >>> Any finite string can be an input to some Turing machine. >>> Can you prove that a Turing machine is not a finite string? >>> >> >> By definition Turing Machines are not finite strings in the >> conventional model. In my x86utm model of computation x86 >> machine language <is> the input to another function written >> in the x86 language. > > The definition does not say "Turing machine is not a finite string". > The definition of puppy does not say it is not a fifteen story office building. -- Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
Page 15 of 17 — ← Prev page 1 … 13 14 [15] 16 17 Next page →
Back to top | Article view | comp.theory
csiph-web