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 11 of 17 — ← Prev page 1 … 9 10 [11] 12 13 … 17 Next page →
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-07 11:52 -0400 |
| Subject | Re: How Partial Simulations incorrectly determine non-halting ---Ben's 10/2022 analysis |
| Message-ID | <v3vach$39ri5$17@i2pn2.org> |
| In reply to | #106495 |
On 6/7/24 11:30 AM, olcott wrote:
> On 6/7/2024 10:27 AM, joes wrote:
>> Am Fri, 07 Jun 2024 10:05:11 -0500 schrieb olcott:
>>> On 6/7/2024 9:55 AM, Python wrote:
>>>> Le 07/06/2024 à 16:47, olcott a écrit :
>>> Turing machines can take a finite string machine description of the
>>> computation that contains themselves they cannot the computation that
>>> actually contains themselves.
>> Does not parse.
>> Recursion can be encoded in a finite string.
>>
>>>>> The issue here is that I proved that DD correctly simulated by HH has
>>>>> different behavior than the directly executed DD(DD) and everyone's
>>>>> "rebuttal" to this proof is to simply ignore it.
>>> When you actually try to form a rebuttal of the above you will see that
>>> I am correct. So far everyone simply ignores the proof that I am correct
>>> as their only rebuttal.
>> The rebuttal is that a simulation should behave the same as the real
>> thing.
>>
>
> Try to show how this DD correctly simulated by any HH ever
> stops running without having its simulation aborted by HH.
>
> _DD()
> [00001e12] 55 push ebp
> [00001e13] 8bec mov ebp,esp
> [00001e15] 51 push ecx
> [00001e16] 8b4508 mov eax,[ebp+08]
> [00001e19] 50 push eax ; push DD
> [00001e1a] 8b4d08 mov ecx,[ebp+08]
> [00001e1d] 51 push ecx ; push DD
> [00001e1e] e85ff5ffff call 00001382 ; call HH
>
> A {correct simulation} means that each instruction of the
> above x86 machine language of DD is correctly simulated
> by HH and simulated in the correct order.
>
> Anyone claiming that HH should report on the behavior
> of the directly executed DD(DD) is requiring a violation
> of the above definition of correct simulation.
>
And thus, you have proved that you are not talking about halting. as
halting *IS* about the directly execute DD(DD), so if your definition of
"correct simulation" can't map to it, it isn't applicable for the problem.
You are just admitting to trying to feed the world your POOP as a
substitue for Halting, but the world doesn't what your POOP, it
generally needs to know about actual Halting.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-07 11:14 -0400 |
| Subject | Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis |
| Message-ID | <v3v843$39ri5$5@i2pn2.org> |
| In reply to | #106471 |
On 6/7/24 10:47 AM, olcott wrote: > 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: >>>>>>>> >>>>>>>>> *HOW PARTIAL SIMULATIONS CORRECTLY DETERMINE NON-HALTING* >>>>>>>>> >>>>>>>>> On 10/13/2022 11:29:23 AM >>>>>>>>> MIT Professor Michael Sipser agreed this verbatim paragraph is >>>>>>>>> correct >>>>>>>>> (He has neither reviewed nor agreed to anything else in this >>>>>>>>> paper) >>>>>>>>> >>>>>>>>> <Professor Sipser agreed> >>>>>>>>> If simulating halt decider H correctly simulates its input D >>>>>>>>> until H >>>>>>>>> correctly determines that its simulated D would never stop running >>>>>>>>> unless aborted then >>>>>>>>> >>>>>>>>> H can abort its simulation of D and correctly report that D >>>>>>>>> specifies a >>>>>>>>> non-halting sequence of configurations. >>>>>>>>> </Professor Sipser agreed> >>>>>>>> >>>>>>>> It is quite clear what Professor Sipser agreed. >>>>>>> >>>>>>> Those were my verbatim words that he agreed to, no one >>>>>>> has ever correctly provided any alternative interpretation >>>>>>> that could possibly make my own HH(DD,DD)==0 incorrect. >>>>>> >>>>>> One can agree with those words because they are both clear and true. >>>>>> Whether they are sufficient to your purposes is another problem but >>>>>> that is nor relevant to their acceptablility. >>>>>> >>>>>>>> If you use those words >>>>>>>> as the second last part of your proof then it sould be obvious >>>>>>>> that we >>>>>>>> need to look at the other parts in order to find an error in the >>>>>>>> proof. >>>>>>> >>>>>>> That is slightly more than zero supporting reasoning yet mere >>>>>>> gibberish >>>>>>> when construed as any rebuttal to this: >>>>>> >>>>>> Those who disagree with you about whether something is "gibberish" >>>>>> may >>>>>> think that you are stupid. You probably don't want them to think so, >>>>>> regardless whether thinking so would be right or wrong. >>>>>> >>>>>>> *This unequivocally proves the behavior of DD correctly simulated >>>>>>> by HH* >>>>>>> https://liarparadox.org/DD_correctly_simulated_by_HH_is_Proven.pdf >>>>>> >>>>>> Why would anyone construe my words as any rebuttal to that? That pdf >>>>>> merely claims that a partucuar author (a C program) proves two >>>>>> particular >>>>>> claims, the second of which is badly formed (because of the two >>>>>> verbs it is hard to parse and consequently hard to be sure that the >>>>>> apparent meaning or apparent lack of meaning is what is intended). >>>>>> >>>>> >>>>> *I will dumb it down for you some more* >>>> >>>> Did you knwo that "dumb it down" does not mean 'change the topic'? >>>> >>>>> Try any show how this DD can be correctly simulated by any HH >>>>> such that this DD reaches past its machine address [00001dbe] >>>>> >>>>> _DD() >>>>> [00001e12] 55 push ebp >>>>> [00001e13] 8bec mov ebp,esp >>>>> [00001e15] 51 push ecx >>>>> [00001e16] 8b4508 mov eax,[ebp+08] >>>>> [00001e19] 50 push eax ; push DD >>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08] >>>>> [00001e1d] 51 push ecx ; push DD >>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH >>>>> >>>>> *That meets this criteria* >>>> >>>> It doesn't if you mean the criteria implied by the subject line. >>>> >>> >>> Yes it does mean that when we ourselves detect the repeating >>> state of DD correctly simulated by HH does meet the first part >>> of the following criteria: >> >> What does your "first part" mean? There is more than one way to >> partition the criteria. >> > > If simulating halt decider HH correctly simulates its input DD > until HH correctly determines that its simulated DD would never > stop running unless aborted then Which doesn't mean what you think it does, because you just don't understand how logic works. Remember, the ONLY definition that Professor Sipper would use for "simulation" is a complete simulation that fully reveals the actual behavior of the input. And, the input is always totally fixed, and a representation of a SPECIFIC probram. It can't be a "template" as templates don't have a specifically defined behavior, except as proven by the behavior of each machine individually, so you only simulate individual machines. Thus, your logic of changing D as you imagine different Hs doesn't work. > >>> <Professor Sipser agreed> >>> If simulating halt decider H correctly simulates its input D >>> until H correctly determines that its simulated D would never >>> stop running unless aborted then >>> >>> H can abort its simulation of D and correctly report that D >>> specifies a non-halting sequence of configurations. >>> </Professor Sipser agreed> >>> >>> That the second part <is> logically entailed by this first part. >>> *No one can possibly correctly disagree with that* >> >> Why would anyone disagree with Sipser? Some people prefer to tell >> more than they know, but Sipser? >> > > On 10/14/2022 7:44 PM, Ben Bacarisse wrote: > > I don't think that is the shell game. PO really /has/ an H > > (it's trivial to do for this one case) that correctly determines > > that P(P) *would* never stop running *unless* aborted. > > He knows and accepts that P(P) actually does stop. > > The wrong answer is justified by what would happen if H > > (and hence a different P) where not what they actually are. > > > > A simulating halt decider is required to report on what the > behavior of its input *would be* for all inputs that > "would never stop running unless aborted". > > A simulating halt decider cannot report on what the behavior > of a non-terminating input actually is because this would take > forever. > > 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. > > This means that H is not allowed to report on the behavior > of the directly executed P(P). > > The issue here is that I proved that DD correctly simulated > by HH has different behavior than the directly executed > DD(DD) and everyone's "rebuttal" to this proof is to simply > ignore it. > >
[toc] | [prev] | [next] | [standalone]
| From | Mikko <mikko.levanto@iki.fi> |
|---|---|
| Date | 2024-06-07 19:56 +0300 |
| Subject | Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis |
| Message-ID | <v3ve38$259cg$1@dont-email.me> |
| In reply to | #106471 |
On 2024-06-07 14:47:35 +0000, olcott said: > 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: >>>>>>>> >>>>>>>>> *HOW PARTIAL SIMULATIONS CORRECTLY DETERMINE NON-HALTING* >>>>>>>>> >>>>>>>>> On 10/13/2022 11:29:23 AM >>>>>>>>> MIT Professor Michael Sipser agreed this verbatim paragraph is correct >>>>>>>>> (He has neither reviewed nor agreed to anything else in this paper) >>>>>>>>> >>>>>>>>> <Professor Sipser agreed> >>>>>>>>> If simulating halt decider H correctly simulates its input D until H >>>>>>>>> correctly determines that its simulated D would never stop running >>>>>>>>> unless aborted then >>>>>>>>> >>>>>>>>> H can abort its simulation of D and correctly report that D specifies a >>>>>>>>> non-halting sequence of configurations. >>>>>>>>> </Professor Sipser agreed> >>>>>>>> >>>>>>>> It is quite clear what Professor Sipser agreed. >>>>>>> >>>>>>> Those were my verbatim words that he agreed to, no one >>>>>>> has ever correctly provided any alternative interpretation >>>>>>> that could possibly make my own HH(DD,DD)==0 incorrect. >>>>>> >>>>>> One can agree with those words because they are both clear and true. >>>>>> Whether they are sufficient to your purposes is another problem but >>>>>> that is nor relevant to their acceptablility. >>>>>> >>>>>>>> If you use those words >>>>>>>> as the second last part of your proof then it sould be obvious that we >>>>>>>> need to look at the other parts in order to find an error in the proof. >>>>>>> >>>>>>> That is slightly more than zero supporting reasoning yet mere gibberish >>>>>>> when construed as any rebuttal to this: >>>>>> >>>>>> Those who disagree with you about whether something is "gibberish" may >>>>>> think that you are stupid. You probably don't want them to think so, >>>>>> regardless whether thinking so would be right or wrong. >>>>>> >>>>>>> *This unequivocally proves the behavior of DD correctly simulated by HH* >>>>>>> https://liarparadox.org/DD_correctly_simulated_by_HH_is_Proven.pdf >>>>>> >>>>>> Why would anyone construe my words as any rebuttal to that? That pdf >>>>>> merely claims that a partucuar author (a C program) proves two particular >>>>>> claims, the second of which is badly formed (because of the two >>>>>> verbs it is hard to parse and consequently hard to be sure that the >>>>>> apparent meaning or apparent lack of meaning is what is intended). >>>>>> >>>>> >>>>> *I will dumb it down for you some more* >>>> >>>> Did you knwo that "dumb it down" does not mean 'change the topic'? >>>> >>>>> Try any show how this DD can be correctly simulated by any HH >>>>> such that this DD reaches past its machine address [00001dbe] >>>>> >>>>> _DD() >>>>> [00001e12] 55 push ebp >>>>> [00001e13] 8bec mov ebp,esp >>>>> [00001e15] 51 push ecx >>>>> [00001e16] 8b4508 mov eax,[ebp+08] >>>>> [00001e19] 50 push eax ; push DD >>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08] >>>>> [00001e1d] 51 push ecx ; push DD >>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH >>>>> >>>>> *That meets this criteria* >>>> >>>> It doesn't if you mean the criteria implied by the subject line. >>>> >>> >>> Yes it does mean that when we ourselves detect the repeating >>> state of DD correctly simulated by HH does meet the first part >>> of the following criteria: >> >> What does your "first part" mean? There is more than one way to >> partition the criteria. >> > > If simulating halt decider HH correctly simulates its input DD > until HH correctly determines that its simulated DD would never > stop running unless aborted then That is all of the criteria, so should not be called "first part". Atually Sipser only agreed about H and D, not about HH and DD but that does not make any difference for the above. In order to prove that the criteria are met you need to prove that (1) simulation halt decider HH correctly partially simulates its input DD until some point, (2) at that point HH can determine that it is possible to continue the simulation forever, and (3) the determination by H is correct. So far you have not proven (3). >>> <Professor Sipser agreed> >>> If simulating halt decider H correctly simulates its input D >>> until H correctly determines that its simulated D would never >>> stop running unless aborted then >>> >>> H can abort its simulation of D and correctly report that D >>> specifies a non-halting sequence of configurations. >>> </Professor Sipser agreed> -- Mikko
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-07 12:11 -0500 |
| Subject | Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis |
| Message-ID | <v3vf0b$24orn$4@dont-email.me> |
| In reply to | #106515 |
On 6/7/2024 11:56 AM, Mikko wrote:
> On 2024-06-07 14:47:35 +0000, olcott said:
>
>> 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:
>>>>>>>>>
>>>>>>>>>> *HOW PARTIAL SIMULATIONS CORRECTLY DETERMINE NON-HALTING*
>>>>>>>>>>
>>>>>>>>>> On 10/13/2022 11:29:23 AM
>>>>>>>>>> MIT Professor Michael Sipser agreed this verbatim paragraph is
>>>>>>>>>> correct
>>>>>>>>>> (He has neither reviewed nor agreed to anything else in this
>>>>>>>>>> paper)
>>>>>>>>>>
>>>>>>>>>> <Professor Sipser agreed>
>>>>>>>>>> If simulating halt decider H correctly simulates its input D
>>>>>>>>>> until H
>>>>>>>>>> correctly determines that its simulated D would never stop
>>>>>>>>>> running
>>>>>>>>>> unless aborted then
>>>>>>>>>>
>>>>>>>>>> H can abort its simulation of D and correctly report that D
>>>>>>>>>> specifies a
>>>>>>>>>> non-halting sequence of configurations.
>>>>>>>>>> </Professor Sipser agreed>
>>>>>>>>>
>>>>>>>>> It is quite clear what Professor Sipser agreed.
>>>>>>>>
>>>>>>>> Those were my verbatim words that he agreed to, no one
>>>>>>>> has ever correctly provided any alternative interpretation
>>>>>>>> that could possibly make my own HH(DD,DD)==0 incorrect.
>>>>>>>
>>>>>>> One can agree with those words because they are both clear and true.
>>>>>>> Whether they are sufficient to your purposes is another problem but
>>>>>>> that is nor relevant to their acceptablility.
>>>>>>>
>>>>>>>>> If you use those words
>>>>>>>>> as the second last part of your proof then it sould be obvious
>>>>>>>>> that we
>>>>>>>>> need to look at the other parts in order to find an error in
>>>>>>>>> the proof.
>>>>>>>>
>>>>>>>> That is slightly more than zero supporting reasoning yet mere
>>>>>>>> gibberish
>>>>>>>> when construed as any rebuttal to this:
>>>>>>>
>>>>>>> Those who disagree with you about whether something is
>>>>>>> "gibberish" may
>>>>>>> think that you are stupid. You probably don't want them to think so,
>>>>>>> regardless whether thinking so would be right or wrong.
>>>>>>>
>>>>>>>> *This unequivocally proves the behavior of DD correctly
>>>>>>>> simulated by HH*
>>>>>>>> https://liarparadox.org/DD_correctly_simulated_by_HH_is_Proven.pdf
>>>>>>>
>>>>>>> Why would anyone construe my words as any rebuttal to that? That pdf
>>>>>>> merely claims that a partucuar author (a C program) proves two
>>>>>>> particular
>>>>>>> claims, the second of which is badly formed (because of the two
>>>>>>> verbs it is hard to parse and consequently hard to be sure that the
>>>>>>> apparent meaning or apparent lack of meaning is what is intended).
>>>>>>>
>>>>>>
>>>>>> *I will dumb it down for you some more*
>>>>>
>>>>> Did you knwo that "dumb it down" does not mean 'change the topic'?
>>>>>
>>>>>> Try any show how this DD can be correctly simulated by any HH
>>>>>> such that this DD reaches past its machine address [00001dbe]
>>>>>>
>>>>>> _DD()
>>>>>> [00001e12] 55 push ebp
>>>>>> [00001e13] 8bec mov ebp,esp
>>>>>> [00001e15] 51 push ecx
>>>>>> [00001e16] 8b4508 mov eax,[ebp+08]
>>>>>> [00001e19] 50 push eax ; push DD
>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08]
>>>>>> [00001e1d] 51 push ecx ; push DD
>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH
>>>>>>
>>>>>> *That meets this criteria*
>>>>>
>>>>> It doesn't if you mean the criteria implied by the subject line.
>>>>>
>>>>
>>>> Yes it does mean that when we ourselves detect the repeating
>>>> state of DD correctly simulated by HH does meet the first part
>>>> of the following criteria:
>>>
>>> What does your "first part" mean? There is more than one way to
>>> partition the criteria.
>>>
>>
>> If simulating halt decider HH correctly simulates its input DD
>> until HH correctly determines that its simulated DD would never
>> stop running unless aborted then
>
> That is all of the criteria, so should not be called "first part".
> Atually Sipser only agreed about H and D, not about HH and DD but
> that does not make any difference for the above.
Professor Sipser knew full well that H and D are mere
placeholders for simulating halt decider H with arbitrary input D.
> In order to prove that the criteria are met you need to prove that
> (1) simulation halt decider HH correctly partially simulates its
> input DD until some point,
> (2) at that point HH can determine that it is possible to continue
> the simulation forever, and > (3) the determination by H is correct.
> So far you have not proven (3).
>
*I have proven it thousands of times in the last three years*
2,000 times would only be an average of less than two proofs
per day.
Richard has finally admitted that he never looked at
any of these proofs thus finally admitting that his
dishonest dodge CHANGE-THE-SUBJECT strawman deception
fake rebuttal was always dishonest and deceptive.
I have proved it several times to you too.
Try to show how this DD correctly simulated by any HH ever
stops running without having its simulation aborted by HH.
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD
[00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD
[00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the
above x86 machine language of DD is correctly simulated
by HH and simulated in the correct order.
Anyone claiming that HH should report on the behavior
of the directly executed DD(DD) is requiring a violation
of the above definition of correct simulation.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-07 14:32 -0400 |
| Subject | Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis |
| Message-ID | <v3vjnu$39ri6$9@i2pn2.org> |
| In reply to | #106516 |
On 6/7/24 1:11 PM, olcott wrote:
> On 6/7/2024 11:56 AM, Mikko wrote:
>> On 2024-06-07 14:47:35 +0000, olcott said:
>>
>>> 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:
>>>>>>>>>>
>>>>>>>>>>> *HOW PARTIAL SIMULATIONS CORRECTLY DETERMINE NON-HALTING*
>>>>>>>>>>>
>>>>>>>>>>> On 10/13/2022 11:29:23 AM
>>>>>>>>>>> MIT Professor Michael Sipser agreed this verbatim paragraph
>>>>>>>>>>> is correct
>>>>>>>>>>> (He has neither reviewed nor agreed to anything else in this
>>>>>>>>>>> paper)
>>>>>>>>>>>
>>>>>>>>>>> <Professor Sipser agreed>
>>>>>>>>>>> If simulating halt decider H correctly simulates its input D
>>>>>>>>>>> until H
>>>>>>>>>>> correctly determines that its simulated D would never stop
>>>>>>>>>>> running
>>>>>>>>>>> unless aborted then
>>>>>>>>>>>
>>>>>>>>>>> H can abort its simulation of D and correctly report that D
>>>>>>>>>>> specifies a
>>>>>>>>>>> non-halting sequence of configurations.
>>>>>>>>>>> </Professor Sipser agreed>
>>>>>>>>>>
>>>>>>>>>> It is quite clear what Professor Sipser agreed.
>>>>>>>>>
>>>>>>>>> Those were my verbatim words that he agreed to, no one
>>>>>>>>> has ever correctly provided any alternative interpretation
>>>>>>>>> that could possibly make my own HH(DD,DD)==0 incorrect.
>>>>>>>>
>>>>>>>> One can agree with those words because they are both clear and
>>>>>>>> true.
>>>>>>>> Whether they are sufficient to your purposes is another problem but
>>>>>>>> that is nor relevant to their acceptablility.
>>>>>>>>
>>>>>>>>>> If you use those words
>>>>>>>>>> as the second last part of your proof then it sould be obvious
>>>>>>>>>> that we
>>>>>>>>>> need to look at the other parts in order to find an error in
>>>>>>>>>> the proof.
>>>>>>>>>
>>>>>>>>> That is slightly more than zero supporting reasoning yet mere
>>>>>>>>> gibberish
>>>>>>>>> when construed as any rebuttal to this:
>>>>>>>>
>>>>>>>> Those who disagree with you about whether something is
>>>>>>>> "gibberish" may
>>>>>>>> think that you are stupid. You probably don't want them to think
>>>>>>>> so,
>>>>>>>> regardless whether thinking so would be right or wrong.
>>>>>>>>
>>>>>>>>> *This unequivocally proves the behavior of DD correctly
>>>>>>>>> simulated by HH*
>>>>>>>>> https://liarparadox.org/DD_correctly_simulated_by_HH_is_Proven.pdf
>>>>>>>>
>>>>>>>> Why would anyone construe my words as any rebuttal to that? That
>>>>>>>> pdf
>>>>>>>> merely claims that a partucuar author (a C program) proves two
>>>>>>>> particular
>>>>>>>> claims, the second of which is badly formed (because of the two
>>>>>>>> verbs it is hard to parse and consequently hard to be sure that the
>>>>>>>> apparent meaning or apparent lack of meaning is what is intended).
>>>>>>>>
>>>>>>>
>>>>>>> *I will dumb it down for you some more*
>>>>>>
>>>>>> Did you knwo that "dumb it down" does not mean 'change the topic'?
>>>>>>
>>>>>>> Try any show how this DD can be correctly simulated by any HH
>>>>>>> such that this DD reaches past its machine address [00001dbe]
>>>>>>>
>>>>>>> _DD()
>>>>>>> [00001e12] 55 push ebp
>>>>>>> [00001e13] 8bec mov ebp,esp
>>>>>>> [00001e15] 51 push ecx
>>>>>>> [00001e16] 8b4508 mov eax,[ebp+08]
>>>>>>> [00001e19] 50 push eax ; push DD
>>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08]
>>>>>>> [00001e1d] 51 push ecx ; push DD
>>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH
>>>>>>>
>>>>>>> *That meets this criteria*
>>>>>>
>>>>>> It doesn't if you mean the criteria implied by the subject line.
>>>>>>
>>>>>
>>>>> Yes it does mean that when we ourselves detect the repeating
>>>>> state of DD correctly simulated by HH does meet the first part
>>>>> of the following criteria:
>>>>
>>>> What does your "first part" mean? There is more than one way to
>>>> partition the criteria.
>>>>
>>>
>>> If simulating halt decider HH correctly simulates its input DD
>>> until HH correctly determines that its simulated DD would never
>>> stop running unless aborted then
>>
>> That is all of the criteria, so should not be called "first part".
>> Atually Sipser only agreed about H and D, not about HH and DD but
>> that does not make any difference for the above.
>
> Professor Sipser knew full well that H and D are mere
> placeholders for simulating halt decider H with arbitrary input D.
>
>> In order to prove that the criteria are met you need to prove that
>> (1) simulation halt decider HH correctly partially simulates its
>> input DD until some point,
>> (2) at that point HH can determine that it is possible to continue
>> the simulation forever, and > (3) the determination by H is correct.
>> So far you have not proven (3).
>>
>
> *I have proven it thousands of times in the last three years*
> 2,000 times would only be an average of less than two proofs
> per day.
No, you haven't PROVEN it, but argued it must be true.
You don't seem to know what a formal proof actually is.
I don't care about your claim, because it is, by defintion, a dead end,
as far as halting is concerned, as partial simulation do not show
non-halting behavior by themselves.
>
> Richard has finally admitted that he never looked at
> any of these proofs thus finally admitting that his
> dishonest dodge CHANGE-THE-SUBJECT strawman deception
> fake rebuttal was always dishonest and deceptive.
That is NOT what I have said, som you just prove yourself to be a LIAR.
I said I haven't put the effort to look into the factuality of your
claim, which is just a claim since you haven't actually stated a proof,.
IF you want to claim a proof, I will ask for a listing of the accepted
predicates that your proof uses as its starting point, and the listing
of the truth perserving operation.
Having never posted such a thing, you have never "Proved" your statement
in the formal system of computation theory.
Sorry Peter, but you have been debunked.
>
> I have proved it several times to you too.
>
Nope, not a proof in sight from you, just arguemnts.
> Try to show how this DD correctly simulated by any HH ever
> stops running without having its simulation aborted by HH.
>
> _DD()
> [00001e12] 55 push ebp
> [00001e13] 8bec mov ebp,esp
> [00001e15] 51 push ecx
> [00001e16] 8b4508 mov eax,[ebp+08]
> [00001e19] 50 push eax ; push DD
> [00001e1a] 8b4d08 mov ecx,[ebp+08]
> [00001e1d] 51 push ecx ; push DD
> [00001e1e] e85ff5ffff call 00001382 ; call HH
>
> A {correct simulation} means that each instruction of the
> above x86 machine language of DD is correctly simulated
> by HH and simulated in the correct order.
>
> Anyone claiming that HH should report on the behavior
> of the directly executed DD(DD) is requiring a violation
> of the above definition of correct simulation.
>
Which just means that you are proving that your HH isn't a halt decider,
BY DEFINITION since that IS required to report on the behavior of the
directly executed DD(DD) as that is what the question asks about, so you
are just admitting to have been using a strawman for your argument.
[toc] | [prev] | [next] | [standalone]
| From | Mikko <mikko.levanto@iki.fi> |
|---|---|
| Date | 2024-06-08 09:36 +0300 |
| Subject | Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis |
| Message-ID | <v40u4u$2gi7t$1@dont-email.me> |
| In reply to | #106516 |
On 2024-06-07 17:11:39 +0000, olcott said: > On 6/7/2024 11:56 AM, Mikko wrote: >> On 2024-06-07 14:47:35 +0000, olcott said: >> >>> 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: >>>>>>>>>> >>>>>>>>>>> *HOW PARTIAL SIMULATIONS CORRECTLY DETERMINE NON-HALTING* >>>>>>>>>>> >>>>>>>>>>> On 10/13/2022 11:29:23 AM >>>>>>>>>>> MIT Professor Michael Sipser agreed this verbatim paragraph is correct >>>>>>>>>>> (He has neither reviewed nor agreed to anything else in this paper) >>>>>>>>>>> >>>>>>>>>>> <Professor Sipser agreed> >>>>>>>>>>> If simulating halt decider H correctly simulates its input D until H >>>>>>>>>>> correctly determines that its simulated D would never stop running >>>>>>>>>>> unless aborted then >>>>>>>>>>> >>>>>>>>>>> H can abort its simulation of D and correctly report that D specifies a >>>>>>>>>>> non-halting sequence of configurations. >>>>>>>>>>> </Professor Sipser agreed> >>>>>>>>>> >>>>>>>>>> It is quite clear what Professor Sipser agreed. >>>>>>>>> >>>>>>>>> Those were my verbatim words that he agreed to, no one >>>>>>>>> has ever correctly provided any alternative interpretation >>>>>>>>> that could possibly make my own HH(DD,DD)==0 incorrect. >>>>>>>> >>>>>>>> One can agree with those words because they are both clear and true. >>>>>>>> Whether they are sufficient to your purposes is another problem but >>>>>>>> that is nor relevant to their acceptablility. >>>>>>>> >>>>>>>>>> If you use those words >>>>>>>>>> as the second last part of your proof then it sould be obvious that we >>>>>>>>>> need to look at the other parts in order to find an error in the proof. >>>>>>>>> >>>>>>>>> That is slightly more than zero supporting reasoning yet mere gibberish >>>>>>>>> when construed as any rebuttal to this: >>>>>>>> >>>>>>>> Those who disagree with you about whether something is "gibberish" may >>>>>>>> think that you are stupid. You probably don't want them to think so, >>>>>>>> regardless whether thinking so would be right or wrong. >>>>>>>> >>>>>>>>> *This unequivocally proves the behavior of DD correctly simulated by HH* >>>>>>>>> https://liarparadox.org/DD_correctly_simulated_by_HH_is_Proven.pdf >>>>>>>> >>>>>>>> Why would anyone construe my words as any rebuttal to that? That pdf >>>>>>>> merely claims that a partucuar author (a C program) proves two particular >>>>>>>> claims, the second of which is badly formed (because of the two >>>>>>>> verbs it is hard to parse and consequently hard to be sure that the >>>>>>>> apparent meaning or apparent lack of meaning is what is intended). >>>>>>>> >>>>>>> >>>>>>> *I will dumb it down for you some more* >>>>>> >>>>>> Did you knwo that "dumb it down" does not mean 'change the topic'? >>>>>> >>>>>>> Try any show how this DD can be correctly simulated by any HH >>>>>>> such that this DD reaches past its machine address [00001dbe] >>>>>>> >>>>>>> _DD() >>>>>>> [00001e12] 55 push ebp >>>>>>> [00001e13] 8bec mov ebp,esp >>>>>>> [00001e15] 51 push ecx >>>>>>> [00001e16] 8b4508 mov eax,[ebp+08] >>>>>>> [00001e19] 50 push eax ; push DD >>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08] >>>>>>> [00001e1d] 51 push ecx ; push DD >>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH >>>>>>> >>>>>>> *That meets this criteria* >>>>>> >>>>>> It doesn't if you mean the criteria implied by the subject line. >>>>>> >>>>> >>>>> Yes it does mean that when we ourselves detect the repeating >>>>> state of DD correctly simulated by HH does meet the first part >>>>> of the following criteria: >>>> >>>> What does your "first part" mean? There is more than one way to >>>> partition the criteria. >>>> >>> >>> If simulating halt decider HH correctly simulates its input DD >>> until HH correctly determines that its simulated DD would never >>> stop running unless aborted then >> >> That is all of the criteria, so should not be called "first part". >> Atually Sipser only agreed about H and D, not about HH and DD but >> that does not make any difference for the above. > > Professor Sipser knew full well that H and D are mere > placeholders for simulating halt decider H with arbitrary input D. Yes, as nothing more is specified in the agreed text. But his expressed agreement does not extend to any substition of those placeholders. >> In order to prove that the criteria are met you need to prove that >> (1) simulation halt decider HH correctly partially simulates its >> input DD until some point, >> (2) at that point HH can determine that it is possible to continue >> the simulation forever, and > (3) the determination by H is correct. >> So far you have not proven (3). > > *I have proven it thousands of times in the last three years* > 2,000 times would only be an average of less than two proofs > per day. No, not even onece. You have often caimed to have proven but you have not presented anything that would even look like a proof. -- Mikko
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-08 07:52 -0500 |
| Subject | Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis |
| Message-ID | <v41k6l$2jqdk$8@dont-email.me> |
| In reply to | #106634 |
On 6/8/2024 1:36 AM, Mikko wrote:
> On 2024-06-07 17:11:39 +0000, olcott said:
>
>> On 6/7/2024 11:56 AM, Mikko wrote:
>>> On 2024-06-07 14:47:35 +0000, olcott said:
>>>
>>>> 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:
>>>>>>>>>>>
>>>>>>>>>>>> *HOW PARTIAL SIMULATIONS CORRECTLY DETERMINE NON-HALTING*
>>>>>>>>>>>>
>>>>>>>>>>>> On 10/13/2022 11:29:23 AM
>>>>>>>>>>>> MIT Professor Michael Sipser agreed this verbatim paragraph
>>>>>>>>>>>> is correct
>>>>>>>>>>>> (He has neither reviewed nor agreed to anything else in this
>>>>>>>>>>>> paper)
>>>>>>>>>>>>
>>>>>>>>>>>> <Professor Sipser agreed>
>>>>>>>>>>>> If simulating halt decider H correctly simulates its input D
>>>>>>>>>>>> until H
>>>>>>>>>>>> correctly determines that its simulated D would never stop
>>>>>>>>>>>> running
>>>>>>>>>>>> unless aborted then
>>>>>>>>>>>>
>>>>>>>>>>>> H can abort its simulation of D and correctly report that D
>>>>>>>>>>>> specifies a
>>>>>>>>>>>> non-halting sequence of configurations.
>>>>>>>>>>>> </Professor Sipser agreed>
>>>>>>>>>>>
>>>>>>>>>>> It is quite clear what Professor Sipser agreed.
>>>>>>>>>>
>>>>>>>>>> Those were my verbatim words that he agreed to, no one
>>>>>>>>>> has ever correctly provided any alternative interpretation
>>>>>>>>>> that could possibly make my own HH(DD,DD)==0 incorrect.
>>>>>>>>>
>>>>>>>>> One can agree with those words because they are both clear and
>>>>>>>>> true.
>>>>>>>>> Whether they are sufficient to your purposes is another problem
>>>>>>>>> but
>>>>>>>>> that is nor relevant to their acceptablility.
>>>>>>>>>
>>>>>>>>>>> If you use those words
>>>>>>>>>>> as the second last part of your proof then it sould be
>>>>>>>>>>> obvious that we
>>>>>>>>>>> need to look at the other parts in order to find an error in
>>>>>>>>>>> the proof.
>>>>>>>>>>
>>>>>>>>>> That is slightly more than zero supporting reasoning yet mere
>>>>>>>>>> gibberish
>>>>>>>>>> when construed as any rebuttal to this:
>>>>>>>>>
>>>>>>>>> Those who disagree with you about whether something is
>>>>>>>>> "gibberish" may
>>>>>>>>> think that you are stupid. You probably don't want them to
>>>>>>>>> think so,
>>>>>>>>> regardless whether thinking so would be right or wrong.
>>>>>>>>>
>>>>>>>>>> *This unequivocally proves the behavior of DD correctly
>>>>>>>>>> simulated by HH*
>>>>>>>>>> https://liarparadox.org/DD_correctly_simulated_by_HH_is_Proven.pdf
>>>>>>>>>
>>>>>>>>> Why would anyone construe my words as any rebuttal to that?
>>>>>>>>> That pdf
>>>>>>>>> merely claims that a partucuar author (a C program) proves two
>>>>>>>>> particular
>>>>>>>>> claims, the second of which is badly formed (because of the two
>>>>>>>>> verbs it is hard to parse and consequently hard to be sure that
>>>>>>>>> the
>>>>>>>>> apparent meaning or apparent lack of meaning is what is intended).
>>>>>>>>>
>>>>>>>>
>>>>>>>> *I will dumb it down for you some more*
>>>>>>>
>>>>>>> Did you knwo that "dumb it down" does not mean 'change the topic'?
>>>>>>>
>>>>>>>> Try any show how this DD can be correctly simulated by any HH
>>>>>>>> such that this DD reaches past its machine address [00001dbe]
>>>>>>>>
>>>>>>>> _DD()
>>>>>>>> [00001e12] 55 push ebp
>>>>>>>> [00001e13] 8bec mov ebp,esp
>>>>>>>> [00001e15] 51 push ecx
>>>>>>>> [00001e16] 8b4508 mov eax,[ebp+08]
>>>>>>>> [00001e19] 50 push eax ; push DD
>>>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08]
>>>>>>>> [00001e1d] 51 push ecx ; push DD
>>>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH
>>>>>>>>
>>>>>>>> *That meets this criteria*
>>>>>>>
>>>>>>> It doesn't if you mean the criteria implied by the subject line.
>>>>>>>
>>>>>>
>>>>>> Yes it does mean that when we ourselves detect the repeating
>>>>>> state of DD correctly simulated by HH does meet the first part
>>>>>> of the following criteria:
>>>>>
>>>>> What does your "first part" mean? There is more than one way to
>>>>> partition the criteria.
>>>>>
>>>>
>>>> If simulating halt decider HH correctly simulates its input DD
>>>> until HH correctly determines that its simulated DD would never
>>>> stop running unless aborted then
>>>
>>> That is all of the criteria, so should not be called "first part".
>>> Atually Sipser only agreed about H and D, not about HH and DD but
>>> that does not make any difference for the above.
>>
>> Professor Sipser knew full well that H and D are mere
>> placeholders for simulating halt decider H with arbitrary input D.
>
> Yes, as nothing more is specified in the agreed text. But his expressed
> agreement does not extend to any substition of those placeholders.
>
It allows substitution of any simulating halt decider for H
and any finite string input for D. If you are going to lie
about this I am going to quit looking at what you say.
<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 words 10/13/2022>
>>> In order to prove that the criteria are met you need to prove that
>>> (1) simulation halt decider HH correctly partially simulates its
>>> input DD until some point,
>>> (2) at that point HH can determine that it is possible to continue
>>> the simulation forever, and > (3) the determination by H is correct.
>>> So far you have not proven (3).
>>
>> *I have proven it thousands of times in the last three years*
>> 2,000 times would only be an average of less than two proofs
>> per day.
>
> No, not even onece. You have often caimed to have proven but
> you have not presented anything that would even look like a
> proof.
>
It will only look like gibberish to anyone not having the mandatory
prerequisites. That does not mean that it <is> gibberish.
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 09:10 -0400 |
| Subject | Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis |
| Message-ID | <v41l89$3cg3t$12@i2pn2.org> |
| In reply to | #106648 |
On 6/8/24 8:52 AM, olcott wrote:
> On 6/8/2024 1:36 AM, Mikko wrote:
>> On 2024-06-07 17:11:39 +0000, olcott said:
>>
>>> On 6/7/2024 11:56 AM, Mikko wrote:
>>>> On 2024-06-07 14:47:35 +0000, olcott said:
>>>>
>>>>> 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:
>>>>>>>>>>>>
>>>>>>>>>>>>> *HOW PARTIAL SIMULATIONS CORRECTLY DETERMINE NON-HALTING*
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 10/13/2022 11:29:23 AM
>>>>>>>>>>>>> MIT Professor Michael Sipser agreed this verbatim paragraph
>>>>>>>>>>>>> is correct
>>>>>>>>>>>>> (He has neither reviewed nor agreed to anything else in
>>>>>>>>>>>>> this paper)
>>>>>>>>>>>>>
>>>>>>>>>>>>> <Professor Sipser agreed>
>>>>>>>>>>>>> If simulating halt decider H correctly simulates its input
>>>>>>>>>>>>> D until H
>>>>>>>>>>>>> correctly determines that its simulated D would never stop
>>>>>>>>>>>>> running
>>>>>>>>>>>>> unless aborted then
>>>>>>>>>>>>>
>>>>>>>>>>>>> H can abort its simulation of D and correctly report that D
>>>>>>>>>>>>> specifies a
>>>>>>>>>>>>> non-halting sequence of configurations.
>>>>>>>>>>>>> </Professor Sipser agreed>
>>>>>>>>>>>>
>>>>>>>>>>>> It is quite clear what Professor Sipser agreed.
>>>>>>>>>>>
>>>>>>>>>>> Those were my verbatim words that he agreed to, no one
>>>>>>>>>>> has ever correctly provided any alternative interpretation
>>>>>>>>>>> that could possibly make my own HH(DD,DD)==0 incorrect.
>>>>>>>>>>
>>>>>>>>>> One can agree with those words because they are both clear and
>>>>>>>>>> true.
>>>>>>>>>> Whether they are sufficient to your purposes is another
>>>>>>>>>> problem but
>>>>>>>>>> that is nor relevant to their acceptablility.
>>>>>>>>>>
>>>>>>>>>>>> If you use those words
>>>>>>>>>>>> as the second last part of your proof then it sould be
>>>>>>>>>>>> obvious that we
>>>>>>>>>>>> need to look at the other parts in order to find an error in
>>>>>>>>>>>> the proof.
>>>>>>>>>>>
>>>>>>>>>>> That is slightly more than zero supporting reasoning yet mere
>>>>>>>>>>> gibberish
>>>>>>>>>>> when construed as any rebuttal to this:
>>>>>>>>>>
>>>>>>>>>> Those who disagree with you about whether something is
>>>>>>>>>> "gibberish" may
>>>>>>>>>> think that you are stupid. You probably don't want them to
>>>>>>>>>> think so,
>>>>>>>>>> regardless whether thinking so would be right or wrong.
>>>>>>>>>>
>>>>>>>>>>> *This unequivocally proves the behavior of DD correctly
>>>>>>>>>>> simulated by HH*
>>>>>>>>>>> https://liarparadox.org/DD_correctly_simulated_by_HH_is_Proven.pdf
>>>>>>>>>>
>>>>>>>>>> Why would anyone construe my words as any rebuttal to that?
>>>>>>>>>> That pdf
>>>>>>>>>> merely claims that a partucuar author (a C program) proves two
>>>>>>>>>> particular
>>>>>>>>>> claims, the second of which is badly formed (because of the two
>>>>>>>>>> verbs it is hard to parse and consequently hard to be sure
>>>>>>>>>> that the
>>>>>>>>>> apparent meaning or apparent lack of meaning is what is
>>>>>>>>>> intended).
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> *I will dumb it down for you some more*
>>>>>>>>
>>>>>>>> Did you knwo that "dumb it down" does not mean 'change the topic'?
>>>>>>>>
>>>>>>>>> Try any show how this DD can be correctly simulated by any HH
>>>>>>>>> such that this DD reaches past its machine address [00001dbe]
>>>>>>>>>
>>>>>>>>> _DD()
>>>>>>>>> [00001e12] 55 push ebp
>>>>>>>>> [00001e13] 8bec mov ebp,esp
>>>>>>>>> [00001e15] 51 push ecx
>>>>>>>>> [00001e16] 8b4508 mov eax,[ebp+08]
>>>>>>>>> [00001e19] 50 push eax ; push DD
>>>>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08]
>>>>>>>>> [00001e1d] 51 push ecx ; push DD
>>>>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH
>>>>>>>>>
>>>>>>>>> *That meets this criteria*
>>>>>>>>
>>>>>>>> It doesn't if you mean the criteria implied by the subject line.
>>>>>>>>
>>>>>>>
>>>>>>> Yes it does mean that when we ourselves detect the repeating
>>>>>>> state of DD correctly simulated by HH does meet the first part
>>>>>>> of the following criteria:
>>>>>>
>>>>>> What does your "first part" mean? There is more than one way to
>>>>>> partition the criteria.
>>>>>>
>>>>>
>>>>> If simulating halt decider HH correctly simulates its input DD
>>>>> until HH correctly determines that its simulated DD would never
>>>>> stop running unless aborted then
>>>>
>>>> That is all of the criteria, so should not be called "first part".
>>>> Atually Sipser only agreed about H and D, not about HH and DD but
>>>> that does not make any difference for the above.
>>>
>>> Professor Sipser knew full well that H and D are mere
>>> placeholders for simulating halt decider H with arbitrary input D.
>>
>> Yes, as nothing more is specified in the agreed text. But his expressed
>> agreement does not extend to any substition of those placeholders.
>>
>
> It allows substitution of any simulating halt decider for H
> and any finite string input for D. If you are going to lie
> about this I am going to quit looking at what you say.
>
> <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 words 10/13/2022>
And you can only use that with the definiton Professor Sipser has for
"Correct Simulation" which you don't do, that of one that goes to
completion. And it is for an input that is FIXED and doesn't change as
you imagine alternate H's.
Since your H doesn't do a correct simulation per the canonical
definition, you can't directly use the first part to claim the second.
You can't even imagine a hypothetical replace for THIS COPY of H that
does such a simulation, because such a hypothetical doesn't change the
input, which will still call the original H, and that simulation WILL
HALT when you include in it the decision the H will abort its simulation
and return 0, thus you never got the permission needed to be correct to
do so, and thus you can be incorrect, which you are.
>
>>>> In order to prove that the criteria are met you need to prove that
>>>> (1) simulation halt decider HH correctly partially simulates its
>>>> input DD until some point,
>>>> (2) at that point HH can determine that it is possible to continue
>>>> the simulation forever, and > (3) the determination by H is correct.
>>>> So far you have not proven (3).
>>>
>>> *I have proven it thousands of times in the last three years*
>>> 2,000 times would only be an average of less than two proofs
>>> per day.
>>
>> No, not even onece. You have often caimed to have proven but
>> you have not presented anything that would even look like a
>> proof.
>>
>
> It will only look like gibberish to anyone not having the mandatory
> prerequisites. That does not mean that it <is> gibberish.
>
> I incorporate by reference
> (a) The x86 language
> (b) The notion of an x86 emulator
>
> (c) I provide this complete function
So?
>
> 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 just a claim. You need to show why that claim
is actually true.
Note, claiming that NO thing meets a requirement is hard. Generally it
is done by the proof type you don't understand, the proof by
contradiction. Where you try to show that if one existed, it would by
necessity be breaking some requirement.
>
> To anyone having this mandatory prerequisite knowledge
> (perhaps not you) every x86 emulation of DDD by any
> x86 emulator H continually repeats the first seven lines
> of DDD until it crashes due to out-of-memory error.
>
Which means you just proved that NO HH that meets your requirements can
ever give an answer for this question.
You Claim this not to be true, so that just shows that your system is
self-contradictory.
And the apparent issue is that you are changing your definition of
"Correct Simulation" between the two.
Apparently quite intentionally, so it can be considered an act of
deception, commonly called a LIE.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-08 08:48 -0500 |
| Subject | Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis |
| Message-ID | <v41nei$2kanc$8@dont-email.me> |
| In reply to | #106663 |
On 6/8/2024 8:10 AM, Richard Damon wrote: > On 6/8/24 8:52 AM, olcott wrote: >> On 6/8/2024 1:36 AM, Mikko wrote: >>> On 2024-06-07 17:11:39 +0000, olcott said: >>> >>>> On 6/7/2024 11:56 AM, Mikko wrote: >>>>> On 2024-06-07 14:47:35 +0000, olcott said: >>>>> >>>>>> 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: >>>>>>>>>>>>> >>>>>>>>>>>>>> *HOW PARTIAL SIMULATIONS CORRECTLY DETERMINE NON-HALTING* >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 10/13/2022 11:29:23 AM >>>>>>>>>>>>>> MIT Professor Michael Sipser agreed this verbatim >>>>>>>>>>>>>> paragraph is correct >>>>>>>>>>>>>> (He has neither reviewed nor agreed to anything else in >>>>>>>>>>>>>> this paper) >>>>>>>>>>>>>> >>>>>>>>>>>>>> <Professor Sipser agreed> >>>>>>>>>>>>>> If simulating halt decider H correctly simulates its input >>>>>>>>>>>>>> D until H >>>>>>>>>>>>>> correctly determines that its simulated D would never stop >>>>>>>>>>>>>> running >>>>>>>>>>>>>> unless aborted then >>>>>>>>>>>>>> >>>>>>>>>>>>>> H can abort its simulation of D and correctly report that >>>>>>>>>>>>>> D specifies a >>>>>>>>>>>>>> non-halting sequence of configurations. >>>>>>>>>>>>>> </Professor Sipser agreed> >>>>>>>>>>>>> >>>>>>>>>>>>> It is quite clear what Professor Sipser agreed. >>>>>>>>>>>> >>>>>>>>>>>> Those were my verbatim words that he agreed to, no one >>>>>>>>>>>> has ever correctly provided any alternative interpretation >>>>>>>>>>>> that could possibly make my own HH(DD,DD)==0 incorrect. >>>>>>>>>>> >>>>>>>>>>> One can agree with those words because they are both clear >>>>>>>>>>> and true. >>>>>>>>>>> Whether they are sufficient to your purposes is another >>>>>>>>>>> problem but >>>>>>>>>>> that is nor relevant to their acceptablility. >>>>>>>>>>> >>>>>>>>>>>>> If you use those words >>>>>>>>>>>>> as the second last part of your proof then it sould be >>>>>>>>>>>>> obvious that we >>>>>>>>>>>>> need to look at the other parts in order to find an error >>>>>>>>>>>>> in the proof. >>>>>>>>>>>> >>>>>>>>>>>> That is slightly more than zero supporting reasoning yet >>>>>>>>>>>> mere gibberish >>>>>>>>>>>> when construed as any rebuttal to this: >>>>>>>>>>> >>>>>>>>>>> Those who disagree with you about whether something is >>>>>>>>>>> "gibberish" may >>>>>>>>>>> think that you are stupid. You probably don't want them to >>>>>>>>>>> think so, >>>>>>>>>>> regardless whether thinking so would be right or wrong. >>>>>>>>>>> >>>>>>>>>>>> *This unequivocally proves the behavior of DD correctly >>>>>>>>>>>> simulated by HH* >>>>>>>>>>>> https://liarparadox.org/DD_correctly_simulated_by_HH_is_Proven.pdf >>>>>>>>>>> >>>>>>>>>>> Why would anyone construe my words as any rebuttal to that? >>>>>>>>>>> That pdf >>>>>>>>>>> merely claims that a partucuar author (a C program) proves >>>>>>>>>>> two particular >>>>>>>>>>> claims, the second of which is badly formed (because of the two >>>>>>>>>>> verbs it is hard to parse and consequently hard to be sure >>>>>>>>>>> that the >>>>>>>>>>> apparent meaning or apparent lack of meaning is what is >>>>>>>>>>> intended). >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> *I will dumb it down for you some more* >>>>>>>>> >>>>>>>>> Did you knwo that "dumb it down" does not mean 'change the topic'? >>>>>>>>> >>>>>>>>>> Try any show how this DD can be correctly simulated by any HH >>>>>>>>>> such that this DD reaches past its machine address [00001dbe] >>>>>>>>>> >>>>>>>>>> _DD() >>>>>>>>>> [00001e12] 55 push ebp >>>>>>>>>> [00001e13] 8bec mov ebp,esp >>>>>>>>>> [00001e15] 51 push ecx >>>>>>>>>> [00001e16] 8b4508 mov eax,[ebp+08] >>>>>>>>>> [00001e19] 50 push eax ; push DD >>>>>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08] >>>>>>>>>> [00001e1d] 51 push ecx ; push DD >>>>>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH >>>>>>>>>> >>>>>>>>>> *That meets this criteria* >>>>>>>>> >>>>>>>>> It doesn't if you mean the criteria implied by the subject line. >>>>>>>>> >>>>>>>> >>>>>>>> Yes it does mean that when we ourselves detect the repeating >>>>>>>> state of DD correctly simulated by HH does meet the first part >>>>>>>> of the following criteria: >>>>>>> >>>>>>> What does your "first part" mean? There is more than one way to >>>>>>> partition the criteria. >>>>>>> >>>>>> >>>>>> If simulating halt decider HH correctly simulates its input DD >>>>>> until HH correctly determines that its simulated DD would never >>>>>> stop running unless aborted then >>>>> >>>>> That is all of the criteria, so should not be called "first part". >>>>> Atually Sipser only agreed about H and D, not about HH and DD but >>>>> that does not make any difference for the above. >>>> >>>> Professor Sipser knew full well that H and D are mere >>>> placeholders for simulating halt decider H with arbitrary input D. >>> >>> Yes, as nothing more is specified in the agreed text. But his expressed >>> agreement does not extend to any substition of those placeholders. >>> >> >> It allows substitution of any simulating halt decider for H >> and any finite string input for D. If you are going to lie >> about this I am going to quit looking at what you say. >> >> <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 words 10/13/2022> > > And you can only use that with the definiton Professor Sipser has for > "Correct Simulation" which you don't do, I prove that my simulation is correct and your "rebuttal" is refusal to look at this proof. This makes your claim that my simulation is incorrect defamation and not any actual rebuttal. On 6/5/2024 10:58 PM, Richard Damon wrote: > On 6/5/24 11:44 PM, olcott wrote: >> >> THIS IS ALL THAT YOU WILL EVER GET TO TALK >> TO ME ABOUT UNTIL YOU ACKNOWLEDGE THAT >> I AM CORRECT OR YOU PROVE THAT I AM INCORRECT > > But, as I said, I won't acknowledge that you > are correct, because I am not willing to put > that effort into your worthless claim. > That you call my proof not a proof is also defamation unless until you correctly point out anything that is missing from this proof. -- 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:10 -0400 |
| Subject | Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis |
| Message-ID | <v41oo8$3cg3t$22@i2pn2.org> |
| In reply to | #106677 |
On 6/8/24 9:48 AM, olcott wrote: > On 6/8/2024 8:10 AM, Richard Damon wrote: >> On 6/8/24 8:52 AM, olcott wrote: >>> On 6/8/2024 1:36 AM, Mikko wrote: >>>> On 2024-06-07 17:11:39 +0000, olcott said: >>>> >>>>> On 6/7/2024 11:56 AM, Mikko wrote: >>>>>> On 2024-06-07 14:47:35 +0000, olcott said: >>>>>> >>>>>>> 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: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> *HOW PARTIAL SIMULATIONS CORRECTLY DETERMINE NON-HALTING* >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 10/13/2022 11:29:23 AM >>>>>>>>>>>>>>> MIT Professor Michael Sipser agreed this verbatim >>>>>>>>>>>>>>> paragraph is correct >>>>>>>>>>>>>>> (He has neither reviewed nor agreed to anything else in >>>>>>>>>>>>>>> this paper) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> <Professor Sipser agreed> >>>>>>>>>>>>>>> If simulating halt decider H correctly simulates its >>>>>>>>>>>>>>> input D until H >>>>>>>>>>>>>>> correctly determines that its simulated D would never >>>>>>>>>>>>>>> stop running >>>>>>>>>>>>>>> unless aborted then >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> H can abort its simulation of D and correctly report that >>>>>>>>>>>>>>> D specifies a >>>>>>>>>>>>>>> non-halting sequence of configurations. >>>>>>>>>>>>>>> </Professor Sipser agreed> >>>>>>>>>>>>>> >>>>>>>>>>>>>> It is quite clear what Professor Sipser agreed. >>>>>>>>>>>>> >>>>>>>>>>>>> Those were my verbatim words that he agreed to, no one >>>>>>>>>>>>> has ever correctly provided any alternative interpretation >>>>>>>>>>>>> that could possibly make my own HH(DD,DD)==0 incorrect. >>>>>>>>>>>> >>>>>>>>>>>> One can agree with those words because they are both clear >>>>>>>>>>>> and true. >>>>>>>>>>>> Whether they are sufficient to your purposes is another >>>>>>>>>>>> problem but >>>>>>>>>>>> that is nor relevant to their acceptablility. >>>>>>>>>>>> >>>>>>>>>>>>>> If you use those words >>>>>>>>>>>>>> as the second last part of your proof then it sould be >>>>>>>>>>>>>> obvious that we >>>>>>>>>>>>>> need to look at the other parts in order to find an error >>>>>>>>>>>>>> in the proof. >>>>>>>>>>>>> >>>>>>>>>>>>> That is slightly more than zero supporting reasoning yet >>>>>>>>>>>>> mere gibberish >>>>>>>>>>>>> when construed as any rebuttal to this: >>>>>>>>>>>> >>>>>>>>>>>> Those who disagree with you about whether something is >>>>>>>>>>>> "gibberish" may >>>>>>>>>>>> think that you are stupid. You probably don't want them to >>>>>>>>>>>> think so, >>>>>>>>>>>> regardless whether thinking so would be right or wrong. >>>>>>>>>>>> >>>>>>>>>>>>> *This unequivocally proves the behavior of DD correctly >>>>>>>>>>>>> simulated by HH* >>>>>>>>>>>>> https://liarparadox.org/DD_correctly_simulated_by_HH_is_Proven.pdf >>>>>>>>>>>> >>>>>>>>>>>> Why would anyone construe my words as any rebuttal to that? >>>>>>>>>>>> That pdf >>>>>>>>>>>> merely claims that a partucuar author (a C program) proves >>>>>>>>>>>> two particular >>>>>>>>>>>> claims, the second of which is badly formed (because of the two >>>>>>>>>>>> verbs it is hard to parse and consequently hard to be sure >>>>>>>>>>>> that the >>>>>>>>>>>> apparent meaning or apparent lack of meaning is what is >>>>>>>>>>>> intended). >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> *I will dumb it down for you some more* >>>>>>>>>> >>>>>>>>>> Did you knwo that "dumb it down" does not mean 'change the >>>>>>>>>> topic'? >>>>>>>>>> >>>>>>>>>>> Try any show how this DD can be correctly simulated by any HH >>>>>>>>>>> such that this DD reaches past its machine address [00001dbe] >>>>>>>>>>> >>>>>>>>>>> _DD() >>>>>>>>>>> [00001e12] 55 push ebp >>>>>>>>>>> [00001e13] 8bec mov ebp,esp >>>>>>>>>>> [00001e15] 51 push ecx >>>>>>>>>>> [00001e16] 8b4508 mov eax,[ebp+08] >>>>>>>>>>> [00001e19] 50 push eax ; push DD >>>>>>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08] >>>>>>>>>>> [00001e1d] 51 push ecx ; push DD >>>>>>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH >>>>>>>>>>> >>>>>>>>>>> *That meets this criteria* >>>>>>>>>> >>>>>>>>>> It doesn't if you mean the criteria implied by the subject line. >>>>>>>>>> >>>>>>>>> >>>>>>>>> Yes it does mean that when we ourselves detect the repeating >>>>>>>>> state of DD correctly simulated by HH does meet the first part >>>>>>>>> of the following criteria: >>>>>>>> >>>>>>>> What does your "first part" mean? There is more than one way to >>>>>>>> partition the criteria. >>>>>>>> >>>>>>> >>>>>>> If simulating halt decider HH correctly simulates its input DD >>>>>>> until HH correctly determines that its simulated DD would never >>>>>>> stop running unless aborted then >>>>>> >>>>>> That is all of the criteria, so should not be called "first part". >>>>>> Atually Sipser only agreed about H and D, not about HH and DD but >>>>>> that does not make any difference for the above. >>>>> >>>>> Professor Sipser knew full well that H and D are mere >>>>> placeholders for simulating halt decider H with arbitrary input D. >>>> >>>> Yes, as nothing more is specified in the agreed text. But his expressed >>>> agreement does not extend to any substition of those placeholders. >>>> >>> >>> It allows substitution of any simulating halt decider for H >>> and any finite string input for D. If you are going to lie >>> about this I am going to quit looking at what you say. >>> >>> <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 words 10/13/2022> >> >> And you can only use that with the definiton Professor Sipser has for >> "Correct Simulation" which you don't do, > > I prove that my simulation is correct and your "rebuttal" > is refusal to look at this proof. Nope, Not by the definition that Professor Sipser uses. You don't get to change his meaning. PERIOD. > Nope, > This makes your claim that my simulation is incorrect > defamation and not any actual rebuttal. Nope. Since you don't actual prove what you claim, me saying you don't prove it is a fact and not defamation. > > On 6/5/2024 10:58 PM, Richard Damon wrote: > > On 6/5/24 11:44 PM, olcott wrote: > >> > >> THIS IS ALL THAT YOU WILL EVER GET TO TALK > >> TO ME ABOUT UNTIL YOU ACKNOWLEDGE THAT > >> I AM CORRECT OR YOU PROVE THAT I AM INCORRECT > > > > But, as I said, I won't acknowledge that you > > are correct, because I am not willing to put > > that effort into your worthless claim. > > > > That you call my proof not a proof is also defamation > unless until you correctly point out anything that is > missing from this proof. > > But it is a FACT. I HAVE pointed out what is missing, ANY set of truth-perserving operations from the accepted facts (which will of course need to name the fact they are working from) to your conclusion.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-08 09:20 -0500 |
| Subject | Re: How Partial Simulations correctly determine non-halting ---Should I quit Richard at this point? |
| Message-ID | <v41pbc$2kanc$15@dont-email.me> |
| In reply to | #106691 |
On 6/8/2024 9:10 AM, Richard Damon wrote:
> On 6/8/24 9:48 AM, olcott wrote:
>> On 6/8/2024 8:10 AM, Richard Damon wrote:
>>> On 6/8/24 8:52 AM, olcott wrote:
>>>> On 6/8/2024 1:36 AM, Mikko wrote:
>>>>> On 2024-06-07 17:11:39 +0000, olcott said:
>>>>>
>>>>>> On 6/7/2024 11:56 AM, Mikko wrote:
>>>>>>> On 2024-06-07 14:47:35 +0000, olcott said:
>>>>>>>
>>>>>>>> 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:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> *HOW PARTIAL SIMULATIONS CORRECTLY DETERMINE NON-HALTING*
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 10/13/2022 11:29:23 AM
>>>>>>>>>>>>>>>> MIT Professor Michael Sipser agreed this verbatim
>>>>>>>>>>>>>>>> paragraph is correct
>>>>>>>>>>>>>>>> (He has neither reviewed nor agreed to anything else in
>>>>>>>>>>>>>>>> this paper)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> <Professor Sipser agreed>
>>>>>>>>>>>>>>>> If simulating halt decider H correctly simulates its
>>>>>>>>>>>>>>>> input D until H
>>>>>>>>>>>>>>>> correctly determines that its simulated D would never
>>>>>>>>>>>>>>>> stop running
>>>>>>>>>>>>>>>> unless aborted then
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> H can abort its simulation of D and correctly report
>>>>>>>>>>>>>>>> that D specifies a
>>>>>>>>>>>>>>>> non-halting sequence of configurations.
>>>>>>>>>>>>>>>> </Professor Sipser agreed>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It is quite clear what Professor Sipser agreed.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Those were my verbatim words that he agreed to, no one
>>>>>>>>>>>>>> has ever correctly provided any alternative interpretation
>>>>>>>>>>>>>> that could possibly make my own HH(DD,DD)==0 incorrect.
>>>>>>>>>>>>>
>>>>>>>>>>>>> One can agree with those words because they are both clear
>>>>>>>>>>>>> and true.
>>>>>>>>>>>>> Whether they are sufficient to your purposes is another
>>>>>>>>>>>>> problem but
>>>>>>>>>>>>> that is nor relevant to their acceptablility.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If you use those words
>>>>>>>>>>>>>>> as the second last part of your proof then it sould be
>>>>>>>>>>>>>>> obvious that we
>>>>>>>>>>>>>>> need to look at the other parts in order to find an error
>>>>>>>>>>>>>>> in the proof.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> That is slightly more than zero supporting reasoning yet
>>>>>>>>>>>>>> mere gibberish
>>>>>>>>>>>>>> when construed as any rebuttal to this:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Those who disagree with you about whether something is
>>>>>>>>>>>>> "gibberish" may
>>>>>>>>>>>>> think that you are stupid. You probably don't want them to
>>>>>>>>>>>>> think so,
>>>>>>>>>>>>> regardless whether thinking so would be right or wrong.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> *This unequivocally proves the behavior of DD correctly
>>>>>>>>>>>>>> simulated by HH*
>>>>>>>>>>>>>> https://liarparadox.org/DD_correctly_simulated_by_HH_is_Proven.pdf
>>>>>>>>>>>>>
>>>>>>>>>>>>> Why would anyone construe my words as any rebuttal to that?
>>>>>>>>>>>>> That pdf
>>>>>>>>>>>>> merely claims that a partucuar author (a C program) proves
>>>>>>>>>>>>> two particular
>>>>>>>>>>>>> claims, the second of which is badly formed (because of the
>>>>>>>>>>>>> two
>>>>>>>>>>>>> verbs it is hard to parse and consequently hard to be sure
>>>>>>>>>>>>> that the
>>>>>>>>>>>>> apparent meaning or apparent lack of meaning is what is
>>>>>>>>>>>>> intended).
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> *I will dumb it down for you some more*
>>>>>>>>>>>
>>>>>>>>>>> Did you knwo that "dumb it down" does not mean 'change the
>>>>>>>>>>> topic'?
>>>>>>>>>>>
>>>>>>>>>>>> Try any show how this DD can be correctly simulated by any HH
>>>>>>>>>>>> such that this DD reaches past its machine address [00001dbe]
>>>>>>>>>>>>
>>>>>>>>>>>> _DD()
>>>>>>>>>>>> [00001e12] 55 push ebp
>>>>>>>>>>>> [00001e13] 8bec mov ebp,esp
>>>>>>>>>>>> [00001e15] 51 push ecx
>>>>>>>>>>>> [00001e16] 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>> [00001e19] 50 push eax ; push DD
>>>>>>>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>> [00001e1d] 51 push ecx ; push DD
>>>>>>>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH
>>>>>>>>>>>>
>>>>>>>>>>>> *That meets this criteria*
>>>>>>>>>>>
>>>>>>>>>>> It doesn't if you mean the criteria implied by the subject line.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Yes it does mean that when we ourselves detect the repeating
>>>>>>>>>> state of DD correctly simulated by HH does meet the first part
>>>>>>>>>> of the following criteria:
>>>>>>>>>
>>>>>>>>> What does your "first part" mean? There is more than one way to
>>>>>>>>> partition the criteria.
>>>>>>>>>
>>>>>>>>
>>>>>>>> If simulating halt decider HH correctly simulates its input DD
>>>>>>>> until HH correctly determines that its simulated DD would never
>>>>>>>> stop running unless aborted then
>>>>>>>
>>>>>>> That is all of the criteria, so should not be called "first part".
>>>>>>> Atually Sipser only agreed about H and D, not about HH and DD but
>>>>>>> that does not make any difference for the above.
>>>>>>
>>>>>> Professor Sipser knew full well that H and D are mere
>>>>>> placeholders for simulating halt decider H with arbitrary input D.
>>>>>
>>>>> Yes, as nothing more is specified in the agreed text. But his
>>>>> expressed
>>>>> agreement does not extend to any substition of those placeholders.
>>>>>
>>>>
>>>> It allows substitution of any simulating halt decider for H
>>>> and any finite string input for D. If you are going to lie
>>>> about this I am going to quit looking at what you say.
>>>>
>>>> <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 words 10/13/2022>
>>>
>>> And you can only use that with the definiton Professor Sipser has for
>>> "Correct Simulation" which you don't do,
>>
>> I prove that my simulation is correct and your "rebuttal"
>> is refusal to look at this proof.
>
> Nope, Not by the definition that Professor Sipser uses.
>
> You don't get to change his meaning. PERIOD.
>
>>
> Nope, > This makes your claim that my simulation is incorrect
>> defamation and not any actual rebuttal.
>
> Nope. Since you don't actual prove what you claim, me saying you don't
> prove it is a fact and not defamation.
>
>>
>> On 6/5/2024 10:58 PM, Richard Damon wrote:
>> > On 6/5/24 11:44 PM, olcott wrote:
>> >>
>> >> THIS IS ALL THAT YOU WILL EVER GET TO TALK
>> >> TO ME ABOUT UNTIL YOU ACKNOWLEDGE THAT
>> >> I AM CORRECT OR YOU PROVE THAT I AM INCORRECT
>> >
>> > But, as I said, I won't acknowledge that you
>> > are correct, because I am not willing to put
>> > that effort into your worthless claim.
>> >
>>
>> That you call my proof not a proof is also defamation
>> unless until you correctly point out anything that is
>> missing from this proof.
>>
>>
>
> But it is a FACT.
>
> I HAVE pointed out what is missing, ANY set of truth-perserving
> operations from the accepted facts (which will of course need to name
> the fact they are working from) to your conclusion.
The accepted facts are here
(a) The x86 language
(b) The notion of an x86 emulator
{The proof that No DDD correctly emulated by any x86
emulator H can possibly reach its own [00001df6] instruction}
Is the set of possible execution traces of DDD correctly
emulated by x86 emulator HH on the basis of the above
accepted facts.
Maybe you are just clueless about these technical details
are are trying to hide this with pure bluster.
_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]
You keep disagreeing with the fact that DDD correctly
emulated by x86 emulator HH only has one single correct
execution trace of repeating the fist seven lines until
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:54 -0400 |
| Subject | Re: How Partial Simulations correctly determine non-halting ---Should I quit Richard at this point? |
| Message-ID | <v41raj$3cg3t$25@i2pn2.org> |
| In reply to | #106697 |
On 6/8/24 10:20 AM, olcott wrote:
> On 6/8/2024 9:10 AM, Richard Damon wrote:
>> On 6/8/24 9:48 AM, olcott wrote:
>>> On 6/8/2024 8:10 AM, Richard Damon wrote:
>>>> On 6/8/24 8:52 AM, olcott wrote:
>>>>> On 6/8/2024 1:36 AM, Mikko wrote:
>>>>>> On 2024-06-07 17:11:39 +0000, olcott said:
>>>>>>
>>>>>>> On 6/7/2024 11:56 AM, Mikko wrote:
>>>>>>>> On 2024-06-07 14:47:35 +0000, olcott said:
>>>>>>>>
>>>>>>>>> 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:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> *HOW PARTIAL SIMULATIONS CORRECTLY DETERMINE NON-HALTING*
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 10/13/2022 11:29:23 AM
>>>>>>>>>>>>>>>>> MIT Professor Michael Sipser agreed this verbatim
>>>>>>>>>>>>>>>>> paragraph is correct
>>>>>>>>>>>>>>>>> (He has neither reviewed nor agreed to anything else in
>>>>>>>>>>>>>>>>> this paper)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> <Professor Sipser agreed>
>>>>>>>>>>>>>>>>> If simulating halt decider H correctly simulates its
>>>>>>>>>>>>>>>>> input D until H
>>>>>>>>>>>>>>>>> correctly determines that its simulated D would never
>>>>>>>>>>>>>>>>> stop running
>>>>>>>>>>>>>>>>> unless aborted then
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> H can abort its simulation of D and correctly report
>>>>>>>>>>>>>>>>> that D specifies a
>>>>>>>>>>>>>>>>> non-halting sequence of configurations.
>>>>>>>>>>>>>>>>> </Professor Sipser agreed>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> It is quite clear what Professor Sipser agreed.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Those were my verbatim words that he agreed to, no one
>>>>>>>>>>>>>>> has ever correctly provided any alternative interpretation
>>>>>>>>>>>>>>> that could possibly make my own HH(DD,DD)==0 incorrect.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> One can agree with those words because they are both clear
>>>>>>>>>>>>>> and true.
>>>>>>>>>>>>>> Whether they are sufficient to your purposes is another
>>>>>>>>>>>>>> problem but
>>>>>>>>>>>>>> that is nor relevant to their acceptablility.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> If you use those words
>>>>>>>>>>>>>>>> as the second last part of your proof then it sould be
>>>>>>>>>>>>>>>> obvious that we
>>>>>>>>>>>>>>>> need to look at the other parts in order to find an
>>>>>>>>>>>>>>>> error in the proof.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> That is slightly more than zero supporting reasoning yet
>>>>>>>>>>>>>>> mere gibberish
>>>>>>>>>>>>>>> when construed as any rebuttal to this:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Those who disagree with you about whether something is
>>>>>>>>>>>>>> "gibberish" may
>>>>>>>>>>>>>> think that you are stupid. You probably don't want them to
>>>>>>>>>>>>>> think so,
>>>>>>>>>>>>>> regardless whether thinking so would be right or wrong.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *This unequivocally proves the behavior of DD correctly
>>>>>>>>>>>>>>> simulated by HH*
>>>>>>>>>>>>>>> https://liarparadox.org/DD_correctly_simulated_by_HH_is_Proven.pdf
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Why would anyone construe my words as any rebuttal to
>>>>>>>>>>>>>> that? That pdf
>>>>>>>>>>>>>> merely claims that a partucuar author (a C program) proves
>>>>>>>>>>>>>> two particular
>>>>>>>>>>>>>> claims, the second of which is badly formed (because of
>>>>>>>>>>>>>> the two
>>>>>>>>>>>>>> verbs it is hard to parse and consequently hard to be sure
>>>>>>>>>>>>>> that the
>>>>>>>>>>>>>> apparent meaning or apparent lack of meaning is what is
>>>>>>>>>>>>>> intended).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> *I will dumb it down for you some more*
>>>>>>>>>>>>
>>>>>>>>>>>> Did you knwo that "dumb it down" does not mean 'change the
>>>>>>>>>>>> topic'?
>>>>>>>>>>>>
>>>>>>>>>>>>> Try any show how this DD can be correctly simulated by any HH
>>>>>>>>>>>>> such that this DD reaches past its machine address [00001dbe]
>>>>>>>>>>>>>
>>>>>>>>>>>>> _DD()
>>>>>>>>>>>>> [00001e12] 55 push ebp
>>>>>>>>>>>>> [00001e13] 8bec mov ebp,esp
>>>>>>>>>>>>> [00001e15] 51 push ecx
>>>>>>>>>>>>> [00001e16] 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>>> [00001e19] 50 push eax ; push DD
>>>>>>>>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>>> [00001e1d] 51 push ecx ; push DD
>>>>>>>>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH
>>>>>>>>>>>>>
>>>>>>>>>>>>> *That meets this criteria*
>>>>>>>>>>>>
>>>>>>>>>>>> It doesn't if you mean the criteria implied by the subject
>>>>>>>>>>>> line.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Yes it does mean that when we ourselves detect the repeating
>>>>>>>>>>> state of DD correctly simulated by HH does meet the first part
>>>>>>>>>>> of the following criteria:
>>>>>>>>>>
>>>>>>>>>> What does your "first part" mean? There is more than one way to
>>>>>>>>>> partition the criteria.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> If simulating halt decider HH correctly simulates its input DD
>>>>>>>>> until HH correctly determines that its simulated DD would
>>>>>>>>> never
>>>>>>>>> stop running unless aborted then
>>>>>>>>
>>>>>>>> That is all of the criteria, so should not be called "first part".
>>>>>>>> Atually Sipser only agreed about H and D, not about HH and DD but
>>>>>>>> that does not make any difference for the above.
>>>>>>>
>>>>>>> Professor Sipser knew full well that H and D are mere
>>>>>>> placeholders for simulating halt decider H with arbitrary input D.
>>>>>>
>>>>>> Yes, as nothing more is specified in the agreed text. But his
>>>>>> expressed
>>>>>> agreement does not extend to any substition of those placeholders.
>>>>>>
>>>>>
>>>>> It allows substitution of any simulating halt decider for H
>>>>> and any finite string input for D. If you are going to lie
>>>>> about this I am going to quit looking at what you say.
>>>>>
>>>>> <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 words 10/13/2022>
>>>>
>>>> And you can only use that with the definiton Professor Sipser has
>>>> for "Correct Simulation" which you don't do,
>>>
>>> I prove that my simulation is correct and your "rebuttal"
>>> is refusal to look at this proof.
>>
>> Nope, Not by the definition that Professor Sipser uses.
>>
>> You don't get to change his meaning. PERIOD.
>>
>>>
>> Nope, > This makes your claim that my simulation is incorrect
>>> defamation and not any actual rebuttal.
>>
>> Nope. Since you don't actual prove what you claim, me saying you don't
>> prove it is a fact and not defamation.
>>
>>>
>>> On 6/5/2024 10:58 PM, Richard Damon wrote:
>>> > On 6/5/24 11:44 PM, olcott wrote:
>>> >>
>>> >> THIS IS ALL THAT YOU WILL EVER GET TO TALK
>>> >> TO ME ABOUT UNTIL YOU ACKNOWLEDGE THAT
>>> >> I AM CORRECT OR YOU PROVE THAT I AM INCORRECT
>>> >
>>> > But, as I said, I won't acknowledge that you
>>> > are correct, because I am not willing to put
>>> > that effort into your worthless claim.
>>> >
>>>
>>> That you call my proof not a proof is also defamation
>>> unless until you correctly point out anything that is
>>> missing from this proof.
>>>
>>>
>>
>> But it is a FACT.
>>
>> I HAVE pointed out what is missing, ANY set of truth-perserving
>> operations from the accepted facts (which will of course need to name
>> the fact they are working from) to your conclusion.
>
> The accepted facts are here
> (a) The x86 language
> (b) The notion of an x86 emulator
>
> {The proof that No DDD correctly emulated by any x86
> emulator H can possibly reach its own [00001df6] instruction}
So, how do you show this claim?
Do you have a tracing of the full INFINITE SET of possible Hs?
>
> Is the set of possible execution traces of DDD correctly
> emulated by x86 emulator HH on the basis of the above
> accepted facts.
>
> Maybe you are just clueless about these technical details
> are are trying to hide this with pure bluster.
>
> _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]
>
> You keep disagreeing with the fact that DDD correctly
> emulated by x86 emulator HH only has one single correct
> execution trace of repeating the fist seven lines until
> out-of-memory error.
>
But that is an INCORRECT trace per your definition,
The call HH instruction MUST be simulated into HH because that IS the
behavior of the x86 instruction.
So, either you admit that you can only trace the x86 instructions of
this input for 7 instructions (and thus not get to the out of memory
error) or
that your input is actual the pairing of this code with the decider (and
thus each decider gets its own input, and thus each input is only
simulated for a finite number of steps, and many of these will just stop
after a finite number of steps with an incomplete (but correct to your
definition) simulation that doesn't prove non-halting.
or you do what the proof says, and pair the DDD with one of the specific
deciders that you claim to give the right results, and when we simulate
that input with another version of H that simulates enough longer, we
see that it WILL reach a final state.
So, which versio is it? Your conclusion is wrong
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-08 10:07 -0500 |
| Subject | Re: How Partial Simulations correctly determine non-halting ---Should I quit Richard at this point? |
| Message-ID | <v41s4e$2l7o9$2@dont-email.me> |
| In reply to | #106707 |
On 6/8/2024 9:54 AM, Richard Damon wrote:
> On 6/8/24 10:20 AM, olcott wrote:
>> On 6/8/2024 9:10 AM, Richard Damon wrote:
>>>
>>> I HAVE pointed out what is missing, ANY set of truth-perserving
>>> operations from the accepted facts (which will of course need to name
>>> the fact they are working from) to your conclusion.
>>
>> The accepted facts are here
>> (a) The x86 language
>> (b) The notion of an x86 emulator
>>
>> {The proof that No DDD correctly emulated by any x86
>> emulator H can possibly reach its own [00001df6] instruction}
>
> So, how do you show this claim?
>
> Do you have a tracing of the full INFINITE SET of possible Hs?
>
>>
>> Is the set of possible execution traces of DDD correctly
>> emulated by x86 emulator HH on the basis of the above
>> accepted facts.
>>
>> Maybe you are just clueless about these technical details
>> are are trying to hide this with pure bluster.
>>
>> _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]
>>
>> You keep disagreeing with the fact that DDD correctly
>> emulated by x86 emulator HH only has one single correct
>> execution trace of repeating the fist seven lines until
>> out-of-memory error.
>>
>
> But that is an INCORRECT trace per your definition,
>
> The call HH instruction MUST be simulated into HH because that IS the
> behavior of the x86 instruction.
Did I ever say that it is not?
For the above DDD correctly emulated by x86 emulator HH
the first seven instructions of DD keep repeating because
DDD keeps calling HH(DDD,DDD) to emulate itself again and
again until HH/DDD hits out-of-memory exception.
This is the only post that I will reply to you on.
I need you to stay focused on this one single point
until you understand it.
*Even Ben admits that H does meet the Sipser criteria*
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
> I don't think that is the shell game. PO really /has/ an H
> (it's trivial to do for this one case) that correctly determines
> that P(P) *would* never stop running *unless* aborted.
--
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 11:15 -0400 |
| Subject | Re: How Partial Simulations correctly determine non-halting ---Should I quit Richard at this point? |
| Message-ID | <v41sjf$3cg3s$8@i2pn2.org> |
| In reply to | #106709 |
On 6/8/24 11:07 AM, olcott wrote:
> On 6/8/2024 9:54 AM, Richard Damon wrote:
>> On 6/8/24 10:20 AM, olcott wrote:
>>> On 6/8/2024 9:10 AM, Richard Damon wrote:
>>>>
>>>> I HAVE pointed out what is missing, ANY set of truth-perserving
>>>> operations from the accepted facts (which will of course need to
>>>> name the fact they are working from) to your conclusion.
>>>
>>> The accepted facts are here
>>> (a) The x86 language
>>> (b) The notion of an x86 emulator
>>>
>>> {The proof that No DDD correctly emulated by any x86
>>> emulator H can possibly reach its own [00001df6] instruction}
>>
>> So, how do you show this claim?
>>
>> Do you have a tracing of the full INFINITE SET of possible Hs?
>>
>>>
>>> Is the set of possible execution traces of DDD correctly
>>> emulated by x86 emulator HH on the basis of the above
>>> accepted facts.
>>>
>>> Maybe you are just clueless about these technical details
>>> are are trying to hide this with pure bluster.
>>>
>>> _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]
>>>
>>> You keep disagreeing with the fact that DDD correctly
>>> emulated by x86 emulator HH only has one single correct
>>> execution trace of repeating the fist seven lines until
>>> out-of-memory error.
>>>
>>
>> But that is an INCORRECT trace per your definition,
>>
>> The call HH instruction MUST be simulated into HH because that IS the
>> behavior of the x86 instruction.
>
> Did I ever say that it is not?
> For the above DDD correctly emulated by x86 emulator HH
> the first seven instructions of DD keep repeating because
> DDD keeps calling HH(DDD,DDD) to emulate itself again and
> again until HH/DDD hits out-of-memory exception.
So the x86 emulation of the code must go into HH(DDD,DDD)
The correct x86 emulation of the call to HH(DDD,DDD) will NEVER get to
the sequence of instrucitions starting at 00001DE2, as the code will
never jump there to just execute it.
By your code, the simulator will "Debug Step" those instructions.
By a pure emulator, that would mean translating the machine code into
the operations it will perform, and then manipulating the virtual
register set being kept by the emulator.
If your "simulation" is ACTUALLY being done using the debug step
hardware of the system (or simulating the actions of that hardware) then
the instruction are executed, but not in sequence as they have all the
steps of the debugger/tracing around them.
So, your claim of what happens just shows you don't understand what the
program you are using actually is doing.
That might explain why the trace you posted the other day wasn't
actually the trace you claimed it was.
>
> This is the only post that I will reply to you on.
> I need you to stay focused on this one single point
> until you understand it.
Is that a promise? I think you will break it.
>
> *Even Ben admits that H does meet the Sipser criteria*
>
> On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
> > I don't think that is the shell game. PO really /has/ an H
> > (it's trivial to do for this one case) that correctly determines
> > that P(P) *would* never stop running *unless* aborted.
>
>
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-08 10:32 -0500 |
| Subject | Re: How Partial Simulations correctly determine non-halting ---Should I quit Richard at this point? |
| Message-ID | <v41tj5$2ll6e$1@dont-email.me> |
| In reply to | #106711 |
On 6/8/2024 10:15 AM, Richard Damon wrote:
> On 6/8/24 11:07 AM, olcott wrote:
>> On 6/8/2024 9:54 AM, Richard Damon wrote:
>>> On 6/8/24 10:20 AM, olcott wrote:
>>>> On 6/8/2024 9:10 AM, Richard Damon wrote:
>>>>>
>>>>> I HAVE pointed out what is missing, ANY set of truth-perserving
>>>>> operations from the accepted facts (which will of course need to
>>>>> name the fact they are working from) to your conclusion.
>>>>
>>>> The accepted facts are here
>>>> (a) The x86 language
>>>> (b) The notion of an x86 emulator
>>>>
>>>> {The proof that No DDD correctly emulated by any x86
>>>> emulator H can possibly reach its own [00001df6] instruction}
>>>
>>> So, how do you show this claim?
>>>
>>> Do you have a tracing of the full INFINITE SET of possible Hs?
>>>
>>>>
>>>> Is the set of possible execution traces of DDD correctly
>>>> emulated by x86 emulator HH on the basis of the above
>>>> accepted facts.
>>>>
>>>> Maybe you are just clueless about these technical details
>>>> are are trying to hide this with pure bluster.
>>>>
>>>> _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]
>>>>
>>>> You keep disagreeing with the fact that DDD correctly
>>>> emulated by x86 emulator HH only has one single correct
>>>> execution trace of repeating the fist seven lines until
>>>> out-of-memory error.
>>>>
>>>
>>> But that is an INCORRECT trace per your definition,
>>>
>>> The call HH instruction MUST be simulated into HH because that IS the
>>> behavior of the x86 instruction.
>>
>> Did I ever say that it is not?
>> For the above DDD correctly emulated by x86 emulator HH
>> the first seven instructions of DD keep repeating because
>> DDD keeps calling HH(DDD,DDD) to emulate itself again and
>> again until HH/DDD hits out-of-memory exception.
>
> So the x86 emulation of the code must go into HH(DDD,DDD)
>
It is pretty stupid to assume otherwise when HH is
stipulated to be an x86 emulator.
> The correct x86 emulation of the call to HH(DDD,DDD) will NEVER get to
> the sequence of instrucitions starting at 00001DE2, as the code will
> never jump there to just execute it.
>
Your are saying that incorrectly DDD correctly emulated by
x86 emulator HH cannot possibly reach it own machine address
of [00001df6].
> By your code, the simulator will "Debug Step" those instructions.
>
The underlying details of one HH are irrelevant when I reference
an infinite set:
{The proof that No DDD correctly emulated by
any x86 emulator H
any x86 emulator H
any x86 emulator H
any x86 emulator H
any x86 emulator H
any x86 emulator H
can possibly reach its own [00001df6] instruction}
> By a pure emulator, that would mean translating the machine code into
> the operations it will perform, and then manipulating the virtual
> register set being kept by the emulator.
>
libx86emu does that.
> If your "simulation" is ACTUALLY being done using the debug step
> hardware of the system (or simulating the actions of that hardware) then
> the instruction are executed, but not in sequence as they have all the
> steps of the debugger/tracing around them.
>
That is not how x86 emulators work.
> So, your claim of what happens just shows you don't understand what the
> program you are using actually is doing.
>
No it shows that you don't know how x86 emulators work.
> That might explain why the trace you posted the other day wasn't
> actually the trace you claimed it was.
>
We are only focusing on this one thread and zero deflection
will be tolerated.
>>
>> This is the only post that I will reply to you on.
>> I need you to stay focused on this one single point
>> until you understand it.
>
> Is that a promise? I think you will break it.
>
When you proved to break out of your "stuck in rebuttal mode"
nonsense and talked about closure I backed off this requirement
for a while.
*Even Ben admits that H does meet the Sipser criteria*
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
> I don't think that is the shell game. PO really /has/ an H
> (it's trivial to do for this one case) that correctly determines
> that P(P) *would* never stop running *unless* aborted.
--
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 12:03 -0400 |
| Subject | Re: How Partial Simulations correctly determine non-halting ---Should I quit Richard at this point? |
| Message-ID | <v41vc6$3cg3t$26@i2pn2.org> |
| In reply to | #106712 |
On 6/8/24 11:32 AM, olcott wrote:
> On 6/8/2024 10:15 AM, Richard Damon wrote:
>> On 6/8/24 11:07 AM, olcott wrote:
>>> On 6/8/2024 9:54 AM, Richard Damon wrote:
>>>> On 6/8/24 10:20 AM, olcott wrote:
>>>>> On 6/8/2024 9:10 AM, Richard Damon wrote:
>>>>>>
>>>>>> I HAVE pointed out what is missing, ANY set of truth-perserving
>>>>>> operations from the accepted facts (which will of course need to
>>>>>> name the fact they are working from) to your conclusion.
>>>>>
>>>>> The accepted facts are here
>>>>> (a) The x86 language
>>>>> (b) The notion of an x86 emulator
>>>>>
>>>>> {The proof that No DDD correctly emulated by any x86
>>>>> emulator H can possibly reach its own [00001df6] instruction}
>>>>
>>>> So, how do you show this claim?
>>>>
>>>> Do you have a tracing of the full INFINITE SET of possible Hs?
>>>>
>>>>>
>>>>> Is the set of possible execution traces of DDD correctly
>>>>> emulated by x86 emulator HH on the basis of the above
>>>>> accepted facts.
>>>>>
>>>>> Maybe you are just clueless about these technical details
>>>>> are are trying to hide this with pure bluster.
>>>>>
>>>>> _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]
>>>>>
>>>>> You keep disagreeing with the fact that DDD correctly
>>>>> emulated by x86 emulator HH only has one single correct
>>>>> execution trace of repeating the fist seven lines until
>>>>> out-of-memory error.
>>>>>
>>>>
>>>> But that is an INCORRECT trace per your definition,
>>>>
>>>> The call HH instruction MUST be simulated into HH because that IS
>>>> the behavior of the x86 instruction.
>>>
>>> Did I ever say that it is not?
>>> For the above DDD correctly emulated by x86 emulator HH
>>> the first seven instructions of DD keep repeating because
>>> DDD keeps calling HH(DDD,DDD) to emulate itself again and
>>> again until HH/DDD hits out-of-memory exception.
>>
>> So the x86 emulation of the code must go into HH(DDD,DDD)
>>
>
> It is pretty stupid to assume otherwise when HH is
> stipulated to be an x86 emulator.
Right, so why did you say otherwise?
>
>> The correct x86 emulation of the call to HH(DDD,DDD) will NEVER get to
>> the sequence of instrucitions starting at 00001DE2, as the code will
>> never jump there to just execute it.
>>
>
> Your are saying that incorrectly DDD correctly emulated by
> x86 emulator HH cannot possibly reach it own machine address
> of [00001df6].
I said nothing about that. You are just serving Herring with Red Sauce
agian.
The CORRECT simulation of DDD can NEVER get back to the sequence of
instructions at 00001DE2, as there is never a jump to that address, only
the emulator starting an emuation of that address, and the correst
simulation of a simulatore is NOT the code the simulated simulator is
looking at, but the code of the simulator doing the simulation.
>
>> By your code, the simulator will "Debug Step" those instructions.
>>
>
> The underlying details of one HH are irrelevant when I reference
> an infinite set:\
But not for your definition of the simulation.
>
> {The proof that No DDD correctly emulated by
> any x86 emulator H
> any x86 emulator H
> any x86 emulator H
> any x86 emulator H
> any x86 emulator H
> any x86 emulator H
> can possibly reach its own [00001df6] instruction}
It seems that by your current analysis, it can't get past the
instruction at 00001DED as there is nothing to simulate after that.
Remember, your definition said to simulate the instructions in the
strict order they were reached.
If we don't have the instruction at 00001382, the simulation has to
stop, as we can't go on.
>
>
>> By a pure emulator, that would mean translating the machine code into
>> the operations it will perform, and then manipulating the virtual
>> register set being kept by the emulator.
>>
>
> libx86emu does that.
And if HH is a pure emulator, it need to do it to (or let libx86emu do
it for it). and HH can't interfear with that process by not following
each instruction with the instruction that follows it.
So, does the libx86emu keep a seperate logging of the instructions that
HH is emulating, as would be needed for HH to be able to examine that trace.
The previous trace you posted wasn't the simulation that HH was doing,
but was a trace of the execution of HH iteself.
It seems that HH doesn't actual have a trace of what it did available
(or at least you didn't show it).
But then, you always seemed to have gotten the "levels" of simulation
incorrect.
>
>> If your "simulation" is ACTUALLY being done using the debug step
>> hardware of the system (or simulating the actions of that hardware)
>> then the instruction are executed, but not in sequence as they have
>> all the steps of the debugger/tracing around them.
>>
>
> That is not how x86 emulators work.
But it is what "Debug Step" implies.
Or, are you not familiar with that part of the x86 hardware.
>
>> So, your claim of what happens just shows you don't understand what
>> the program you are using actually is doing.
>>
>
> No it shows that you don't know how x86 emulators work.
So, what did I not understand?
>
>> That might explain why the trace you posted the other day wasn't
>> actually the trace you claimed it was.
>>
>
> We are only focusing on this one thread and zero deflection
> will be tolerated.
Ok, so why doesn't your HH here trace into HH
And why does it start to show a trace of instructions that are never
actually directly simulated by the HH that we are talking about>
>
>>>
>>> This is the only post that I will reply to you on.
>>> I need you to stay focused on this one single point
>>> until you understand it.
>>
>> Is that a promise? I think you will break it.
>>
>
> When you proved to break out of your "stuck in rebuttal mode"
> nonsense and talked about closure I backed off this requirement
> for a while.
>
> *Even Ben admits that H does meet the Sipser criteria*
>
> On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
> > I don't think that is the shell game. PO really /has/ an H
> > (it's trivial to do for this one case) that correctly determines
> > that P(P) *would* never stop running *unless* aborted.
>
Nope, he is just pointing out your circular logic.
Yes, P(P) won't halt if the code of H won't abort it.
But if the code of H does abort it, it will halt.
Thus, if the question actually WAS "Will the template P(P) Halt if the
decider it is pair with doesn't abort its simulation", then he agreed
you could answer No.
But that isn't the Halting Question, so it isn't the correct answer to
the question that H is supposed to answer.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-08 12:10 -0500 |
| Subject | Re: How Partial Simulations correctly determine non-halting ---Should I quit Richard at this point? |
| Message-ID | <v423a9$2m6lc$1@dont-email.me> |
| In reply to | #106713 |
On 6/8/2024 11:03 AM, Richard Damon wrote:
> On 6/8/24 11:32 AM, olcott wrote:
>> On 6/8/2024 10:15 AM, Richard Damon wrote:
>>> On 6/8/24 11:07 AM, olcott wrote:
>>>> On 6/8/2024 9:54 AM, Richard Damon wrote:
>>>>> On 6/8/24 10:20 AM, olcott wrote:
>>>>>> On 6/8/2024 9:10 AM, Richard Damon wrote:
>>>>>>>
>>>>>>> I HAVE pointed out what is missing, ANY set of truth-perserving
>>>>>>> operations from the accepted facts (which will of course need to
>>>>>>> name the fact they are working from) to your conclusion.
>>>>>>
>>>>>> The accepted facts are here
>>>>>> (a) The x86 language
>>>>>> (b) The notion of an x86 emulator
>>>>>>
>>>>>> {The proof that No DDD correctly emulated by any x86
>>>>>> emulator H can possibly reach its own [00001df6] instruction}
>>>>>
>>>>> So, how do you show this claim?
>>>>>
>>>>> Do you have a tracing of the full INFINITE SET of possible Hs?
>>>>>
>>>>>>
>>>>>> Is the set of possible execution traces of DDD correctly
>>>>>> emulated by x86 emulator HH on the basis of the above
>>>>>> accepted facts.
>>>>>>
>>>>>> Maybe you are just clueless about these technical details
>>>>>> are are trying to hide this with pure bluster.
>>>>>>
>>>>>> _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]
>>>>>>
>>>>>> You keep disagreeing with the fact that DDD correctly
>>>>>> emulated by x86 emulator HH only has one single correct
>>>>>> execution trace of repeating the fist seven lines until
>>>>>> out-of-memory error.
>>>>>>
>>>>>
>>>>> But that is an INCORRECT trace per your definition,
>>>>>
>>>>> The call HH instruction MUST be simulated into HH because that IS
>>>>> the behavior of the x86 instruction.
>>>>
>>>> Did I ever say that it is not?
>>>> For the above DDD correctly emulated by x86 emulator HH
>>>> the first seven instructions of DD keep repeating because
>>>> DDD keeps calling HH(DDD,DDD) to emulate itself again and
>>>> again until HH/DDD hits out-of-memory exception.
>>>
>>> So the x86 emulation of the code must go into HH(DDD,DDD)
>>>
>>
>> It is pretty stupid to assume otherwise when HH is
>> stipulated to be an x86 emulator.
>
> Right, so why did you say otherwise?
>
I never said otherwise you simply "read" meanings that I didn't say.
this thread: [Should I quit Richard at this point?]
stands alone and should not be interpreted within the
context of anything else that I ever said.
>>
>>> The correct x86 emulation of the call to HH(DDD,DDD) will NEVER get
>>> to the sequence of instrucitions starting at 00001DE2, as the code
>>> will never jump there to just execute it.
>>>
>>
>> Your are saying that incorrectly DDD correctly emulated by
>> x86 emulator HH cannot possibly reach it own machine address
>> of [00001df6].
>
> I said nothing about that. You are just serving Herring with Red Sauce
> agian.
>
>>> The correct x86 emulation of the call to HH(DDD,DDD) will NEVER get
>>> to the sequence of instructions starting at 00001DE2
Wrong! DDD correctly simulated by HH will never reach its own
machine address of 00001df6 because DDD correctly simulated
by HH keeps starting over with another instance of itself at
00001DE2 after the prior instance calls HH(DDD,DDD) to simulate
itself again.
> The CORRECT simulation of DDD can NEVER get back to the sequence of
> instructions at 00001DE2, as there is never a jump to that address, only
> the emulator starting an emuation of that address, and the correst
> simulation of a simulatore is NOT the code the simulated simulator is
> looking at, but the code of the simulator doing the simulation.
>
DDD correctly simulated by HH will never reach its own
machine address of 00001df6 because DDD correctly simulated
by HH keeps starting over with another instance of itself at
00001DE2 after the prior instance calls HH(DDD,DDD) to simulate
itself again.
>>
>>> By your code, the simulator will "Debug Step" those instructions.
>>>
>>
>> The underlying details of one HH are irrelevant when I reference
>> an infinite set:\
>
> But not for your definition of the simulation.
>
>>
>> {The proof that No DDD correctly emulated by
>> any x86 emulator H
>> any x86 emulator H
>> any x86 emulator H
>> any x86 emulator H
>> any x86 emulator H
>> any x86 emulator H
>> can possibly reach its own [00001df6] instruction}
>
> It seems that by your current analysis, it can't get past the
> instruction at 00001DED as there is nothing to simulate after that.
>
*A stupid thing to say*
>>>>>> [00001ded] e890f5ffff call 00001382 ; call HH
>>>>>> [00001df2] 83c408 add esp,+08
>>>>>> [00001df5] 5d pop ebp
>>>>>> [00001df6] c3 ret
>>>>>> Size in bytes:(0021) [00001df6]
> Remember, your definition said to simulate the instructions in the
> strict order they were reached.
>
> If we don't have the instruction at 00001382, the simulation has to
> stop, as we can't go on.
>
*A stupid thing to say*
>>>>>> _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]
It has been stipulated that there is ALWAYS an x86
emulator at the address 00001382.
>>
>>
>>> By a pure emulator, that would mean translating the machine code into
>>> the operations it will perform, and then manipulating the virtual
>>> register set being kept by the emulator.
>>>
>>
>> libx86emu does that.
>
> And if HH is a pure emulator, it need to do it to (or let libx86emu do
> it for it). and HH can't interfear with that process by not following
> each instruction with the instruction that follows it.
>
This thread is only about what you have already agreed to dozens
of times and you fail to notice that because rebuttal is your
game and honest dialogues are most always off-the-table for you.
*Ben already agreed that the criteria that*
*Professor Sipser agreed to have been met*
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
> I don't think that is the shell game. PO really /has/ an H
> (it's trivial to do for this one case) that correctly determines
> that P(P) *would* never stop running *unless* aborted.
You want to always ignore that so you can remain in rebuttal
mode at the expense of truth.
> So, does the libx86emu keep a seperate logging of the instructions that
> HH is emulating, as would be needed for HH to be able to examine that
> trace.
>
> The previous trace you posted wasn't the simulation that HH was doing,
> but was a trace of the execution of HH iteself.
>
> It seems that HH doesn't actual have a trace of what it did available
> (or at least you didn't show it).
>
LIAR LIAR PANTS ON FIRE
I HAVE SHOWN THIS TRACE AGAIN AND AGAIN FOR THREE YEARS
Begin Local Halt Decider Simulation Execution Trace Stored at:113075
[00001c22][00113061][00113065] 55 push ebp
[00001c23][00113061][00113065] 8bec mov ebp,esp
[00001c25][0011305d][00103031] 51 push ecx
[00001c26][0011305d][00103031] 8b4508 mov eax,[ebp+08]
[00001c29][00113059][00001c22] 50 push eax ; push DD
[00001c2a][00113059][00001c22] 8b4d08 mov ecx,[ebp+08]
[00001c2d][00113055][00001c22] 51 push ecx ; push DD
[00001c2e][00113051][00001c33] e80ff7ffff call 00001342 ; call HH
New slave_stack at:14da95
[00001c22][0015da89][0015da8d] 55 push ebp
[00001c23][0015da89][0015da8d] 8bec mov ebp,esp
[00001c25][0015da85][0014da59] 51 push ecx
[00001c26][0015da85][0014da59] 8b4508 mov eax,[ebp+08]
[00001c29][0015da81][00001c22] 50 push eax ; push DD
[00001c2a][0015da81][00001c22] 8b4d08 mov ecx,[ebp+08]
[00001c2d][0015da7d][00001c22] 51 push ecx ; push DD
[00001c2e][0015da79][00001c33] e80ff7ffff call 00001342 ; call HH
Local Halt Decider: Recursive Simulation Detected Simulation Stopped
First published complete execution trace proving that D is correctly
simulated by H and correctly simulated by simulated H. The proof of
this that everyone has ignored for three solid years is that the derived
execution traces exactly match the behavior specified by the x86
machine code of D.
On 5/29/2021 2:26 PM, olcott wrote:
[Would the simulation of D be infinitely nested unless simulating
partial halt decider H terminated its simulation of D?]
Message-ID: <YJKdnZg9v__rCC_9nZ2dnUU7-QXNnZ2d@giganews.com>
> But then, you always seemed to have gotten the "levels" of simulation
> incorrect.
>
No you just lie about this.
>
>>
>>> If your "simulation" is ACTUALLY being done using the debug step
>>> hardware of the system (or simulating the actions of that hardware)
>>> then the instruction are executed, but not in sequence as they have
>>> all the steps of the debugger/tracing around them.
>>>
>>
>> That is not how x86 emulators work.
>
> But it is what "Debug Step" implies.
>
It <is> a Debug_Step though the emulated code.
You keep freaking forgetting what the Hell an emulator is.
> Or, are you not familiar with that part of the x86 hardware.
>
Yes.
>>
>>> So, your claim of what happens just shows you don't understand what
>>> the program you are using actually is doing.
>>>
>>
>> No it shows that you don't know how x86 emulators work.
>
> So, what did I not understand?
>
You keep freaking forgetting what the Hell an emulator is.
>>
>>> That might explain why the trace you posted the other day wasn't
>>> actually the trace you claimed it was.
>>>
>>
>> We are only focusing on this one thread and zero deflection
>> will be tolerated.
>
> Ok, so why doesn't your HH here trace into HH
>
As I have said 5,000 times when people cannot possibly
understand 1/2 of one page of code mixing in another 250
pages cannot possibly help.
> And why does it start to show a trace of instructions that are never
> actually directly simulated by the HH that we are talking about>
>
I have already proved THREE FREAKING YEARS AGO
that D is correctly simulated by H and D is correctly
simulated by simulated H.
That everyone has ignored this proof is probably
because they were trying to hide their own cluelessness.
>>
>>>>
>>>> This is the only post that I will reply to you on.
>>>> I need you to stay focused on this one single point
>>>> until you understand it.
>>>
>>> Is that a promise? I think you will break it.
>>>
>>
>> When you proved to break out of your "stuck in rebuttal mode"
>> nonsense and talked about closure I backed off this requirement
>> for a while.
>>
>> *Even Ben admits that H does meet the Sipser criteria*
>>
>> On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
>> > I don't think that is the shell game. PO really /has/ an H
>> > (it's trivial to do for this one case) that correctly determines
>> > that P(P) *would* never stop running *unless* aborted.
>>
>
> Nope, he is just pointing out your circular logic.
>
LIAR LIAR PANTS ON FIRE
> Yes, P(P) won't halt if the code of H won't abort it.
>
thus meeting the Sipser approved criteria.
> But if the code of H does abort it, it will halt.
>
D is accountable for the behavior of its actual input and
not freaking accountable for any damn thing else in the
whole freaking universe.
That there is a consensus of opinion against this is
just like the consensus of opinion that the Earth was flat
prior to Pythagoras.
Halt deciders compute the mapping FROM THEIR INPUTS
BASED ON THE ACTUAL BEHAVIOR THAT THIS INPUT SPECIFIES.
This input specifies the behavior of DD correctly
simulated by HH.
That everyone wants to avoid looking at my conclusive
proof that DD correctly simulated by HH has provably
different behavior than the direct executed DD(DD) is
dishonest.
> Thus, if the question actually WAS "Will the template P(P) Halt if the
> decider it is pair with doesn't abort its simulation", then he agreed
> you could answer No.
>
> But that isn't the Halting Question, so it isn't the correct answer to
> the question that H is supposed to answer.
--
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-08 18:12 +0000 |
| Subject | Re: How Partial Simulations correctly determine non-halting ---Should I quit Richard at this point? |
| Message-ID | <v426up$3de90$1@i2pn2.org> |
| In reply to | #106715 |
Am Sat, 08 Jun 2024 12:10:33 -0500 schrieb olcott: > On 6/8/2024 11:03 AM, Richard Damon wrote: >> On 6/8/24 11:32 AM, olcott wrote: >>> On 6/8/2024 10:15 AM, Richard Damon wrote: >>>> On 6/8/24 11:07 AM, olcott wrote: >>>>> On 6/8/2024 9:54 AM, Richard Damon wrote: >>>>>> On 6/8/24 10:20 AM, olcott wrote: >>>>>>> On 6/8/2024 9:10 AM, Richard Damon wrote: >>>> By your code, the simulator will "Debug Step" those instructions. >>>> >>> The underlying details of one HH are irrelevant when I reference an >>> infinite set:\ What are all the other HH? > *Ben already agreed that the criteria that* > *Professor Sipser agreed to have been met* > > On 10/14/2022 7:44 PM, Ben Bacarisse wrote: > > I don't think that is the shell game. PO really /has/ an H (it's > > trivial to do for this one case) that correctly determines that P(P) > > *would* never stop running *unless* aborted. What do I care what Ben thinks (sorry). And Sipser's "criterion" is not at all disputed. >> Yes, P(P) won't halt if the code of H won't abort it. >> > thus meeting the Sipser approved criteria. > >> But if the code of H does abort it, it will halt. >> > D is accountable for the behavior of its actual input and not freaking > accountable for any damn thing else in the whole freaking universe. > Halt deciders compute the mapping FROM THEIR INPUTS BASED ON THE ACTUAL > BEHAVIOR THAT THIS INPUT SPECIFIES. > This input specifies the behavior of DD correctly simulated by HH. > That everyone wants to avoid looking at my conclusive proof that DD > correctly simulated by HH has provably different behavior than the > direct executed DD(DD) is dishonest. Dishonest is claiming a simulator gets to a different conclusion. >> Thus, if the question actually WAS "Will the template P(P) Halt if the >> decider it is pair with doesn't abort its simulation", then he agreed >> you could answer No. >> But that isn't the Halting Question, so it isn't the correct answer to >> the question that H is supposed to answer. -- joes
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-08 13:36 -0500 |
| Subject | Re: How Partial Simulations correctly determine non-halting ---Should I quit Richard at this point? |
| Message-ID | <v428ak$2no74$1@dont-email.me> |
| In reply to | #106717 |
On 6/8/2024 1:12 PM, joes wrote:
> Am Sat, 08 Jun 2024 12:10:33 -0500 schrieb olcott:
>> On 6/8/2024 11:03 AM, Richard Damon wrote:
>>> On 6/8/24 11:32 AM, olcott wrote:
>>>> On 6/8/2024 10:15 AM, Richard Damon wrote:
>>>>> On 6/8/24 11:07 AM, olcott wrote:
>>>>>> On 6/8/2024 9:54 AM, Richard Damon wrote:
>>>>>>> On 6/8/24 10:20 AM, olcott wrote:
>>>>>>>> On 6/8/2024 9:10 AM, Richard Damon wrote:
>
>>>>> By your code, the simulator will "Debug Step" those instructions.
>>>>>
>>>> The underlying details of one HH are irrelevant when I reference an
>>>> infinite set:\
> What are all the other HH?
>
>> *Ben already agreed that the criteria that*
>> *Professor Sipser agreed to have been met*
>>
>> On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
>> > I don't think that is the shell game. PO really /has/ an H (it's
>> > trivial to do for this one case) that correctly determines that P(P)
>> > *would* never stop running *unless* aborted.
>
> What do I care what Ben thinks (sorry).
> And Sipser's "criterion" is not at all disputed.
>
It is not Sipser's criteria it is MY criteria that I
spent two years carefully composing that professor Sipser
reviewed and approved.
>>> Yes, P(P) won't halt if the code of H won't abort it.
>>>
>> thus meeting the Sipser approved criteria.
>>
>>> But if the code of H does abort it, it will halt.
>>>
>> D is accountable for the behavior of its actual input and not freaking
>> accountable for any damn thing else in the whole freaking universe.
>
>> Halt deciders compute the mapping FROM THEIR INPUTS BASED ON THE ACTUAL
>> BEHAVIOR THAT THIS INPUT SPECIFIES.
>> This input specifies the behavior of DD correctly simulated by HH.
>
>> That everyone wants to avoid looking at my conclusive proof that DD
>> correctly simulated by HH has provably different behavior than the
>> direct executed DD(DD) is dishonest.
>
> Dishonest is claiming a simulator gets to a different conclusion.
>
I conclusively prove otherwise and everyone:
(a) Ignores this proof
(b) Fails to understand this proof
(c) Lies about the results of this proof.
Before we can get to the behavior of the directly executed
DD(DD) we must first see that the Sipser approved criteria
have been met:
<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>
Try to show how this DD correctly simulated by any HH ever
stops running without having its simulation aborted by HH.
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD
[00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD
[00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the
above x86 machine language of DD is correctly simulated
by HH and simulated in the correct order.
The above is the complete proof that DD correctly simulated
by any HH that can possibly exist never stops running without
having its simulation aborted by HH (or crashing for OOM 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 | joes <noreply@example.com> |
|---|---|
| Date | 2024-06-08 19:59 +0000 |
| Subject | Re: How Partial Simulations correctly determine non-halting ---Should I quit Richard at this point? |
| Message-ID | <v42d6k$3de90$2@i2pn2.org> |
| In reply to | #106718 |
Am Sat, 08 Jun 2024 13:36:04 -0500 schrieb olcott: > On 6/8/2024 1:12 PM, joes wrote: >> Am Sat, 08 Jun 2024 12:10:33 -0500 schrieb olcott: >>> On 6/8/2024 11:03 AM, Richard Damon wrote: >>>> On 6/8/24 11:32 AM, olcott wrote: >>>>> On 6/8/2024 10:15 AM, Richard Damon wrote: >>>>>> On 6/8/24 11:07 AM, olcott wrote: >>>>>>> On 6/8/2024 9:54 AM, Richard Damon wrote: >>>>>>>> On 6/8/24 10:20 AM, olcott wrote: >>>>>>>>> On 6/8/2024 9:10 AM, Richard Damon wrote: >> >> What are all the other HH? Still waiting on this. >> And Sipser's "criterion" is not at all disputed. > It is not Sipser's criteria it is MY criteria that I spent two years > carefully composing that professor Sipser reviewed and approved. It shouldn't have taken 2 years. >>> D is accountable for the behavior of its actual input and not freaking >>> accountable for any damn thing else in the whole freaking universe. >>> Halt deciders compute the mapping FROM THEIR INPUTS BASED ON THE >>> ACTUAL BEHAVIOR THAT THIS INPUT SPECIFIES. And not based on whatever else the simulator might wrongly do with it. >>> That everyone wants to avoid looking at my conclusive proof that DD >>> correctly simulated by HH has provably different behavior than the >>> direct executed DD(DD) is dishonest. >> Dishonest is claiming a simulator gets to a different conclusion. A simulator that simulates something different than the real thing is not a simulator. > I conclusively prove otherwise and everyone: > (a) Ignores this proof (b) Fails to understand this proof (c) Lies about > the results of this proof. Even if that part may be right, it is of no use to the halting problem. > Before we can get to the behavior of the directly executed DD(DD) we > must first see that the Sipser approved criteria have been met: I already agreed to it. -- joes
[toc] | [prev] | [next] | [standalone]
Page 11 of 17 — ← Prev page 1 … 9 10 [11] 12 13 … 17 Next page →
Back to top | Article view | comp.theory
csiph-web