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 4 of 17 — ← Prev page 1 2 3 [4] 5 6 … 17 Next page →
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-06 08:37 -0500 |
| Subject | Re: Halting Problem is wrong two different ways --very stupid |
| Message-ID | <v3se34$1gra7$8@dont-email.me> |
| In reply to | #106383 |
On 6/6/2024 3:52 AM, Mikko wrote:
> On 2024-06-06 02:09:35 +0000, olcott said:
>
>> On 6/5/2024 1:33 PM, joes wrote:
>>> Am Wed, 05 Jun 2024 12:09:18 -0500 schrieb olcott:
>>>> On 6/5/2024 12:03 PM, John Smith wrote:
>>>>> On 5/06/24 04:16, olcott wrote:
>>>>>> On 6/4/2024 9:12 PM, John Smith wrote:
>>>>>>> On 5/06/24 04:05, olcott wrote:
>>>>>>>> On 6/4/2024 8:48 PM, Richard Damon wrote:
>>>> (6) Can Carol correctly answer “no” to this question?
>>>> Let's ask Carol. If she says “yes”, she's saying that “no” is the
>>>> correct answer for her, so “yes” is incorrect. If she says “no”, she's
>>>> saying that she cannot correctly answer “no”, which is her answer. We
>>>> are assuming for this and all subsequent questions that the only
>>>> acceptable answers are “yes” and “no”, and in this case, both answers
>>>> are incorrect. Carol cannot answer the question correctly. Now let's
>>>> ask
>>>> Dave. He says “no”, and he is correct because Carol cannot correctly
>>>> answer “no”. So (6) is subjective because it is a consistent,
>>>> satisfiable specification for some agent (anyone other than Carol), and
>>>> an inconsistent, unsatisfiable specification for some agent (Carol).
>>
>>> But that's like running a different machine. That's not interesting.
>>> We wanted to see a machine that can answer ALL questions.
>>
>> To expect a correct answer to an incorrect question has
>> always been very stupid.
>
> To call a question incorrect just because one stupid machine cannot
> correctly answer it is stupid.
>
Whenever and yes/no question has no correct yes/no answer such
as What time is it (yes or no)?
It this sentence true or false "this sentence is not true" ???
Then the question is incorrect.
People that are woefully ignorant of context in linguistics
think that they can get away with simply ignoring how the
context of who is asked change the meaning of a question.
When one anchors their views in ignorance they anchor these
views in error.
Can Carol correctly answer “no” to this (yes/no) question?
...is a consistent, satisfiable specification for some
agent (anyone other than Carol), and an inconsistent,
unsatisfiable specification for some agent (Carol). (Hehner:2017)
If Carol answers “no” to this question she is saying that “no” is the
wrong answer, if she is correct then “no” is the right answer making her
necessarily incorrect.
If Carol answers “yes” to this question she is saying that “no” is the
correct answer thus making “yes” necessarily the wrong answer.
Thus both [yes, no] are the wrong answer from Carol, thus “no” is the
correct answer from anyone else.
Since the question posed to Carol has no correct answer from Carol and
the same word-for-word question does have a correct answer from anyone
else linguistics understands that these are two different questions
because they have different meanings depending on the linguistic context
of who is asked.
A concrete example of how the meaning of the same word-for-word question
has an entirely different answer depending on who is asked: Are you a
little girl?
We can see that Carol's question posed to Carol is self-contradictory
for Carol because the question contradicts both yes/no answers from
Carol.
Upon careful examination we can see that Carol's question posed to Carol
is isomorphic to input D to decider H where D has been defined to do the
opposite of whatever Boolean value that H returns.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-06 22:08 -0400 |
| Subject | Re: Halting Problem is wrong two different ways --very stupid |
| Message-ID | <v3tq2n$388rj$8@i2pn2.org> |
| In reply to | #106397 |
On 6/6/24 9:37 AM, olcott wrote: > On 6/6/2024 3:52 AM, Mikko wrote: >> On 2024-06-06 02:09:35 +0000, olcott said: >> >>> On 6/5/2024 1:33 PM, joes wrote: >>>> Am Wed, 05 Jun 2024 12:09:18 -0500 schrieb olcott: >>>>> On 6/5/2024 12:03 PM, John Smith wrote: >>>>>> On 5/06/24 04:16, olcott wrote: >>>>>>> On 6/4/2024 9:12 PM, John Smith wrote: >>>>>>>> On 5/06/24 04:05, olcott wrote: >>>>>>>>> On 6/4/2024 8:48 PM, Richard Damon wrote: >>>>> (6) Can Carol correctly answer “no” to this question? >>>>> Let's ask Carol. If she says “yes”, she's saying that “no” is the >>>>> correct answer for her, so “yes” is incorrect. If she says “no”, she's >>>>> saying that she cannot correctly answer “no”, which is her answer. We >>>>> are assuming for this and all subsequent questions that the only >>>>> acceptable answers are “yes” and “no”, and in this case, both answers >>>>> are incorrect. Carol cannot answer the question correctly. Now >>>>> let's ask >>>>> Dave. He says “no”, and he is correct because Carol cannot correctly >>>>> answer “no”. So (6) is subjective because it is a consistent, >>>>> satisfiable specification for some agent (anyone other than Carol), >>>>> and >>>>> an inconsistent, unsatisfiable specification for some agent (Carol). >>> >>>> But that's like running a different machine. That's not interesting. >>>> We wanted to see a machine that can answer ALL questions. >>> >>> To expect a correct answer to an incorrect question has >>> always been very stupid. >> >> To call a question incorrect just because one stupid machine cannot >> correctly answer it is stupid. >> > > Whenever and yes/no question has no correct yes/no answer such > as What time is it (yes or no)? > It this sentence true or false "this sentence is not true" ??? > Then the question is incorrect. But the actual question of the Halting Problem always has a correct yes or not answer. Your problem is you forget that to ask it, you first need to define what H does, and thus H's answer has been fixed, so the other answer can be correct. You apparently just don't understand the basics of the theory you have been claiming to be an expert in. > > People that are woefully ignorant of context in linguistics > think that they can get away with simply ignoring how the > context of who is asked change the meaning of a question. > When one anchors their views in ignorance they anchor these > views in error. > > Can Carol correctly answer “no” to this (yes/no) question? > > ...is a consistent, satisfiable specification for some > agent (anyone other than Carol), and an inconsistent, > unsatisfiable specification for some agent (Carol). (Hehner:2017) > > If Carol answers “no” to this question she is saying that “no” is the > wrong answer, if she is correct then “no” is the right answer making her > necessarily incorrect. > > If Carol answers “yes” to this question she is saying that “no” is the > correct answer thus making “yes” necessarily the wrong answer. > > Thus both [yes, no] are the wrong answer from Carol, thus “no” is the > correct answer from anyone else. > > Since the question posed to Carol has no correct answer from Carol and > the same word-for-word question does have a correct answer from anyone > else linguistics understands that these are two different questions > because they have different meanings depending on the linguistic context > of who is asked. > > A concrete example of how the meaning of the same word-for-word question > has an entirely different answer depending on who is asked: Are you a > little girl? > > We can see that Carol's question posed to Carol is self-contradictory > for Carol because the question contradicts both yes/no answers from > Carol. > > Upon careful examination we can see that Carol's question posed to Carol > is isomorphic to input D to decider H where D has been defined to do the > opposite of whatever Boolean value that H returns. > >
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-05 19:42 -0400 |
| Subject | Re: Halting Problem is wrong two different ways |
| Message-ID | <v3qt56$354i9$2@i2pn2.org> |
| In reply to | #106326 |
On 6/5/24 1:09 PM, olcott wrote: > *Disagreeing with verified facts does not count as any rebuttal* And thus, you haven't rebutted ANYTHING important for years. Just repeated your false claims over and over as your LIES that are based on misleading definitions and fautly logic. That you can't see that might be your saving grace, as God my consider you just a mental incompetent. But, since you previously claimed yourself to be God, that option might not really be open.
[toc] | [prev] | [next] | [standalone]
| From | Mikko <mikko.levanto@iki.fi> |
|---|---|
| Date | 2024-06-06 11:45 +0300 |
| Subject | Re: Halting Problem is wrong two different ways |
| Message-ID | <v3rsv1$1ed2j$1@dont-email.me> |
| In reply to | #106326 |
On 2024-06-05 17:09:18 +0000, olcott said: > On 6/5/2024 12:03 PM, John Smith wrote: >> On 5/06/24 04:16, olcott wrote: >>> On 6/4/2024 9:12 PM, John Smith wrote: >>>> On 5/06/24 04:05, olcott wrote: >>>>> On 6/4/2024 8:48 PM, Richard Damon wrote: >>>>>> But the question it asks is an OBJECTIVE question that doesn't depend >>>>>> on who it is asked of. >>>>>> >>>>> >>>>> When H is asked about the behavior of a Machine that is programmed >>>>> to do the opposite of whatever it says then the context that it is H >>>>> that is being asked is an inherent aspect of the meaning of this >>>>> question and cannot be correctly ignored. >>>> >>>> Every machine does something. It either halts, or it doesn't. If a >>>> machine halts, then it halts even if you ask someone different. If the >>>> machine halts when I ask Bob whether it halts and he says it halts, >>>> then it still halts when I ask Alice whether it halts and she says it >>>> doesn't halt. Alice is wrong. The linguistic context doesn't change the >>>> fact that it halts. >>> >>> Professor Hehner proves my same point with Carol's question. >>> https://www.cs.toronto.edu/~hehner/OSS.pdf >>> >>> Richard found a loophole that I fixed and told professor Hehner about: >>> Can Carol correctly answer “no” to this (yes/no) question? >>> >> >> It's not "Can Carol" - it's "Does Carol" > > *Disagreeing with verified facts does not count as any rebuttal* > I inserted "(yes/no)" to close the loophole that Richard found. That addition does not constrain what Carol can say. Whether that makes "Absolutely not" an incorrect answer is another problem. -- Mikko
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-06 08:23 -0500 |
| Subject | Re: Halting Problem is wrong two different ways |
| Message-ID | <v3sd8n$1gra7$6@dont-email.me> |
| In reply to | #106382 |
On 6/6/2024 3:45 AM, Mikko wrote:
> On 2024-06-05 17:09:18 +0000, olcott said:
>
>> On 6/5/2024 12:03 PM, John Smith wrote:
>>> On 5/06/24 04:16, olcott wrote:
>>>> On 6/4/2024 9:12 PM, John Smith wrote:
>>>>> On 5/06/24 04:05, olcott wrote:
>>>>>> On 6/4/2024 8:48 PM, Richard Damon wrote:
>>>>>>> But the question it asks is an OBJECTIVE question that doesn't
>>>>>>> depend on who it is asked of.
>>>>>>>
>>>>>>
>>>>>> When H is asked about the behavior of a Machine that is programmed
>>>>>> to do the opposite of whatever it says then the context that it is H
>>>>>> that is being asked is an inherent aspect of the meaning of this
>>>>>> question and cannot be correctly ignored.
>>>>>
>>>>> Every machine does something. It either halts, or it doesn't. If a
>>>>> machine halts, then it halts even if you ask someone different. If
>>>>> the machine halts when I ask Bob whether it halts and he says it
>>>>> halts, then it still halts when I ask Alice whether it halts and
>>>>> she says it doesn't halt. Alice is wrong. The linguistic context
>>>>> doesn't change the fact that it halts.
>>>>
>>>> Professor Hehner proves my same point with Carol's question.
>>>> https://www.cs.toronto.edu/~hehner/OSS.pdf
>>>>
>>>> Richard found a loophole that I fixed and told professor Hehner about:
>>>> Can Carol correctly answer “no” to this (yes/no) question?
>>>>
>>>
>>> It's not "Can Carol" - it's "Does Carol"
>>
>> *Disagreeing with verified facts does not count as any rebuttal*
>> I inserted "(yes/no)" to close the loophole that Richard found.
>
> That addition does not constrain what Carol can say. Whether that
> makes "Absolutely not" an incorrect answer is another problem.
>
Can Carol correctly answer “no” to this [yes/no] question?
...is a consistent, satisfiable specification for some
agent (anyone other than Carol), and an inconsistent,
unsatisfiable specification for some agent (Carol). (Hehner:2017)
If Carol answers “no” to this question she is saying that “no” is the
wrong answer, if she is correct then “no” is the right answer making her
necessarily incorrect.
If Carol answers “yes” to this question she is saying that “no” is the
correct answer thus making “yes” necessarily the wrong answer.
Thus both [yes, no] are the wrong answer from Carol, thus “no” is the
correct answer from anyone else.
When anyone or machine is asked a yes/no question and this
yes/no question has no correct answer from this person or
machine because both yes and no are contradicted then this
is an incorrect question. I first brought this up in this
forum back in 2004.
Alan Turing's Halting Problem is incorrectly formed (PART-TWO) sci.logic
On 6/20/2004 11:31 AM, Peter Olcott wrote:
> PREMISES:
> (1) The Halting Problem was specified in such a way that a solution
> was defined to be impossible.
>
> (2) The set of questions that are defined to not have any possible
> correct answer(s) forms a proper subset of all possible questions.
> …
> CONCLUSION:
> Therefore the Halting Problem is an ill-formed question.
>
USENET Message-ID:
<kZiBc.103407$Gx4.18142@bgtnsc04-news.ops.worldnet.att.net>
*Direct Link to original message*
http://al.howardknight.net/?STYPE=msgid&MSGI=%3CkZiBc.103407%24Gx4.18142%40bgtnsc04-news.ops.worldnet.att.net%3E+
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-06 22:08 -0400 |
| Subject | Re: Halting Problem is wrong two different ways |
| Message-ID | <v3tq2p$388rj$9@i2pn2.org> |
| In reply to | #106395 |
On 6/6/24 9:23 AM, olcott wrote: > On 6/6/2024 3:45 AM, Mikko wrote: >> On 2024-06-05 17:09:18 +0000, olcott said: >> >>> On 6/5/2024 12:03 PM, John Smith wrote: >>>> On 5/06/24 04:16, olcott wrote: >>>>> On 6/4/2024 9:12 PM, John Smith wrote: >>>>>> On 5/06/24 04:05, olcott wrote: >>>>>>> On 6/4/2024 8:48 PM, Richard Damon wrote: >>>>>>>> But the question it asks is an OBJECTIVE question that doesn't >>>>>>>> depend on who it is asked of. >>>>>>>> >>>>>>> >>>>>>> When H is asked about the behavior of a Machine that is programmed >>>>>>> to do the opposite of whatever it says then the context that it is H >>>>>>> that is being asked is an inherent aspect of the meaning of this >>>>>>> question and cannot be correctly ignored. >>>>>> >>>>>> Every machine does something. It either halts, or it doesn't. If a >>>>>> machine halts, then it halts even if you ask someone different. If >>>>>> the machine halts when I ask Bob whether it halts and he says it >>>>>> halts, then it still halts when I ask Alice whether it halts and >>>>>> she says it doesn't halt. Alice is wrong. The linguistic context >>>>>> doesn't change the fact that it halts. >>>>> >>>>> Professor Hehner proves my same point with Carol's question. >>>>> https://www.cs.toronto.edu/~hehner/OSS.pdf >>>>> >>>>> Richard found a loophole that I fixed and told professor Hehner about: >>>>> Can Carol correctly answer “no” to this (yes/no) question? >>>>> >>>> >>>> It's not "Can Carol" - it's "Does Carol" >>> >>> *Disagreeing with verified facts does not count as any rebuttal* >>> I inserted "(yes/no)" to close the loophole that Richard found. >> >> That addition does not constrain what Carol can say. Whether that >> makes "Absolutely not" an incorrect answer is another problem. >> > > Can Carol correctly answer “no” to this [yes/no] question? > > ...is a consistent, satisfiable specification for some > agent (anyone other than Carol), and an inconsistent, > unsatisfiable specification for some agent (Carol). (Hehner:2017) > > If Carol answers “no” to this question she is saying that “no” is the > wrong answer, if she is correct then “no” is the right answer making her > necessarily incorrect. > > If Carol answers “yes” to this question she is saying that “no” is the > correct answer thus making “yes” necessarily the wrong answer. > > Thus both [yes, no] are the wrong answer from Carol, thus “no” is the > correct answer from anyone else. > > When anyone or machine is asked a yes/no question and this > yes/no question has no correct answer from this person or > machine because both yes and no are contradicted then this > is an incorrect question. I first brought this up in this > forum back in 2004. > Except you forget that the Halting Question DOES have a correct answer, since it is only asked about a SPECIFIC machine, and that machine will either Halt or not. The key point is that H^ is constructed using a copy of H, to make what ever answer H will give to be wrong. And it can do that, as it is property of this class of programs that they always give the same answer to the same input, and H is forced to answer to be a decider. > Alan Turing's Halting Problem is incorrectly formed (PART-TWO) sci.logic > On 6/20/2004 11:31 AM, Peter Olcott wrote: > > PREMISES: > > (1) The Halting Problem was specified in such a way that a solution > > was defined to be impossible. > > > > (2) The set of questions that are defined to not have any possible > > correct answer(s) forms a proper subset of all possible questions. > > … > > CONCLUSION: > > Therefore the Halting Problem is an ill-formed question. > > > USENET Message-ID: > <kZiBc.103407$Gx4.18142@bgtnsc04-news.ops.worldnet.att.net> > > *Direct Link to original message* > http://al.howardknight.net/?STYPE=msgid&MSGI=%3CkZiBc.103407%24Gx4.18142%40bgtnsc04-news.ops.worldnet.att.net%3E+ > > >
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-04 22:22 -0400 |
| Subject | Re: Halting Problem is wrong two different ways |
| Message-ID | <v3oi5p$328ec$11@i2pn2.org> |
| In reply to | #106276 |
On 6/4/24 10:05 PM, olcott wrote:
> On 6/4/2024 8:48 PM, Richard Damon wrote:
>> On 6/4/24 1:40 PM, olcott wrote:
>>> On 6/4/2024 3:28 AM, Mikko wrote:
>>>> On 2024-06-03 18:14:39 +0000, olcott said:
>>>>
>>>>> On 6/3/2024 9:27 AM, Mikko wrote:
>>>>>> On 2024-06-03 12:20:01 +0000, olcott said:
>>>>>>
>>>>>>> On 6/3/2024 4:42 AM, Ben Bacarisse wrote:
>>>>>>>> Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
>>>>>>>>
>>>>>>>>> PO's D(D) halts, as illustrated in various traces that have
>>>>>>>>> been posted here.
>>>>>>>>> PO's H(D,D) returns 0 : [NOT halting] also as illustrated in
>>>>>>>>> various traces.
>>>>>>>>> i.e. exactly as the Linz proof claims. PO has acknowledged
>>>>>>>>> both these
>>>>>>>>> results. Same for the HH/DD variants.
>>>>>>>>>
>>>>>>>>> You might imagine that's the end of the matter - PO failed. :)
>>>>>>>>>
>>>>>>>>> That's right, but PO just carries on anyway!
>>>>>>>>
>>>>>>>> He has quite explicitly stated that false (0) is the correct
>>>>>>>> result for
>>>>>>>> H(D,D) "even though D(D) halts". I am mystified why anyone
>>>>>>>> continues to
>>>>>>>> discuss the matter until he equally explicitly repudiates that
>>>>>>>> claim.
>>>>>>>>
>>>>>>>
>>>>>>> Deciders only compute the mapping *from their inputs* to their own
>>>>>>> accept or reject state.
>>>>>>
>>>>>> That does not restrict what a problem statement can specify.
>>>>>> If the computed mapping differs from the specified one the
>>>>>> decider does not solve the problem.
>>>>>
>>>>> int sum(int x, int y) { return x + y; }
>>>>> sum(2,3) cannot return the sum of 5 + 6.
>>>>
>>>> That does not restrict what a problem statement can specify.
>>>> If the mapping computed by sum differs from the specified one
>>>> the program sum does not solve the problem.
>>>>
>>>
>>> On 6/3/2024 9:53 PM, Richard Damon wrote:
>>> > Because you keep on mentioning about DD Halting,
>>> > which IS about the direct execution of DD
>>>
>>> Only when one contradicts the definition of a decider that must
>>> compute the mapping FROM ITS INPUTS BASED ON THE ACTUAL BEHAVIOR
>>> OF THESE INPUTS (as measured by DD correctly simulated by HH).
>>
>> But strings don't HAVE "Behavior", they only represent things that do.
>>
>
> Turing Machine descriptions specify behavior to UTMs.
Right, because that description represents the Turing Machine whose
behavior the UTM will recreate.
Remember, the DEFINITION of a UTM is that it exactly reproduces the
results of the machine that the description describes.
So, by that logic, your HH needs to answer about the behavior that a UTM
would bget when it simulates that input, which will still be paired to
the HH that it was paired with (and not changed to be the UTM).
That WILL be exactly the behavior of the direct execution of the input,
the thing you try to claim it can not be, but it is shown that you are
just a liar.
>
>> And, for a Halt decider, that thing they represent is the program,
>> whose direct execution specifies the proper behavior of the input.
>>
>> The DEFINITON IS NOT "as measured by DD correctly simulated by HH",
>> as deciders, by their definiton, are trying to compute the mapping of
>> their input according to a defined function, which is a function of
>> just that input. Since that function doesn't know which "H' is going
>> to try to decide on it, it can't change its answer based on which H we
>> ask.
>>
>> Proper Deciders can not be asked "Subjective" questions, unless we
>> SPECIFICALLY define the mapping to include the decider as one of the
>> inputs, and at that point, the question actually ceases to be
>> subjective, as it becomes, what should THAT H say about this input,
>> which is back to an objective agian (since machines are deterministic,
>> so the definition of H tells us what H will answer to that question).
>>
>>>
>>> When we go ahead and contradict this definition then the
>>> *HALTING PROBLEM IS STILL WRONG IN A DIFFERENT WAY*
>>
>> Nope, YOU are wrong, because you
>>
>>>
>>> When D is defined to do the opposite of whatever yes/no
>>> an answer that H provides then the counter-example input
>>> is precisely isomorphic to the question:
>>> Is this sentence: "This sentence is not true." true or false?
>>> Thus that question and the HP question are both incorrect
>>> because both yes and no are the wrong answer.
>>
>> Nope, Just shows how small your mind is.
>>
>> Proven elsewhere.,
>>
>>>
>>> The theory of computation may be ignorant of the details of
>>> how the context of who is asked a question changes the meaning
>>> of this question, none-the-less this cannot be ignored.
>>> It is and remains incorrect for the theory of computation
>>> to ignore this.
>>>
>>
>> But the question it asks is an OBJECTIVE question that doesn't depend
>> on who it is asked of.
>>
>
> When H is asked about the behavior of a Machine that is programmed
> to do the opposite of whatever it says then the context that it is H
> that is being asked is an inherent aspect of the meaning of this
> question and cannot be correctly ignored.
>
> The theory of computation people are ignorant of how linguistic
> context change the meaning of expressions REALLY IS NO EXCUSE.
>
>> It is your own fault for trying to rephrase it incorrectly into a
>> subjective version.
>>
>> Thus, you statment is just a deceitful lie.
>
> You may have to go to Hell for calling me a liar when you know
> that I believe what I say because this makes you a liar. I say
> this for your own safety.
>
[toc] | [prev] | [next] | [standalone]
| From | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2024-06-05 10:11 +0200 |
| Subject | Re: Halting Problem is wrong two different ways |
| Message-ID | <v3p6jq$sg73$3@dont-email.me> |
| In reply to | #106276 |
Op 05.jun.2024 om 04:05 schreef olcott:
> On 6/4/2024 8:48 PM, Richard Damon wrote:
>> On 6/4/24 1:40 PM, olcott wrote:
>>> On 6/4/2024 3:28 AM, Mikko wrote:
>>>> On 2024-06-03 18:14:39 +0000, olcott said:
>>>>
>>>>> On 6/3/2024 9:27 AM, Mikko wrote:
>>>>>> On 2024-06-03 12:20:01 +0000, olcott said:
>>>>>>
>>>>>>> On 6/3/2024 4:42 AM, Ben Bacarisse wrote:
>>>>>>>> Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
>>>>>>>>
>>>>>>>>> PO's D(D) halts, as illustrated in various traces that have
>>>>>>>>> been posted here.
>>>>>>>>> PO's H(D,D) returns 0 : [NOT halting] also as illustrated in
>>>>>>>>> various traces.
>>>>>>>>> i.e. exactly as the Linz proof claims. PO has acknowledged
>>>>>>>>> both these
>>>>>>>>> results. Same for the HH/DD variants.
>>>>>>>>>
>>>>>>>>> You might imagine that's the end of the matter - PO failed. :)
>>>>>>>>>
>>>>>>>>> That's right, but PO just carries on anyway!
>>>>>>>>
>>>>>>>> He has quite explicitly stated that false (0) is the correct
>>>>>>>> result for
>>>>>>>> H(D,D) "even though D(D) halts". I am mystified why anyone
>>>>>>>> continues to
>>>>>>>> discuss the matter until he equally explicitly repudiates that
>>>>>>>> claim.
>>>>>>>>
>>>>>>>
>>>>>>> Deciders only compute the mapping *from their inputs* to their own
>>>>>>> accept or reject state.
>>>>>>
>>>>>> That does not restrict what a problem statement can specify.
>>>>>> If the computed mapping differs from the specified one the
>>>>>> decider does not solve the problem.
>>>>>
>>>>> int sum(int x, int y) { return x + y; }
>>>>> sum(2,3) cannot return the sum of 5 + 6.
>>>>
>>>> That does not restrict what a problem statement can specify.
>>>> If the mapping computed by sum differs from the specified one
>>>> the program sum does not solve the problem.
>>>>
>>>
>>> On 6/3/2024 9:53 PM, Richard Damon wrote:
>>> > Because you keep on mentioning about DD Halting,
>>> > which IS about the direct execution of DD
>>>
>>> Only when one contradicts the definition of a decider that must
>>> compute the mapping FROM ITS INPUTS BASED ON THE ACTUAL BEHAVIOR
>>> OF THESE INPUTS (as measured by DD correctly simulated by HH).
>>
>> But strings don't HAVE "Behavior", they only represent things that do.
>>
>
> Turing Machine descriptions specify behavior to UTMs.
>
>> And, for a Halt decider, that thing they represent is the program,
>> whose direct execution specifies the proper behavior of the input.
>>
>> The DEFINITON IS NOT "as measured by DD correctly simulated by HH",
>> as deciders, by their definiton, are trying to compute the mapping of
>> their input according to a defined function, which is a function of
>> just that input. Since that function doesn't know which "H' is going
>> to try to decide on it, it can't change its answer based on which H we
>> ask.
>>
>> Proper Deciders can not be asked "Subjective" questions, unless we
>> SPECIFICALLY define the mapping to include the decider as one of the
>> inputs, and at that point, the question actually ceases to be
>> subjective, as it becomes, what should THAT H say about this input,
>> which is back to an objective agian (since machines are deterministic,
>> so the definition of H tells us what H will answer to that question).
>>
>>>
>>> When we go ahead and contradict this definition then the
>>> *HALTING PROBLEM IS STILL WRONG IN A DIFFERENT WAY*
>>
>> Nope, YOU are wrong, because you
>>
>>>
>>> When D is defined to do the opposite of whatever yes/no
>>> an answer that H provides then the counter-example input
>>> is precisely isomorphic to the question:
>>> Is this sentence: "This sentence is not true." true or false?
>>> Thus that question and the HP question are both incorrect
>>> because both yes and no are the wrong answer.
>>
>> Nope, Just shows how small your mind is.
>>
>> Proven elsewhere.,
>>
>>>
>>> The theory of computation may be ignorant of the details of
>>> how the context of who is asked a question changes the meaning
>>> of this question, none-the-less this cannot be ignored.
>>> It is and remains incorrect for the theory of computation
>>> to ignore this.
>>>
>>
>> But the question it asks is an OBJECTIVE question that doesn't depend
>> on who it is asked of.
>>
>
> When H is asked about the behavior of a Machine that is programmed
> to do the opposite of whatever it says then the context that it is H
> that is being asked is an inherent aspect of the meaning of this
> question and cannot be correctly ignored.
But that has nothing to do with your simulation result. Your simulation
does not even reach the part that contradict its result.
Your decider even diagnoses programs as non-halting when they do not
contradict the result of the decider, as in:
typedef int (*ptr)(); // ptr is pointer to int function in C
int H(ptr p, ptr i);
int main()
{
H(main, 0);
}
It is clear that main does not programmed to do the opposite of what H
says.
This illustrates that a simulating halt-decider is a bad idea, because
the decider itself does not halt when simulated by itself and therefore
its results are often false negatives.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-05 08:59 -0500 |
| Subject | Re: Halting Problem is wrong two different ways |
| Message-ID | <v3pr0p$1003g$3@dont-email.me> |
| In reply to | #106299 |
On 6/5/2024 3:11 AM, Fred. Zwarts wrote:
> Op 05.jun.2024 om 04:05 schreef olcott:
>> On 6/4/2024 8:48 PM, Richard Damon wrote:
>>> On 6/4/24 1:40 PM, olcott wrote:
>>>> On 6/4/2024 3:28 AM, Mikko wrote:
>>>>> On 2024-06-03 18:14:39 +0000, olcott said:
>>>>>
>>>>>> On 6/3/2024 9:27 AM, Mikko wrote:
>>>>>>> On 2024-06-03 12:20:01 +0000, olcott said:
>>>>>>>
>>>>>>>> On 6/3/2024 4:42 AM, Ben Bacarisse wrote:
>>>>>>>>> Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
>>>>>>>>>
>>>>>>>>>> PO's D(D) halts, as illustrated in various traces that have
>>>>>>>>>> been posted here.
>>>>>>>>>> PO's H(D,D) returns 0 : [NOT halting] also as illustrated in
>>>>>>>>>> various traces.
>>>>>>>>>> i.e. exactly as the Linz proof claims. PO has acknowledged
>>>>>>>>>> both these
>>>>>>>>>> results. Same for the HH/DD variants.
>>>>>>>>>>
>>>>>>>>>> You might imagine that's the end of the matter - PO failed. :)
>>>>>>>>>>
>>>>>>>>>> That's right, but PO just carries on anyway!
>>>>>>>>>
>>>>>>>>> He has quite explicitly stated that false (0) is the correct
>>>>>>>>> result for
>>>>>>>>> H(D,D) "even though D(D) halts". I am mystified why anyone
>>>>>>>>> continues to
>>>>>>>>> discuss the matter until he equally explicitly repudiates that
>>>>>>>>> claim.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Deciders only compute the mapping *from their inputs* to their own
>>>>>>>> accept or reject state.
>>>>>>>
>>>>>>> That does not restrict what a problem statement can specify.
>>>>>>> If the computed mapping differs from the specified one the
>>>>>>> decider does not solve the problem.
>>>>>>
>>>>>> int sum(int x, int y) { return x + y; }
>>>>>> sum(2,3) cannot return the sum of 5 + 6.
>>>>>
>>>>> That does not restrict what a problem statement can specify.
>>>>> If the mapping computed by sum differs from the specified one
>>>>> the program sum does not solve the problem.
>>>>>
>>>>
>>>> On 6/3/2024 9:53 PM, Richard Damon wrote:
>>>> > Because you keep on mentioning about DD Halting,
>>>> > which IS about the direct execution of DD
>>>>
>>>> Only when one contradicts the definition of a decider that must
>>>> compute the mapping FROM ITS INPUTS BASED ON THE ACTUAL BEHAVIOR
>>>> OF THESE INPUTS (as measured by DD correctly simulated by HH).
>>>
>>> But strings don't HAVE "Behavior", they only represent things that do.
>>>
>>
>> Turing Machine descriptions specify behavior to UTMs.
>>
>>> And, for a Halt decider, that thing they represent is the program,
>>> whose direct execution specifies the proper behavior of the input.
>>>
>>> The DEFINITON IS NOT "as measured by DD correctly simulated by HH",
>>> as deciders, by their definiton, are trying to compute the mapping of
>>> their input according to a defined function, which is a function of
>>> just that input. Since that function doesn't know which "H' is going
>>> to try to decide on it, it can't change its answer based on which H
>>> we ask.
>>>
>>> Proper Deciders can not be asked "Subjective" questions, unless we
>>> SPECIFICALLY define the mapping to include the decider as one of the
>>> inputs, and at that point, the question actually ceases to be
>>> subjective, as it becomes, what should THAT H say about this input,
>>> which is back to an objective agian (since machines are
>>> deterministic, so the definition of H tells us what H will answer to
>>> that question).
>>>
>>>>
>>>> When we go ahead and contradict this definition then the
>>>> *HALTING PROBLEM IS STILL WRONG IN A DIFFERENT WAY*
>>>
>>> Nope, YOU are wrong, because you
>>>
>>>>
>>>> When D is defined to do the opposite of whatever yes/no
>>>> an answer that H provides then the counter-example input
>>>> is precisely isomorphic to the question:
>>>> Is this sentence: "This sentence is not true." true or false?
>>>> Thus that question and the HP question are both incorrect
>>>> because both yes and no are the wrong answer.
>>>
>>> Nope, Just shows how small your mind is.
>>>
>>> Proven elsewhere.,
>>>
>>>>
>>>> The theory of computation may be ignorant of the details of
>>>> how the context of who is asked a question changes the meaning
>>>> of this question, none-the-less this cannot be ignored.
>>>> It is and remains incorrect for the theory of computation
>>>> to ignore this.
>>>>
>>>
>>> But the question it asks is an OBJECTIVE question that doesn't depend
>>> on who it is asked of.
>>>
>>
>> When H is asked about the behavior of a Machine that is programmed
>> to do the opposite of whatever it says then the context that it is H
>> that is being asked is an inherent aspect of the meaning of this
>> question and cannot be correctly ignored.
>
> But that has nothing to do with your simulation result.
Notice the subject line of this thread.
That HH is being asked an incorrect question is the second
way that the Halting Problem is wrong.
> Your simulation
> does not even reach the part that contradict its result.
> Your decider even diagnoses programs as non-halting when they do not
> contradict the result of the decider, as in:
>
> typedef int (*ptr)(); // ptr is pointer to int function in C
>
> int H(ptr p, ptr i);
>
> int main()
> {
> H(main, 0);
> }
>
> It is clear that main does not programmed to do the opposite of what H
> says.
>
*I was surprised that this worked correctly: here are the details*
int main()
{
Output("Input_Halts = ", HH(main,(ptr)0));
}
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[00001e42][00103375][00000000] 55 push ebp ; begin main
[00001e43][00103375][00000000] 8bec mov ebp,esp
[00001e45][00103371][00000000] 6a00 push +00
[00001e47][0010336d][00001e42] 68421e0000 push 00001e42 ; push main
[00001e4c][00103369][00001e51] e831f5ffff call 00001382 ; call HH
New slave_stack at:103419
Begin Local Halt Decider Simulation Execution Trace Stored at:113421
[00001e42][0011340d][00113411] 55 push ebp ; begin main
[00001e43][0011340d][00113411] 8bec mov ebp,esp
[00001e45][00113409][00000000] 6a00 push +00
[00001e47][00113405][00001e42] 68421e0000 push 00001e42 ; push main
[00001e4c][00113401][00001e51] e831f5ffff call 00001382 ; call HH
New slave_stack at:14de41
[00001e42][0015de35][0015de39] 55 push ebp ; begin main
[00001e43][0015de35][0015de39] 8bec mov ebp,esp
[00001e45][0015de31][00000000] 6a00 push +00
[00001e47][0015de2d][00001e42] 68421e0000 push 00001e42 ; push main
[00001e4c][0015de29][00001e51] e831f5ffff call 00001382 ; call HH
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
[00001e51][00103375][00000000] 83c408 add esp,+08
[00001e54][00103371][00000000] 50 push eax
[00001e55][0010336d][00000743] 6843070000 push 00000743
[00001e5a][0010336d][00000743] e843e9ffff call 000007a2
Input_Halts = 0
[00001e5f][00103375][00000000] 83c408 add esp,+08
[00001e62][00103375][00000000] eb79 jmp 00001edd
[00001edd][00103375][00000000] 33c0 xor eax,eax
[00001edf][00103379][00000018] 5d pop ebp
[00001ee0][0010337d][00000000] c3 ret ; end main
Number of Instructions Executed(12311) == 184 Pages
So main() does halt at its final state at [00001ee0] which proves
that the directly executed HH(main,(ptr)0) called by main() halts
and returns 0;
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2024-06-05 20:51 +0200 |
| Subject | Re: Halting Problem is wrong two different ways |
| Message-ID | <v3qc3c$1305p$1@dont-email.me> |
| In reply to | #106317 |
Op 05.jun.2024 om 15:59 schreef olcott:
> On 6/5/2024 3:11 AM, Fred. Zwarts wrote:
>> Op 05.jun.2024 om 04:05 schreef olcott:
>>> On 6/4/2024 8:48 PM, Richard Damon wrote:
>>>> On 6/4/24 1:40 PM, olcott wrote:
>>>>> On 6/4/2024 3:28 AM, Mikko wrote:
>>>>>> On 2024-06-03 18:14:39 +0000, olcott said:
>>>>>>
>>>>>>> On 6/3/2024 9:27 AM, Mikko wrote:
>>>>>>>> On 2024-06-03 12:20:01 +0000, olcott said:
>>>>>>>>
>>>>>>>>> On 6/3/2024 4:42 AM, Ben Bacarisse wrote:
>>>>>>>>>> Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
>>>>>>>>>>
>>>>>>>>>>> PO's D(D) halts, as illustrated in various traces that have
>>>>>>>>>>> been posted here.
>>>>>>>>>>> PO's H(D,D) returns 0 : [NOT halting] also as illustrated in
>>>>>>>>>>> various traces.
>>>>>>>>>>> i.e. exactly as the Linz proof claims. PO has acknowledged
>>>>>>>>>>> both these
>>>>>>>>>>> results. Same for the HH/DD variants.
>>>>>>>>>>>
>>>>>>>>>>> You might imagine that's the end of the matter - PO failed. :)
>>>>>>>>>>>
>>>>>>>>>>> That's right, but PO just carries on anyway!
>>>>>>>>>>
>>>>>>>>>> He has quite explicitly stated that false (0) is the correct
>>>>>>>>>> result for
>>>>>>>>>> H(D,D) "even though D(D) halts". I am mystified why anyone
>>>>>>>>>> continues to
>>>>>>>>>> discuss the matter until he equally explicitly repudiates that
>>>>>>>>>> claim.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Deciders only compute the mapping *from their inputs* to their own
>>>>>>>>> accept or reject state.
>>>>>>>>
>>>>>>>> That does not restrict what a problem statement can specify.
>>>>>>>> If the computed mapping differs from the specified one the
>>>>>>>> decider does not solve the problem.
>>>>>>>
>>>>>>> int sum(int x, int y) { return x + y; }
>>>>>>> sum(2,3) cannot return the sum of 5 + 6.
>>>>>>
>>>>>> That does not restrict what a problem statement can specify.
>>>>>> If the mapping computed by sum differs from the specified one
>>>>>> the program sum does not solve the problem.
>>>>>>
>>>>>
>>>>> On 6/3/2024 9:53 PM, Richard Damon wrote:
>>>>> > Because you keep on mentioning about DD Halting,
>>>>> > which IS about the direct execution of DD
>>>>>
>>>>> Only when one contradicts the definition of a decider that must
>>>>> compute the mapping FROM ITS INPUTS BASED ON THE ACTUAL BEHAVIOR
>>>>> OF THESE INPUTS (as measured by DD correctly simulated by HH).
>>>>
>>>> But strings don't HAVE "Behavior", they only represent things that do.
>>>>
>>>
>>> Turing Machine descriptions specify behavior to UTMs.
>>>
>>>> And, for a Halt decider, that thing they represent is the program,
>>>> whose direct execution specifies the proper behavior of the input.
>>>>
>>>> The DEFINITON IS NOT "as measured by DD correctly simulated by HH",
>>>> as deciders, by their definiton, are trying to compute the mapping
>>>> of their input according to a defined function, which is a function
>>>> of just that input. Since that function doesn't know which "H' is
>>>> going to try to decide on it, it can't change its answer based on
>>>> which H we ask.
>>>>
>>>> Proper Deciders can not be asked "Subjective" questions, unless we
>>>> SPECIFICALLY define the mapping to include the decider as one of the
>>>> inputs, and at that point, the question actually ceases to be
>>>> subjective, as it becomes, what should THAT H say about this input,
>>>> which is back to an objective agian (since machines are
>>>> deterministic, so the definition of H tells us what H will answer to
>>>> that question).
>>>>
>>>>>
>>>>> When we go ahead and contradict this definition then the
>>>>> *HALTING PROBLEM IS STILL WRONG IN A DIFFERENT WAY*
>>>>
>>>> Nope, YOU are wrong, because you
>>>>
>>>>>
>>>>> When D is defined to do the opposite of whatever yes/no
>>>>> an answer that H provides then the counter-example input
>>>>> is precisely isomorphic to the question:
>>>>> Is this sentence: "This sentence is not true." true or false?
>>>>> Thus that question and the HP question are both incorrect
>>>>> because both yes and no are the wrong answer.
>>>>
>>>> Nope, Just shows how small your mind is.
>>>>
>>>> Proven elsewhere.,
>>>>
>>>>>
>>>>> The theory of computation may be ignorant of the details of
>>>>> how the context of who is asked a question changes the meaning
>>>>> of this question, none-the-less this cannot be ignored.
>>>>> It is and remains incorrect for the theory of computation
>>>>> to ignore this.
>>>>>
>>>>
>>>> But the question it asks is an OBJECTIVE question that doesn't
>>>> depend on who it is asked of.
>>>>
>>>
>>> When H is asked about the behavior of a Machine that is programmed
>>> to do the opposite of whatever it says then the context that it is H
>>> that is being asked is an inherent aspect of the meaning of this
>>> question and cannot be correctly ignored.
>>
>> But that has nothing to do with your simulation result.
>
> Notice the subject line of this thread.
> That HH is being asked an incorrect question is the second
> way that the Halting Problem is wrong.
>
>> Your simulation does not even reach the part that contradict its result.
>> Your decider even diagnoses programs as non-halting when they do not
>> contradict the result of the decider, as in:
>>
>> typedef int (*ptr)(); // ptr is pointer to int function in C
>>
>> int H(ptr p, ptr i);
>>
>> int main()
>> {
>> H(main, 0);
>> }
>>
>> It is clear that main does not programmed to do the opposite of what H
>> says.
>>
>
> *I was surprised that this worked correctly: here are the details*
>
> int main()
> {
> Output("Input_Halts = ", HH(main,(ptr)0));
> }
>
> machine stack stack machine assembly
> address address data code language
> ======== ======== ======== ========= =============
> [00001e42][00103375][00000000] 55 push ebp ; begin main
> [00001e43][00103375][00000000] 8bec mov ebp,esp
> [00001e45][00103371][00000000] 6a00 push +00
> [00001e47][0010336d][00001e42] 68421e0000 push 00001e42 ; push main
> [00001e4c][00103369][00001e51] e831f5ffff call 00001382 ; call HH
> New slave_stack at:103419
>
> Begin Local Halt Decider Simulation Execution Trace Stored at:113421
> [00001e42][0011340d][00113411] 55 push ebp ; begin main
> [00001e43][0011340d][00113411] 8bec mov ebp,esp
> [00001e45][00113409][00000000] 6a00 push +00
> [00001e47][00113405][00001e42] 68421e0000 push 00001e42 ; push main
> [00001e4c][00113401][00001e51] e831f5ffff call 00001382 ; call HH
> New slave_stack at:14de41
> [00001e42][0015de35][0015de39] 55 push ebp ; begin main
> [00001e43][0015de35][0015de39] 8bec mov ebp,esp
> [00001e45][0015de31][00000000] 6a00 push +00
> [00001e47][0015de2d][00001e42] 68421e0000 push 00001e42 ; push main
> [00001e4c][0015de29][00001e51] e831f5ffff call 00001382 ; call HH
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>
> [00001e51][00103375][00000000] 83c408 add esp,+08
> [00001e54][00103371][00000000] 50 push eax
> [00001e55][0010336d][00000743] 6843070000 push 00000743
> [00001e5a][0010336d][00000743] e843e9ffff call 000007a2
> Input_Halts = 0
> [00001e5f][00103375][00000000] 83c408 add esp,+08
> [00001e62][00103375][00000000] eb79 jmp 00001edd
> [00001edd][00103375][00000000] 33c0 xor eax,eax
> [00001edf][00103379][00000018] 5d pop ebp
> [00001ee0][0010337d][00000000] c3 ret ; end main
> Number of Instructions Executed(12311) == 184 Pages
>
> So main() does halt at its final state at [00001ee0] which proves
> that the directly executed HH(main,(ptr)0) called by main() halts
> and returns 0;
>
Your HH returns 0, reporting that main does not halt. So this is an
example of how your HH produces a false negative.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-05 17:44 -0500 |
| Subject | Re: Halting Problem is wrong two different ways |
| Message-ID | <v3qpp1$15div$1@dont-email.me> |
| In reply to | #106343 |
On 6/5/2024 1:51 PM, Fred. Zwarts wrote:
> Op 05.jun.2024 om 15:59 schreef olcott:
>> On 6/5/2024 3:11 AM, Fred. Zwarts wrote:
>>> Op 05.jun.2024 om 04:05 schreef olcott:
>>>> On 6/4/2024 8:48 PM, Richard Damon wrote:
>>>>> On 6/4/24 1:40 PM, olcott wrote:
>>>>>> On 6/4/2024 3:28 AM, Mikko wrote:
>>>>>>> On 2024-06-03 18:14:39 +0000, olcott said:
>>>>>>>
>>>>>>>> On 6/3/2024 9:27 AM, Mikko wrote:
>>>>>>>>> On 2024-06-03 12:20:01 +0000, olcott said:
>>>>>>>>>
>>>>>>>>>> On 6/3/2024 4:42 AM, Ben Bacarisse wrote:
>>>>>>>>>>> Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>> PO's D(D) halts, as illustrated in various traces that have
>>>>>>>>>>>> been posted here.
>>>>>>>>>>>> PO's H(D,D) returns 0 : [NOT halting] also as illustrated in
>>>>>>>>>>>> various traces.
>>>>>>>>>>>> i.e. exactly as the Linz proof claims. PO has acknowledged
>>>>>>>>>>>> both these
>>>>>>>>>>>> results. Same for the HH/DD variants.
>>>>>>>>>>>>
>>>>>>>>>>>> You might imagine that's the end of the matter - PO failed. :)
>>>>>>>>>>>>
>>>>>>>>>>>> That's right, but PO just carries on anyway!
>>>>>>>>>>>
>>>>>>>>>>> He has quite explicitly stated that false (0) is the correct
>>>>>>>>>>> result for
>>>>>>>>>>> H(D,D) "even though D(D) halts". I am mystified why anyone
>>>>>>>>>>> continues to
>>>>>>>>>>> discuss the matter until he equally explicitly repudiates
>>>>>>>>>>> that claim.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Deciders only compute the mapping *from their inputs* to their
>>>>>>>>>> own
>>>>>>>>>> accept or reject state.
>>>>>>>>>
>>>>>>>>> That does not restrict what a problem statement can specify.
>>>>>>>>> If the computed mapping differs from the specified one the
>>>>>>>>> decider does not solve the problem.
>>>>>>>>
>>>>>>>> int sum(int x, int y) { return x + y; }
>>>>>>>> sum(2,3) cannot return the sum of 5 + 6.
>>>>>>>
>>>>>>> That does not restrict what a problem statement can specify.
>>>>>>> If the mapping computed by sum differs from the specified one
>>>>>>> the program sum does not solve the problem.
>>>>>>>
>>>>>>
>>>>>> On 6/3/2024 9:53 PM, Richard Damon wrote:
>>>>>> > Because you keep on mentioning about DD Halting,
>>>>>> > which IS about the direct execution of DD
>>>>>>
>>>>>> Only when one contradicts the definition of a decider that must
>>>>>> compute the mapping FROM ITS INPUTS BASED ON THE ACTUAL BEHAVIOR
>>>>>> OF THESE INPUTS (as measured by DD correctly simulated by HH).
>>>>>
>>>>> But strings don't HAVE "Behavior", they only represent things that do.
>>>>>
>>>>
>>>> Turing Machine descriptions specify behavior to UTMs.
>>>>
>>>>> And, for a Halt decider, that thing they represent is the program,
>>>>> whose direct execution specifies the proper behavior of the input.
>>>>>
>>>>> The DEFINITON IS NOT "as measured by DD correctly simulated by
>>>>> HH", as deciders, by their definiton, are trying to compute the
>>>>> mapping of their input according to a defined function, which is a
>>>>> function of just that input. Since that function doesn't know which
>>>>> "H' is going to try to decide on it, it can't change its answer
>>>>> based on which H we ask.
>>>>>
>>>>> Proper Deciders can not be asked "Subjective" questions, unless we
>>>>> SPECIFICALLY define the mapping to include the decider as one of
>>>>> the inputs, and at that point, the question actually ceases to be
>>>>> subjective, as it becomes, what should THAT H say about this input,
>>>>> which is back to an objective agian (since machines are
>>>>> deterministic, so the definition of H tells us what H will answer
>>>>> to that question).
>>>>>
>>>>>>
>>>>>> When we go ahead and contradict this definition then the
>>>>>> *HALTING PROBLEM IS STILL WRONG IN A DIFFERENT WAY*
>>>>>
>>>>> Nope, YOU are wrong, because you
>>>>>
>>>>>>
>>>>>> When D is defined to do the opposite of whatever yes/no
>>>>>> an answer that H provides then the counter-example input
>>>>>> is precisely isomorphic to the question:
>>>>>> Is this sentence: "This sentence is not true." true or false?
>>>>>> Thus that question and the HP question are both incorrect
>>>>>> because both yes and no are the wrong answer.
>>>>>
>>>>> Nope, Just shows how small your mind is.
>>>>>
>>>>> Proven elsewhere.,
>>>>>
>>>>>>
>>>>>> The theory of computation may be ignorant of the details of
>>>>>> how the context of who is asked a question changes the meaning
>>>>>> of this question, none-the-less this cannot be ignored.
>>>>>> It is and remains incorrect for the theory of computation
>>>>>> to ignore this.
>>>>>>
>>>>>
>>>>> But the question it asks is an OBJECTIVE question that doesn't
>>>>> depend on who it is asked of.
>>>>>
>>>>
>>>> When H is asked about the behavior of a Machine that is programmed
>>>> to do the opposite of whatever it says then the context that it is H
>>>> that is being asked is an inherent aspect of the meaning of this
>>>> question and cannot be correctly ignored.
>>>
>>> But that has nothing to do with your simulation result.
>>
>> Notice the subject line of this thread.
>> That HH is being asked an incorrect question is the second
>> way that the Halting Problem is wrong.
>>
>>> Your simulation does not even reach the part that contradict its result.
>>> Your decider even diagnoses programs as non-halting when they do not
>>> contradict the result of the decider, as in:
>>>
>>> typedef int (*ptr)(); // ptr is pointer to int function in C
>>>
>>> int H(ptr p, ptr i);
>>>
>>> int main()
>>> {
>>> H(main, 0);
>>> }
>>>
>>> It is clear that main does not programmed to do the opposite of what
>>> H says.
>>>
>>
>> *I was surprised that this worked correctly: here are the details*
>>
>> int main()
>> {
>> Output("Input_Halts = ", HH(main,(ptr)0));
>> }
>>
>> machine stack stack machine assembly
>> address address data code language
>> ======== ======== ======== ========= =============
>> [00001e42][00103375][00000000] 55 push ebp ; begin main
>> [00001e43][00103375][00000000] 8bec mov ebp,esp
>> [00001e45][00103371][00000000] 6a00 push +00
>> [00001e47][0010336d][00001e42] 68421e0000 push 00001e42 ; push main
>> [00001e4c][00103369][00001e51] e831f5ffff call 00001382 ; call HH
>> New slave_stack at:103419
>>
>> Begin Local Halt Decider Simulation Execution Trace Stored at:113421
>> [00001e42][0011340d][00113411] 55 push ebp ; begin main
>> [00001e43][0011340d][00113411] 8bec mov ebp,esp
>> [00001e45][00113409][00000000] 6a00 push +00
>> [00001e47][00113405][00001e42] 68421e0000 push 00001e42 ; push main
>> [00001e4c][00113401][00001e51] e831f5ffff call 00001382 ; call HH
>> New slave_stack at:14de41
>> [00001e42][0015de35][0015de39] 55 push ebp ; begin main
>> [00001e43][0015de35][0015de39] 8bec mov ebp,esp
>> [00001e45][0015de31][00000000] 6a00 push +00
>> [00001e47][0015de2d][00001e42] 68421e0000 push 00001e42 ; push main
>> [00001e4c][0015de29][00001e51] e831f5ffff call 00001382 ; call HH
>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>
>> [00001e51][00103375][00000000] 83c408 add esp,+08
>> [00001e54][00103371][00000000] 50 push eax
>> [00001e55][0010336d][00000743] 6843070000 push 00000743
>> [00001e5a][0010336d][00000743] e843e9ffff call 000007a2
>> Input_Halts = 0
>> [00001e5f][00103375][00000000] 83c408 add esp,+08
>> [00001e62][00103375][00000000] eb79 jmp 00001edd
>> [00001edd][00103375][00000000] 33c0 xor eax,eax
>> [00001edf][00103379][00000018] 5d pop ebp
>> [00001ee0][0010337d][00000000] c3 ret ; end main
>> Number of Instructions Executed(12311) == 184 Pages
>>
>> So main() does halt at its final state at [00001ee0] which proves
>> that the directly executed HH(main,(ptr)0) called by main() halts
>> and returns 0;
>>
>
> Your HH returns 0, reporting that main does not halt. So this is an
> example of how your HH produces a false negative.
My HH returns 0 indicating that what you specified results in recursive
simulation that cannot possibly ever stop running unless aborted.
You don't sufficiently understand the technical details of this
to verify the actual facts.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2024-06-06 18:01 +0200 |
| Subject | Re: Halting Problem is wrong two different ways |
| Message-ID | <v3smh1$1ihop$1@dont-email.me> |
| In reply to | #106347 |
Op 06.jun.2024 om 00:44 schreef olcott:
> On 6/5/2024 1:51 PM, Fred. Zwarts wrote:
>> Op 05.jun.2024 om 15:59 schreef olcott:
>>> On 6/5/2024 3:11 AM, Fred. Zwarts wrote:
>>>> Op 05.jun.2024 om 04:05 schreef olcott:
>>>>> On 6/4/2024 8:48 PM, Richard Damon wrote:
>>>>>> On 6/4/24 1:40 PM, olcott wrote:
>>>>>>> On 6/4/2024 3:28 AM, Mikko wrote:
>>>>>>>> On 2024-06-03 18:14:39 +0000, olcott said:
>>>>>>>>
>>>>>>>>> On 6/3/2024 9:27 AM, Mikko wrote:
>>>>>>>>>> On 2024-06-03 12:20:01 +0000, olcott said:
>>>>>>>>>>
>>>>>>>>>>> On 6/3/2024 4:42 AM, Ben Bacarisse wrote:
>>>>>>>>>>>> Mike Terry <news.dead.person.stones@darjeeling.plus.com>
>>>>>>>>>>>> writes:
>>>>>>>>>>>>
>>>>>>>>>>>>> PO's D(D) halts, as illustrated in various traces that have
>>>>>>>>>>>>> been posted here.
>>>>>>>>>>>>> PO's H(D,D) returns 0 : [NOT halting] also as illustrated
>>>>>>>>>>>>> in various traces.
>>>>>>>>>>>>> i.e. exactly as the Linz proof claims. PO has acknowledged
>>>>>>>>>>>>> both these
>>>>>>>>>>>>> results. Same for the HH/DD variants.
>>>>>>>>>>>>>
>>>>>>>>>>>>> You might imagine that's the end of the matter - PO
>>>>>>>>>>>>> failed. :)
>>>>>>>>>>>>>
>>>>>>>>>>>>> That's right, but PO just carries on anyway!
>>>>>>>>>>>>
>>>>>>>>>>>> He has quite explicitly stated that false (0) is the correct
>>>>>>>>>>>> result for
>>>>>>>>>>>> H(D,D) "even though D(D) halts". I am mystified why anyone
>>>>>>>>>>>> continues to
>>>>>>>>>>>> discuss the matter until he equally explicitly repudiates
>>>>>>>>>>>> that claim.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Deciders only compute the mapping *from their inputs* to
>>>>>>>>>>> their own
>>>>>>>>>>> accept or reject state.
>>>>>>>>>>
>>>>>>>>>> That does not restrict what a problem statement can specify.
>>>>>>>>>> If the computed mapping differs from the specified one the
>>>>>>>>>> decider does not solve the problem.
>>>>>>>>>
>>>>>>>>> int sum(int x, int y) { return x + y; }
>>>>>>>>> sum(2,3) cannot return the sum of 5 + 6.
>>>>>>>>
>>>>>>>> That does not restrict what a problem statement can specify.
>>>>>>>> If the mapping computed by sum differs from the specified one
>>>>>>>> the program sum does not solve the problem.
>>>>>>>>
>>>>>>>
>>>>>>> On 6/3/2024 9:53 PM, Richard Damon wrote:
>>>>>>> > Because you keep on mentioning about DD Halting,
>>>>>>> > which IS about the direct execution of DD
>>>>>>>
>>>>>>> Only when one contradicts the definition of a decider that must
>>>>>>> compute the mapping FROM ITS INPUTS BASED ON THE ACTUAL BEHAVIOR
>>>>>>> OF THESE INPUTS (as measured by DD correctly simulated by HH).
>>>>>>
>>>>>> But strings don't HAVE "Behavior", they only represent things that
>>>>>> do.
>>>>>>
>>>>>
>>>>> Turing Machine descriptions specify behavior to UTMs.
>>>>>
>>>>>> And, for a Halt decider, that thing they represent is the program,
>>>>>> whose direct execution specifies the proper behavior of the input.
>>>>>>
>>>>>> The DEFINITON IS NOT "as measured by DD correctly simulated by
>>>>>> HH", as deciders, by their definiton, are trying to compute the
>>>>>> mapping of their input according to a defined function, which is a
>>>>>> function of just that input. Since that function doesn't know
>>>>>> which "H' is going to try to decide on it, it can't change its
>>>>>> answer based on which H we ask.
>>>>>>
>>>>>> Proper Deciders can not be asked "Subjective" questions, unless we
>>>>>> SPECIFICALLY define the mapping to include the decider as one of
>>>>>> the inputs, and at that point, the question actually ceases to be
>>>>>> subjective, as it becomes, what should THAT H say about this
>>>>>> input, which is back to an objective agian (since machines are
>>>>>> deterministic, so the definition of H tells us what H will answer
>>>>>> to that question).
>>>>>>
>>>>>>>
>>>>>>> When we go ahead and contradict this definition then the
>>>>>>> *HALTING PROBLEM IS STILL WRONG IN A DIFFERENT WAY*
>>>>>>
>>>>>> Nope, YOU are wrong, because you
>>>>>>
>>>>>>>
>>>>>>> When D is defined to do the opposite of whatever yes/no
>>>>>>> an answer that H provides then the counter-example input
>>>>>>> is precisely isomorphic to the question:
>>>>>>> Is this sentence: "This sentence is not true." true or false?
>>>>>>> Thus that question and the HP question are both incorrect
>>>>>>> because both yes and no are the wrong answer.
>>>>>>
>>>>>> Nope, Just shows how small your mind is.
>>>>>>
>>>>>> Proven elsewhere.,
>>>>>>
>>>>>>>
>>>>>>> The theory of computation may be ignorant of the details of
>>>>>>> how the context of who is asked a question changes the meaning
>>>>>>> of this question, none-the-less this cannot be ignored.
>>>>>>> It is and remains incorrect for the theory of computation
>>>>>>> to ignore this.
>>>>>>>
>>>>>>
>>>>>> But the question it asks is an OBJECTIVE question that doesn't
>>>>>> depend on who it is asked of.
>>>>>>
>>>>>
>>>>> When H is asked about the behavior of a Machine that is programmed
>>>>> to do the opposite of whatever it says then the context that it is H
>>>>> that is being asked is an inherent aspect of the meaning of this
>>>>> question and cannot be correctly ignored.
>>>>
>>>> But that has nothing to do with your simulation result.
>>>
>>> Notice the subject line of this thread.
>>> That HH is being asked an incorrect question is the second
>>> way that the Halting Problem is wrong.
>>>
>>>> Your simulation does not even reach the part that contradict its
>>>> result.
>>>> Your decider even diagnoses programs as non-halting when they do not
>>>> contradict the result of the decider, as in:
>>>>
>>>> typedef int (*ptr)(); // ptr is pointer to int function in C
>>>>
>>>> int H(ptr p, ptr i);
>>>>
>>>> int main()
>>>> {
>>>> H(main, 0);
>>>> }
>>>>
>>>> It is clear that main does not programmed to do the opposite of what
>>>> H says.
>>>>
>>>
>>> *I was surprised that this worked correctly: here are the details*
>>>
>>> int main()
>>> {
>>> Output("Input_Halts = ", HH(main,(ptr)0));
>>> }
>>>
>>> machine stack stack machine assembly
>>> address address data code language
>>> ======== ======== ======== ========= =============
>>> [00001e42][00103375][00000000] 55 push ebp ; begin main
>>> [00001e43][00103375][00000000] 8bec mov ebp,esp
>>> [00001e45][00103371][00000000] 6a00 push +00
>>> [00001e47][0010336d][00001e42] 68421e0000 push 00001e42 ; push main
>>> [00001e4c][00103369][00001e51] e831f5ffff call 00001382 ; call HH
>>> New slave_stack at:103419
>>>
>>> Begin Local Halt Decider Simulation Execution Trace Stored at:113421
>>> [00001e42][0011340d][00113411] 55 push ebp ; begin main
>>> [00001e43][0011340d][00113411] 8bec mov ebp,esp
>>> [00001e45][00113409][00000000] 6a00 push +00
>>> [00001e47][00113405][00001e42] 68421e0000 push 00001e42 ; push main
>>> [00001e4c][00113401][00001e51] e831f5ffff call 00001382 ; call HH
>>> New slave_stack at:14de41
>>> [00001e42][0015de35][0015de39] 55 push ebp ; begin main
>>> [00001e43][0015de35][0015de39] 8bec mov ebp,esp
>>> [00001e45][0015de31][00000000] 6a00 push +00
>>> [00001e47][0015de2d][00001e42] 68421e0000 push 00001e42 ; push main
>>> [00001e4c][0015de29][00001e51] e831f5ffff call 00001382 ; call HH
>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>>
>>> [00001e51][00103375][00000000] 83c408 add esp,+08
>>> [00001e54][00103371][00000000] 50 push eax
>>> [00001e55][0010336d][00000743] 6843070000 push 00000743
>>> [00001e5a][0010336d][00000743] e843e9ffff call 000007a2
>>> Input_Halts = 0
>>> [00001e5f][00103375][00000000] 83c408 add esp,+08
>>> [00001e62][00103375][00000000] eb79 jmp 00001edd
>>> [00001edd][00103375][00000000] 33c0 xor eax,eax
>>> [00001edf][00103379][00000018] 5d pop ebp
>>> [00001ee0][0010337d][00000000] c3 ret ; end main
>>> Number of Instructions Executed(12311) == 184 Pages
>>>
>>> So main() does halt at its final state at [00001ee0] which proves
>>> that the directly executed HH(main,(ptr)0) called by main() halts
>>> and returns 0;
>>>
>>
>> Your HH returns 0, reporting that main does not halt. So this is an
>> example of how your HH produces a false negative.
>
> My HH returns 0 indicating that what you specified results in recursive
> simulation that cannot possibly ever stop running unless aborted.
>
> You don't sufficiently understand the technical details of this
> to verify the actual facts.
>
That may be a good explanation why there is a false negative. But it
does not change the fact that there is a false negative.
If you don't know what a false negative is:
A test that returns 'no' when the reality is 'yes'.
Your test returns no, the direct execution is 'yes'.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-06 11:07 -0500 |
| Subject | Re: Halting Problem is wrong two different ways |
| Message-ID | <v3smsg$1iedv$4@dont-email.me> |
| In reply to | #106415 |
On 6/6/2024 11:01 AM, Fred. Zwarts wrote:
> Op 06.jun.2024 om 00:44 schreef olcott:
>> On 6/5/2024 1:51 PM, Fred. Zwarts wrote:
>>> Op 05.jun.2024 om 15:59 schreef olcott:
>>>> On 6/5/2024 3:11 AM, Fred. Zwarts wrote:
>>>>> Op 05.jun.2024 om 04:05 schreef olcott:
>>>>>> On 6/4/2024 8:48 PM, Richard Damon wrote:
>>>>>>> On 6/4/24 1:40 PM, olcott wrote:
>>>>>>>> On 6/4/2024 3:28 AM, Mikko wrote:
>>>>>>>>> On 2024-06-03 18:14:39 +0000, olcott said:
>>>>>>>>>
>>>>>>>>>> On 6/3/2024 9:27 AM, Mikko wrote:
>>>>>>>>>>> On 2024-06-03 12:20:01 +0000, olcott said:
>>>>>>>>>>>
>>>>>>>>>>>> On 6/3/2024 4:42 AM, Ben Bacarisse wrote:
>>>>>>>>>>>>> Mike Terry <news.dead.person.stones@darjeeling.plus.com>
>>>>>>>>>>>>> writes:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> PO's D(D) halts, as illustrated in various traces that
>>>>>>>>>>>>>> have been posted here.
>>>>>>>>>>>>>> PO's H(D,D) returns 0 : [NOT halting] also as illustrated
>>>>>>>>>>>>>> in various traces.
>>>>>>>>>>>>>> i.e. exactly as the Linz proof claims. PO has
>>>>>>>>>>>>>> acknowledged both these
>>>>>>>>>>>>>> results. Same for the HH/DD variants.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You might imagine that's the end of the matter - PO
>>>>>>>>>>>>>> failed. :)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> That's right, but PO just carries on anyway!
>>>>>>>>>>>>>
>>>>>>>>>>>>> He has quite explicitly stated that false (0) is the
>>>>>>>>>>>>> correct result for
>>>>>>>>>>>>> H(D,D) "even though D(D) halts". I am mystified why anyone
>>>>>>>>>>>>> continues to
>>>>>>>>>>>>> discuss the matter until he equally explicitly repudiates
>>>>>>>>>>>>> that claim.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Deciders only compute the mapping *from their inputs* to
>>>>>>>>>>>> their own
>>>>>>>>>>>> accept or reject state.
>>>>>>>>>>>
>>>>>>>>>>> That does not restrict what a problem statement can specify.
>>>>>>>>>>> If the computed mapping differs from the specified one the
>>>>>>>>>>> decider does not solve the problem.
>>>>>>>>>>
>>>>>>>>>> int sum(int x, int y) { return x + y; }
>>>>>>>>>> sum(2,3) cannot return the sum of 5 + 6.
>>>>>>>>>
>>>>>>>>> That does not restrict what a problem statement can specify.
>>>>>>>>> If the mapping computed by sum differs from the specified one
>>>>>>>>> the program sum does not solve the problem.
>>>>>>>>>
>>>>>>>>
>>>>>>>> On 6/3/2024 9:53 PM, Richard Damon wrote:
>>>>>>>> > Because you keep on mentioning about DD Halting,
>>>>>>>> > which IS about the direct execution of DD
>>>>>>>>
>>>>>>>> Only when one contradicts the definition of a decider that must
>>>>>>>> compute the mapping FROM ITS INPUTS BASED ON THE ACTUAL BEHAVIOR
>>>>>>>> OF THESE INPUTS (as measured by DD correctly simulated by HH).
>>>>>>>
>>>>>>> But strings don't HAVE "Behavior", they only represent things
>>>>>>> that do.
>>>>>>>
>>>>>>
>>>>>> Turing Machine descriptions specify behavior to UTMs.
>>>>>>
>>>>>>> And, for a Halt decider, that thing they represent is the
>>>>>>> program, whose direct execution specifies the proper behavior of
>>>>>>> the input.
>>>>>>>
>>>>>>> The DEFINITON IS NOT "as measured by DD correctly simulated by
>>>>>>> HH", as deciders, by their definiton, are trying to compute the
>>>>>>> mapping of their input according to a defined function, which is
>>>>>>> a function of just that input. Since that function doesn't know
>>>>>>> which "H' is going to try to decide on it, it can't change its
>>>>>>> answer based on which H we ask.
>>>>>>>
>>>>>>> Proper Deciders can not be asked "Subjective" questions, unless
>>>>>>> we SPECIFICALLY define the mapping to include the decider as one
>>>>>>> of the inputs, and at that point, the question actually ceases to
>>>>>>> be subjective, as it becomes, what should THAT H say about this
>>>>>>> input, which is back to an objective agian (since machines are
>>>>>>> deterministic, so the definition of H tells us what H will answer
>>>>>>> to that question).
>>>>>>>
>>>>>>>>
>>>>>>>> When we go ahead and contradict this definition then the
>>>>>>>> *HALTING PROBLEM IS STILL WRONG IN A DIFFERENT WAY*
>>>>>>>
>>>>>>> Nope, YOU are wrong, because you
>>>>>>>
>>>>>>>>
>>>>>>>> When D is defined to do the opposite of whatever yes/no
>>>>>>>> an answer that H provides then the counter-example input
>>>>>>>> is precisely isomorphic to the question:
>>>>>>>> Is this sentence: "This sentence is not true." true or false?
>>>>>>>> Thus that question and the HP question are both incorrect
>>>>>>>> because both yes and no are the wrong answer.
>>>>>>>
>>>>>>> Nope, Just shows how small your mind is.
>>>>>>>
>>>>>>> Proven elsewhere.,
>>>>>>>
>>>>>>>>
>>>>>>>> The theory of computation may be ignorant of the details of
>>>>>>>> how the context of who is asked a question changes the meaning
>>>>>>>> of this question, none-the-less this cannot be ignored.
>>>>>>>> It is and remains incorrect for the theory of computation
>>>>>>>> to ignore this.
>>>>>>>>
>>>>>>>
>>>>>>> But the question it asks is an OBJECTIVE question that doesn't
>>>>>>> depend on who it is asked of.
>>>>>>>
>>>>>>
>>>>>> When H is asked about the behavior of a Machine that is programmed
>>>>>> to do the opposite of whatever it says then the context that it is H
>>>>>> that is being asked is an inherent aspect of the meaning of this
>>>>>> question and cannot be correctly ignored.
>>>>>
>>>>> But that has nothing to do with your simulation result.
>>>>
>>>> Notice the subject line of this thread.
>>>> That HH is being asked an incorrect question is the second
>>>> way that the Halting Problem is wrong.
>>>>
>>>>> Your simulation does not even reach the part that contradict its
>>>>> result.
>>>>> Your decider even diagnoses programs as non-halting when they do
>>>>> not contradict the result of the decider, as in:
>>>>>
>>>>> typedef int (*ptr)(); // ptr is pointer to int function in C
>>>>>
>>>>> int H(ptr p, ptr i);
>>>>>
>>>>> int main()
>>>>> {
>>>>> H(main, 0);
>>>>> }
>>>>>
>>>>> It is clear that main does not programmed to do the opposite of
>>>>> what H says.
>>>>>
>>>>
>>>> *I was surprised that this worked correctly: here are the details*
>>>>
>>>> int main()
>>>> {
>>>> Output("Input_Halts = ", HH(main,(ptr)0));
>>>> }
>>>>
>>>> machine stack stack machine assembly
>>>> address address data code language
>>>> ======== ======== ======== ========= =============
>>>> [00001e42][00103375][00000000] 55 push ebp ; begin main
>>>> [00001e43][00103375][00000000] 8bec mov ebp,esp
>>>> [00001e45][00103371][00000000] 6a00 push +00
>>>> [00001e47][0010336d][00001e42] 68421e0000 push 00001e42 ; push main
>>>> [00001e4c][00103369][00001e51] e831f5ffff call 00001382 ; call HH
>>>> New slave_stack at:103419
>>>>
>>>> Begin Local Halt Decider Simulation Execution Trace Stored at:113421
>>>> [00001e42][0011340d][00113411] 55 push ebp ; begin main
>>>> [00001e43][0011340d][00113411] 8bec mov ebp,esp
>>>> [00001e45][00113409][00000000] 6a00 push +00
>>>> [00001e47][00113405][00001e42] 68421e0000 push 00001e42 ; push main
>>>> [00001e4c][00113401][00001e51] e831f5ffff call 00001382 ; call HH
>>>> New slave_stack at:14de41
>>>> [00001e42][0015de35][0015de39] 55 push ebp ; begin main
>>>> [00001e43][0015de35][0015de39] 8bec mov ebp,esp
>>>> [00001e45][0015de31][00000000] 6a00 push +00
>>>> [00001e47][0015de2d][00001e42] 68421e0000 push 00001e42 ; push main
>>>> [00001e4c][0015de29][00001e51] e831f5ffff call 00001382 ; call HH
>>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>>>
>>>> [00001e51][00103375][00000000] 83c408 add esp,+08
>>>> [00001e54][00103371][00000000] 50 push eax
>>>> [00001e55][0010336d][00000743] 6843070000 push 00000743
>>>> [00001e5a][0010336d][00000743] e843e9ffff call 000007a2
>>>> Input_Halts = 0
>>>> [00001e5f][00103375][00000000] 83c408 add esp,+08
>>>> [00001e62][00103375][00000000] eb79 jmp 00001edd
>>>> [00001edd][00103375][00000000] 33c0 xor eax,eax
>>>> [00001edf][00103379][00000018] 5d pop ebp
>>>> [00001ee0][0010337d][00000000] c3 ret ; end main
>>>> Number of Instructions Executed(12311) == 184 Pages
>>>>
>>>> So main() does halt at its final state at [00001ee0] which proves
>>>> that the directly executed HH(main,(ptr)0) called by main() halts
>>>> and returns 0;
>>>>
>>>
>>> Your HH returns 0, reporting that main does not halt. So this is an
>>> example of how your HH produces a false negative.
>>
>> My HH returns 0 indicating that what you specified results in recursive
>> simulation that cannot possibly ever stop running unless aborted.
>>
>> You don't sufficiently understand the technical details of this
>> to verify the actual facts.
>>
>
> That may be a good explanation why there is a false negative. But it
> does not change the fact that there is a false negative.
> If you don't know what a false negative is:
> A test that returns 'no' when the reality is 'yes'.
> Your test returns no, the direct execution is 'yes'.
>
<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>
Try to show how this DD can be correctly simulated by any HH
*would stop running without having its simulation aborted*
thus fails to match the above criteria.
_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
You can't do it and if you even imply otherwise *THIS IS DECEPTION*
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2024-06-06 18:34 +0200 |
| Subject | Re: Halting Problem is wrong two different ways |
| Message-ID | <v3sof4$1ihop$2@dont-email.me> |
| In reply to | #106417 |
Op 06.jun.2024 om 18:07 schreef olcott:
> On 6/6/2024 11:01 AM, Fred. Zwarts wrote:
>> Op 06.jun.2024 om 00:44 schreef olcott:
>>> On 6/5/2024 1:51 PM, Fred. Zwarts wrote:
>>>> Op 05.jun.2024 om 15:59 schreef olcott:
>>>>> On 6/5/2024 3:11 AM, Fred. Zwarts wrote:
>>>>>> Op 05.jun.2024 om 04:05 schreef olcott:
>>>>>>> On 6/4/2024 8:48 PM, Richard Damon wrote:
>>>>>>>> On 6/4/24 1:40 PM, olcott wrote:
>>>>>>>>> On 6/4/2024 3:28 AM, Mikko wrote:
>>>>>>>>>> On 2024-06-03 18:14:39 +0000, olcott said:
>>>>>>>>>>
>>>>>>>>>>> On 6/3/2024 9:27 AM, Mikko wrote:
>>>>>>>>>>>> On 2024-06-03 12:20:01 +0000, olcott said:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 6/3/2024 4:42 AM, Ben Bacarisse wrote:
>>>>>>>>>>>>>> Mike Terry <news.dead.person.stones@darjeeling.plus.com>
>>>>>>>>>>>>>> writes:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> PO's D(D) halts, as illustrated in various traces that
>>>>>>>>>>>>>>> have been posted here.
>>>>>>>>>>>>>>> PO's H(D,D) returns 0 : [NOT halting] also as illustrated
>>>>>>>>>>>>>>> in various traces.
>>>>>>>>>>>>>>> i.e. exactly as the Linz proof claims. PO has
>>>>>>>>>>>>>>> acknowledged both these
>>>>>>>>>>>>>>> results. Same for the HH/DD variants.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You might imagine that's the end of the matter - PO
>>>>>>>>>>>>>>> failed. :)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> That's right, but PO just carries on anyway!
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> He has quite explicitly stated that false (0) is the
>>>>>>>>>>>>>> correct result for
>>>>>>>>>>>>>> H(D,D) "even though D(D) halts". I am mystified why
>>>>>>>>>>>>>> anyone continues to
>>>>>>>>>>>>>> discuss the matter until he equally explicitly repudiates
>>>>>>>>>>>>>> that claim.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Deciders only compute the mapping *from their inputs* to
>>>>>>>>>>>>> their own
>>>>>>>>>>>>> accept or reject state.
>>>>>>>>>>>>
>>>>>>>>>>>> That does not restrict what a problem statement can specify.
>>>>>>>>>>>> If the computed mapping differs from the specified one the
>>>>>>>>>>>> decider does not solve the problem.
>>>>>>>>>>>
>>>>>>>>>>> int sum(int x, int y) { return x + y; }
>>>>>>>>>>> sum(2,3) cannot return the sum of 5 + 6.
>>>>>>>>>>
>>>>>>>>>> That does not restrict what a problem statement can specify.
>>>>>>>>>> If the mapping computed by sum differs from the specified one
>>>>>>>>>> the program sum does not solve the problem.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 6/3/2024 9:53 PM, Richard Damon wrote:
>>>>>>>>> > Because you keep on mentioning about DD Halting,
>>>>>>>>> > which IS about the direct execution of DD
>>>>>>>>>
>>>>>>>>> Only when one contradicts the definition of a decider that must
>>>>>>>>> compute the mapping FROM ITS INPUTS BASED ON THE ACTUAL BEHAVIOR
>>>>>>>>> OF THESE INPUTS (as measured by DD correctly simulated by HH).
>>>>>>>>
>>>>>>>> But strings don't HAVE "Behavior", they only represent things
>>>>>>>> that do.
>>>>>>>>
>>>>>>>
>>>>>>> Turing Machine descriptions specify behavior to UTMs.
>>>>>>>
>>>>>>>> And, for a Halt decider, that thing they represent is the
>>>>>>>> program, whose direct execution specifies the proper behavior of
>>>>>>>> the input.
>>>>>>>>
>>>>>>>> The DEFINITON IS NOT "as measured by DD correctly simulated by
>>>>>>>> HH", as deciders, by their definiton, are trying to compute the
>>>>>>>> mapping of their input according to a defined function, which is
>>>>>>>> a function of just that input. Since that function doesn't know
>>>>>>>> which "H' is going to try to decide on it, it can't change its
>>>>>>>> answer based on which H we ask.
>>>>>>>>
>>>>>>>> Proper Deciders can not be asked "Subjective" questions, unless
>>>>>>>> we SPECIFICALLY define the mapping to include the decider as one
>>>>>>>> of the inputs, and at that point, the question actually ceases
>>>>>>>> to be subjective, as it becomes, what should THAT H say about
>>>>>>>> this input, which is back to an objective agian (since machines
>>>>>>>> are deterministic, so the definition of H tells us what H will
>>>>>>>> answer to that question).
>>>>>>>>
>>>>>>>>>
>>>>>>>>> When we go ahead and contradict this definition then the
>>>>>>>>> *HALTING PROBLEM IS STILL WRONG IN A DIFFERENT WAY*
>>>>>>>>
>>>>>>>> Nope, YOU are wrong, because you
>>>>>>>>
>>>>>>>>>
>>>>>>>>> When D is defined to do the opposite of whatever yes/no
>>>>>>>>> an answer that H provides then the counter-example input
>>>>>>>>> is precisely isomorphic to the question:
>>>>>>>>> Is this sentence: "This sentence is not true." true or false?
>>>>>>>>> Thus that question and the HP question are both incorrect
>>>>>>>>> because both yes and no are the wrong answer.
>>>>>>>>
>>>>>>>> Nope, Just shows how small your mind is.
>>>>>>>>
>>>>>>>> Proven elsewhere.,
>>>>>>>>
>>>>>>>>>
>>>>>>>>> The theory of computation may be ignorant of the details of
>>>>>>>>> how the context of who is asked a question changes the meaning
>>>>>>>>> of this question, none-the-less this cannot be ignored.
>>>>>>>>> It is and remains incorrect for the theory of computation
>>>>>>>>> to ignore this.
>>>>>>>>>
>>>>>>>>
>>>>>>>> But the question it asks is an OBJECTIVE question that doesn't
>>>>>>>> depend on who it is asked of.
>>>>>>>>
>>>>>>>
>>>>>>> When H is asked about the behavior of a Machine that is programmed
>>>>>>> to do the opposite of whatever it says then the context that it is H
>>>>>>> that is being asked is an inherent aspect of the meaning of this
>>>>>>> question and cannot be correctly ignored.
>>>>>>
>>>>>> But that has nothing to do with your simulation result.
>>>>>
>>>>> Notice the subject line of this thread.
>>>>> That HH is being asked an incorrect question is the second
>>>>> way that the Halting Problem is wrong.
>>>>>
>>>>>> Your simulation does not even reach the part that contradict its
>>>>>> result.
>>>>>> Your decider even diagnoses programs as non-halting when they do
>>>>>> not contradict the result of the decider, as in:
>>>>>>
>>>>>> typedef int (*ptr)(); // ptr is pointer to int function in C
>>>>>>
>>>>>> int H(ptr p, ptr i);
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>> H(main, 0);
>>>>>> }
>>>>>>
>>>>>> It is clear that main does not programmed to do the opposite of
>>>>>> what H says.
>>>>>>
>>>>>
>>>>> *I was surprised that this worked correctly: here are the details*
>>>>>
>>>>> int main()
>>>>> {
>>>>> Output("Input_Halts = ", HH(main,(ptr)0));
>>>>> }
>>>>>
>>>>> machine stack stack machine assembly
>>>>> address address data code language
>>>>> ======== ======== ======== ========= =============
>>>>> [00001e42][00103375][00000000] 55 push ebp ; begin main
>>>>> [00001e43][00103375][00000000] 8bec mov ebp,esp
>>>>> [00001e45][00103371][00000000] 6a00 push +00
>>>>> [00001e47][0010336d][00001e42] 68421e0000 push 00001e42 ; push main
>>>>> [00001e4c][00103369][00001e51] e831f5ffff call 00001382 ; call HH
>>>>> New slave_stack at:103419
>>>>>
>>>>> Begin Local Halt Decider Simulation Execution Trace Stored at:113421
>>>>> [00001e42][0011340d][00113411] 55 push ebp ; begin main
>>>>> [00001e43][0011340d][00113411] 8bec mov ebp,esp
>>>>> [00001e45][00113409][00000000] 6a00 push +00
>>>>> [00001e47][00113405][00001e42] 68421e0000 push 00001e42 ; push main
>>>>> [00001e4c][00113401][00001e51] e831f5ffff call 00001382 ; call HH
>>>>> New slave_stack at:14de41
>>>>> [00001e42][0015de35][0015de39] 55 push ebp ; begin main
>>>>> [00001e43][0015de35][0015de39] 8bec mov ebp,esp
>>>>> [00001e45][0015de31][00000000] 6a00 push +00
>>>>> [00001e47][0015de2d][00001e42] 68421e0000 push 00001e42 ; push main
>>>>> [00001e4c][0015de29][00001e51] e831f5ffff call 00001382 ; call HH
>>>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>>>>
>>>>> [00001e51][00103375][00000000] 83c408 add esp,+08
>>>>> [00001e54][00103371][00000000] 50 push eax
>>>>> [00001e55][0010336d][00000743] 6843070000 push 00000743
>>>>> [00001e5a][0010336d][00000743] e843e9ffff call 000007a2
>>>>> Input_Halts = 0
>>>>> [00001e5f][00103375][00000000] 83c408 add esp,+08
>>>>> [00001e62][00103375][00000000] eb79 jmp 00001edd
>>>>> [00001edd][00103375][00000000] 33c0 xor eax,eax
>>>>> [00001edf][00103379][00000018] 5d pop ebp
>>>>> [00001ee0][0010337d][00000000] c3 ret ; end main
>>>>> Number of Instructions Executed(12311) == 184 Pages
>>>>>
>>>>> So main() does halt at its final state at [00001ee0] which proves
>>>>> that the directly executed HH(main,(ptr)0) called by main() halts
>>>>> and returns 0;
>>>>>
>>>>
>>>> Your HH returns 0, reporting that main does not halt. So this is an
>>>> example of how your HH produces a false negative.
>>>
>>> My HH returns 0 indicating that what you specified results in recursive
>>> simulation that cannot possibly ever stop running unless aborted.
>>>
>>> You don't sufficiently understand the technical details of this
>>> to verify the actual facts.
>>>
>>
>> That may be a good explanation why there is a false negative. But it
>> does not change the fact that there is a false negative.
>> If you don't know what a false negative is:
>> A test that returns 'no' when the reality is 'yes'.
>> Your test returns no, the direct execution is 'yes'.
>>
>
> <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>
>
> Try to show how this DD can be correctly simulated by any HH
> *would stop running without having its simulation aborted*
> thus fails to match the above criteria.
>
> _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
>
> You can't do it and if you even imply otherwise *THIS IS DECEPTION*
>
Your own proof shows that main halts. Your own proof shows that HH
returns a non-halting result. By *definition* that is a false negative.
So, whether or not Sipser agreed with your explanation, it might might
be a good explanation why your H returns false negatives.
Maybe you should not be worried about false negatives, because it seems
that your decider is not meant to report about reality, but about its
own result, which, of course, is trivially correct.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-06 11:44 -0500 |
| Subject | Re: Halting Problem is wrong two different ways |
| Message-ID | <v3sp2b$1j6kb$2@dont-email.me> |
| In reply to | #106418 |
On 6/6/2024 11:34 AM, Fred. Zwarts wrote:
> Op 06.jun.2024 om 18:07 schreef olcott:
>> On 6/6/2024 11:01 AM, Fred. Zwarts wrote:
>>> Op 06.jun.2024 om 00:44 schreef olcott:
>>>> On 6/5/2024 1:51 PM, Fred. Zwarts wrote:
>>>>> Op 05.jun.2024 om 15:59 schreef olcott:
>>>>>> On 6/5/2024 3:11 AM, Fred. Zwarts wrote:
>>>>>>> Op 05.jun.2024 om 04:05 schreef olcott:
>>>>>>>> On 6/4/2024 8:48 PM, Richard Damon wrote:
>>>>>>>>> On 6/4/24 1:40 PM, olcott wrote:
>>>>>>>>>> On 6/4/2024 3:28 AM, Mikko wrote:
>>>>>>>>>>> On 2024-06-03 18:14:39 +0000, olcott said:
>>>>>>>>>>>
>>>>>>>>>>>> On 6/3/2024 9:27 AM, Mikko wrote:
>>>>>>>>>>>>> On 2024-06-03 12:20:01 +0000, olcott said:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 6/3/2024 4:42 AM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>> Mike Terry <news.dead.person.stones@darjeeling.plus.com>
>>>>>>>>>>>>>>> writes:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> PO's D(D) halts, as illustrated in various traces that
>>>>>>>>>>>>>>>> have been posted here.
>>>>>>>>>>>>>>>> PO's H(D,D) returns 0 : [NOT halting] also as
>>>>>>>>>>>>>>>> illustrated in various traces.
>>>>>>>>>>>>>>>> i.e. exactly as the Linz proof claims. PO has
>>>>>>>>>>>>>>>> acknowledged both these
>>>>>>>>>>>>>>>> results. Same for the HH/DD variants.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> You might imagine that's the end of the matter - PO
>>>>>>>>>>>>>>>> failed. :)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> That's right, but PO just carries on anyway!
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> He has quite explicitly stated that false (0) is the
>>>>>>>>>>>>>>> correct result for
>>>>>>>>>>>>>>> H(D,D) "even though D(D) halts". I am mystified why
>>>>>>>>>>>>>>> anyone continues to
>>>>>>>>>>>>>>> discuss the matter until he equally explicitly repudiates
>>>>>>>>>>>>>>> that claim.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Deciders only compute the mapping *from their inputs* to
>>>>>>>>>>>>>> their own
>>>>>>>>>>>>>> accept or reject state.
>>>>>>>>>>>>>
>>>>>>>>>>>>> That does not restrict what a problem statement can specify.
>>>>>>>>>>>>> If the computed mapping differs from the specified one the
>>>>>>>>>>>>> decider does not solve the problem.
>>>>>>>>>>>>
>>>>>>>>>>>> int sum(int x, int y) { return x + y; }
>>>>>>>>>>>> sum(2,3) cannot return the sum of 5 + 6.
>>>>>>>>>>>
>>>>>>>>>>> That does not restrict what a problem statement can specify.
>>>>>>>>>>> If the mapping computed by sum differs from the specified one
>>>>>>>>>>> the program sum does not solve the problem.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 6/3/2024 9:53 PM, Richard Damon wrote:
>>>>>>>>>> > Because you keep on mentioning about DD Halting,
>>>>>>>>>> > which IS about the direct execution of DD
>>>>>>>>>>
>>>>>>>>>> Only when one contradicts the definition of a decider that must
>>>>>>>>>> compute the mapping FROM ITS INPUTS BASED ON THE ACTUAL BEHAVIOR
>>>>>>>>>> OF THESE INPUTS (as measured by DD correctly simulated by HH).
>>>>>>>>>
>>>>>>>>> But strings don't HAVE "Behavior", they only represent things
>>>>>>>>> that do.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Turing Machine descriptions specify behavior to UTMs.
>>>>>>>>
>>>>>>>>> And, for a Halt decider, that thing they represent is the
>>>>>>>>> program, whose direct execution specifies the proper behavior
>>>>>>>>> of the input.
>>>>>>>>>
>>>>>>>>> The DEFINITON IS NOT "as measured by DD correctly simulated by
>>>>>>>>> HH", as deciders, by their definiton, are trying to compute the
>>>>>>>>> mapping of their input according to a defined function, which
>>>>>>>>> is a function of just that input. Since that function doesn't
>>>>>>>>> know which "H' is going to try to decide on it, it can't change
>>>>>>>>> its answer based on which H we ask.
>>>>>>>>>
>>>>>>>>> Proper Deciders can not be asked "Subjective" questions, unless
>>>>>>>>> we SPECIFICALLY define the mapping to include the decider as
>>>>>>>>> one of the inputs, and at that point, the question actually
>>>>>>>>> ceases to be subjective, as it becomes, what should THAT H say
>>>>>>>>> about this input, which is back to an objective agian (since
>>>>>>>>> machines are deterministic, so the definition of H tells us
>>>>>>>>> what H will answer to that question).
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> When we go ahead and contradict this definition then the
>>>>>>>>>> *HALTING PROBLEM IS STILL WRONG IN A DIFFERENT WAY*
>>>>>>>>>
>>>>>>>>> Nope, YOU are wrong, because you
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> When D is defined to do the opposite of whatever yes/no
>>>>>>>>>> an answer that H provides then the counter-example input
>>>>>>>>>> is precisely isomorphic to the question:
>>>>>>>>>> Is this sentence: "This sentence is not true." true or false?
>>>>>>>>>> Thus that question and the HP question are both incorrect
>>>>>>>>>> because both yes and no are the wrong answer.
>>>>>>>>>
>>>>>>>>> Nope, Just shows how small your mind is.
>>>>>>>>>
>>>>>>>>> Proven elsewhere.,
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The theory of computation may be ignorant of the details of
>>>>>>>>>> how the context of who is asked a question changes the meaning
>>>>>>>>>> of this question, none-the-less this cannot be ignored.
>>>>>>>>>> It is and remains incorrect for the theory of computation
>>>>>>>>>> to ignore this.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> But the question it asks is an OBJECTIVE question that doesn't
>>>>>>>>> depend on who it is asked of.
>>>>>>>>>
>>>>>>>>
>>>>>>>> When H is asked about the behavior of a Machine that is programmed
>>>>>>>> to do the opposite of whatever it says then the context that it
>>>>>>>> is H
>>>>>>>> that is being asked is an inherent aspect of the meaning of this
>>>>>>>> question and cannot be correctly ignored.
>>>>>>>
>>>>>>> But that has nothing to do with your simulation result.
>>>>>>
>>>>>> Notice the subject line of this thread.
>>>>>> That HH is being asked an incorrect question is the second
>>>>>> way that the Halting Problem is wrong.
>>>>>>
>>>>>>> Your simulation does not even reach the part that contradict its
>>>>>>> result.
>>>>>>> Your decider even diagnoses programs as non-halting when they do
>>>>>>> not contradict the result of the decider, as in:
>>>>>>>
>>>>>>> typedef int (*ptr)(); // ptr is pointer to int function
>>>>>>> in C
>>>>>>>
>>>>>>> int H(ptr p, ptr i);
>>>>>>>
>>>>>>> int main()
>>>>>>> {
>>>>>>> H(main, 0);
>>>>>>> }
>>>>>>>
>>>>>>> It is clear that main does not programmed to do the opposite of
>>>>>>> what H says.
>>>>>>>
>>>>>>
>>>>>> *I was surprised that this worked correctly: here are the details*
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>> Output("Input_Halts = ", HH(main,(ptr)0));
>>>>>> }
>>>>>>
>>>>>> machine stack stack machine assembly
>>>>>> address address data code language
>>>>>> ======== ======== ======== ========= =============
>>>>>> [00001e42][00103375][00000000] 55 push ebp ; begin main
>>>>>> [00001e43][00103375][00000000] 8bec mov ebp,esp
>>>>>> [00001e45][00103371][00000000] 6a00 push +00
>>>>>> [00001e47][0010336d][00001e42] 68421e0000 push 00001e42 ; push main
>>>>>> [00001e4c][00103369][00001e51] e831f5ffff call 00001382 ; call HH
>>>>>> New slave_stack at:103419
>>>>>>
>>>>>> Begin Local Halt Decider Simulation Execution Trace Stored
>>>>>> at:113421
>>>>>> [00001e42][0011340d][00113411] 55 push ebp ; begin main
>>>>>> [00001e43][0011340d][00113411] 8bec mov ebp,esp
>>>>>> [00001e45][00113409][00000000] 6a00 push +00
>>>>>> [00001e47][00113405][00001e42] 68421e0000 push 00001e42 ; push main
>>>>>> [00001e4c][00113401][00001e51] e831f5ffff call 00001382 ; call HH
>>>>>> New slave_stack at:14de41
>>>>>> [00001e42][0015de35][0015de39] 55 push ebp ; begin main
>>>>>> [00001e43][0015de35][0015de39] 8bec mov ebp,esp
>>>>>> [00001e45][0015de31][00000000] 6a00 push +00
>>>>>> [00001e47][0015de2d][00001e42] 68421e0000 push 00001e42 ; push main
>>>>>> [00001e4c][0015de29][00001e51] e831f5ffff call 00001382 ; call HH
>>>>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>>>>>
>>>>>> [00001e51][00103375][00000000] 83c408 add esp,+08
>>>>>> [00001e54][00103371][00000000] 50 push eax
>>>>>> [00001e55][0010336d][00000743] 6843070000 push 00000743
>>>>>> [00001e5a][0010336d][00000743] e843e9ffff call 000007a2
>>>>>> Input_Halts = 0
>>>>>> [00001e5f][00103375][00000000] 83c408 add esp,+08
>>>>>> [00001e62][00103375][00000000] eb79 jmp 00001edd
>>>>>> [00001edd][00103375][00000000] 33c0 xor eax,eax
>>>>>> [00001edf][00103379][00000018] 5d pop ebp
>>>>>> [00001ee0][0010337d][00000000] c3 ret ; end main
>>>>>> Number of Instructions Executed(12311) == 184 Pages
>>>>>>
>>>>>> So main() does halt at its final state at [00001ee0] which proves
>>>>>> that the directly executed HH(main,(ptr)0) called by main() halts
>>>>>> and returns 0;
>>>>>>
>>>>>
>>>>> Your HH returns 0, reporting that main does not halt. So this is an
>>>>> example of how your HH produces a false negative.
>>>>
>>>> My HH returns 0 indicating that what you specified results in recursive
>>>> simulation that cannot possibly ever stop running unless aborted.
>>>>
>>>> You don't sufficiently understand the technical details of this
>>>> to verify the actual facts.
>>>>
>>>
>>> That may be a good explanation why there is a false negative. But it
>>> does not change the fact that there is a false negative.
>>> If you don't know what a false negative is:
>>> A test that returns 'no' when the reality is 'yes'.
>>> Your test returns no, the direct execution is 'yes'.
>>>
>>
>> <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>
>>
>> Try to show how this DD can be correctly simulated by any HH
>> *would stop running without having its simulation aborted*
>> thus fails to match the above criteria.
>>
>> _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
>>
>> You can't do it and if you even imply otherwise *THIS IS DECEPTION*
>>
>
> Your own proof shows that main halts.
There is no main() above thus your attempt at the
strawman deception has failed.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | immibis <news2@immibis.com> |
|---|---|
| Date | 2024-06-06 20:09 +0200 |
| Subject | Re: Halting Problem is wrong two different ways |
| Message-ID | <v3su0a$1infb$2@dont-email.me> |
| In reply to | #106418 |
On 6/06/24 18:34, Fred. Zwarts wrote: > Your own proof shows that main halts. Your own proof shows that HH > returns a non-halting result. By *definition* that is a false negative. Olcott believes that DD(DD) and the input to HH(DD,DD) are two different things, and that facts about one have absolutely no relation to the other, so he thinks this is not a false negative. He believes all three things are true: * DD(DD) halts. * The input to HH(DD,DD) doesn't halt. * HH(DD,DD) is a correct simulation of DD(DD). This is like believing that: * 2+2=4 * The input to Plus(2,2) specifies a total of 5. * Plus is a correct simulation of +
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-05 19:46 -0400 |
| Subject | Re: Halting Problem is wrong two different ways |
| Message-ID | <v3qtck$354i9$3@i2pn2.org> |
| In reply to | #106317 |
On 6/5/24 9:59 AM, olcott wrote:
> On 6/5/2024 3:11 AM, Fred. Zwarts wrote:
>> Op 05.jun.2024 om 04:05 schreef olcott:
>>> On 6/4/2024 8:48 PM, Richard Damon wrote:
>>>> On 6/4/24 1:40 PM, olcott wrote:
>>>>> On 6/4/2024 3:28 AM, Mikko wrote:
>>>>>> On 2024-06-03 18:14:39 +0000, olcott said:
>>>>>>
>>>>>>> On 6/3/2024 9:27 AM, Mikko wrote:
>>>>>>>> On 2024-06-03 12:20:01 +0000, olcott said:
>>>>>>>>
>>>>>>>>> On 6/3/2024 4:42 AM, Ben Bacarisse wrote:
>>>>>>>>>> Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
>>>>>>>>>>
>>>>>>>>>>> PO's D(D) halts, as illustrated in various traces that have
>>>>>>>>>>> been posted here.
>>>>>>>>>>> PO's H(D,D) returns 0 : [NOT halting] also as illustrated in
>>>>>>>>>>> various traces.
>>>>>>>>>>> i.e. exactly as the Linz proof claims. PO has acknowledged
>>>>>>>>>>> both these
>>>>>>>>>>> results. Same for the HH/DD variants.
>>>>>>>>>>>
>>>>>>>>>>> You might imagine that's the end of the matter - PO failed. :)
>>>>>>>>>>>
>>>>>>>>>>> That's right, but PO just carries on anyway!
>>>>>>>>>>
>>>>>>>>>> He has quite explicitly stated that false (0) is the correct
>>>>>>>>>> result for
>>>>>>>>>> H(D,D) "even though D(D) halts". I am mystified why anyone
>>>>>>>>>> continues to
>>>>>>>>>> discuss the matter until he equally explicitly repudiates that
>>>>>>>>>> claim.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Deciders only compute the mapping *from their inputs* to their own
>>>>>>>>> accept or reject state.
>>>>>>>>
>>>>>>>> That does not restrict what a problem statement can specify.
>>>>>>>> If the computed mapping differs from the specified one the
>>>>>>>> decider does not solve the problem.
>>>>>>>
>>>>>>> int sum(int x, int y) { return x + y; }
>>>>>>> sum(2,3) cannot return the sum of 5 + 6.
>>>>>>
>>>>>> That does not restrict what a problem statement can specify.
>>>>>> If the mapping computed by sum differs from the specified one
>>>>>> the program sum does not solve the problem.
>>>>>>
>>>>>
>>>>> On 6/3/2024 9:53 PM, Richard Damon wrote:
>>>>> > Because you keep on mentioning about DD Halting,
>>>>> > which IS about the direct execution of DD
>>>>>
>>>>> Only when one contradicts the definition of a decider that must
>>>>> compute the mapping FROM ITS INPUTS BASED ON THE ACTUAL BEHAVIOR
>>>>> OF THESE INPUTS (as measured by DD correctly simulated by HH).
>>>>
>>>> But strings don't HAVE "Behavior", they only represent things that do.
>>>>
>>>
>>> Turing Machine descriptions specify behavior to UTMs.
>>>
>>>> And, for a Halt decider, that thing they represent is the program,
>>>> whose direct execution specifies the proper behavior of the input.
>>>>
>>>> The DEFINITON IS NOT "as measured by DD correctly simulated by HH",
>>>> as deciders, by their definiton, are trying to compute the mapping
>>>> of their input according to a defined function, which is a function
>>>> of just that input. Since that function doesn't know which "H' is
>>>> going to try to decide on it, it can't change its answer based on
>>>> which H we ask.
>>>>
>>>> Proper Deciders can not be asked "Subjective" questions, unless we
>>>> SPECIFICALLY define the mapping to include the decider as one of the
>>>> inputs, and at that point, the question actually ceases to be
>>>> subjective, as it becomes, what should THAT H say about this input,
>>>> which is back to an objective agian (since machines are
>>>> deterministic, so the definition of H tells us what H will answer to
>>>> that question).
>>>>
>>>>>
>>>>> When we go ahead and contradict this definition then the
>>>>> *HALTING PROBLEM IS STILL WRONG IN A DIFFERENT WAY*
>>>>
>>>> Nope, YOU are wrong, because you
>>>>
>>>>>
>>>>> When D is defined to do the opposite of whatever yes/no
>>>>> an answer that H provides then the counter-example input
>>>>> is precisely isomorphic to the question:
>>>>> Is this sentence: "This sentence is not true." true or false?
>>>>> Thus that question and the HP question are both incorrect
>>>>> because both yes and no are the wrong answer.
>>>>
>>>> Nope, Just shows how small your mind is.
>>>>
>>>> Proven elsewhere.,
>>>>
>>>>>
>>>>> The theory of computation may be ignorant of the details of
>>>>> how the context of who is asked a question changes the meaning
>>>>> of this question, none-the-less this cannot be ignored.
>>>>> It is and remains incorrect for the theory of computation
>>>>> to ignore this.
>>>>>
>>>>
>>>> But the question it asks is an OBJECTIVE question that doesn't
>>>> depend on who it is asked of.
>>>>
>>>
>>> When H is asked about the behavior of a Machine that is programmed
>>> to do the opposite of whatever it says then the context that it is H
>>> that is being asked is an inherent aspect of the meaning of this
>>> question and cannot be correctly ignored.
>>
>> But that has nothing to do with your simulation result.
>
> Notice the subject line of this thread.
> That HH is being asked an incorrect question is the second
> way that the Halting Problem is wrong.
>
>> Your simulation does not even reach the part that contradict its result.
>> Your decider even diagnoses programs as non-halting when they do not
>> contradict the result of the decider, as in:
>>
>> typedef int (*ptr)(); // ptr is pointer to int function in C
>>
>> int H(ptr p, ptr i);
>>
>> int main()
>> {
>> H(main, 0);
>> }
>>
>> It is clear that main does not programmed to do the opposite of what H
>> says.
>>
>
> *I was surprised that this worked correctly: here are the details*
>
> int main()
> {
> Output("Input_Halts = ", HH(main,(ptr)0));
> }
>
> machine stack stack machine assembly
> address address data code language
> ======== ======== ======== ========= =============
> [00001e42][00103375][00000000] 55 push ebp ; begin main
> [00001e43][00103375][00000000] 8bec mov ebp,esp
> [00001e45][00103371][00000000] 6a00 push +00
> [00001e47][0010336d][00001e42] 68421e0000 push 00001e42 ; push main
> [00001e4c][00103369][00001e51] e831f5ffff call 00001382 ; call HH
> New slave_stack at:103419
>
> Begin Local Halt Decider Simulation Execution Trace Stored at:113421
> [00001e42][0011340d][00113411] 55 push ebp ; begin main
> [00001e43][0011340d][00113411] 8bec mov ebp,esp
> [00001e45][00113409][00000000] 6a00 push +00
> [00001e47][00113405][00001e42] 68421e0000 push 00001e42 ; push main
> [00001e4c][00113401][00001e51] e831f5ffff call 00001382 ; call HH
> New slave_stack at:14de41
> [00001e42][0015de35][0015de39] 55 push ebp ; begin main
> [00001e43][0015de35][0015de39] 8bec mov ebp,esp
> [00001e45][0015de31][00000000] 6a00 push +00
> [00001e47][0015de2d][00001e42] 68421e0000 push 00001e42 ; push main
> [00001e4c][0015de29][00001e51] e831f5ffff call 00001382 ; call HH
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>
> [00001e51][00103375][00000000] 83c408 add esp,+08
> [00001e54][00103371][00000000] 50 push eax
> [00001e55][0010336d][00000743] 6843070000 push 00000743
> [00001e5a][0010336d][00000743] e843e9ffff call 000007a2
> Input_Halts = 0
> [00001e5f][00103375][00000000] 83c408 add esp,+08
> [00001e62][00103375][00000000] eb79 jmp 00001edd
> [00001edd][00103375][00000000] 33c0 xor eax,eax
> [00001edf][00103379][00000018] 5d pop ebp
> [00001ee0][0010337d][00000000] c3 ret ; end main
> Number of Instructions Executed(12311) == 184 Pages
>
> So main() does halt at its final state at [00001ee0] which proves
> that the directly executed HH(main,(ptr)0) called by main() halts
> and returns 0;
>
As does main when it calls DD(DD)
So that halts.
And any simulation that says otherwise, is INCORRECT by definition.
Note, your PARTIAL simulation by HH correctly simulates each step it
simulates, and then appies INVALID LOGIC to deteremine that its input is
not halting, so the simulation correctly shows the PARTIAL behavior of
DD(DD), as far as it goes, and then HH LIES to itself to say its
simulation shows it doesn't halt.
So, HH is just wrong because it made an INVALID conclusion from
incomplete data.
[toc] | [prev] | [next] | [standalone]
| From | Mikko <mikko.levanto@iki.fi> |
|---|---|
| Date | 2024-06-06 12:02 +0300 |
| Subject | Re: Halting Problem is wrong two different ways |
| Message-ID | <v3rtuh$1eiaa$1@dont-email.me> |
| In reply to | #106317 |
On 2024-06-05 13:59:53 +0000, olcott said:
> On 6/5/2024 3:11 AM, Fred. Zwarts wrote:
>> Op 05.jun.2024 om 04:05 schreef olcott:
>>> On 6/4/2024 8:48 PM, Richard Damon wrote:
>>>> On 6/4/24 1:40 PM, olcott wrote:
>>>>> On 6/4/2024 3:28 AM, Mikko wrote:
>>>>>> On 2024-06-03 18:14:39 +0000, olcott said:
>>>>>>
>>>>>>> On 6/3/2024 9:27 AM, Mikko wrote:
>>>>>>>> On 2024-06-03 12:20:01 +0000, olcott said:
>>>>>>>>
>>>>>>>>> On 6/3/2024 4:42 AM, Ben Bacarisse wrote:
>>>>>>>>>> Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
>>>>>>>>>>
>>>>>>>>>>> PO's D(D) halts, as illustrated in various traces that have been posted here.
>>>>>>>>>>> PO's H(D,D) returns 0 : [NOT halting] also as illustrated in various traces.
>>>>>>>>>>> i.e. exactly as the Linz proof claims. PO has acknowledged both these
>>>>>>>>>>> results. Same for the HH/DD variants.
>>>>>>>>>>>
>>>>>>>>>>> You might imagine that's the end of the matter - PO failed. :)
>>>>>>>>>>>
>>>>>>>>>>> That's right, but PO just carries on anyway!
>>>>>>>>>>
>>>>>>>>>> He has quite explicitly stated that false (0) is the correct result for
>>>>>>>>>> H(D,D) "even though D(D) halts". I am mystified why anyone continues to
>>>>>>>>>> discuss the matter until he equally explicitly repudiates that claim.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Deciders only compute the mapping *from their inputs* to their own
>>>>>>>>> accept or reject state.
>>>>>>>>
>>>>>>>> That does not restrict what a problem statement can specify.
>>>>>>>> If the computed mapping differs from the specified one the
>>>>>>>> decider does not solve the problem.
>>>>>>>
>>>>>>> int sum(int x, int y) { return x + y; }
>>>>>>> sum(2,3) cannot return the sum of 5 + 6.
>>>>>>
>>>>>> That does not restrict what a problem statement can specify.
>>>>>> If the mapping computed by sum differs from the specified one
>>>>>> the program sum does not solve the problem.
>>>>>>
>>>>>
>>>>> On 6/3/2024 9:53 PM, Richard Damon wrote:
>>>>> > Because you keep on mentioning about DD Halting,
>>>>> > which IS about the direct execution of DD
>>>>>
>>>>> Only when one contradicts the definition of a decider that must
>>>>> compute the mapping FROM ITS INPUTS BASED ON THE ACTUAL BEHAVIOR
>>>>> OF THESE INPUTS (as measured by DD correctly simulated by HH).
>>>>
>>>> But strings don't HAVE "Behavior", they only represent things that do.
>>>>
>>>
>>> Turing Machine descriptions specify behavior to UTMs.
>>>
>>>> And, for a Halt decider, that thing they represent is the program,
>>>> whose direct execution specifies the proper behavior of the input.
>>>>
>>>> The DEFINITON IS NOT "as measured by DD correctly simulated by HH", as
>>>> deciders, by their definiton, are trying to compute the mapping of
>>>> their input according to a defined function, which is a function of
>>>> just that input. Since that function doesn't know which "H' is going to
>>>> try to decide on it, it can't change its answer based on which H we ask.
>>>>
>>>> Proper Deciders can not be asked "Subjective" questions, unless we
>>>> SPECIFICALLY define the mapping to include the decider as one of the
>>>> inputs, and at that point, the question actually ceases to be
>>>> subjective, as it becomes, what should THAT H say about this input,
>>>> which is back to an objective agian (since machines are deterministic,
>>>> so the definition of H tells us what H will answer to that question).
>>>>
>>>>>
>>>>> When we go ahead and contradict this definition then the
>>>>> *HALTING PROBLEM IS STILL WRONG IN A DIFFERENT WAY*
>>>>
>>>> Nope, YOU are wrong, because you
>>>>
>>>>>
>>>>> When D is defined to do the opposite of whatever yes/no
>>>>> an answer that H provides then the counter-example input
>>>>> is precisely isomorphic to the question:
>>>>> Is this sentence: "This sentence is not true." true or false?
>>>>> Thus that question and the HP question are both incorrect
>>>>> because both yes and no are the wrong answer.
>>>>
>>>> Nope, Just shows how small your mind is.
>>>>
>>>> Proven elsewhere.,
>>>>
>>>>>
>>>>> The theory of computation may be ignorant of the details of
>>>>> how the context of who is asked a question changes the meaning
>>>>> of this question, none-the-less this cannot be ignored.
>>>>> It is and remains incorrect for the theory of computation
>>>>> to ignore this.
>>>>>
>>>>
>>>> But the question it asks is an OBJECTIVE question that doesn't depend
>>>> on who it is asked of.
>>>>
>>>
>>> When H is asked about the behavior of a Machine that is programmed
>>> to do the opposite of whatever it says then the context that it is H
>>> that is being asked is an inherent aspect of the meaning of this
>>> question and cannot be correctly ignored.
>>
>> But that has nothing to do with your simulation result.
>
> Notice the subject line of this thread.
> That HH is being asked an incorrect question is the second
> way that the Halting Problem is wrong.
>
>> Your simulation does not even reach the part that contradict its result.
>> Your decider even diagnoses programs as non-halting when they do not
>> contradict the result of the decider, as in:
>>
>> typedef int (*ptr)(); // ptr is pointer to int function in C
>>
>> int H(ptr p, ptr i);
>>
>> int main()
>> {
>> H(main, 0);
>> }
>>
>> It is clear that main does not programmed to do the opposite of what H says.
>>
>
> *I was surprised that this worked correctly:
Be specific: the test of HH workeed correcty when it
correctrly demonstrated that HH woked incorrectly.
HH did not work correctly when it, just before main
halted, said that main will not
> here are the details*
>
> int main()
> {
> Output("Input_Halts = ", HH(main,(ptr)0));
> }
>
> machine stack stack machine assembly
> address address data code language
> ======== ======== ======== ========= =============
> [00001e42][00103375][00000000] 55 push ebp ; begin main
> [00001e43][00103375][00000000] 8bec mov ebp,esp
> [00001e45][00103371][00000000] 6a00 push +00
> [00001e47][0010336d][00001e42] 68421e0000 push 00001e42 ; push main
> [00001e4c][00103369][00001e51] e831f5ffff call 00001382 ; call HH
> New slave_stack at:103419
>
> Begin Local Halt Decider Simulation Execution Trace Stored at:113421
> [00001e42][0011340d][00113411] 55 push ebp ; begin main
> [00001e43][0011340d][00113411] 8bec mov ebp,esp
> [00001e45][00113409][00000000] 6a00 push +00
> [00001e47][00113405][00001e42] 68421e0000 push 00001e42 ; push main
> [00001e4c][00113401][00001e51] e831f5ffff call 00001382 ; call HH
> New slave_stack at:14de41
> [00001e42][0015de35][0015de39] 55 push ebp ; begin main
> [00001e43][0015de35][0015de39] 8bec mov ebp,esp
> [00001e45][0015de31][00000000] 6a00 push +00
> [00001e47][0015de2d][00001e42] 68421e0000 push 00001e42 ; push main
> [00001e4c][0015de29][00001e51] e831f5ffff call 00001382 ; call HH
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>
> [00001e51][00103375][00000000] 83c408 add esp,+08
> [00001e54][00103371][00000000] 50 push eax
> [00001e55][0010336d][00000743] 6843070000 push 00000743
> [00001e5a][0010336d][00000743] e843e9ffff call 000007a2
> Input_Halts = 0
Here main reports that HH said that main will not halt.
> [00001e5f][00103375][00000000] 83c408 add esp,+08
> [00001e62][00103375][00000000] eb79 jmp 00001edd
> [00001edd][00103375][00000000] 33c0 xor eax,eax
> [00001edf][00103379][00000018] 5d pop ebp
> [00001ee0][0010337d][00000000] c3 ret ; end main
Here main halts.
> Number of Instructions Executed(12311) == 184 Pages
>
> So main() does halt at its final state at [00001ee0] which proves
> that the directly executed HH(main,(ptr)0) called by main() halts
> and returns 0;
That main halts does not prove that HH returns 0 but that doesn't
mater as that was already proven right after HH returned 0.
--
Mikko
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-06 08:41 -0500 |
| Subject | Re: Halting Problem is wrong two different ways |
| Message-ID | <v3se9h$1gra7$9@dont-email.me> |
| In reply to | #106384 |
On 6/6/2024 4:02 AM, Mikko wrote:
> On 2024-06-05 13:59:53 +0000, olcott said:
>
>> On 6/5/2024 3:11 AM, Fred. Zwarts wrote:
>>> Op 05.jun.2024 om 04:05 schreef olcott:
>>>> On 6/4/2024 8:48 PM, Richard Damon wrote:
>>>>> On 6/4/24 1:40 PM, olcott wrote:
>>>>>> On 6/4/2024 3:28 AM, Mikko wrote:
>>>>>>> On 2024-06-03 18:14:39 +0000, olcott said:
>>>>>>>
>>>>>>>> On 6/3/2024 9:27 AM, Mikko wrote:
>>>>>>>>> On 2024-06-03 12:20:01 +0000, olcott said:
>>>>>>>>>
>>>>>>>>>> On 6/3/2024 4:42 AM, Ben Bacarisse wrote:
>>>>>>>>>>> Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>> PO's D(D) halts, as illustrated in various traces that have
>>>>>>>>>>>> been posted here.
>>>>>>>>>>>> PO's H(D,D) returns 0 : [NOT halting] also as illustrated in
>>>>>>>>>>>> various traces.
>>>>>>>>>>>> i.e. exactly as the Linz proof claims. PO has acknowledged
>>>>>>>>>>>> both these
>>>>>>>>>>>> results. Same for the HH/DD variants.
>>>>>>>>>>>>
>>>>>>>>>>>> You might imagine that's the end of the matter - PO failed. :)
>>>>>>>>>>>>
>>>>>>>>>>>> That's right, but PO just carries on anyway!
>>>>>>>>>>>
>>>>>>>>>>> He has quite explicitly stated that false (0) is the correct
>>>>>>>>>>> result for
>>>>>>>>>>> H(D,D) "even though D(D) halts". I am mystified why anyone
>>>>>>>>>>> continues to
>>>>>>>>>>> discuss the matter until he equally explicitly repudiates
>>>>>>>>>>> that claim.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Deciders only compute the mapping *from their inputs* to their
>>>>>>>>>> own
>>>>>>>>>> accept or reject state.
>>>>>>>>>
>>>>>>>>> That does not restrict what a problem statement can specify.
>>>>>>>>> If the computed mapping differs from the specified one the
>>>>>>>>> decider does not solve the problem.
>>>>>>>>
>>>>>>>> int sum(int x, int y) { return x + y; }
>>>>>>>> sum(2,3) cannot return the sum of 5 + 6.
>>>>>>>
>>>>>>> That does not restrict what a problem statement can specify.
>>>>>>> If the mapping computed by sum differs from the specified one
>>>>>>> the program sum does not solve the problem.
>>>>>>>
>>>>>>
>>>>>> On 6/3/2024 9:53 PM, Richard Damon wrote:
>>>>>> > Because you keep on mentioning about DD Halting,
>>>>>> > which IS about the direct execution of DD
>>>>>>
>>>>>> Only when one contradicts the definition of a decider that must
>>>>>> compute the mapping FROM ITS INPUTS BASED ON THE ACTUAL BEHAVIOR
>>>>>> OF THESE INPUTS (as measured by DD correctly simulated by HH).
>>>>>
>>>>> But strings don't HAVE "Behavior", they only represent things that do.
>>>>>
>>>>
>>>> Turing Machine descriptions specify behavior to UTMs.
>>>>
>>>>> And, for a Halt decider, that thing they represent is the program,
>>>>> whose direct execution specifies the proper behavior of the input.
>>>>>
>>>>> The DEFINITON IS NOT "as measured by DD correctly simulated by
>>>>> HH", as deciders, by their definiton, are trying to compute the
>>>>> mapping of their input according to a defined function, which is a
>>>>> function of just that input. Since that function doesn't know which
>>>>> "H' is going to try to decide on it, it can't change its answer
>>>>> based on which H we ask.
>>>>>
>>>>> Proper Deciders can not be asked "Subjective" questions, unless we
>>>>> SPECIFICALLY define the mapping to include the decider as one of
>>>>> the inputs, and at that point, the question actually ceases to be
>>>>> subjective, as it becomes, what should THAT H say about this input,
>>>>> which is back to an objective agian (since machines are
>>>>> deterministic, so the definition of H tells us what H will answer
>>>>> to that question).
>>>>>
>>>>>>
>>>>>> When we go ahead and contradict this definition then the
>>>>>> *HALTING PROBLEM IS STILL WRONG IN A DIFFERENT WAY*
>>>>>
>>>>> Nope, YOU are wrong, because you
>>>>>
>>>>>>
>>>>>> When D is defined to do the opposite of whatever yes/no
>>>>>> an answer that H provides then the counter-example input
>>>>>> is precisely isomorphic to the question:
>>>>>> Is this sentence: "This sentence is not true." true or false?
>>>>>> Thus that question and the HP question are both incorrect
>>>>>> because both yes and no are the wrong answer.
>>>>>
>>>>> Nope, Just shows how small your mind is.
>>>>>
>>>>> Proven elsewhere.,
>>>>>
>>>>>>
>>>>>> The theory of computation may be ignorant of the details of
>>>>>> how the context of who is asked a question changes the meaning
>>>>>> of this question, none-the-less this cannot be ignored.
>>>>>> It is and remains incorrect for the theory of computation
>>>>>> to ignore this.
>>>>>>
>>>>>
>>>>> But the question it asks is an OBJECTIVE question that doesn't
>>>>> depend on who it is asked of.
>>>>>
>>>>
>>>> When H is asked about the behavior of a Machine that is programmed
>>>> to do the opposite of whatever it says then the context that it is H
>>>> that is being asked is an inherent aspect of the meaning of this
>>>> question and cannot be correctly ignored.
>>>
>>> But that has nothing to do with your simulation result.
>>
>> Notice the subject line of this thread.
>> That HH is being asked an incorrect question is the second
>> way that the Halting Problem is wrong.
>>
>>> Your simulation does not even reach the part that contradict its result.
>>> Your decider even diagnoses programs as non-halting when they do not
>>> contradict the result of the decider, as in:
>>>
>>> typedef int (*ptr)(); // ptr is pointer to int function in C
>>>
>>> int H(ptr p, ptr i);
>>>
>>> int main()
>>> {
>>> H(main, 0);
>>> }
>>>
>>> It is clear that main does not programmed to do the opposite of what
>>> H says.
>>>
>>
>> *I was surprised that this worked correctly:
>
> Be specific: the test of HH workeed correcty when it
> correctrly demonstrated that HH woked incorrectly.
> HH did not work correctly when it, just before main
> halted, said that main will not
>
>> here are the details*
>>
>> int main()
>> {
>> Output("Input_Halts = ", HH(main,(ptr)0));
>> }
>>
>> machine stack stack machine assembly
>> address address data code language
>> ======== ======== ======== ========= =============
>> [00001e42][00103375][00000000] 55 push ebp ; begin main
>> [00001e43][00103375][00000000] 8bec mov ebp,esp
>> [00001e45][00103371][00000000] 6a00 push +00
>> [00001e47][0010336d][00001e42] 68421e0000 push 00001e42 ; push main
>> [00001e4c][00103369][00001e51] e831f5ffff call 00001382 ; call HH
>> New slave_stack at:103419
>>
>> Begin Local Halt Decider Simulation Execution Trace Stored at:113421
>> [00001e42][0011340d][00113411] 55 push ebp ; begin main
>> [00001e43][0011340d][00113411] 8bec mov ebp,esp
>> [00001e45][00113409][00000000] 6a00 push +00
>> [00001e47][00113405][00001e42] 68421e0000 push 00001e42 ; push main
>> [00001e4c][00113401][00001e51] e831f5ffff call 00001382 ; call HH
>> New slave_stack at:14de41
>> [00001e42][0015de35][0015de39] 55 push ebp ; begin main
>> [00001e43][0015de35][0015de39] 8bec mov ebp,esp
>> [00001e45][0015de31][00000000] 6a00 push +00
>> [00001e47][0015de2d][00001e42] 68421e0000 push 00001e42 ; push main
>> [00001e4c][0015de29][00001e51] e831f5ffff call 00001382 ; call HH
>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>
>> [00001e51][00103375][00000000] 83c408 add esp,+08
>> [00001e54][00103371][00000000] 50 push eax
>> [00001e55][0010336d][00000743] 6843070000 push 00000743
>> [00001e5a][0010336d][00000743] e843e9ffff call 000007a2
>> Input_Halts = 0
>
> Here main reports that HH said that main will not halt.
>
>> [00001e5f][00103375][00000000] 83c408 add esp,+08
>> [00001e62][00103375][00000000] eb79 jmp 00001edd
>> [00001edd][00103375][00000000] 33c0 xor eax,eax
>> [00001edf][00103379][00000018] 5d pop ebp
>> [00001ee0][0010337d][00000000] c3 ret ; end main
>
> Here main halts.
>
>> Number of Instructions Executed(12311) == 184 Pages
>>
>> So main() does halt at its final state at [00001ee0] which proves
>> that the directly executed HH(main,(ptr)0) called by main() halts
>> and returns 0;
>
> That main halts does not prove that HH returns 0 but that doesn't
> mater as that was already proven right after HH returned 0.
>
*Your failure to understand the correctness of these words is noted*
*Your failure to understand the correctness of these words is noted*
*Your failure to understand the correctness of these words is noted*
<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>
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Mikko <mikko.levanto@iki.fi> |
|---|---|
| Date | 2024-06-06 18:07 +0300 |
| Subject | Re: Halting Problem is wrong two different ways |
| Message-ID | <v3sjao$1i80h$1@dont-email.me> |
| In reply to | #106398 |
On 2024-06-06 13:41:05 +0000, olcott said:
> On 6/6/2024 4:02 AM, Mikko wrote:
>> On 2024-06-05 13:59:53 +0000, olcott said:
>>
>>> On 6/5/2024 3:11 AM, Fred. Zwarts wrote:
>>>> Op 05.jun.2024 om 04:05 schreef olcott:
>>>>> On 6/4/2024 8:48 PM, Richard Damon wrote:
>>>>>> On 6/4/24 1:40 PM, olcott wrote:
>>>>>>> On 6/4/2024 3:28 AM, Mikko wrote:
>>>>>>>> On 2024-06-03 18:14:39 +0000, olcott said:
>>>>>>>>
>>>>>>>>> On 6/3/2024 9:27 AM, Mikko wrote:
>>>>>>>>>> On 2024-06-03 12:20:01 +0000, olcott said:
>>>>>>>>>>
>>>>>>>>>>> On 6/3/2024 4:42 AM, Ben Bacarisse wrote:
>>>>>>>>>>>> Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
>>>>>>>>>>>>
>>>>>>>>>>>>> PO's D(D) halts, as illustrated in various traces that have been posted here.
>>>>>>>>>>>>> PO's H(D,D) returns 0 : [NOT halting] also as illustrated in various traces.
>>>>>>>>>>>>> i.e. exactly as the Linz proof claims. PO has acknowledged both these
>>>>>>>>>>>>> results. Same for the HH/DD variants.
>>>>>>>>>>>>>
>>>>>>>>>>>>> You might imagine that's the end of the matter - PO failed. :)
>>>>>>>>>>>>>
>>>>>>>>>>>>> That's right, but PO just carries on anyway!
>>>>>>>>>>>>
>>>>>>>>>>>> He has quite explicitly stated that false (0) is the correct result for
>>>>>>>>>>>> H(D,D) "even though D(D) halts". I am mystified why anyone continues to
>>>>>>>>>>>> discuss the matter until he equally explicitly repudiates that claim.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Deciders only compute the mapping *from their inputs* to their own
>>>>>>>>>>> accept or reject state.
>>>>>>>>>>
>>>>>>>>>> That does not restrict what a problem statement can specify.
>>>>>>>>>> If the computed mapping differs from the specified one the
>>>>>>>>>> decider does not solve the problem.
>>>>>>>>>
>>>>>>>>> int sum(int x, int y) { return x + y; }
>>>>>>>>> sum(2,3) cannot return the sum of 5 + 6.
>>>>>>>>
>>>>>>>> That does not restrict what a problem statement can specify.
>>>>>>>> If the mapping computed by sum differs from the specified one
>>>>>>>> the program sum does not solve the problem.
>>>>>>>>
>>>>>>>
>>>>>>> On 6/3/2024 9:53 PM, Richard Damon wrote:
>>>>>>> > Because you keep on mentioning about DD Halting,
>>>>>>> > which IS about the direct execution of DD
>>>>>>>
>>>>>>> Only when one contradicts the definition of a decider that must
>>>>>>> compute the mapping FROM ITS INPUTS BASED ON THE ACTUAL BEHAVIOR
>>>>>>> OF THESE INPUTS (as measured by DD correctly simulated by HH).
>>>>>>
>>>>>> But strings don't HAVE "Behavior", they only represent things that do.
>>>>>>
>>>>>
>>>>> Turing Machine descriptions specify behavior to UTMs.
>>>>>
>>>>>> And, for a Halt decider, that thing they represent is the program,
>>>>>> whose direct execution specifies the proper behavior of the input.
>>>>>>
>>>>>> The DEFINITON IS NOT "as measured by DD correctly simulated by HH", as
>>>>>> deciders, by their definiton, are trying to compute the mapping of
>>>>>> their input according to a defined function, which is a function of
>>>>>> just that input. Since that function doesn't know which "H' is going to
>>>>>> try to decide on it, it can't change its answer based on which H we ask.
>>>>>>
>>>>>> Proper Deciders can not be asked "Subjective" questions, unless we
>>>>>> SPECIFICALLY define the mapping to include the decider as one of the
>>>>>> inputs, and at that point, the question actually ceases to be
>>>>>> subjective, as it becomes, what should THAT H say about this input,
>>>>>> which is back to an objective agian (since machines are deterministic,
>>>>>> so the definition of H tells us what H will answer to that question).
>>>>>>
>>>>>>>
>>>>>>> When we go ahead and contradict this definition then the
>>>>>>> *HALTING PROBLEM IS STILL WRONG IN A DIFFERENT WAY*
>>>>>>
>>>>>> Nope, YOU are wrong, because you
>>>>>>
>>>>>>>
>>>>>>> When D is defined to do the opposite of whatever yes/no
>>>>>>> an answer that H provides then the counter-example input
>>>>>>> is precisely isomorphic to the question:
>>>>>>> Is this sentence: "This sentence is not true." true or false?
>>>>>>> Thus that question and the HP question are both incorrect
>>>>>>> because both yes and no are the wrong answer.
>>>>>>
>>>>>> Nope, Just shows how small your mind is.
>>>>>>
>>>>>> Proven elsewhere.,
>>>>>>
>>>>>>>
>>>>>>> The theory of computation may be ignorant of the details of
>>>>>>> how the context of who is asked a question changes the meaning
>>>>>>> of this question, none-the-less this cannot be ignored.
>>>>>>> It is and remains incorrect for the theory of computation
>>>>>>> to ignore this.
>>>>>>>
>>>>>>
>>>>>> But the question it asks is an OBJECTIVE question that doesn't depend
>>>>>> on who it is asked of.
>>>>>>
>>>>>
>>>>> When H is asked about the behavior of a Machine that is programmed
>>>>> to do the opposite of whatever it says then the context that it is H
>>>>> that is being asked is an inherent aspect of the meaning of this
>>>>> question and cannot be correctly ignored.
>>>>
>>>> But that has nothing to do with your simulation result.
>>>
>>> Notice the subject line of this thread.
>>> That HH is being asked an incorrect question is the second
>>> way that the Halting Problem is wrong.
>>>
>>>> Your simulation does not even reach the part that contradict its result.
>>>> Your decider even diagnoses programs as non-halting when they do not
>>>> contradict the result of the decider, as in:
>>>>
>>>> typedef int (*ptr)(); // ptr is pointer to int function in C
>>>>
>>>> int H(ptr p, ptr i);
>>>>
>>>> int main()
>>>> {
>>>> H(main, 0);
>>>> }
>>>>
>>>> It is clear that main does not programmed to do the opposite of what H says.
>>>>
>>>
>>> *I was surprised that this worked correctly:
>>
>> Be specific: the test of HH workeed correcty when it
>> correctrly demonstrated that HH woked incorrectly.
>> HH did not work correctly when it, just before main
>> halted, said that main will not
>>
>>> here are the details*
>>>
>>> int main()
>>> {
>>> Output("Input_Halts = ", HH(main,(ptr)0));
>>> }
>>>
>>> machine stack stack machine assembly
>>> address address data code language
>>> ======== ======== ======== ========= =============
>>> [00001e42][00103375][00000000] 55 push ebp ; begin main
>>> [00001e43][00103375][00000000] 8bec mov ebp,esp
>>> [00001e45][00103371][00000000] 6a00 push +00
>>> [00001e47][0010336d][00001e42] 68421e0000 push 00001e42 ; push main
>>> [00001e4c][00103369][00001e51] e831f5ffff call 00001382 ; call HH
>>> New slave_stack at:103419
>>>
>>> Begin Local Halt Decider Simulation Execution Trace Stored at:113421
>>> [00001e42][0011340d][00113411] 55 push ebp ; begin main
>>> [00001e43][0011340d][00113411] 8bec mov ebp,esp
>>> [00001e45][00113409][00000000] 6a00 push +00
>>> [00001e47][00113405][00001e42] 68421e0000 push 00001e42 ; push main
>>> [00001e4c][00113401][00001e51] e831f5ffff call 00001382 ; call HH
>>> New slave_stack at:14de41
>>> [00001e42][0015de35][0015de39] 55 push ebp ; begin main
>>> [00001e43][0015de35][0015de39] 8bec mov ebp,esp
>>> [00001e45][0015de31][00000000] 6a00 push +00
>>> [00001e47][0015de2d][00001e42] 68421e0000 push 00001e42 ; push main
>>> [00001e4c][0015de29][00001e51] e831f5ffff call 00001382 ; call HH
>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>>
>>> [00001e51][00103375][00000000] 83c408 add esp,+08
>>> [00001e54][00103371][00000000] 50 push eax
>>> [00001e55][0010336d][00000743] 6843070000 push 00000743
>>> [00001e5a][0010336d][00000743] e843e9ffff call 000007a2
>>> Input_Halts = 0
>>
>> Here main reports that HH said that main will not halt.
>>
>>> [00001e5f][00103375][00000000] 83c408 add esp,+08
>>> [00001e62][00103375][00000000] eb79 jmp 00001edd
>>> [00001edd][00103375][00000000] 33c0 xor eax,eax
>>> [00001edf][00103379][00000018] 5d pop ebp
>>> [00001ee0][0010337d][00000000] c3 ret ; end main
>>
>> Here main halts.
>>
>>> Number of Instructions Executed(12311) == 184 Pages
>>>
>>> So main() does halt at its final state at [00001ee0] which proves
>>> that the directly executed HH(main,(ptr)0) called by main() halts
>>> and returns 0;
>>
>> That main halts does not prove that HH returns 0 but that doesn't
>> mater as that was already proven right after HH returned 0.
>>
>
> *Your failure to understand the correctness of these words is noted*
> *Your failure to understand the correctness of these words is noted*
> *Your failure to understand the correctness of these words is noted*
What makes you think that I failed to notice the correctness
of my words? Or is "those" intended to point to something else?
> <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>
But did not agree with your claim that there is an error in his proof.
--
Mikko
[toc] | [prev] | [next] | [standalone]
Page 4 of 17 — ← Prev page 1 2 3 [4] 5 6 … 17 Next page →
Back to top | Article view | comp.theory
csiph-web