Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > sci.logic > #334952 > unrolled thread
| Started by | immibis <news@immibis.com> |
|---|---|
| First post | 2024-06-03 02:16 +0200 |
| Last post | 2024-06-04 17:25 +0200 |
| Articles | 20 on this page of 172 — 13 participants |
Back to article view | Back to sci.logic
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? wij <wyniijj5@gmail.com> - 2024-06-03 09:06 +0800
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 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? wij <wyniijj5@gmail.com> - 2024-06-03 12:11 +0800
Re: Why does Olcott care about simulation, anyway? wij <wyniijj5@gmail.com> - 2024-06-03 12:11 +0800
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 "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 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 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 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 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 Richard Damon <richard@damon-family.org> - 2024-06-04 21:48 -0400
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 olcott <polcott333@gmail.com> - 2024-06-06 10:31 -0500
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 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 --- 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 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 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 ---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? 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 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 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 ---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
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 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 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 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 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 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 immibis <news@immibis.com> - 2024-06-07 16:25 +0200
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
Page 8 of 9 — ← Prev page 1 2 3 4 5 6 7 [8] 9 Next page →
| 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 | #335161 |
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 | #335162 |
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 | #335163 |
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 | #335163 |
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 | #335096 |
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 | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-05 08:18 -0500 |
| Subject | Re: Halting Problem is wrong two different ways |
| Message-ID | <v3poj0$v133$6@dont-email.me> |
| In reply to | #335046 |
On 6/5/2024 2:13 AM, Mikko wrote:
> On 2024-06-04 17:40:47 +0000, olcott said:
>
>> 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).
>>
>> When we go ahead and contradict this definition then the
>> *HALTING PROBLEM IS STILL WRONG IN A DIFFERENT WAY*
>>
>> 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.
>>
>> 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.
>
> Nice to see that you don't disagree with my observation that
> your statement
>
>>>>>> Deciders only compute the mapping *from their inputs* to their own
>>>>>> accept or reject state.
>
> does not restrict what a problem statement can specify.
>
Sure it does.
int sum(int x, int y) { return x + y; }
sum(3,4) cannot correctly return the sum of 5 + 6.
H(D,D) cannot possibly return the halt status of D(D) because
D calls H in recursive simulation thus forcing the behavior of
D correctly simulated by H to be different than the behavior of
the directly executed D(D).
Requiring H(D,D) to return the halt status of D(D) is exactly
the same as requiring sum(3,4) to return the sum of 5 + 6.
*This unequivocally proves the behavior of DD correctly simulated by HH*
https://liarparadox.org/DD_correctly_simulated_by_HH_is_Proven.pdf
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | joes <noreply@example.com> |
|---|---|
| Date | 2024-06-05 18:25 +0000 |
| Subject | Re: Halting Problem is wrong two different ways |
| Message-ID | <v3qai9$34b9u$12@i2pn2.org> |
| In reply to | #335091 |
Am Wed, 05 Jun 2024 08:18:24 -0500 schrieb olcott:
> On 6/5/2024 2:13 AM, Mikko wrote:
>> On 2024-06-04 17:40:47 +0000, olcott said:
>>> 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:
>> Nice to see that you don't disagree with my observation that your
>> statement
>>>>>>> Deciders only compute the mapping *from their inputs* to their own
>>>>>>> accept or reject state.
>> does not restrict what a problem statement can specify.
>>
> Sure it does.
> int sum(int x, int y) { return x + y; }
> sum(3,4) cannot correctly return the sum of 5 + 6.
>
> H(D,D) cannot possibly return the halt status of D(D) because D calls H
> in recursive simulation thus forcing the behavior of D correctly
> simulated by H to be different than the behavior of the directly
> executed D(D).
Then D is not a simulator.
> Requiring H(D,D) to return the halt status of D(D) is exactly the same
> as requiring sum(3,4) to return the sum of 5 + 6.
Uh, what? Wasn't H specified to return exactly that?
--
joes
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-05 19:51 -0400 |
| Subject | Re: Halting Problem is wrong two different ways |
| Message-ID | <v3qtld$354ia$2@i2pn2.org> |
| In reply to | #335091 |
On 6/5/24 9:18 AM, olcott wrote: > H(D,D) cannot possibly return the halt status of D(D) because > D calls H in recursive simulation thus forcing the behavior of > D correctly simulated by H to be different than the behavior of > the directly executed D(D). So, you admit that HH can not actualy be a Halt Decider if it can not correctly return that halt status of the machine described by its input, which is the task of a halt Decide > > Requiring H(D,D) to return the halt status of D(D) is exactly > the same as requiring sum(3,4) to return the sum of 5 + 6. Nope, because H WAS given D, and D as input, so needs to answer about D(D). Sum(3, 4) was not given 5 and 6 as input, so shouldn't answer about those, but that is EXACTLY what you say H should be doing, when H is asked aobut H(D,D) where D calls that H, you say H shoudl actualanswer about D'(D') as if it was called as H(D',D') where D' is built from a DIFFERENT decider H', that doesn't abort. > > *This unequivocally proves the behavior of DD correctly simulated by HH* > https://liarparadox.org/DD_correctly_simulated_by_HH_is_Proven.pdf > > Nope, you are just proving that you are nothing but a pathological liar with a reckless disregard for the truth.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-07 09:09 -0500 |
| Subject | Re: Halting Problem is wrong two different ways |
| Message-ID | <v3v4bi$22vrk$7@dont-email.me> |
| In reply to | #335091 |
On 6/7/2024 1:22 AM, Mikko wrote: > On 2024-06-06 15:18:21 +0000, olcott said: >> >> *Here is that problem statement* >> Prove that sum(3,4) is incorrect on the basis that >> sum(3,4) cannot and does not provide the sum of 5 + 6. > > That problem statement does not restrict what another > problem statement may specify. > It is an analogy. All halt deciders are only allowed to report on the actual behavior of their actual input. I have proven right here that the actual behavior of the actual input is that it remains stuck in recursive simulation. Try any show how this DD can be correctly simulated by any HH such that this DD reaches past its machine address [00001dbe] _DD() [00001e12] 55 push ebp [00001e13] 8bec mov ebp,esp [00001e15] 51 push ecx [00001e16] 8b4508 mov eax,[ebp+08] [00001e19] 50 push eax ; push DD [00001e1a] 8b4d08 mov ecx,[ebp+08] [00001e1d] 51 push ecx ; push DD [00001e1e] e85ff5ffff call 00001382 ; call HH I proved that I am correct and no one even looks at this proof, that is NOT AN HONEST DIALOGUE. The above proof proves that DD is correctly simulated by HH and DD simulated by HH DOES MEET the Sipser approve criteria. <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> If simulating halt decider H correctly simulates its input D until H correctly determines that its simulated D would never stop running unless aborted then H can abort its simulation of D and correctly report that D specifies a non-halting sequence of configurations. </MIT Professor Sipser agreed to ONLY these verbatim words10/13/2022> Professor Sipser <is> the author of the best selling theory of computation textbook. *Introduction to the Theory of Computation, by Michael Sipser* https://www.amazon.com/Introduction-Theory-Computation-Michael-Sipser/dp/113318779X/ -- Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-07 11:14 -0400 |
| Subject | Re: Halting Problem is wrong two different ways |
| Message-ID | <v3v845$39ri5$6@i2pn2.org> |
| In reply to | #335200 |
On 6/7/24 10:09 AM, olcott wrote: > On 6/7/2024 1:22 AM, Mikko wrote: >> On 2024-06-06 15:18:21 +0000, olcott said: >>> >>> *Here is that problem statement* >>> Prove that sum(3,4) is incorrect on the basis that >>> sum(3,4) cannot and does not provide the sum of 5 + 6. >> >> That problem statement does not restrict what another >> problem statement may specify. >> > > It is an analogy. > > All halt deciders are only allowed to report on the actual > behavior of their actual input. Right, which is DEFINED to be the behavior of the machine that the input describes. > > I have proven right here that the actual behavior of the actual > input is that it remains stuck in recursive simulation. Nope. > > Try any show how this DD can be correctly simulated by any HH > such that this DD reaches past its machine address [00001dbe] Why, the two are not equivalent, unless HH doesn't ever abort, and then it isn't a decider. As has been pointed out, partial simulation not reaching a final state doesn't say anything about the input not halting. You also seem to forget that to ask what H does, H is at that point a SPECIFIC machine, as only machines have "behavior", not sets of machines. (We might be able to find the common behaviors of the set, after we establish the behavior of the individual machines in the set). > > _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 > > I proved that I am correct and no one even looks > at this proof, that is NOT AN HONEST DIALOGUE. Nope, you proved you don't know what you are talking about, and that you don't know how to actually present a proof. > > The above proof proves that DD is correctly simulated by HH > and DD simulated by HH DOES MEET the Sipser approve criteria. And were is the "Proof" per the ruls of a formal system. What well establish facts were you basing your logic on. What trurh preserving operations did you apply to those well establish facts? YOu have made a argument, as done in more abstract philosophy of you claims, which just isn't a proof. Probably because you just don't understand what PROOF actually means. > > <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> > If simulating halt decider H correctly simulates its input D > until H correctly determines that its simulated D would never > stop running unless aborted then > > H can abort its simulation of D and correctly report that D > specifies a non-halting sequence of configurations. > </MIT Professor Sipser agreed to ONLY these verbatim words10/13/2022> And to Professor Sipser, "Correct" as in Correct Simulation, means a simulation that carries all the way to the final state and reveals the actual behavior of the machine whose description is being simulated. Trying to apply ANY different meaning just shows you to be a deceptive liar, (which you do). THIS H (and that is the only machine that is H her) does NOT correctly simulate its input, since it WILL abort it, so that clause can not apply, H doesn't even correctly predict what an actual correct simulation (even if it doesn't do it) does, so you can't even generalize the statement, Ultimately, your logic fails, because you change the input with slight of hand when you try to evaluate different Hs, which breaks your logic, as the question is about THIS input, not some non-input that is just a chameleon. > > Professor Sipser <is> the author of the best selling theory of > computation textbook. > > *Introduction to the Theory of Computation, by Michael Sipser* > https://www.amazon.com/Introduction-Theory-Computation-Michael-Sipser/dp/113318779X/ > >
[toc] | [prev] | [next] | [standalone]
| From | immibis <news@immibis.com> |
|---|---|
| Date | 2024-06-07 16:25 +0200 |
| Subject | Re: Halting Problem is wrong two different ways |
| Message-ID | <v3v597$1o9el$2@dont-email.me> |
| In reply to | #335091 |
On 5/06/24 15:18, olcott wrote:
> On 6/5/2024 2:13 AM, Mikko wrote:
>> On 2024-06-04 17:40:47 +0000, olcott said:
>>
>> Nice to see that you don't disagree with my observation that
>> your statement
>>
>>>>>>> Deciders only compute the mapping *from their inputs* to their own
>>>>>>> accept or reject state.
>>
>> does not restrict what a problem statement can specify.
>>
>
> Sure it does.
> int sum(int x, int y) { return x + y; }
> sum(3,4) cannot correctly return the sum of 5 + 6.
According to you, the correct simulation simulate(sum,3,4) can correctly
return the sum of 5+6.
[toc] | [prev] | [next] | [standalone]
| From | Mike Terry <news.dead.person.stones@darjeeling.plus.com> |
|---|---|
| Date | 2024-06-03 17:58 +0100 |
| Message-ID | <B7ycneJbccrZa8D7nZ2dnZfqn_qdnZ2d@brightview.co.uk> |
| In reply to | #334970 |
On 03/06/2024 10:42, 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. > >> So really, there's no /need/ to "refute" everything he says - the end >> result will be exactly the same as just ignoring him, BUT WITH THE LATTER >> ONLY NEEDING 0.1% OF THE EFFORT and eliminating 99.9% of the posting >> clutter in these newsgroups. [ok, comp.theory will die pretty quickly, but >> it is not discussing anything useful, so that's ok for most people... (with >> some reluctance)] > > Do we know that? There's the start of a discussion of quines on > comp.lang.c that probably belongs here, but no will dare come here to > discuss it because of all the junk. I'd like to think that comp.theory could continue without PO. That would be great but let's face it there aren't too many people around with questions or suggestions about computing theory, and with the GG links severed there will be less new blood finding the group in future. I saw the quine thread last night, but haven't thought about it much yet. My first thought was aren't quines supposed to be about a specific programming language like C where the executable is generated purely from compiling the C code? Malcolm has presumably embedded his source folder as a binary resource in his executable, and the executable just extracts that resource and "prints" it. If that counted as a quine then quines would be pretty unchallenging, hence more thought needed (like how did his source folder get "compiled" into his quine executable? and for me, what /exactly/ is a quine? I'm not clear on that when you move beyond a single compiler to entire tool sets that produce a program... Such a toolset can simply copy the source to some location accessible to the program [like a binary resource inside the executable] and the program can just access it and print it out?). Anyway the C and C++ groups have healthy traffic regardless of PO, so will carry on - at least as long as the current crowd are around. I still think the break with GG will ultimately cut off new posters who would have encountered the group via GG, so the long term future is not good, but that's some way off. Mike.
[toc] | [prev] | [next] | [standalone]
| From | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2024-06-03 09:58 +0200 |
| Message-ID | <v3jt2s$3qblu$1@dont-email.me> |
| In reply to | #334952 |
Op 03.jun.2024 om 02:16 schreef immibis: > The halting problem says you can't find a Turing machine that tells > whether executing each other Turing machine will halt. Simulation has > nothing to do with the question. Maybe because by using simulation he can shift the attention from the pathological part of the Linz proof, to another halting problem, namely that a simulating decider does not halt because it causes infinite recursion. His own claim that D does not reach the pathological part (after line 03), displays already that the simulation is unable to process the pathological part. But the simulation introduces a new halting problem (recursive simulation), which he thinks is an answer for the original halting problem.
[toc] | [prev] | [next] | [standalone]
| From | Mike Terry <news.dead.person.stones@darjeeling.plus.com> |
|---|---|
| Date | 2024-06-03 18:36 +0100 |
| Message-ID | <HlGdnbvc3Ly_YsD7nZ2dnZfqn_adnZ2d@brightview.co.uk> |
| In reply to | #334968 |
On 03/06/2024 08:58, Fred. Zwarts wrote: > Op 03.jun.2024 om 02:16 schreef immibis: >> The halting problem says you can't find a Turing machine that tells whether executing each other >> Turing machine will halt. Simulation has nothing to do with the question. > > Maybe because by using simulation he can shift the attention from the pathological part of the Linz > proof, to another halting problem, namely that a simulating decider does not halt because it causes > infinite recursion. PO's simulating decider does not cause infinite recursion. That only occurs in the case where the decider performs a FULL simulation of its input, whereas typically for PO his H/HH/... perform PARTIAL simulations, where the decider monitors what is being simulated and breaks off the simulation when a particular condition is observed. So yes, there is recursive simulation, but not /infinite/ recursion since at each level of simulation the simulator is free to just stop simulating at any time. In practice this means that the outer simulator H will be the one to break out, since it will always be ahead of all the inner simulations of H in how far it has progressed. This situation is in contrast with direct call recursion, where the outer caller has no control to break the recursion - it only regains control once the inner calls have all returned. PO does not properly understand this distinction. > > His own claim that D does not reach the pathological part (after line 03), displays already that the > simulation is unable to process the pathological part. But the simulation introduces a new halting > problem (recursive simulation), which he thinks is an answer for the original halting problem. You're using PO's phrase "pathological" but that is a bad (misleading) term because it suggests there is something WRONG/BAD (aka sick?) in the situation. E.g. H processing input which is a description of its own source code. There is nothing whatsoever wrong with that - it's just that PO gets confused by it and so argues to ban it. Perhaps there is an alternative term that doesn't have the deliberate connotation of "sickness". Mike.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-03 13:03 -0500 |
| Message-ID | <v3l0i0$5d3$2@dont-email.me> |
| In reply to | #334984 |
On 6/3/2024 12:36 PM, Mike Terry wrote: > On 03/06/2024 08:58, Fred. Zwarts wrote: >> Op 03.jun.2024 om 02:16 schreef immibis: >>> The halting problem says you can't find a Turing machine that tells >>> whether executing each other Turing machine will halt. Simulation has >>> nothing to do with the question. >> >> Maybe because by using simulation he can shift the attention from the >> pathological part of the Linz proof, to another halting problem, >> namely that a simulating decider does not halt because it causes >> infinite recursion. > > PO's simulating decider does not cause infinite recursion. That only > occurs in the case where the decider performs a FULL simulation of its > input, whereas typically for PO his H/HH/... perform PARTIAL > simulations, where the decider monitors what is being simulated and > breaks off the simulation when a particular condition is observed. > Thanks for affirming that. You are my most technically competent and honest reviewer. > So yes, there is recursive simulation, but not /infinite/ recursion > since at each level of simulation the simulator is free to just stop > simulating at any time. In practice this means that the outer simulator > H will be the one to break out, since it will always be ahead of all the > inner simulations of H in how far it has progressed. This situation is > in contrast with direct call recursion, where the outer caller has no > control to break the recursion - it only regains control once the inner > calls have all returned. > > PO does not properly understand this distinction. > *You can keep ignoring this that does not make it go away* On 10/13/2022 11:29:23 AM MIT Professor Michael Sipser agreed this verbatim paragraph is correct (He has neither reviewed nor agreed to anything else in this paper) <Professor Sipser agreed> If simulating halt decider H correctly simulates its input D until H correctly determines that its simulated D would never stop running unless aborted then H can abort its simulation of D and correctly report that D specifies a non-halting sequence of configurations. </Professor Sipser agreed> *You can ignore the above forever, that does not make it away* >> >> His own claim that D does not reach the pathological part (after line >> 03), displays already that the simulation is unable to process the >> pathological part. But the simulation introduces a new halting problem >> (recursive simulation), which he thinks is an answer for the original >> halting problem. > > You're using PO's phrase "pathological" but that is a bad (misleading) > term because it suggests there is something WRONG/BAD (aka sick?) in the > situation. E.g. H processing input which is a description of its own > source code. There is nothing whatsoever wrong with that - it's just > that PO gets confused by it and so argues to ban it. Perhaps there is > an alternative term that doesn't have the deliberate connotation of > "sickness". > > Mike. > *Two PhD computer science professors disagree* E C R Hehner. *Problems with the Halting Problem*, COMPUTING2011 Symposium on 75 years of Turing Machine and Lambda-Calculus, Karlsruhe Germany, invited, 2011 October 20-21; Advances in Computer Science and Engineering v.10 n.1 p.31-60, 2013 https://www.cs.toronto.edu/~hehner/PHP.pdf E C R Hehner. *Objective and Subjective Specifications* WST Workshop on Termination, Oxford. 2018 July 18. See https://www.cs.toronto.edu/~hehner/OSS.pdf Bill Stoddart. *The Halting Paradox* 20 December 2017 https://arxiv.org/abs/1906.05340 arXiv:1906.05340 [cs.LO] *You can ignore the above forever, that does not make it away* -- 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 | Mike Terry <news.dead.person.stones@darjeeling.plus.com> |
|---|---|
| Date | 2024-06-03 19:56 +0100 |
| Message-ID | <lBmcnX-HlodbjMP7nZ2dnZfqn_idnZ2d@brightview.co.uk> |
| In reply to | #334986 |
On 03/06/2024 19:03, olcott wrote: > On 6/3/2024 12:36 PM, Mike Terry wrote: >> On 03/06/2024 08:58, Fred. Zwarts wrote: >>> Op 03.jun.2024 om 02:16 schreef immibis: >>>> The halting problem says you can't find a Turing machine that tells whether executing each other >>>> Turing machine will halt. Simulation has nothing to do with the question. >>> >>> Maybe because by using simulation he can shift the attention from the pathological part of the >>> Linz proof, to another halting problem, namely that a simulating decider does not halt because it >>> causes infinite recursion. >> >> PO's simulating decider does not cause infinite recursion. That only occurs in the case where the >> decider performs a FULL simulation of its input, whereas typically for PO his H/HH/... perform >> PARTIAL simulations, where the decider monitors what is being simulated and breaks off the >> simulation when a particular condition is observed. >> > > Thanks for affirming that. You are my most technically > competent and honest reviewer. > >> So yes, there is recursive simulation, but not /infinite/ recursion since at each level of >> simulation the simulator is free to just stop simulating at any time. In practice this means that >> the outer simulator H will be the one to break out, since it will always be ahead of all the inner >> simulations of H in how far it has progressed. This situation is in contrast with direct call >> recursion, where the outer caller has no control to break the recursion - it only regains control >> once the inner calls have all returned. >> >> PO does not properly understand this distinction. >> > > *You can keep ignoring this that does not make it go away* > > On 10/13/2022 11:29:23 AM > MIT Professor Michael Sipser agreed this verbatim paragraph is correct > (He has neither reviewed nor agreed to anything else in this paper) > > <Professor Sipser agreed> > If simulating halt decider H correctly simulates its input D until H > correctly determines that its simulated D would never stop running > unless aborted then > > H can abort its simulation of D and correctly report that D specifies a > non-halting sequence of configurations. > </Professor Sipser agreed> > > *You can ignore the above forever, that does not make it away* I do not ignore the above. I recently posted an example of it: a simulating HD correctly reporting non-halting after detecting a tight loop in the computation represented by its input. The problem with the above is with YOU. (You misinterpret/misapply what Sipser says.) And of course your entire purpose behind quoting the above is just an appeal to authority. You know that's a fallacy, because from time to time you accuse others of doing it. > >>> >>> His own claim that D does not reach the pathological part (after line 03), displays already that >>> the simulation is unable to process the pathological part. But the simulation introduces a new >>> halting problem (recursive simulation), which he thinks is an answer for the original halting >>> problem. >> >> You're using PO's phrase "pathological" but that is a bad (misleading) term because it suggests >> there is something WRONG/BAD (aka sick?) in the situation. E.g. H processing input which is a >> description of its own source code. There is nothing whatsoever wrong with that - it's just that >> PO gets confused by it and so argues to ban it. Perhaps there is an alternative term that >> doesn't have the deliberate connotation of "sickness". >> >> Mike. >> > > *Two PhD computer science professors disagree* > > E C R Hehner. *Problems with the Halting Problem*, COMPUTING2011 Symposium on 75 years of Turing > Machine and Lambda-Calculus, Karlsruhe Germany, invited, 2011 October 20-21; Advances in Computer > Science and Engineering v.10 n.1 p.31-60, 2013 > https://www.cs.toronto.edu/~hehner/PHP.pdf > > E C R Hehner. *Objective and Subjective Specifications* > WST Workshop on Termination, Oxford. 2018 July 18. > See https://www.cs.toronto.edu/~hehner/OSS.pdf > > Bill Stoddart. *The Halting Paradox* > 20 December 2017 > https://arxiv.org/abs/1906.05340 > arXiv:1906.05340 [cs.LO] > > *You can ignore the above forever, that does not make it away* > Well, it kinda DOES. This is just a blatant appeal to authority on your part, so it can rightly be ignored. I'll say again - if you have some argument to make, argue it yourself in your own words rather than attempting to shut down discussion through appeal to authority. [Perhaps Hehner/Stoddart are just idiots who got things wrong, or much more likely you've completely misinterpreted what they're saying, or you've misunderstood the context or whatever and you are the idiot. The bottom line is THEY ARE NOT HERE ARGUING ANY CASE SO WHAT YOU SAY THEY BELIEVE IS TOTALLY IRRELEVANT. And there's no need for anyone to get into discussions over whether it is Hehner/Stoddart or yourself who is confused...] Mike.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-03 14:26 -0500 |
| Subject | Re: Why does Olcott care about simulation, anyway? --- woeful ignorance |
| Message-ID | <v3l5cc$tom$2@dont-email.me> |
| In reply to | #334987 |
On 6/3/2024 1:56 PM, Mike Terry wrote: > On 03/06/2024 19:03, olcott wrote: >> On 6/3/2024 12:36 PM, Mike Terry wrote: >>> On 03/06/2024 08:58, Fred. Zwarts wrote: >>>> Op 03.jun.2024 om 02:16 schreef immibis: >>>>> The halting problem says you can't find a Turing machine that tells >>>>> whether executing each other Turing machine will halt. Simulation >>>>> has nothing to do with the question. >>>> >>>> Maybe because by using simulation he can shift the attention from >>>> the pathological part of the Linz proof, to another halting problem, >>>> namely that a simulating decider does not halt because it causes >>>> infinite recursion. >>> >>> PO's simulating decider does not cause infinite recursion. That only >>> occurs in the case where the decider performs a FULL simulation of >>> its input, whereas typically for PO his H/HH/... perform PARTIAL >>> simulations, where the decider monitors what is being simulated and >>> breaks off the simulation when a particular condition is observed. >>> >> >> Thanks for affirming that. You are my most technically >> competent and honest reviewer. >> >>> So yes, there is recursive simulation, but not /infinite/ recursion >>> since at each level of simulation the simulator is free to just stop >>> simulating at any time. In practice this means that the outer >>> simulator H will be the one to break out, since it will always be >>> ahead of all the inner simulations of H in how far it has >>> progressed. This situation is in contrast with direct call >>> recursion, where the outer caller has no control to break the >>> recursion - it only regains control once the inner calls have all >>> returned. >>> >>> PO does not properly understand this distinction. >>> >> >> *You can keep ignoring this that does not make it go away* >> >> On 10/13/2022 11:29:23 AM >> MIT Professor Michael Sipser agreed this verbatim paragraph is correct >> (He has neither reviewed nor agreed to anything else in this paper) >> >> <Professor Sipser agreed> >> If simulating halt decider H correctly simulates its input D until H >> correctly determines that its simulated D would never stop running >> unless aborted then >> >> H can abort its simulation of D and correctly report that D specifies a >> non-halting sequence of configurations. >> </Professor Sipser agreed> >> >> *You can ignore the above forever, that does not make it away* > > I do not ignore the above. I recently posted an example of it: a > simulating HD correctly reporting non-halting after detecting a tight > loop in the computation represented by its input. > > The problem with the above is with YOU. (You misinterpret/misapply what > Sipser says.) > > And of course your entire purpose behind quoting the above is just an > appeal to authority. You know that's a fallacy, because from time to > time you accuse others of doing it. > I knew that these exact words were exactly correct about a year before I asked professor Sipser to review them. That you say that I misinterpret them without proving the reasoning behind this give me no basis to correct your incorrect understanding. So far I have shown the error of everyone that tried to explain the details of how they believe that I misinterpreted my own words. >> >>>> >>>> His own claim that D does not reach the pathological part (after >>>> line 03), displays already that the simulation is unable to process >>>> the pathological part. But the simulation introduces a new halting >>>> problem (recursive simulation), which he thinks is an answer for the >>>> original halting problem. >>> >>> You're using PO's phrase "pathological" but that is a bad >>> (misleading) term because it suggests there is something WRONG/BAD >>> (aka sick?) in the situation. E.g. H processing input which is a >>> description of its own source code. There is nothing whatsoever >>> wrong with that - it's just that PO gets confused by it and so argues >>> to ban it. Perhaps there is an alternative term that doesn't have >>> the deliberate connotation of "sickness". >>> >>> Mike. >>> >> >> *Two PhD computer science professors disagree* >> >> E C R Hehner. *Problems with the Halting Problem*, COMPUTING2011 >> Symposium on 75 years of Turing Machine and Lambda-Calculus, Karlsruhe >> Germany, invited, 2011 October 20-21; Advances in Computer Science and >> Engineering v.10 n.1 p.31-60, 2013 >> https://www.cs.toronto.edu/~hehner/PHP.pdf >> >> E C R Hehner. *Objective and Subjective Specifications* >> WST Workshop on Termination, Oxford. 2018 July 18. >> See https://www.cs.toronto.edu/~hehner/OSS.pdf >> >> Bill Stoddart. *The Halting Paradox* >> 20 December 2017 >> https://arxiv.org/abs/1906.05340 >> arXiv:1906.05340 [cs.LO] >> >> *You can ignore the above forever, that does not make it away* >> > > Well, it kinda DOES. This is just a blatant appeal to authority on your > part, so it can rightly be ignored. I'll say again - if you have some > argument to make, argue it yourself in your own words rather than > attempting to shut down discussion through appeal to authority. > It proves that I am not a crackpot. > [Perhaps Hehner/Stoddart are just idiots who got things wrong, or much > more likely you've completely misinterpreted what they're saying, or > you've misunderstood the context or whatever and you are the idiot. The > bottom line is THEY ARE NOT HERE ARGUING ANY CASE SO WHAT YOU SAY THEY > BELIEVE IS TOTALLY IRRELEVANT. And there's no need for anyone to get > into discussions over whether it is Hehner/Stoddart or yourself who is > confused...] > > > Mike. > The issue that I and professor Hehner agree on is that incorrect questions have no correct answer only because the question itself is incorrect. He does not call them incorrect questions. The halting problem proof counter-example is essentially a question that has the same form as the Liar Paradox when posed to a specific machine. That this machine cannot answer this question is only because both yes and no are the wrong answer from this machine. The theory of computation is woefully ignorant of context in linguistics, thus anchored in this woeful ignorance TOC simply assumes that the context of who (which machine) is asked the (halting) question is irrelevant. Because of this woeful ignorance TOC does not notice that the halting question about an input that does the opposite of whatever value this machine returns is never construed as an incorrect question. -- 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 | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-03 19:47 -0500 |
| Message-ID | <v3lo7l$3sil$1@dont-email.me> |
| In reply to | #334987 |
On 6/3/2024 1:56 PM, Mike Terry wrote:
> On 03/06/2024 19:03, olcott wrote:
>> On 6/3/2024 12:36 PM, Mike Terry wrote:
>>> On 03/06/2024 08:58, Fred. Zwarts wrote:
>>>> Op 03.jun.2024 om 02:16 schreef immibis:
>>>>> The halting problem says you can't find a Turing machine that tells
>>>>> whether executing each other Turing machine will halt. Simulation
>>>>> has nothing to do with the question.
>>>>
>>>> Maybe because by using simulation he can shift the attention from
>>>> the pathological part of the Linz proof, to another halting problem,
>>>> namely that a simulating decider does not halt because it causes
>>>> infinite recursion.
>>>
>>> PO's simulating decider does not cause infinite recursion. That only
>>> occurs in the case where the decider performs a FULL simulation of
>>> its input, whereas typically for PO his H/HH/... perform PARTIAL
>>> simulations, where the decider monitors what is being simulated and
>>> breaks off the simulation when a particular condition is observed.
>>>
>>
>> Thanks for affirming that. You are my most technically
>> competent and honest reviewer.
>>
>>> So yes, there is recursive simulation, but not /infinite/ recursion
>>> since at each level of simulation the simulator is free to just stop
>>> simulating at any time. In practice this means that the outer
>>> simulator H will be the one to break out, since it will always be
>>> ahead of all the inner simulations of H in how far it has
>>> progressed. This situation is in contrast with direct call
>>> recursion, where the outer caller has no control to break the
>>> recursion - it only regains control once the inner calls have all
>>> returned.
>>>
>>> PO does not properly understand this distinction.
>>>
>>
>> *You can keep ignoring this that does not make it go away*
>>
>> On 10/13/2022 11:29:23 AM
>> MIT Professor Michael Sipser agreed this verbatim paragraph is correct
>> (He has neither reviewed nor agreed to anything else in this paper)
>>
>> <Professor Sipser agreed>
>> If simulating halt decider H correctly simulates its input D until H
>> correctly determines that its simulated D would never stop running
>> unless aborted then
>>
>> H can abort its simulation of D and correctly report that D specifies a
>> non-halting sequence of configurations.
>> </Professor Sipser agreed>
>>
>> *You can ignore the above forever, that does not make it away*
>
> I do not ignore the above. I recently posted an example of it: a
> simulating HD correctly reporting non-halting after detecting a tight
> loop in the computation represented by its input.
>
> The problem with the above is with YOU. (You misinterpret/misapply what
> Sipser says.)
>
> And of course your entire purpose behind quoting the above is just an
> appeal to authority. You know that's a fallacy, because from time to
> time you accuse others of doing it.
>
>>
>>>>
>>>> His own claim that D does not reach the pathological part (after
>>>> line 03), displays already that the simulation is unable to process
>>>> the pathological part. But the simulation introduces a new halting
>>>> problem (recursive simulation), which he thinks is an answer for the
>>>> original halting problem.
>>>
>>> You're using PO's phrase "pathological" but that is a bad
>>> (misleading) term because it suggests there is something WRONG/BAD
>>> (aka sick?) in the situation. E.g. H processing input which is a
>>> description of its own source code. There is nothing whatsoever
>>> wrong with that - it's just that PO gets confused by it and so argues
>>> to ban it. Perhaps there is an alternative term that doesn't have
>>> the deliberate connotation of "sickness".
>>>
>>> Mike.
>>>
>>
>> *Two PhD computer science professors disagree*
>>
>> E C R Hehner. *Problems with the Halting Problem*, COMPUTING2011
>> Symposium on 75 years of Turing Machine and Lambda-Calculus, Karlsruhe
>> Germany, invited, 2011 October 20-21; Advances in Computer Science and
>> Engineering v.10 n.1 p.31-60, 2013
>> https://www.cs.toronto.edu/~hehner/PHP.pdf
>>
>> E C R Hehner. *Objective and Subjective Specifications*
>> WST Workshop on Termination, Oxford. 2018 July 18.
>> See https://www.cs.toronto.edu/~hehner/OSS.pdf
>>
>> Bill Stoddart. *The Halting Paradox*
>> 20 December 2017
>> https://arxiv.org/abs/1906.05340
>> arXiv:1906.05340 [cs.LO]
>>
>> *You can ignore the above forever, that does not make it away*
>>
>
> Well, it kinda DOES. This is just a blatant appeal to authority on your
> part, so it can rightly be ignored. I'll say again - if you have some
> argument to make, argue it yourself in your own words rather than
> attempting to shut down discussion through appeal to authority.
>
*Those were my verbatim words that professor Sipser agreed to*
All the people that tried to show how I misinterpreted my own words
utterly failed.
Those that claimed Professor Sipser understood my words differently than
I did had only one basis that I remember being presented that is easily
proven false. *They tried to get away with contradicting this*
DD correctly emulated by any HH that can possibly exist DOES NOT HALT
DD correctly emulated by any HH that can possibly exist DOES NOT HALT
DD correctly emulated by any HH that can possibly exist DOES NOT HALT
typedef int (*ptr)(); // ptr is pointer to int function in C
00 int HH(ptr p, ptr i);
01 int DD(ptr p)
02 {
03 int Halt_Status = HH(p, p);
04 if (Halt_Status)
05 HERE: goto HERE;
06 return Halt_Status;
07 }
_DD()
[00001c22] 55 push ebp
[00001c23] 8bec mov ebp,esp
[00001c25] 51 push ecx
[00001c26] 8b4508 mov eax,[ebp+08]
[00001c29] 50 push eax ; push DD 1c22
[00001c2a] 8b4d08 mov ecx,[ebp+08]
[00001c2d] 51 push ecx ; push DD 1c22
[00001c2e] e80ff7ffff call 00001342 ; call HH
[00001c33] 83c408 add esp,+08
[00001c36] 8945fc mov [ebp-04],eax
[00001c39] 837dfc00 cmp dword [ebp-04],+00
[00001c3d] 7402 jz 00001c41
[00001c3f] ebfe jmp 00001c3f
[00001c41] 8b45fc mov eax,[ebp-04]
[00001c44] 8be5 mov esp,ebp
[00001c46] 5d pop ebp
[00001c47] c3 ret
Size in bytes:(0038) [00001c47]
> [Perhaps Hehner/Stoddart are just idiots who got things wrong, or much
> more likely you've completely misinterpreted what they're saying, or
> you've misunderstood the context or whatever and you are the idiot. The
> bottom line is THEY ARE NOT HERE ARGUING ANY CASE SO WHAT YOU SAY THEY
> BELIEVE IS TOTALLY IRRELEVANT. And there's no need for anyone to get
> into discussions over whether it is Hehner/Stoddart or yourself who is
> confused...]
>
>
> Mike.
>
After many extensive conversations with professor Hehner:
His most relevant belief is that the halting problem cannot
be solved because there is something wrong with it.
Professor Hehner: Yes, I would sign that statement.
*My concise summation of the error*
The way that the halting problem is conventionally understood is that H
must correctly answer yes or no to an input that contradicts both
answers, thus H is being asked a question isomorphic to the Liar
Paradox: Is this sentence true or false: "This sentence is not true." ?
Professor Hehner got to something very much like that in his 2018 paper
with his Carol's question. https://www.cs.toronto.edu/~hehner/OSS.pdf
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-03 20:59 -0400 |
| Message-ID | <v3lots$2uv04$14@i2pn2.org> |
| In reply to | #334994 |
On 6/3/24 8:47 PM, olcott wrote:
> On 6/3/2024 1:56 PM, Mike Terry wrote:
>> On 03/06/2024 19:03, olcott wrote:
>>> On 6/3/2024 12:36 PM, Mike Terry wrote:
>>>> On 03/06/2024 08:58, Fred. Zwarts wrote:
>>>>> Op 03.jun.2024 om 02:16 schreef immibis:
>>>>>> The halting problem says you can't find a Turing machine that
>>>>>> tells whether executing each other Turing machine will halt.
>>>>>> Simulation has nothing to do with the question.
>>>>>
>>>>> Maybe because by using simulation he can shift the attention from
>>>>> the pathological part of the Linz proof, to another halting
>>>>> problem, namely that a simulating decider does not halt because it
>>>>> causes infinite recursion.
>>>>
>>>> PO's simulating decider does not cause infinite recursion. That
>>>> only occurs in the case where the decider performs a FULL simulation
>>>> of its input, whereas typically for PO his H/HH/... perform PARTIAL
>>>> simulations, where the decider monitors what is being simulated and
>>>> breaks off the simulation when a particular condition is observed.
>>>>
>>>
>>> Thanks for affirming that. You are my most technically
>>> competent and honest reviewer.
>>>
>>>> So yes, there is recursive simulation, but not /infinite/ recursion
>>>> since at each level of simulation the simulator is free to just stop
>>>> simulating at any time. In practice this means that the outer
>>>> simulator H will be the one to break out, since it will always be
>>>> ahead of all the inner simulations of H in how far it has
>>>> progressed. This situation is in contrast with direct call
>>>> recursion, where the outer caller has no control to break the
>>>> recursion - it only regains control once the inner calls have all
>>>> returned.
>>>>
>>>> PO does not properly understand this distinction.
>>>>
>>>
>>> *You can keep ignoring this that does not make it go away*
>>>
>>> On 10/13/2022 11:29:23 AM
>>> MIT Professor Michael Sipser agreed this verbatim paragraph is correct
>>> (He has neither reviewed nor agreed to anything else in this paper)
>>>
>>> <Professor Sipser agreed>
>>> If simulating halt decider H correctly simulates its input D until H
>>> correctly determines that its simulated D would never stop running
>>> unless aborted then
>>>
>>> H can abort its simulation of D and correctly report that D specifies a
>>> non-halting sequence of configurations.
>>> </Professor Sipser agreed>
>>>
>>> *You can ignore the above forever, that does not make it away*
>>
>> I do not ignore the above. I recently posted an example of it: a
>> simulating HD correctly reporting non-halting after detecting a tight
>> loop in the computation represented by its input.
>>
>> The problem with the above is with YOU. (You misinterpret/misapply
>> what Sipser says.)
>>
>> And of course your entire purpose behind quoting the above is just an
>> appeal to authority. You know that's a fallacy, because from time to
>> time you accuse others of doing it.
>>
>>>
>>>>>
>>>>> His own claim that D does not reach the pathological part (after
>>>>> line 03), displays already that the simulation is unable to process
>>>>> the pathological part. But the simulation introduces a new halting
>>>>> problem (recursive simulation), which he thinks is an answer for
>>>>> the original halting problem.
>>>>
>>>> You're using PO's phrase "pathological" but that is a bad
>>>> (misleading) term because it suggests there is something WRONG/BAD
>>>> (aka sick?) in the situation. E.g. H processing input which is a
>>>> description of its own source code. There is nothing whatsoever
>>>> wrong with that - it's just that PO gets confused by it and so
>>>> argues to ban it. Perhaps there is an alternative term that
>>>> doesn't have the deliberate connotation of "sickness".
>>>>
>>>> Mike.
>>>>
>>>
>>> *Two PhD computer science professors disagree*
>>>
>>> E C R Hehner. *Problems with the Halting Problem*, COMPUTING2011
>>> Symposium on 75 years of Turing Machine and Lambda-Calculus,
>>> Karlsruhe Germany, invited, 2011 October 20-21; Advances in Computer
>>> Science and Engineering v.10 n.1 p.31-60, 2013
>>> https://www.cs.toronto.edu/~hehner/PHP.pdf
>>>
>>> E C R Hehner. *Objective and Subjective Specifications*
>>> WST Workshop on Termination, Oxford. 2018 July 18.
>>> See https://www.cs.toronto.edu/~hehner/OSS.pdf
>>>
>>> Bill Stoddart. *The Halting Paradox*
>>> 20 December 2017
>>> https://arxiv.org/abs/1906.05340
>>> arXiv:1906.05340 [cs.LO]
>>>
>>> *You can ignore the above forever, that does not make it away*
>>>
>>
>> Well, it kinda DOES. This is just a blatant appeal to authority on
>> your part, so it can rightly be ignored. I'll say again - if you have
>> some argument to make, argue it yourself in your own words rather than
>> attempting to shut down discussion through appeal to authority.
>>
>
> *Those were my verbatim words that professor Sipser agreed to*
> All the people that tried to show how I misinterpreted my own words
> utterly failed.
>
> Those that claimed Professor Sipser understood my words differently than
> I did had only one basis that I remember being presented that is easily
> proven false. *They tried to get away with contradicting this*
>
> DD correctly emulated by any HH that can possibly exist DOES NOT HALT
> DD correctly emulated by any HH that can possibly exist DOES NOT HALT
> DD correctly emulated by any HH that can possibly exist DOES NOT HALT
It does.
Has been proven.
You just don't know the meaning of the words you are using.
DD(DD) HALTS if HH(DD,DD) returns 0, and for your design, the only other
case is an HH that isn't a decider.
What you actually seem to be claiming is that no HH can correctly
simulate the DD built on it to a final state, or equivalently, No HH can
prove that the DD built on it will Halt.
Neither of these show that DD doesn't Halt, only that HH's simulation
can't get there.
>
> typedef int (*ptr)(); // ptr is pointer to int function in C
> 00 int HH(ptr p, ptr i);
> 01 int DD(ptr p)
> 02 {
> 03 int Halt_Status = HH(p, p);
> 04 if (Halt_Status)
> 05 HERE: goto HERE;
> 06 return Halt_Status;
> 07 }
>
> _DD()
> [00001c22] 55 push ebp
> [00001c23] 8bec mov ebp,esp
> [00001c25] 51 push ecx
> [00001c26] 8b4508 mov eax,[ebp+08]
> [00001c29] 50 push eax ; push DD 1c22
> [00001c2a] 8b4d08 mov ecx,[ebp+08]
> [00001c2d] 51 push ecx ; push DD 1c22
> [00001c2e] e80ff7ffff call 00001342 ; call HH
> [00001c33] 83c408 add esp,+08
> [00001c36] 8945fc mov [ebp-04],eax
> [00001c39] 837dfc00 cmp dword [ebp-04],+00
> [00001c3d] 7402 jz 00001c41
> [00001c3f] ebfe jmp 00001c3f
> [00001c41] 8b45fc mov eax,[ebp-04]
> [00001c44] 8be5 mov esp,ebp
> [00001c46] 5d pop ebp
> [00001c47] c3 ret
> Size in bytes:(0038) [00001c47]
>
>> [Perhaps Hehner/Stoddart are just idiots who got things wrong, or much
>> more likely you've completely misinterpreted what they're saying, or
>> you've misunderstood the context or whatever and you are the idiot.
>> The bottom line is THEY ARE NOT HERE ARGUING ANY CASE SO WHAT YOU SAY
>> THEY BELIEVE IS TOTALLY IRRELEVANT. And there's no need for anyone to
>> get into discussions over whether it is Hehner/Stoddart or yourself
>> who is confused...]
>>
>>
>> Mike.
>>
>
> After many extensive conversations with professor Hehner:
> His most relevant belief is that the halting problem cannot
> be solved because there is something wrong with it.
>
> Professor Hehner: Yes, I would sign that statement.
>
> *My concise summation of the error*
> The way that the halting problem is conventionally understood is that H
> must correctly answer yes or no to an input that contradicts both
> answers, thus H is being asked a question isomorphic to the Liar
> Paradox: Is this sentence true or false: "This sentence is not true." ?
>
> Professor Hehner got to something very much like that in his 2018 paper
> with his Carol's question. https://www.cs.toronto.edu/~hehner/OSS.pdf
>
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-03 20:05 -0500 |
| Message-ID | <v3lp8g$43oa$2@dont-email.me> |
| In reply to | #335000 |
On 6/3/2024 7:59 PM, Richard Damon wrote:
> On 6/3/24 8:47 PM, olcott wrote:
>> On 6/3/2024 1:56 PM, Mike Terry wrote:
>>> On 03/06/2024 19:03, olcott wrote:
>>>> On 6/3/2024 12:36 PM, Mike Terry wrote:
>>>>> On 03/06/2024 08:58, Fred. Zwarts wrote:
>>>>>> Op 03.jun.2024 om 02:16 schreef immibis:
>>>>>>> The halting problem says you can't find a Turing machine that
>>>>>>> tells whether executing each other Turing machine will halt.
>>>>>>> Simulation has nothing to do with the question.
>>>>>>
>>>>>> Maybe because by using simulation he can shift the attention from
>>>>>> the pathological part of the Linz proof, to another halting
>>>>>> problem, namely that a simulating decider does not halt because it
>>>>>> causes infinite recursion.
>>>>>
>>>>> PO's simulating decider does not cause infinite recursion. That
>>>>> only occurs in the case where the decider performs a FULL
>>>>> simulation of its input, whereas typically for PO his H/HH/...
>>>>> perform PARTIAL simulations, where the decider monitors what is
>>>>> being simulated and breaks off the simulation when a particular
>>>>> condition is observed.
>>>>>
>>>>
>>>> Thanks for affirming that. You are my most technically
>>>> competent and honest reviewer.
>>>>
>>>>> So yes, there is recursive simulation, but not /infinite/ recursion
>>>>> since at each level of simulation the simulator is free to just
>>>>> stop simulating at any time. In practice this means that the outer
>>>>> simulator H will be the one to break out, since it will always be
>>>>> ahead of all the inner simulations of H in how far it has
>>>>> progressed. This situation is in contrast with direct call
>>>>> recursion, where the outer caller has no control to break the
>>>>> recursion - it only regains control once the inner calls have all
>>>>> returned.
>>>>>
>>>>> PO does not properly understand this distinction.
>>>>>
>>>>
>>>> *You can keep ignoring this that does not make it go away*
>>>>
>>>> On 10/13/2022 11:29:23 AM
>>>> MIT Professor Michael Sipser agreed this verbatim paragraph is correct
>>>> (He has neither reviewed nor agreed to anything else in this paper)
>>>>
>>>> <Professor Sipser agreed>
>>>> If simulating halt decider H correctly simulates its input D until H
>>>> correctly determines that its simulated D would never stop running
>>>> unless aborted then
>>>>
>>>> H can abort its simulation of D and correctly report that D specifies a
>>>> non-halting sequence of configurations.
>>>> </Professor Sipser agreed>
>>>>
>>>> *You can ignore the above forever, that does not make it away*
>>>
>>> I do not ignore the above. I recently posted an example of it: a
>>> simulating HD correctly reporting non-halting after detecting a tight
>>> loop in the computation represented by its input.
>>>
>>> The problem with the above is with YOU. (You misinterpret/misapply
>>> what Sipser says.)
>>>
>>> And of course your entire purpose behind quoting the above is just an
>>> appeal to authority. You know that's a fallacy, because from time to
>>> time you accuse others of doing it.
>>>
>>>>
>>>>>>
>>>>>> His own claim that D does not reach the pathological part (after
>>>>>> line 03), displays already that the simulation is unable to
>>>>>> process the pathological part. But the simulation introduces a new
>>>>>> halting problem (recursive simulation), which he thinks is an
>>>>>> answer for the original halting problem.
>>>>>
>>>>> You're using PO's phrase "pathological" but that is a bad
>>>>> (misleading) term because it suggests there is something WRONG/BAD
>>>>> (aka sick?) in the situation. E.g. H processing input which is a
>>>>> description of its own source code. There is nothing whatsoever
>>>>> wrong with that - it's just that PO gets confused by it and so
>>>>> argues to ban it. Perhaps there is an alternative term that
>>>>> doesn't have the deliberate connotation of "sickness".
>>>>>
>>>>> Mike.
>>>>>
>>>>
>>>> *Two PhD computer science professors disagree*
>>>>
>>>> E C R Hehner. *Problems with the Halting Problem*, COMPUTING2011
>>>> Symposium on 75 years of Turing Machine and Lambda-Calculus,
>>>> Karlsruhe Germany, invited, 2011 October 20-21; Advances in Computer
>>>> Science and Engineering v.10 n.1 p.31-60, 2013
>>>> https://www.cs.toronto.edu/~hehner/PHP.pdf
>>>>
>>>> E C R Hehner. *Objective and Subjective Specifications*
>>>> WST Workshop on Termination, Oxford. 2018 July 18.
>>>> See https://www.cs.toronto.edu/~hehner/OSS.pdf
>>>>
>>>> Bill Stoddart. *The Halting Paradox*
>>>> 20 December 2017
>>>> https://arxiv.org/abs/1906.05340
>>>> arXiv:1906.05340 [cs.LO]
>>>>
>>>> *You can ignore the above forever, that does not make it away*
>>>>
>>>
>>> Well, it kinda DOES. This is just a blatant appeal to authority on
>>> your part, so it can rightly be ignored. I'll say again - if you
>>> have some argument to make, argue it yourself in your own words
>>> rather than attempting to shut down discussion through appeal to
>>> authority.
>>>
>>
>> *Those were my verbatim words that professor Sipser agreed to*
>> All the people that tried to show how I misinterpreted my own words
>> utterly failed.
>>
>> Those that claimed Professor Sipser understood my words differently than
>> I did had only one basis that I remember being presented that is easily
>> proven false. *They tried to get away with contradicting this*
>>
>> DD correctly emulated by any HH that can possibly exist DOES NOT HALT
>> DD correctly emulated by any HH that can possibly exist DOES NOT HALT
>> DD correctly emulated by any HH that can possibly exist DOES NOT HALT
>
> It does.
>
> Has been proven.
>
*I say that you know you are a liar until after you show the steps*
typedef int (*ptr)(); // ptr is pointer to int function in C
00 int HH(ptr p, ptr i);
01 int DD(ptr p)
02 {
03 int Halt_Status = HH(p, p);
04 if (Halt_Status)
05 HERE: goto HERE;
06 return Halt_Status;
07 }
_DD()
[00001c22] 55 push ebp
[00001c23] 8bec mov ebp,esp
[00001c25] 51 push ecx
[00001c26] 8b4508 mov eax,[ebp+08]
[00001c29] 50 push eax ; push DD 1c22
[00001c2a] 8b4d08 mov ecx,[ebp+08]
[00001c2d] 51 push ecx ; push DD 1c22
[00001c2e] e80ff7ffff call 00001342 ; call HH
[00001c33] 83c408 add esp,+08
[00001c36] 8945fc mov [ebp-04],eax
[00001c39] 837dfc00 cmp dword [ebp-04],+00
[00001c3d] 7402 jz 00001c41
[00001c3f] ebfe jmp 00001c3f
[00001c41] 8b45fc mov eax,[ebp-04]
[00001c44] 8be5 mov esp,ebp
[00001c46] 5d pop ebp
[00001c47] c3 ret
Size in bytes:(0038) [00001c47]
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
Page 8 of 9 — ← Prev page 1 2 3 4 5 6 7 [8] 9 Next page →
Back to top | Article view | sci.logic
csiph-web