Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.theory > #107301 > unrolled thread
| Started by | olcott <polcott333@gmail.com> |
|---|---|
| First post | 2024-06-16 22:33 -0500 |
| Last post | 2024-06-18 22:16 -0400 |
| Articles | 20 on this page of 169 — 7 participants |
Back to article view | Back to comp.theory
Simulating termination analyzers for dummies olcott <polcott333@gmail.com> - 2024-06-16 22:33 -0500
Re: Simulating termination analyzers for dummies "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-17 10:31 +0200
Re: Simulating termination analyzers for dummies olcott <polcott333@gmail.com> - 2024-06-17 07:20 -0500
Re: Simulating termination analyzers for dummies "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-17 15:30 +0200
Re: Simulating termination analyzers for dummies olcott <polcott333@gmail.com> - 2024-06-17 08:47 -0500
Re: Simulating termination analyzers for dummies "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-17 16:18 +0200
Re: Simulating termination analyzers for dummies olcott <polcott333@gmail.com> - 2024-06-17 09:34 -0500
Re: Simulating termination analyzers for dummies "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-17 16:49 +0200
Re: Simulating termination analyzers for dummies olcott <polcott333@gmail.com> - 2024-06-17 10:56 -0500
Re: Simulating termination analyzers for dummies "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-18 09:57 +0200
Re: Simulating termination analyzers for dummies olcott <polcott333@gmail.com> - 2024-06-18 07:38 -0500
Re: Simulating termination analyzers for dummies Python <python@invalid.org> - 2024-06-18 14:42 +0200
Re: Simulating termination analyzers for dummies olcott <polcott333@gmail.com> - 2024-06-18 08:34 -0500
Re: Simulating termination analyzers for dummies Richard Damon <richard@damon-family.org> - 2024-06-18 22:16 -0400
Re: Simulating termination analyzers for dummies "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-18 17:20 +0200
Re: Simulating termination analyzers for dummies olcott <polcott333@gmail.com> - 2024-06-18 10:33 -0500
Re: Simulating termination analyzers for dummies "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-18 17:47 +0200
Re: Simulating termination analyzers for dummies olcott <polcott333@gmail.com> - 2024-06-18 11:26 -0500
Re: Simulating termination analyzers for dummies Python <python@invalid.org> - 2024-06-18 18:28 +0200
Re: Simulating termination analyzers for dummies olcott <polcott333@gmail.com> - 2024-06-18 11:34 -0500
Re: Simulating termination analyzers for dummies "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-19 10:08 +0200
Re: Simulating termination analyzers for dummies olcott <polcott333@gmail.com> - 2024-06-19 08:00 -0500
Re: Simulating termination analyzers for dummies "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-19 15:56 +0200
Re: Simulating termination analyzers for dummies olcott <polcott333@gmail.com> - 2024-06-19 10:01 -0500
Re: Simulating termination analyzers for dummies "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-19 17:47 +0200
Re: Simulating termination analyzers for dummies olcott <polcott333@gmail.com> - 2024-06-19 11:08 -0500
Re: Simulating termination analyzers for dummies "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-20 10:17 +0200
Re: Simulating termination analyzers for dummies Richard Damon <richard@damon-family.org> - 2024-06-19 20:23 -0400
Re: Simulating termination analyzers for dummies olcott <polcott333@gmail.com> - 2024-06-19 19:44 -0500
Re: Simulating termination analyzers for dummies Richard Damon <richard@damon-family.org> - 2024-06-19 21:39 -0400
Re: Simulating termination analyzers for dummies olcott <polcott333@gmail.com> - 2024-06-19 21:02 -0500
Re: Simulating termination analyzers for dummies Richard Damon <richard@damon-family.org> - 2024-06-19 22:17 -0400
Re: Simulating termination analyzers for dummies olcott <polcott333@gmail.com> - 2024-06-19 21:25 -0500
Re: Simulating termination analyzers for dummies Richard Damon <richard@damon-family.org> - 2024-06-20 07:33 -0400
Re: Simulating termination analyzers for dummies olcott <polcott333@gmail.com> - 2024-06-20 09:58 -0500
Re: Simulating termination analyzers for dummies Richard Damon <richard@damon-family.org> - 2024-06-20 21:55 -0400
Re: Simulating termination analyzers for dummies joes <noreply@example.com> - 2024-06-20 22:48 +0000
Re: Simulating termination analyzers for dummies olcott <polcott333@gmail.com> - 2024-06-20 17:52 -0500
Re: Simulating termination analyzers for dummies joes <noreply@example.com> - 2024-06-20 23:05 +0000
Re: Simulating termination analyzers for dummies olcott <polcott333@gmail.com> - 2024-06-20 18:09 -0500
Re: Simulating termination analyzers for dummies Richard Damon <richard@damon-family.org> - 2024-06-20 21:55 -0400
Re: Simulating termination analyzers for dummies olcott <polcott333@gmail.com> - 2024-06-20 21:29 -0500
Re: Simulating termination analyzers for dummies Richard Damon <richard@damon-family.org> - 2024-06-20 22:43 -0400
Re: Simulating termination analyzers for dummies Mikko <mikko.levanto@iki.fi> - 2024-06-20 08:17 +0300
Re: Simulating termination analyzers for dummies olcott <polcott333@gmail.com> - 2024-06-20 00:22 -0500
Re: Simulating termination analyzers for dummies Richard Damon <richard@damon-family.org> - 2024-06-20 07:33 -0400
Re: Simulating termination analyzers for dummies Mikko <mikko.levanto@iki.fi> - 2024-06-20 17:54 +0300
Re: Simulating termination analyzers for dummies olcott <polcott333@gmail.com> - 2024-06-20 10:06 -0500
Re: Simulating termination analyzers for dummies Richard Damon <richard@damon-family.org> - 2024-06-20 21:55 -0400
Re: Simulating termination analyzers for dummies Python <python@invalid.org> - 2024-06-18 17:56 +0200
Re: Simulating termination analyzers for dummies olcott <polcott333@gmail.com> - 2024-06-18 11:29 -0500
Re: Simulating termination analyzers for dummies Richard Damon <richard@damon-family.org> - 2024-06-18 22:16 -0400
Re: Simulating termination analyzers for dummies Richard Damon <richard@damon-family.org> - 2024-06-18 22:16 -0400
Re: Simulating termination analyzers for dummies Richard Damon <richard@damon-family.org> - 2024-06-17 18:42 -0400
Re: Simulating termination analyzers for dummies olcott <polcott333@gmail.com> - 2024-06-17 20:16 -0500
Re: Simulating termination analyzers for dummies Richard Damon <richard@damon-family.org> - 2024-06-17 21:24 -0400
Re: Simulating termination analyzers for dummies olcott <polcott333@gmail.com> - 2024-06-17 21:04 -0500
Re: Simulating termination analyzers for dummies Richard Damon <richard@damon-family.org> - 2024-06-17 22:33 -0400
Re: Simulating termination analyzers for dummies olcott <polcott333@gmail.com> - 2024-06-17 21:36 -0500
Re: Simulating termination analyzers for dummies Richard Damon <richard@damon-family.org> - 2024-06-17 22:44 -0400
Re: Simulating termination analyzers for dummies olcott <polcott333@gmail.com> - 2024-06-17 22:01 -0500
Re: Simulating termination analyzers for dummies Richard Damon <richard@damon-family.org> - 2024-06-17 23:15 -0400
Re: Simulating termination analyzers for dummies olcott <polcott333@gmail.com> - 2024-06-17 22:28 -0500
Re: Simulating termination analyzers for dummies Richard Damon <richard@damon-family.org> - 2024-06-18 07:36 -0400
Re: Simulating termination analyzers for dummies olcott <polcott333@gmail.com> - 2024-06-18 08:21 -0500
Re: Simulating termination analyzers by dummies joes <noreply@example.com> - 2024-06-18 17:06 +0000
Re: Simulating termination analyzers by dummies --- What does halting mean? olcott <polcott333@gmail.com> - 2024-06-18 12:25 -0500
Re: Simulating termination analyzers by dummies --- What does halting mean? joes <noreply@example.com> - 2024-06-18 17:57 +0000
Re: Simulating termination analyzers by dummies --- What does halting mean? olcott <polcott333@gmail.com> - 2024-06-18 13:16 -0500
Re: Simulating termination analyzers by dummies --- What does halting mean? joes <noreply@example.com> - 2024-06-18 20:37 +0000
Re: Simulating termination analyzers by dummies --- What does halting mean? olcott <polcott333@gmail.com> - 2024-06-18 16:29 -0500
Re: Simulating termination analyzers by dummies --- What does halting mean? joes <noreply@example.com> - 2024-06-19 08:48 +0000
Re: Simulating termination analyzers by dummies --- test of dishonesty olcott <polcott333@gmail.com> - 2024-06-19 08:12 -0500
Re: Simulating termination analyzers by dummies --- What does halting mean? olcott <polcott333@gmail.com> - 2024-06-18 16:08 -0500
Re: Simulating termination analyzers by dummies --- What does halting mean? Alan Mackenzie <acm@muc.de> - 2024-06-18 21:36 +0000
Re: Simulating termination analyzers by dummies --- What does halting mean? olcott <polcott333@gmail.com> - 2024-06-18 16:54 -0500
Re: Simulating termination analyzers by dummies --- What does halting mean? Alan Mackenzie <acm@muc.de> - 2024-06-19 09:29 +0000
Re: Simulating termination analyzers by dummies --- What does halting mean? olcott <polcott333@gmail.com> - 2024-06-19 09:05 -0500
Re: Simulating termination analyzers by dummies --- What does halting mean? joes <noreply@example.com> - 2024-06-19 17:51 +0000
Re: Simulating termination analyzers by dummies --- The only reply until addressed olcott <polcott333@gmail.com> - 2024-06-19 12:52 -0500
Re: Simulating termination analyzers by dummies --- addressed joes <noreply@example.com> - 2024-06-19 18:03 +0000
Re: Simulating termination analyzers by dummies --- --- the only reply until FULLY addressed olcott <polcott333@gmail.com> - 2024-06-19 13:26 -0500
Re: Simulating termination analyzers by dummies --- --- the only reply until FULLY addressed joes <noreply@example.com> - 2024-06-20 16:33 +0000
Re: Simulating termination analyzers by dummies --- What does halting mean? Mikko <mikko.levanto@iki.fi> - 2024-06-20 08:29 +0300
Re: Simulating termination analyzers by dummies --- What does halting mean? olcott <polcott333@gmail.com> - 2024-06-20 00:40 -0500
Re: Simulating termination analyzers by dummies --- What does halting mean? Mikko <mikko.levanto@iki.fi> - 2024-06-20 18:08 +0300
Re: Simulating termination analyzers by dummies --- What does halting mean? olcott <polcott333@gmail.com> - 2024-06-20 10:23 -0500
Re: Simulating termination analyzers by dummies --- What does halting mean? Richard Damon <richard@damon-family.org> - 2024-06-20 21:55 -0400
Re: Simulating termination analyzers by dummies --- What does halting mean? Mikko <mikko.levanto@iki.fi> - 2024-06-21 10:11 +0300
Re: Simulating termination analyzers by dummies --- What does halting mean? olcott <polcott333@gmail.com> - 2024-06-21 08:19 -0500
Re: Simulating termination analyzers by dummies --- What does halting mean? Richard Damon <richard@damon-family.org> - 2024-06-21 10:06 -0400
Re: Simulating termination analyzers by dummies --- What does halting mean? Mikko <mikko.levanto@iki.fi> - 2024-06-22 11:05 +0300
Re: Simulating termination analyzers by dummies --- What does halting mean? olcott <polcott333@gmail.com> - 2024-06-22 08:04 -0500
Re: Simulating termination analyzers by dummies --- What does halting mean? Richard Damon <richard@damon-family.org> - 2024-06-22 09:27 -0400
Re: Simulating termination analyzers by dummies --- criteria is met olcott <polcott333@gmail.com> - 2024-06-22 09:11 -0500
Re: Simulating termination analyzers by dummies --- criteria is met Richard Damon <richard@damon-family.org> - 2024-06-22 10:20 -0400
Re: Simulating termination analyzers by dummies --- criteria is met olcott <polcott333@gmail.com> - 2024-06-22 09:42 -0500
Re: Simulating termination analyzers by dummies --- criteria is met Richard Damon <richard@damon-family.org> - 2024-06-22 11:08 -0400
Re: Simulating termination analyzers by dummies --- criteria is met joes <noreply@example.com> - 2024-06-22 14:53 +0000
Re: Simulating termination analyzers by dummies --- criteria is met Mikko <mikko.levanto@iki.fi> - 2024-06-23 10:57 +0300
Re: Simulating termination analyzers by dummies --- criteria is met olcott <polcott333@gmail.com> - 2024-06-23 08:13 -0500
Re: Simulating termination analyzers by dummies --- criteria is met Mikko <mikko.levanto@iki.fi> - 2024-06-24 10:22 +0300
Re: Simulating termination analyzers by dummies --- criteria is met olcott <polcott333@gmail.com> - 2024-06-24 08:46 -0500
Re: Simulating termination analyzers by dummies --- criteria is met joes <noreply@example.com> - 2024-06-24 19:52 +0000
Re: Simulating termination analyzers by dummies --- criteria is met Alan Mackenzie <acm@muc.de> - 2024-06-24 20:27 +0000
Re: Simulating termination analyzers by dummies --- criteria is met olcott <polcott333@gmail.com> - 2024-06-24 16:10 -0500
Re: Simulating termination analyzers by dummies --- criteria is met Richard Damon <richard@damon-family.org> - 2024-06-24 19:48 -0400
Re: Simulating termination analyzers by dummies --- criteria is met joes <noreply@example.com> - 2024-06-25 08:48 +0000
Re: Simulating termination analyzers by dummies --- criteria is met "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-25 14:14 +0200
Re: Simulating termination analyzers by dummies --- criteria is met Mikko <mikko.levanto@iki.fi> - 2024-06-25 12:27 +0300
Re: Simulating termination analyzers by dummies --- criteria is met Alan Mackenzie <acm@muc.de> - 2024-06-25 14:06 +0000
Re: Simulating termination analyzers by dummies --- criteria is met olcott <polcott333@gmail.com> - 2024-06-24 16:12 -0500
Re: Simulating termination analyzers by dummies --- criteria is met Richard Damon <richard@damon-family.org> - 2024-06-24 19:53 -0400
Re: Simulating termination analyzers by dummies --- criteria is met Richard Damon <richard@damon-family.org> - 2024-06-24 19:44 -0400
Re: Simulating termination analyzers by dummies --- What does halting mean? Richard Damon <richard@damon-family.org> - 2024-06-18 22:16 -0400
Re: Simulating termination analyzers by dummies --- What does halting mean? olcott <polcott333@gmail.com> - 2024-06-18 21:30 -0500
Re: Simulating termination analyzers by dummies --- What does halting mean? Richard Damon <richard@damon-family.org> - 2024-06-18 22:41 -0400
Re: Simulating termination analyzers by dummies --- What does halting mean? olcott <polcott333@gmail.com> - 2024-06-18 21:51 -0500
Re: Simulating termination analyzers by dummies --- What does halting mean? joes <noreply@example.com> - 2024-06-19 09:08 +0000
Re: Simulating termination analyzers by dummies --- What does halting mean? olcott <polcott333@gmail.com> - 2024-06-19 08:31 -0500
Re: Simulating termination analyzers by dummies --- What does halting mean? joes <noreply@example.com> - 2024-06-19 17:43 +0000
Re: Simulating termination analyzers by dummies --- the only reply until addressed olcott <polcott333@gmail.com> - 2024-06-19 12:48 -0500
Re: Simulating termination analyzers by dummies --- the only reply until addressed joes <noreply@example.com> - 2024-06-19 17:59 +0000
Re: Simulating termination analyzers by dummies --- What does halting mean? Richard Damon <richard@damon-family.org> - 2024-06-19 07:30 -0400
Re: Simulating termination analyzers by dummies --- What does halting mean? olcott <polcott333@gmail.com> - 2024-06-19 09:23 -0500
Re: Simulating termination analyzers by dummies --- What does halting mean? joes <noreply@example.com> - 2024-06-19 16:43 +0000
Re: Simulating termination analyzers by dummies --- What does halting mean? olcott <polcott333@gmail.com> - 2024-06-19 12:09 -0500
Re: Simulating termination analyzers by dummies --- What does halting mean? Richard Damon <richard@damon-family.org> - 2024-06-19 20:24 -0400
Re: Simulating termination analyzers by dummies --- What does halting mean? olcott <polcott333@gmail.com> - 2024-06-19 12:16 -0500
Re: Simulating termination analyzers by dummies --- What does halting mean? joes <noreply@example.com> - 2024-06-19 17:32 +0000
Re: Simulating termination analyzers by dummies --- What does halting mean? olcott <polcott333@gmail.com> - 2024-06-19 12:40 -0500
Re: Simulating termination analyzers by dummies --- What does halting mean? Richard Damon <richard@damon-family.org> - 2024-06-19 20:24 -0400
Re: Simulating termination analyzers by dummies --- What does halting mean? Richard Damon <richard@damon-family.org> - 2024-06-19 20:24 -0400
Re: Simulating termination analyzers by dummies --- What does halting mean? joes <noreply@example.com> - 2024-06-19 08:57 +0000
Re: Simulating termination analyzers by dummies --- What does halting mean? olcott <polcott333@gmail.com> - 2024-06-19 08:20 -0500
Re: Simulating termination analyzers by dummies --- What does halting mean? joes <noreply@example.com> - 2024-06-19 16:25 +0000
Re: Simulating termination analyzers by dummies --- What does halting mean? Richard Damon <richard@damon-family.org> - 2024-06-19 20:24 -0400
Re: Simulating termination analyzers by dummies --- What does halting mean? "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-19 10:18 +0200
Re: Simulating termination analyzers by dummies --- What does halting mean? olcott <polcott333@gmail.com> - 2024-06-19 08:11 -0500
Re: Simulating termination analyzers by dummies --- What does halting mean? "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-19 16:11 +0200
Re: Simulating termination analyzers by dummies --- What does halting mean? olcott <polcott333@gmail.com> - 2024-06-19 10:07 -0500
Re: Simulating termination analyzers by dummies --- What does halting mean? "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-19 17:50 +0200
Re: Simulating termination analyzers by dummies --- What does halting mean? olcott <polcott333@gmail.com> - 2024-06-19 11:10 -0500
Re: Simulating termination analyzers by dummies --- What does halting mean? "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-20 10:23 +0200
Re: Simulating termination analyzers by dummies --- What does halting mean? olcott <polcott333@gmail.com> - 2024-06-20 09:16 -0500
Re: Simulating termination analyzers by dummies --- What does halting mean? joes <noreply@example.com> - 2024-06-20 16:29 +0000
Re: Simulating termination analyzers by dummies --- What does halting mean? olcott <polcott333@gmail.com> - 2024-06-20 11:35 -0500
Re: Simulating termination analyzers by dummies --- What does halting mean? "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-21 09:58 +0200
Re: Simulating termination analyzers by dummies --- What does halting mean? olcott <polcott333@gmail.com> - 2024-06-21 08:12 -0500
Re: Simulating termination analyzers by dummies --- What does halting mean? Richard Damon <richard@damon-family.org> - 2024-06-21 10:11 -0400
Re: Simulating termination analyzers by dummies --- What does halting mean? joes <noreply@example.com> - 2024-06-20 22:54 +0000
Re: Simulating termination analyzers by dummies --- What does halting mean? Mikko <mikko.levanto@iki.fi> - 2024-06-20 08:43 +0300
Re: Simulating termination analyzers by dummies --- What does halting mean? olcott <polcott333@gmail.com> - 2024-06-20 09:45 -0500
Re: Simulating termination analyzers by dummies --- What does halting mean? Mikko <mikko.levanto@iki.fi> - 2024-06-21 10:02 +0300
Re: Simulating termination analyzers by dummies --- What does halting mean? olcott <polcott333@gmail.com> - 2024-06-21 08:18 -0500
Re: Simulating termination analyzers by dummies --- What does halting mean? Richard Damon <richard@damon-family.org> - 2024-06-21 10:20 -0400
Re: Simulating termination analyzers by dummies --- What does halting mean? Mikko <mikko.levanto@iki.fi> - 2024-06-22 11:14 +0300
Re: Simulating termination analyzers for dummies Richard Damon <richard@damon-family.org> - 2024-06-18 22:16 -0400
Re: Simulating termination analyzers for dummies Python <python@invalid.org> - 2024-06-18 13:52 +0200
Re: Simulating termination analyzers for dummies Mikko <mikko.levanto@iki.fi> - 2024-06-18 19:21 +0300
Re: Simulating termination analyzers for dummies olcott <polcott333@gmail.com> - 2024-06-18 11:30 -0500
Re: Simulating termination analyzers for dummies Mikko <mikko.levanto@iki.fi> - 2024-06-18 19:37 +0300
Re: Simulating termination analyzers for dummies olcott <polcott333@gmail.com> - 2024-06-18 11:45 -0500
Re: Simulating termination analyzers for dummies Mikko <mikko.levanto@iki.fi> - 2024-06-19 12:30 +0300
Re: Simulating termination analyzers for dummies olcott <polcott333@gmail.com> - 2024-06-19 08:47 -0500
Re: Simulating termination analyzers for dummies joes <noreply@example.com> - 2024-06-19 17:45 +0000
Re: Simulating termination analyzers for dummies --- The only reply until addressed olcott <polcott333@gmail.com> - 2024-06-19 12:49 -0500
Re: Simulating termination analyzers for dummies Mikko <mikko.levanto@iki.fi> - 2024-06-20 08:53 +0300
Re: Simulating termination analyzers for dummies Richard Damon <richard@damon-family.org> - 2024-06-18 22:16 -0400
Page 5 of 9 — ← Prev page 1 2 3 4 [5] 6 7 8 9 Next page →
| From | joes <noreply@example.com> |
|---|---|
| Date | 2024-06-19 18:03 +0000 |
| Subject | Re: Simulating termination analyzers by dummies --- addressed |
| Message-ID | <v4v6if$fhqs$11@i2pn2.org> |
| In reply to | #107459 |
Am Wed, 19 Jun 2024 12:52:59 -0500 schrieb olcott:
> On 6/19/2024 12:51 PM, joes wrote:
>> Am Wed, 19 Jun 2024 09:05:29 -0500 schrieb olcott:
>>> On 6/19/2024 4:29 AM, Alan Mackenzie wrote:
>>>> olcott <polcott333@gmail.com> wrote:
>>>>> On 6/18/2024 4:36 PM, Alan Mackenzie wrote:
>>>>>> In comp.theory olcott <polcott333@gmail.com> wrote:
>>>>>>> On 6/18/2024 12:57 PM, joes wrote:
>>>>>>>> Am Tue, 18 Jun 2024 12:25:44 -0500 schrieb olcott:
>>>>>>>>> On 6/18/2024 12:06 PM, joes wrote:
>>> When the adapted UTM halts after recognizing the repeating state of a
>>> Turing Machine Description that only loops and transitions to its
>>> reject state then this adapted UTM is a halt decider for inputs that
>>> only loop.
>> But not a simulator.
^
>>>>>>>>> A UTM can be adapted so that it only simulates a fixed number of
>>>>>>>>> iterations of an input that loops.
>>>>>> As has often been said, it is then no longer a universal turing
>>>>>> machine.
>>> So what?
>> You wanted to simulate the input.
^
>>>>> It is a mistake for a simulating termination analyzer to simulate
>>>>> infinite repeating states.
>>>> How can that be a "mistake" if it's what the thing is programmed to
>>>> do?
>>> Termination analyzers are required to halt so it fails to meet its
>>> spec.
>> What use is an analyser that can't deal with possible loops?
^
> void DDD()
> {
> H0(DDD);
> }
H0 should just return that DDD halts, which it does.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-19 13:26 -0500 |
| Subject | Re: Simulating termination analyzers by dummies --- --- the only reply until FULLY addressed |
| Message-ID | <v4v7t4$238f5$2@dont-email.me> |
| In reply to | #107461 |
On 6/19/2024 1:03 PM, joes wrote:
> Am Wed, 19 Jun 2024 12:52:59 -0500 schrieb olcott:
>> On 6/19/2024 12:51 PM, joes wrote:
>>> Am Wed, 19 Jun 2024 09:05:29 -0500 schrieb olcott:
>>>> On 6/19/2024 4:29 AM, Alan Mackenzie wrote:
>>>>> olcott <polcott333@gmail.com> wrote:
>>>>>> On 6/18/2024 4:36 PM, Alan Mackenzie wrote:
>>>>>>> In comp.theory olcott <polcott333@gmail.com> wrote:
>>>>>>>> On 6/18/2024 12:57 PM, joes wrote:
>>>>>>>>> Am Tue, 18 Jun 2024 12:25:44 -0500 schrieb olcott:
>>>>>>>>>> On 6/18/2024 12:06 PM, joes wrote:
>
>>>> When the adapted UTM halts after recognizing the repeating state of a
>>>> Turing Machine Description that only loops and transitions to its
>>>> reject state then this adapted UTM is a halt decider for inputs that
>>>> only loop.
>>> But not a simulator.
> ^
>
>>>>>>>>>> A UTM can be adapted so that it only simulates a fixed number of
>>>>>>>>>> iterations of an input that loops.
>>>>>>> As has often been said, it is then no longer a universal turing
>>>>>>> machine.
>>>> So what?
>>> You wanted to simulate the input.
> ^
>
>>>>>> It is a mistake for a simulating termination analyzer to simulate
>>>>>> infinite repeating states.
>>>>> How can that be a "mistake" if it's what the thing is programmed to
>>>>> do?
>>>> Termination analyzers are required to halt so it fails to meet its
>>>> spec.
>>> What use is an analyser that can't deal with possible loops?
> ^
>
>> void DDD()
>> {
>> H0(DDD);
>> }
> H0 should just return that DDD halts, which it does.
_DDD()
[000020a2] 55 push ebp ; housekeeping
[000020a3] 8bec mov ebp,esp ; housekeeping
[000020a5] 68a2200000 push 000020a2 ; push DDD
[000020aa] e8f3f9ffff call 00001aa2 ; call H0
[000020af] 83c404 add esp,+04 ; housekeeping
[000020b2] 5d pop ebp ; housekeeping
[000020b3] c3 ret ; never gets here
Size in bytes:(0018) [000020b3]
Of every H0 that can possibly exist such that H0 emulates
DDD WHAT ARE THE EXACT STEPS OF DDD CORRECTLY EMULATED
BY H0 SUCH THAT THE EMULATED DDD REACHES [000020b3] ???
*I can do this many hundreds of times if necessary*
*I can do this many hundreds of times if necessary*
*I can do this many hundreds of times if necessary*
--
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-20 16:33 +0000 |
| Subject | Re: Simulating termination analyzers by dummies --- --- the only reply until FULLY addressed |
| Message-ID | <v51ljt$inq6$3@i2pn2.org> |
| In reply to | #107462 |
Am Wed, 19 Jun 2024 13:26:44 -0500 schrieb olcott:
> On 6/19/2024 1:03 PM, joes wrote:
>> Am Wed, 19 Jun 2024 12:52:59 -0500 schrieb olcott:
>>> On 6/19/2024 12:51 PM, joes wrote:
>>>> Am Wed, 19 Jun 2024 09:05:29 -0500 schrieb olcott:
>>>>> On 6/19/2024 4:29 AM, Alan Mackenzie wrote:
>>>>>> olcott <polcott333@gmail.com> wrote:
>>>>>>> On 6/18/2024 4:36 PM, Alan Mackenzie wrote:
>>>>>>>> In comp.theory olcott <polcott333@gmail.com> wrote:
>>>>>>>>> On 6/18/2024 12:57 PM, joes wrote:
>>>>>>>>>> Am Tue, 18 Jun 2024 12:25:44 -0500 schrieb olcott:
>>>>>>>>>>> On 6/18/2024 12:06 PM, joes wrote:
>>>>> When the adapted UTM halts after recognizing the repeating state of
>>>>> a Turing Machine Description that only loops and transitions to its
>>>>> reject state then this adapted UTM is a halt decider for inputs that
>>>>> only loop.
>>>> But not a simulator.
>>>>>>>>>>> A UTM can be adapted so that it only simulates a fixed number
>>>>>>>>>>> of iterations of an input that loops.
>>>>>>>> As has often been said, it is then no longer a universal turing
>>>>>>>> machine.
>>>>>>> It is a mistake for a simulating termination analyzer to simulate
>>>>>>> infinite repeating states.
>>>>>> How can that be a "mistake" if it's what the thing is programmed to
>>>>>> do?
>>>> What use is an analyser that can't deal with possible loops?
>>> void DDD()
>>> {
>>> H0(DDD);
>>> }
>> H0 should just return that DDD halts, which it does.
The truthteller nonparadox.
> Of every H0 that can possibly exist such that H0 emulates DDD WHAT ARE
> THE EXACT STEPS OF DDD CORRECTLY EMULATED BY H0 SUCH THAT THE EMULATED
> DDD REACHES [000020b3] ???
Whatever H0 does, we know that it halts and returns to DDD which calls it.
> *I can do this many hundreds of times if necessary*
That is not necessary. Instead engage with the above point.
--
Man kann mit dunklen Zahlen nicht rechnen. Für die eigentliche Mathematik
sind sie vollkommen nutzlos. --Wolfgang Mückenheim
[toc] | [prev] | [next] | [standalone]
| From | Mikko <mikko.levanto@iki.fi> |
|---|---|
| Date | 2024-06-20 08:29 +0300 |
| Subject | Re: Simulating termination analyzers by dummies --- What does halting mean? |
| Message-ID | <v50ena$2ecrp$1@dont-email.me> |
| In reply to | #107434 |
On 2024-06-19 14:05:29 +0000, olcott said:
> On 6/19/2024 4:29 AM, Alan Mackenzie wrote:
>> olcott <polcott333@gmail.com> wrote:
>>> On 6/18/2024 4:36 PM, Alan Mackenzie wrote:
>>>> [ Followup-To: set ]
>>
>>>> In comp.theory olcott <polcott333@gmail.com> wrote:
>>>>> On 6/18/2024 12:57 PM, joes wrote:
>>>>>> Am Tue, 18 Jun 2024 12:25:44 -0500 schrieb olcott:
>>>>>>> On 6/18/2024 12:06 PM, joes wrote:
>>>>>>> void DDD()
>>>>>>> {
>>>>>>> H0(DDD);
>>>>>>> }
>>>>>>> DDD correctly simulated by any H0 cannot possibly halt.
>>>>>>>> DDD halts iff H0 halts.
>>
>>>>>> So H0 returns "doesn't halt" to DDD, which then stops running,
>>>>>> so H0 should have returned "halts".
>>
>>>>> This was three messages ago.
>>>>> I had to make sure that you understood that halting
>>>>> does not mean stopping for any reason and only includes
>>>>> the equivalent of terminating normally.
>>
>>>> No. You're wrong, here. A turing machine is either running or it's
>>>> halted. There's no third alternative. If your C programs are not in one
>>>> of these two states, they're not equivalent to turing machines.
>>
>>> Although I agree with this there seems to be nuances of
>>> disagreement across the experts.
>>
>> I doubt that very much. The whole point of turing machines is to remove
>> ambiguity and unneeded features from the theory of computation. A third
>> alternative state is unneeded.
>>
>
> Some people say that a TM can halt in a non-final state.
People may use different words to express the same facts. What some
people call "halting in a non-final state" is called "rejecting" by
some other people. But the facts are what they are independently of
the words used to express them.
--
Mikko
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-20 00:40 -0500 |
| Subject | Re: Simulating termination analyzers by dummies --- What does halting mean? |
| Message-ID | <v50fcc$2efr5$1@dont-email.me> |
| In reply to | #107480 |
On 6/20/2024 12:29 AM, Mikko wrote:
> On 2024-06-19 14:05:29 +0000, olcott said:
>
>> On 6/19/2024 4:29 AM, Alan Mackenzie wrote:
>>> olcott <polcott333@gmail.com> wrote:
>>>> On 6/18/2024 4:36 PM, Alan Mackenzie wrote:
>>>>> [ Followup-To: set ]
>>>
>>>>> In comp.theory olcott <polcott333@gmail.com> wrote:
>>>>>> On 6/18/2024 12:57 PM, joes wrote:
>>>>>>> Am Tue, 18 Jun 2024 12:25:44 -0500 schrieb olcott:
>>>>>>>> On 6/18/2024 12:06 PM, joes wrote:
>>>>>>>> void DDD()
>>>>>>>> {
>>>>>>>> H0(DDD);
>>>>>>>> }
>>>>>>>> DDD correctly simulated by any H0 cannot possibly halt.
>>>>>>>>> DDD halts iff H0 halts.
>>>
>>>>>>> So H0 returns "doesn't halt" to DDD, which then stops running,
>>>>>>> so H0 should have returned "halts".
>>>
>>>>>> This was three messages ago.
>>>>>> I had to make sure that you understood that halting
>>>>>> does not mean stopping for any reason and only includes
>>>>>> the equivalent of terminating normally.
>>>
>>>>> No. You're wrong, here. A turing machine is either running or it's
>>>>> halted. There's no third alternative. If your C programs are not
>>>>> in one
>>>>> of these two states, they're not equivalent to turing machines.
>>>
>>>> Although I agree with this there seems to be nuances of
>>>> disagreement across the experts.
>>>
>>> I doubt that very much. The whole point of turing machines is to remove
>>> ambiguity and unneeded features from the theory of computation. A third
>>> alternative state is unneeded.
>>>
>>
>> Some people say that a TM can halt in a non-final state.
>
> People may use different words to express the same facts. What some
> people call "halting in a non-final state" is called "rejecting" by
> some other people. But the facts are what they are independently of
> the words used to express them.
>
Ambiguity and vagueness make communication less effective.
I use C because there are zero gaps in exactly what it means.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Mikko <mikko.levanto@iki.fi> |
|---|---|
| Date | 2024-06-20 18:08 +0300 |
| Subject | Re: Simulating termination analyzers by dummies --- What does halting mean? |
| Message-ID | <v51gli$2kgr3$1@dont-email.me> |
| In reply to | #107481 |
On 2024-06-20 05:40:28 +0000, olcott said:
> On 6/20/2024 12:29 AM, Mikko wrote:
>> On 2024-06-19 14:05:29 +0000, olcott said:
>>
>>> On 6/19/2024 4:29 AM, Alan Mackenzie wrote:
>>>> olcott <polcott333@gmail.com> wrote:
>>>>> On 6/18/2024 4:36 PM, Alan Mackenzie wrote:
>>>>>> [ Followup-To: set ]
>>>>
>>>>>> In comp.theory olcott <polcott333@gmail.com> wrote:
>>>>>>> On 6/18/2024 12:57 PM, joes wrote:
>>>>>>>> Am Tue, 18 Jun 2024 12:25:44 -0500 schrieb olcott:
>>>>>>>>> On 6/18/2024 12:06 PM, joes wrote:
>>>>>>>>> void DDD()
>>>>>>>>> {
>>>>>>>>> H0(DDD);
>>>>>>>>> }
>>>>>>>>> DDD correctly simulated by any H0 cannot possibly halt.
>>>>>>>>>> DDD halts iff H0 halts.
>>>>
>>>>>>>> So H0 returns "doesn't halt" to DDD, which then stops running,
>>>>>>>> so H0 should have returned "halts".
>>>>
>>>>>>> This was three messages ago.
>>>>>>> I had to make sure that you understood that halting
>>>>>>> does not mean stopping for any reason and only includes
>>>>>>> the equivalent of terminating normally.
>>>>
>>>>>> No. You're wrong, here. A turing machine is either running or it's
>>>>>> halted. There's no third alternative. If your C programs are not in one
>>>>>> of these two states, they're not equivalent to turing machines.
>>>>
>>>>> Although I agree with this there seems to be nuances of
>>>>> disagreement across the experts.
>>>>
>>>> I doubt that very much. The whole point of turing machines is to remove
>>>> ambiguity and unneeded features from the theory of computation. A third
>>>> alternative state is unneeded.
>>>>
>>>
>>> Some people say that a TM can halt in a non-final state.
>>
>> People may use different words to express the same facts. What some
>> people call "halting in a non-final state" is called "rejecting" by
>> some other people. But the facts are what they are independently of
>> the words used to express them.
>
> Ambiguity and vagueness make communication less effective.
As does use of common words and expressions for uncommon meanings.
> I use C because there are zero gaps in exactly what it means.
THere are lont of gaps in C. Some are mistakes that are corrected in
technical corrigenda. Others are undefined and implementation defined
behaviour. Your program uses non-standard extensions to C so it does
not communicate well. If also is too big to be a part of a publishable
article.
--
Mikko
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-20 10:23 -0500 |
| Subject | Re: Simulating termination analyzers by dummies --- What does halting mean? |
| Message-ID | <v51hgt$2kigj$1@dont-email.me> |
| In reply to | #107498 |
On 6/20/2024 10:08 AM, Mikko wrote:
> On 2024-06-20 05:40:28 +0000, olcott said:
>
>> On 6/20/2024 12:29 AM, Mikko wrote:
>>> On 2024-06-19 14:05:29 +0000, olcott said:
>>>
>>>> On 6/19/2024 4:29 AM, Alan Mackenzie wrote:
>>>>> olcott <polcott333@gmail.com> wrote:
>>>>>> On 6/18/2024 4:36 PM, Alan Mackenzie wrote:
>>>>>>> [ Followup-To: set ]
>>>>>
>>>>>>> In comp.theory olcott <polcott333@gmail.com> wrote:
>>>>>>>> On 6/18/2024 12:57 PM, joes wrote:
>>>>>>>>> Am Tue, 18 Jun 2024 12:25:44 -0500 schrieb olcott:
>>>>>>>>>> On 6/18/2024 12:06 PM, joes wrote:
>>>>>>>>>> void DDD()
>>>>>>>>>> {
>>>>>>>>>> H0(DDD);
>>>>>>>>>> }
>>>>>>>>>> DDD correctly simulated by any H0 cannot possibly halt.
>>>>>>>>>>> DDD halts iff H0 halts.
>>>>>
>>>>>>>>> So H0 returns "doesn't halt" to DDD, which then stops running,
>>>>>>>>> so H0 should have returned "halts".
>>>>>
>>>>>>>> This was three messages ago.
>>>>>>>> I had to make sure that you understood that halting
>>>>>>>> does not mean stopping for any reason and only includes
>>>>>>>> the equivalent of terminating normally.
>>>>>
>>>>>>> No. You're wrong, here. A turing machine is either running or it's
>>>>>>> halted. There's no third alternative. If your C programs are
>>>>>>> not in one
>>>>>>> of these two states, they're not equivalent to turing machines.
>>>>>
>>>>>> Although I agree with this there seems to be nuances of
>>>>>> disagreement across the experts.
>>>>>
>>>>> I doubt that very much. The whole point of turing machines is to
>>>>> remove
>>>>> ambiguity and unneeded features from the theory of computation. A
>>>>> third
>>>>> alternative state is unneeded.
>>>>>
>>>>
>>>> Some people say that a TM can halt in a non-final state.
>>>
>>> People may use different words to express the same facts. What some
>>> people call "halting in a non-final state" is called "rejecting" by
>>> some other people. But the facts are what they are independently of
>>> the words used to express them.
>>
>> Ambiguity and vagueness make communication less effective.
>
> As does use of common words and expressions for uncommon meanings.
>
>> I use C because there are zero gaps in exactly what it means.
>
> THere are lont of gaps in C. Some are mistakes that are corrected in
> technical corrigenda. Others are undefined and implementation defined
> behaviour. Your program uses non-standard extensions to C so it does
> not communicate well. If also is too big to be a part of a publishable
> article.
>
*There are zero gaps in the behavior of DDD correctly simulated by HH0*
https://liarparadox.org/HH0_(DDD)_Full_Trace.pdf
_DDD()
[00002093] 55 push ebp
[00002094] 8bec mov ebp,esp
[00002096] 6893200000 push 00002093 ; push DDD
[0000209b] e853f4ffff call 000014f3 ; call HH0
[000020a0] 83c404 add esp,+04
[000020a3] 5d pop ebp
[000020a4] c3 ret
Size in bytes:(0018) [000020a4]
Whereas the Linz specification of Ĥ says that embedded_H
does something or other that is totally unspecified:
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
--
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-20 21:55 -0400 |
| Subject | Re: Simulating termination analyzers by dummies --- What does halting mean? |
| Message-ID | <v52mik$jund$5@i2pn2.org> |
| In reply to | #107499 |
On 6/20/24 11:23 AM, olcott wrote:
> On 6/20/2024 10:08 AM, Mikko wrote:
>> On 2024-06-20 05:40:28 +0000, olcott said:
>>
>>> On 6/20/2024 12:29 AM, Mikko wrote:
>>>> On 2024-06-19 14:05:29 +0000, olcott said:
>>>>
>>>>> On 6/19/2024 4:29 AM, Alan Mackenzie wrote:
>>>>>> olcott <polcott333@gmail.com> wrote:
>>>>>>> On 6/18/2024 4:36 PM, Alan Mackenzie wrote:
>>>>>>>> [ Followup-To: set ]
>>>>>>
>>>>>>>> In comp.theory olcott <polcott333@gmail.com> wrote:
>>>>>>>>> On 6/18/2024 12:57 PM, joes wrote:
>>>>>>>>>> Am Tue, 18 Jun 2024 12:25:44 -0500 schrieb olcott:
>>>>>>>>>>> On 6/18/2024 12:06 PM, joes wrote:
>>>>>>>>>>> void DDD()
>>>>>>>>>>> {
>>>>>>>>>>> H0(DDD);
>>>>>>>>>>> }
>>>>>>>>>>> DDD correctly simulated by any H0 cannot possibly halt.
>>>>>>>>>>>> DDD halts iff H0 halts.
>>>>>>
>>>>>>>>>> So H0 returns "doesn't halt" to DDD, which then stops running,
>>>>>>>>>> so H0 should have returned "halts".
>>>>>>
>>>>>>>>> This was three messages ago.
>>>>>>>>> I had to make sure that you understood that halting
>>>>>>>>> does not mean stopping for any reason and only includes
>>>>>>>>> the equivalent of terminating normally.
>>>>>>
>>>>>>>> No. You're wrong, here. A turing machine is either running or
>>>>>>>> it's
>>>>>>>> halted. There's no third alternative. If your C programs are
>>>>>>>> not in one
>>>>>>>> of these two states, they're not equivalent to turing machines.
>>>>>>
>>>>>>> Although I agree with this there seems to be nuances of
>>>>>>> disagreement across the experts.
>>>>>>
>>>>>> I doubt that very much. The whole point of turing machines is to
>>>>>> remove
>>>>>> ambiguity and unneeded features from the theory of computation. A
>>>>>> third
>>>>>> alternative state is unneeded.
>>>>>>
>>>>>
>>>>> Some people say that a TM can halt in a non-final state.
>>>>
>>>> People may use different words to express the same facts. What some
>>>> people call "halting in a non-final state" is called "rejecting" by
>>>> some other people. But the facts are what they are independently of
>>>> the words used to express them.
>>>
>>> Ambiguity and vagueness make communication less effective.
>>
>> As does use of common words and expressions for uncommon meanings.
>>
>>> I use C because there are zero gaps in exactly what it means.
>>
>> THere are lont of gaps in C. Some are mistakes that are corrected in
>> technical corrigenda. Others are undefined and implementation defined
>> behaviour. Your program uses non-standard extensions to C so it does
>> not communicate well. If also is too big to be a part of a publishable
>> article.
>>
>
> *There are zero gaps in the behavior of DDD correctly simulated by HH0*
> https://liarparadox.org/HH0_(DDD)_Full_Trace.pdf
>
> _DDD()
> [00002093] 55 push ebp
> [00002094] 8bec mov ebp,esp
> [00002096] 6893200000 push 00002093 ; push DDD
> [0000209b] e853f4ffff call 000014f3 ; call HH0
> [000020a0] 83c404 add esp,+04
> [000020a3] 5d pop ebp
> [000020a4] c3 ret
> Size in bytes:(0018) [000020a4]
Which is EXACTLY the behavior of DDD direcctly executed until HH0 stops
simulating it.
So, "Correct Simulaition by HH doesn't determine the behavior of this
input (which HAS to include the x86 instruction of THIS HH0 or it can't
get past the call instruction).
Thus, you are just showing that your "alternate" form of halting is just
an invalid question.
>
> Whereas the Linz specification of Ĥ says that embedded_H
> does something or other that is totally unspecified:
No, it is logically specified by the requirement that H be a correct
halt decider, and he shows that based on that requirement, there can not
be such a thing.
>
> When Ĥ is applied to ⟨Ĥ⟩
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
WHich you are neglecting the requirements on H on those two limes,
probably because you don't understand the concept of requirements, so
you don't understand the concept of truth.
[toc] | [prev] | [next] | [standalone]
| From | Mikko <mikko.levanto@iki.fi> |
|---|---|
| Date | 2024-06-21 10:11 +0300 |
| Subject | Re: Simulating termination analyzers by dummies --- What does halting mean? |
| Message-ID | <v5393g$3286d$3@dont-email.me> |
| In reply to | #107499 |
On 2024-06-20 15:23:09 +0000, olcott said:
> On 6/20/2024 10:08 AM, Mikko wrote:
>> On 2024-06-20 05:40:28 +0000, olcott said:
>>
>>> On 6/20/2024 12:29 AM, Mikko wrote:
>>>> On 2024-06-19 14:05:29 +0000, olcott said:
>>>>
>>>>> On 6/19/2024 4:29 AM, Alan Mackenzie wrote:
>>>>>> olcott <polcott333@gmail.com> wrote:
>>>>>>> On 6/18/2024 4:36 PM, Alan Mackenzie wrote:
>>>>>>>> [ Followup-To: set ]
>>>>>>
>>>>>>>> In comp.theory olcott <polcott333@gmail.com> wrote:
>>>>>>>>> On 6/18/2024 12:57 PM, joes wrote:
>>>>>>>>>> Am Tue, 18 Jun 2024 12:25:44 -0500 schrieb olcott:
>>>>>>>>>>> On 6/18/2024 12:06 PM, joes wrote:
>>>>>>>>>>> void DDD()
>>>>>>>>>>> {
>>>>>>>>>>> H0(DDD);
>>>>>>>>>>> }
>>>>>>>>>>> DDD correctly simulated by any H0 cannot possibly halt.
>>>>>>>>>>>> DDD halts iff H0 halts.
>>>>>>
>>>>>>>>>> So H0 returns "doesn't halt" to DDD, which then stops running,
>>>>>>>>>> so H0 should have returned "halts".
>>>>>>
>>>>>>>>> This was three messages ago.
>>>>>>>>> I had to make sure that you understood that halting
>>>>>>>>> does not mean stopping for any reason and only includes
>>>>>>>>> the equivalent of terminating normally.
>>>>>>
>>>>>>>> No. You're wrong, here. A turing machine is either running or it's
>>>>>>>> halted. There's no third alternative. If your C programs are not in one
>>>>>>>> of these two states, they're not equivalent to turing machines.
>>>>>>
>>>>>>> Although I agree with this there seems to be nuances of
>>>>>>> disagreement across the experts.
>>>>>>
>>>>>> I doubt that very much. The whole point of turing machines is to remove
>>>>>> ambiguity and unneeded features from the theory of computation. A third
>>>>>> alternative state is unneeded.
>>>>>>
>>>>>
>>>>> Some people say that a TM can halt in a non-final state.
>>>>
>>>> People may use different words to express the same facts. What some
>>>> people call "halting in a non-final state" is called "rejecting" by
>>>> some other people. But the facts are what they are independently of
>>>> the words used to express them.
>>>
>>> Ambiguity and vagueness make communication less effective.
>>
>> As does use of common words and expressions for uncommon meanings.
>>
>>> I use C because there are zero gaps in exactly what it means.
>>
>> THere are lont of gaps in C. Some are mistakes that are corrected in
>> technical corrigenda. Others are undefined and implementation defined
>> behaviour. Your program uses non-standard extensions to C so it does
>> not communicate well. If also is too big to be a part of a publishable
>> article.
>>
>
> *There are zero gaps in the behavior of DDD correctly simulated by HH0*
> https://liarparadox.org/HH0_(DDD)_Full_Trace.pdf
>
> _DDD()
> [00002093] 55 push ebp
> [00002094] 8bec mov ebp,esp
> [00002096] 6893200000 push 00002093 ; push DDD
> [0000209b] e853f4ffff call 000014f3 ; call HH0
> [000020a0] 83c404 add esp,+04
> [000020a3] 5d pop ebp
> [000020a4] c3 ret
> Size in bytes:(0018) [000020a4]
>
> Whereas the Linz specification of Ĥ says that embedded_H
> does something or other that is totally unspecified:
>
> When Ĥ is applied to ⟨Ĥ⟩
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
Linz Ĥ is fully defined in terms of H, so its behaviour can be inferred
from the behaviour of H. Therefore Linz can prove about the behaviour of
both Ĥ and H what needs be proven.
--
Mikko
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-21 08:19 -0500 |
| Subject | Re: Simulating termination analyzers by dummies --- What does halting mean? |
| Message-ID | <v53ul0$35vak$5@dont-email.me> |
| In reply to | #107528 |
On 6/21/2024 2:11 AM, Mikko wrote:
> On 2024-06-20 15:23:09 +0000, olcott said:
>
>> On 6/20/2024 10:08 AM, Mikko wrote:
>>> On 2024-06-20 05:40:28 +0000, olcott said:
>>>
>>>> On 6/20/2024 12:29 AM, Mikko wrote:
>>>>> On 2024-06-19 14:05:29 +0000, olcott said:
>>>>>
>>>>>> On 6/19/2024 4:29 AM, Alan Mackenzie wrote:
>>>>>>> olcott <polcott333@gmail.com> wrote:
>>>>>>>> On 6/18/2024 4:36 PM, Alan Mackenzie wrote:
>>>>>>>>> [ Followup-To: set ]
>>>>>>>
>>>>>>>>> In comp.theory olcott <polcott333@gmail.com> wrote:
>>>>>>>>>> On 6/18/2024 12:57 PM, joes wrote:
>>>>>>>>>>> Am Tue, 18 Jun 2024 12:25:44 -0500 schrieb olcott:
>>>>>>>>>>>> On 6/18/2024 12:06 PM, joes wrote:
>>>>>>>>>>>> void DDD()
>>>>>>>>>>>> {
>>>>>>>>>>>> H0(DDD);
>>>>>>>>>>>> }
>>>>>>>>>>>> DDD correctly simulated by any H0 cannot possibly halt.
>>>>>>>>>>>>> DDD halts iff H0 halts.
>>>>>>>
>>>>>>>>>>> So H0 returns "doesn't halt" to DDD, which then stops running,
>>>>>>>>>>> so H0 should have returned "halts".
>>>>>>>
>>>>>>>>>> This was three messages ago.
>>>>>>>>>> I had to make sure that you understood that halting
>>>>>>>>>> does not mean stopping for any reason and only includes
>>>>>>>>>> the equivalent of terminating normally.
>>>>>>>
>>>>>>>>> No. You're wrong, here. A turing machine is either running or
>>>>>>>>> it's
>>>>>>>>> halted. There's no third alternative. If your C programs are
>>>>>>>>> not in one
>>>>>>>>> of these two states, they're not equivalent to turing machines.
>>>>>>>
>>>>>>>> Although I agree with this there seems to be nuances of
>>>>>>>> disagreement across the experts.
>>>>>>>
>>>>>>> I doubt that very much. The whole point of turing machines is to
>>>>>>> remove
>>>>>>> ambiguity and unneeded features from the theory of computation.
>>>>>>> A third
>>>>>>> alternative state is unneeded.
>>>>>>>
>>>>>>
>>>>>> Some people say that a TM can halt in a non-final state.
>>>>>
>>>>> People may use different words to express the same facts. What some
>>>>> people call "halting in a non-final state" is called "rejecting" by
>>>>> some other people. But the facts are what they are independently of
>>>>> the words used to express them.
>>>>
>>>> Ambiguity and vagueness make communication less effective.
>>>
>>> As does use of common words and expressions for uncommon meanings.
>>>
>>>> I use C because there are zero gaps in exactly what it means.
>>>
>>> THere are lont of gaps in C. Some are mistakes that are corrected in
>>> technical corrigenda. Others are undefined and implementation defined
>>> behaviour. Your program uses non-standard extensions to C so it does
>>> not communicate well. If also is too big to be a part of a publishable
>>> article.
>>>
>>
>> *There are zero gaps in the behavior of DDD correctly simulated by HH0*
>> https://liarparadox.org/HH0_(DDD)_Full_Trace.pdf
>>
>> _DDD()
>> [00002093] 55 push ebp
>> [00002094] 8bec mov ebp,esp
>> [00002096] 6893200000 push 00002093 ; push DDD
>> [0000209b] e853f4ffff call 000014f3 ; call HH0
>> [000020a0] 83c404 add esp,+04
>> [000020a3] 5d pop ebp
>> [000020a4] c3 ret
>> Size in bytes:(0018) [000020a4]
>>
>> Whereas the Linz specification of Ĥ says that embedded_H
>> does something or other that is totally unspecified:
>>
>> When Ĥ is applied to ⟨Ĥ⟩
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
> Linz Ĥ is fully defined in terms of H, so its behaviour can be inferred
> from the behaviour of H. Therefore Linz can prove about the behaviour of
> both Ĥ and H what needs be proven.
>
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(d) simulated ⟨Ĥ⟩ copies its input ⟨Ĥ⟩
(e) simulated ⟨Ĥ⟩ invokes simulated embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(f) simulated embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(g) goto (d) with one more level of simulation
Two complete simulations show a pair of identical TMD's are simulating a
pair of identical inputs. We can see this thus proving recursive
simulation.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-21 10:06 -0400 |
| Subject | Re: Simulating termination analyzers by dummies --- What does halting mean? |
| Message-ID | <v541dh$lkkc$2@i2pn2.org> |
| In reply to | #107537 |
On 6/21/24 9:19 AM, olcott wrote:
> On 6/21/2024 2:11 AM, Mikko wrote:
>> On 2024-06-20 15:23:09 +0000, olcott said:
>>
>>> On 6/20/2024 10:08 AM, Mikko wrote:
>>>> On 2024-06-20 05:40:28 +0000, olcott said:
>>>>
>>>>> On 6/20/2024 12:29 AM, Mikko wrote:
>>>>>> On 2024-06-19 14:05:29 +0000, olcott said:
>>>>>>
>>>>>>> On 6/19/2024 4:29 AM, Alan Mackenzie wrote:
>>>>>>>> olcott <polcott333@gmail.com> wrote:
>>>>>>>>> On 6/18/2024 4:36 PM, Alan Mackenzie wrote:
>>>>>>>>>> [ Followup-To: set ]
>>>>>>>>
>>>>>>>>>> In comp.theory olcott <polcott333@gmail.com> wrote:
>>>>>>>>>>> On 6/18/2024 12:57 PM, joes wrote:
>>>>>>>>>>>> Am Tue, 18 Jun 2024 12:25:44 -0500 schrieb olcott:
>>>>>>>>>>>>> On 6/18/2024 12:06 PM, joes wrote:
>>>>>>>>>>>>> void DDD()
>>>>>>>>>>>>> {
>>>>>>>>>>>>> H0(DDD);
>>>>>>>>>>>>> }
>>>>>>>>>>>>> DDD correctly simulated by any H0 cannot possibly halt.
>>>>>>>>>>>>>> DDD halts iff H0 halts.
>>>>>>>>
>>>>>>>>>>>> So H0 returns "doesn't halt" to DDD, which then stops running,
>>>>>>>>>>>> so H0 should have returned "halts".
>>>>>>>>
>>>>>>>>>>> This was three messages ago.
>>>>>>>>>>> I had to make sure that you understood that halting
>>>>>>>>>>> does not mean stopping for any reason and only includes
>>>>>>>>>>> the equivalent of terminating normally.
>>>>>>>>
>>>>>>>>>> No. You're wrong, here. A turing machine is either running
>>>>>>>>>> or it's
>>>>>>>>>> halted. There's no third alternative. If your C programs are
>>>>>>>>>> not in one
>>>>>>>>>> of these two states, they're not equivalent to turing machines.
>>>>>>>>
>>>>>>>>> Although I agree with this there seems to be nuances of
>>>>>>>>> disagreement across the experts.
>>>>>>>>
>>>>>>>> I doubt that very much. The whole point of turing machines is
>>>>>>>> to remove
>>>>>>>> ambiguity and unneeded features from the theory of computation.
>>>>>>>> A third
>>>>>>>> alternative state is unneeded.
>>>>>>>>
>>>>>>>
>>>>>>> Some people say that a TM can halt in a non-final state.
>>>>>>
>>>>>> People may use different words to express the same facts. What some
>>>>>> people call "halting in a non-final state" is called "rejecting" by
>>>>>> some other people. But the facts are what they are independently of
>>>>>> the words used to express them.
>>>>>
>>>>> Ambiguity and vagueness make communication less effective.
>>>>
>>>> As does use of common words and expressions for uncommon meanings.
>>>>
>>>>> I use C because there are zero gaps in exactly what it means.
>>>>
>>>> THere are lont of gaps in C. Some are mistakes that are corrected in
>>>> technical corrigenda. Others are undefined and implementation defined
>>>> behaviour. Your program uses non-standard extensions to C so it does
>>>> not communicate well. If also is too big to be a part of a publishable
>>>> article.
>>>>
>>>
>>> *There are zero gaps in the behavior of DDD correctly simulated by HH0*
>>> https://liarparadox.org/HH0_(DDD)_Full_Trace.pdf
>>>
>>> _DDD()
>>> [00002093] 55 push ebp
>>> [00002094] 8bec mov ebp,esp
>>> [00002096] 6893200000 push 00002093 ; push DDD
>>> [0000209b] e853f4ffff call 000014f3 ; call HH0
>>> [000020a0] 83c404 add esp,+04
>>> [000020a3] 5d pop ebp
>>> [000020a4] c3 ret
>>> Size in bytes:(0018) [000020a4]
>>>
>>> Whereas the Linz specification of Ĥ says that embedded_H
>>> does something or other that is totally unspecified:
>>>
>>> When Ĥ is applied to ⟨Ĥ⟩
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>
>> Linz Ĥ is fully defined in terms of H, so its behaviour can be inferred
>> from the behaviour of H. Therefore Linz can prove about the behaviour of
>> both Ĥ and H what needs be proven.
>>
>
> (a) Ĥ copies its input ⟨Ĥ⟩
> (b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
> (c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
> (d) simulated ⟨Ĥ⟩ copies its input ⟨Ĥ⟩
> (e) simulated ⟨Ĥ⟩ invokes simulated embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
> (f) simulated embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
> (g) goto (d) with one more level of simulation
>
> Two complete simulations show a pair of identical TMD's are simulating a
> pair of identical inputs. We can see this thus proving recursive
> simulation.
>
Except your argument is based on the INCORRECT assumption of what H, and
thus embedded_H does.
You are forgetting the consequences of behavior. You have proved that
*IF H DOESN'T ABORT ITS SIMULATION* that the behavior is infinite, but
that is a FALSE ASSUMPTION, as you later have H abort its simulation.
This is a CLASSICAL example of an unsound argument, making it based on a
statement that turns out to be false.
YOu are just provig that you have NO understanding of how logic works.
[toc] | [prev] | [next] | [standalone]
| From | Mikko <mikko.levanto@iki.fi> |
|---|---|
| Date | 2024-06-22 11:05 +0300 |
| Subject | Re: Simulating termination analyzers by dummies --- What does halting mean? |
| Message-ID | <v560kp$3lqrq$2@dont-email.me> |
| In reply to | #107537 |
On 2024-06-21 13:19:28 +0000, olcott said:
> On 6/21/2024 2:11 AM, Mikko wrote:
>> On 2024-06-20 15:23:09 +0000, olcott said:
>>
>>> On 6/20/2024 10:08 AM, Mikko wrote:
>>>> On 2024-06-20 05:40:28 +0000, olcott said:
>>>>
>>>>> On 6/20/2024 12:29 AM, Mikko wrote:
>>>>>> On 2024-06-19 14:05:29 +0000, olcott said:
>>>>>>
>>>>>>> On 6/19/2024 4:29 AM, Alan Mackenzie wrote:
>>>>>>>> olcott <polcott333@gmail.com> wrote:
>>>>>>>>> On 6/18/2024 4:36 PM, Alan Mackenzie wrote:
>>>>>>>>>> [ Followup-To: set ]
>>>>>>>>
>>>>>>>>>> In comp.theory olcott <polcott333@gmail.com> wrote:
>>>>>>>>>>> On 6/18/2024 12:57 PM, joes wrote:
>>>>>>>>>>>> Am Tue, 18 Jun 2024 12:25:44 -0500 schrieb olcott:
>>>>>>>>>>>>> On 6/18/2024 12:06 PM, joes wrote:
>>>>>>>>>>>>> void DDD()
>>>>>>>>>>>>> {
>>>>>>>>>>>>> H0(DDD);
>>>>>>>>>>>>> }
>>>>>>>>>>>>> DDD correctly simulated by any H0 cannot possibly halt.
>>>>>>>>>>>>>> DDD halts iff H0 halts.
>>>>>>>>
>>>>>>>>>>>> So H0 returns "doesn't halt" to DDD, which then stops running,
>>>>>>>>>>>> so H0 should have returned "halts".
>>>>>>>>
>>>>>>>>>>> This was three messages ago.
>>>>>>>>>>> I had to make sure that you understood that halting
>>>>>>>>>>> does not mean stopping for any reason and only includes
>>>>>>>>>>> the equivalent of terminating normally.
>>>>>>>>
>>>>>>>>>> No. You're wrong, here. A turing machine is either running or it's
>>>>>>>>>> halted. There's no third alternative. If your C programs are not in one
>>>>>>>>>> of these two states, they're not equivalent to turing machines.
>>>>>>>>
>>>>>>>>> Although I agree with this there seems to be nuances of
>>>>>>>>> disagreement across the experts.
>>>>>>>>
>>>>>>>> I doubt that very much. The whole point of turing machines is to remove
>>>>>>>> ambiguity and unneeded features from the theory of computation. A third
>>>>>>>> alternative state is unneeded.
>>>>>>>>
>>>>>>>
>>>>>>> Some people say that a TM can halt in a non-final state.
>>>>>>
>>>>>> People may use different words to express the same facts. What some
>>>>>> people call "halting in a non-final state" is called "rejecting" by
>>>>>> some other people. But the facts are what they are independently of
>>>>>> the words used to express them.
>>>>>
>>>>> Ambiguity and vagueness make communication less effective.
>>>>
>>>> As does use of common words and expressions for uncommon meanings.
>>>>
>>>>> I use C because there are zero gaps in exactly what it means.
>>>>
>>>> THere are lont of gaps in C. Some are mistakes that are corrected in
>>>> technical corrigenda. Others are undefined and implementation defined
>>>> behaviour. Your program uses non-standard extensions to C so it does
>>>> not communicate well. If also is too big to be a part of a publishable
>>>> article.
>>>>
>>>
>>> *There are zero gaps in the behavior of DDD correctly simulated by HH0*
>>> https://liarparadox.org/HH0_(DDD)_Full_Trace.pdf
>>>
>>> _DDD()
>>> [00002093] 55 push ebp
>>> [00002094] 8bec mov ebp,esp
>>> [00002096] 6893200000 push 00002093 ; push DDD
>>> [0000209b] e853f4ffff call 000014f3 ; call HH0
>>> [000020a0] 83c404 add esp,+04
>>> [000020a3] 5d pop ebp
>>> [000020a4] c3 ret
>>> Size in bytes:(0018) [000020a4]
>>>
>>> Whereas the Linz specification of Ĥ says that embedded_H
>>> does something or other that is totally unspecified:
>>>
>>> When Ĥ is applied to ⟨Ĥ⟩
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>
>> Linz Ĥ is fully defined in terms of H, so its behaviour can be inferred
>> from the behaviour of H. Therefore Linz can prove about the behaviour of
>> both Ĥ and H what needs be proven.
>
> (a) Ĥ copies its input ⟨Ĥ⟩
> (b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
> (c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
> (d) simulated ⟨Ĥ⟩ copies its input ⟨Ĥ⟩
> (e) simulated ⟨Ĥ⟩ invokes simulated embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
> (f) simulated embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
> (g) goto (d) with one more level of simulation
Linz says nothing about simulations or other methods H may use. Those
are already fully determined by the construction. But if H does those
(c)..(g)
then so does Ĥ.
> Two complete simulations show a pair of identical TMD's are simulating
> a pair of identical inputs. We can see this thus proving recursive
> simulation.
Yes. However, this observation is not used in steps (c)..(g).
--
Mikko
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-22 08:04 -0500 |
| Subject | Re: Simulating termination analyzers by dummies --- What does halting mean? |
| Message-ID | <v56i4t$3or0r$2@dont-email.me> |
| In reply to | #107591 |
On 6/22/2024 3:05 AM, Mikko wrote:
> On 2024-06-21 13:19:28 +0000, olcott said:
>
>> On 6/21/2024 2:11 AM, Mikko wrote:
>>> On 2024-06-20 15:23:09 +0000, olcott said:
>>>
>>>> On 6/20/2024 10:08 AM, Mikko wrote:
>>>>> On 2024-06-20 05:40:28 +0000, olcott said:
>>>>>
>>>>>> On 6/20/2024 12:29 AM, Mikko wrote:
>>>>>>> On 2024-06-19 14:05:29 +0000, olcott said:
>>>>>>>
>>>>>>>> On 6/19/2024 4:29 AM, Alan Mackenzie wrote:
>>>>>>>>> olcott <polcott333@gmail.com> wrote:
>>>>>>>>>> On 6/18/2024 4:36 PM, Alan Mackenzie wrote:
>>>>>>>>>>> [ Followup-To: set ]
>>>>>>>>>
>>>>>>>>>>> In comp.theory olcott <polcott333@gmail.com> wrote:
>>>>>>>>>>>> On 6/18/2024 12:57 PM, joes wrote:
>>>>>>>>>>>>> Am Tue, 18 Jun 2024 12:25:44 -0500 schrieb olcott:
>>>>>>>>>>>>>> On 6/18/2024 12:06 PM, joes wrote:
>>>>>>>>>>>>>> void DDD()
>>>>>>>>>>>>>> {
>>>>>>>>>>>>>> H0(DDD);
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>> DDD correctly simulated by any H0 cannot possibly halt.
>>>>>>>>>>>>>>> DDD halts iff H0 halts.
>>>>>>>>>
>>>>>>>>>>>>> So H0 returns "doesn't halt" to DDD, which then stops running,
>>>>>>>>>>>>> so H0 should have returned "halts".
>>>>>>>>>
>>>>>>>>>>>> This was three messages ago.
>>>>>>>>>>>> I had to make sure that you understood that halting
>>>>>>>>>>>> does not mean stopping for any reason and only includes
>>>>>>>>>>>> the equivalent of terminating normally.
>>>>>>>>>
>>>>>>>>>>> No. You're wrong, here. A turing machine is either running
>>>>>>>>>>> or it's
>>>>>>>>>>> halted. There's no third alternative. If your C programs
>>>>>>>>>>> are not in one
>>>>>>>>>>> of these two states, they're not equivalent to turing machines.
>>>>>>>>>
>>>>>>>>>> Although I agree with this there seems to be nuances of
>>>>>>>>>> disagreement across the experts.
>>>>>>>>>
>>>>>>>>> I doubt that very much. The whole point of turing machines is
>>>>>>>>> to remove
>>>>>>>>> ambiguity and unneeded features from the theory of
>>>>>>>>> computation. A third
>>>>>>>>> alternative state is unneeded.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Some people say that a TM can halt in a non-final state.
>>>>>>>
>>>>>>> People may use different words to express the same facts. What some
>>>>>>> people call "halting in a non-final state" is called "rejecting" by
>>>>>>> some other people. But the facts are what they are independently of
>>>>>>> the words used to express them.
>>>>>>
>>>>>> Ambiguity and vagueness make communication less effective.
>>>>>
>>>>> As does use of common words and expressions for uncommon meanings.
>>>>>
>>>>>> I use C because there are zero gaps in exactly what it means.
>>>>>
>>>>> THere are lont of gaps in C. Some are mistakes that are corrected in
>>>>> technical corrigenda. Others are undefined and implementation defined
>>>>> behaviour. Your program uses non-standard extensions to C so it does
>>>>> not communicate well. If also is too big to be a part of a publishable
>>>>> article.
>>>>>
>>>>
>>>> *There are zero gaps in the behavior of DDD correctly simulated by HH0*
>>>> https://liarparadox.org/HH0_(DDD)_Full_Trace.pdf
>>>>
>>>> _DDD()
>>>> [00002093] 55 push ebp
>>>> [00002094] 8bec mov ebp,esp
>>>> [00002096] 6893200000 push 00002093 ; push DDD
>>>> [0000209b] e853f4ffff call 000014f3 ; call HH0
>>>> [000020a0] 83c404 add esp,+04
>>>> [000020a3] 5d pop ebp
>>>> [000020a4] c3 ret
>>>> Size in bytes:(0018) [000020a4]
>>>>
>>>> Whereas the Linz specification of Ĥ says that embedded_H
>>>> does something or other that is totally unspecified:
>>>>
>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>
>>> Linz Ĥ is fully defined in terms of H, so its behaviour can be inferred
>>> from the behaviour of H. Therefore Linz can prove about the behaviour of
>>> both Ĥ and H what needs be proven.
>>
>> (a) Ĥ copies its input ⟨Ĥ⟩
>> (b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
>> (c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
>> (d) simulated ⟨Ĥ⟩ copies its input ⟨Ĥ⟩
>> (e) simulated ⟨Ĥ⟩ invokes simulated embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
>> (f) simulated embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
>> (g) goto (d) with one more level of simulation
>
> Linz says nothing about simulations
I am the sole inventor of the simulating halt decider.
Ben Bacarisse contacted professor Sipser to verify that he
really did says this. The details are in this forum about
the same date.
https://www.amazon.com/Introduction-Theory-Computation-Michael-Sipser/dp/113318779X/
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its input D
until H correctly determines that its simulated D would never
stop running unless aborted then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
*Ben also verified that the criteria have been met*
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
> I don't think that is the shell game. PO really /has/ an H
> (it's trivial to do for this one case) that correctly determines
> that P(P) *would* never stop running *unless* aborted.
> or other methods H may use. Those
> are already fully determined by the construction. But if H does those
> (c)..(g)
> then so does Ĥ.
>
>> Two complete simulations show a pair of identical TMD's are simulating
>> a pair of identical inputs. We can see this thus proving recursive
>> simulation.
>
> Yes. However, this observation is not used in steps (c)..(g).
>
--
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-22 09:27 -0400 |
| Subject | Re: Simulating termination analyzers by dummies --- What does halting mean? |
| Message-ID | <v56jfu$onl3$4@i2pn2.org> |
| In reply to | #107601 |
On 6/22/24 9:04 AM, olcott wrote:
> On 6/22/2024 3:05 AM, Mikko wrote:
>> On 2024-06-21 13:19:28 +0000, olcott said:
>>
>>> On 6/21/2024 2:11 AM, Mikko wrote:
>>>> On 2024-06-20 15:23:09 +0000, olcott said:
>>>>
>>>>> On 6/20/2024 10:08 AM, Mikko wrote:
>>>>>> On 2024-06-20 05:40:28 +0000, olcott said:
>>>>>>
>>>>>>> On 6/20/2024 12:29 AM, Mikko wrote:
>>>>>>>> On 2024-06-19 14:05:29 +0000, olcott said:
>>>>>>>>
>>>>>>>>> On 6/19/2024 4:29 AM, Alan Mackenzie wrote:
>>>>>>>>>> olcott <polcott333@gmail.com> wrote:
>>>>>>>>>>> On 6/18/2024 4:36 PM, Alan Mackenzie wrote:
>>>>>>>>>>>> [ Followup-To: set ]
>>>>>>>>>>
>>>>>>>>>>>> In comp.theory olcott <polcott333@gmail.com> wrote:
>>>>>>>>>>>>> On 6/18/2024 12:57 PM, joes wrote:
>>>>>>>>>>>>>> Am Tue, 18 Jun 2024 12:25:44 -0500 schrieb olcott:
>>>>>>>>>>>>>>> On 6/18/2024 12:06 PM, joes wrote:
>>>>>>>>>>>>>>> void DDD()
>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>> H0(DDD);
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>> DDD correctly simulated by any H0 cannot possibly halt.
>>>>>>>>>>>>>>>> DDD halts iff H0 halts.
>>>>>>>>>>
>>>>>>>>>>>>>> So H0 returns "doesn't halt" to DDD, which then stops
>>>>>>>>>>>>>> running,
>>>>>>>>>>>>>> so H0 should have returned "halts".
>>>>>>>>>>
>>>>>>>>>>>>> This was three messages ago.
>>>>>>>>>>>>> I had to make sure that you understood that halting
>>>>>>>>>>>>> does not mean stopping for any reason and only includes
>>>>>>>>>>>>> the equivalent of terminating normally.
>>>>>>>>>>
>>>>>>>>>>>> No. You're wrong, here. A turing machine is either running
>>>>>>>>>>>> or it's
>>>>>>>>>>>> halted. There's no third alternative. If your C programs
>>>>>>>>>>>> are not in one
>>>>>>>>>>>> of these two states, they're not equivalent to turing machines.
>>>>>>>>>>
>>>>>>>>>>> Although I agree with this there seems to be nuances of
>>>>>>>>>>> disagreement across the experts.
>>>>>>>>>>
>>>>>>>>>> I doubt that very much. The whole point of turing machines is
>>>>>>>>>> to remove
>>>>>>>>>> ambiguity and unneeded features from the theory of
>>>>>>>>>> computation. A third
>>>>>>>>>> alternative state is unneeded.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Some people say that a TM can halt in a non-final state.
>>>>>>>>
>>>>>>>> People may use different words to express the same facts. What some
>>>>>>>> people call "halting in a non-final state" is called "rejecting" by
>>>>>>>> some other people. But the facts are what they are independently of
>>>>>>>> the words used to express them.
>>>>>>>
>>>>>>> Ambiguity and vagueness make communication less effective.
>>>>>>
>>>>>> As does use of common words and expressions for uncommon meanings.
>>>>>>
>>>>>>> I use C because there are zero gaps in exactly what it means.
>>>>>>
>>>>>> THere are lont of gaps in C. Some are mistakes that are corrected in
>>>>>> technical corrigenda. Others are undefined and implementation defined
>>>>>> behaviour. Your program uses non-standard extensions to C so it does
>>>>>> not communicate well. If also is too big to be a part of a
>>>>>> publishable
>>>>>> article.
>>>>>>
>>>>>
>>>>> *There are zero gaps in the behavior of DDD correctly simulated by
>>>>> HH0*
>>>>> https://liarparadox.org/HH0_(DDD)_Full_Trace.pdf
>>>>>
>>>>> _DDD()
>>>>> [00002093] 55 push ebp
>>>>> [00002094] 8bec mov ebp,esp
>>>>> [00002096] 6893200000 push 00002093 ; push DDD
>>>>> [0000209b] e853f4ffff call 000014f3 ; call HH0
>>>>> [000020a0] 83c404 add esp,+04
>>>>> [000020a3] 5d pop ebp
>>>>> [000020a4] c3 ret
>>>>> Size in bytes:(0018) [000020a4]
>>>>>
>>>>> Whereas the Linz specification of Ĥ says that embedded_H
>>>>> does something or other that is totally unspecified:
>>>>>
>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>
>>>> Linz Ĥ is fully defined in terms of H, so its behaviour can be inferred
>>>> from the behaviour of H. Therefore Linz can prove about the
>>>> behaviour of
>>>> both Ĥ and H what needs be proven.
>>>
>>> (a) Ĥ copies its input ⟨Ĥ⟩
>>> (b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
>>> (c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
>>> (d) simulated ⟨Ĥ⟩ copies its input ⟨Ĥ⟩
>>> (e) simulated ⟨Ĥ⟩ invokes simulated embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
>>> (f) simulated embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
>>> (g) goto (d) with one more level of simulation
>>
>> Linz says nothing about simulations
>
> I am the sole inventor of the simulating halt decider.
>
> Ben Bacarisse contacted professor Sipser to verify that he
> really did says this. The details are in this forum about
> the same date.
>
> https://www.amazon.com/Introduction-Theory-Computation-Michael-Sipser/dp/113318779X/
>
> <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
> If simulating halt decider H correctly simulates its input D
> until H correctly determines that its simulated D would never
> stop running unless aborted then
>
> H can abort its simulation of D and correctly report that D
> specifies a non-halting sequence of configurations.
> </MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
And, as I remember, he also verified that he disagrees with your
definition of correct simulation.
>
> *Ben also verified that the criteria have been met*
> On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
> > I don't think that is the shell game. PO really /has/ an H
> > (it's trivial to do for this one case) that correctly determines
> > that P(P) *would* never stop running *unless* aborted.
Right, Ben was willing to do what I am not that you can prove that, by
your definition, H can show that it "must" abort its simulation or the
input will run forever.
But, just like me, he also agrees that this is NOT the defintion of
Halting, so H is just shown to be a correct (partial) POOP decider but
ot a Halt Decider, not even for that one input.
So, you are just pointing out the evidence that you are LYING about the
ACTUAL Halt Deciders, but just playing word shell games about your POOP.
>
>> or other methods H may use. Those are already fully determined by the
>> construction. But if H does those (c)..(g)
>> then so does Ĥ.
>>
>>> Two complete simulations show a pair of identical TMD's are
>>> simulating a pair of identical inputs. We can see this thus proving
>>> recursive simulation.
>>
>> Yes. However, this observation is not used in steps (c)..(g).
>>
>
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-22 09:11 -0500 |
| Subject | Re: Simulating termination analyzers by dummies --- criteria is met |
| Message-ID | <v56m2g$3or0r$8@dont-email.me> |
| In reply to | #107609 |
On 6/22/2024 8:27 AM, Richard Damon wrote:
> On 6/22/24 9:04 AM, olcott wrote:
>> On 6/22/2024 3:05 AM, Mikko wrote:
>>> On 2024-06-21 13:19:28 +0000, olcott said:
>>>
>>>> On 6/21/2024 2:11 AM, Mikko wrote:
>>>>> On 2024-06-20 15:23:09 +0000, olcott said:
>>>>>
>>>>>> On 6/20/2024 10:08 AM, Mikko wrote:
>>>>>>> On 2024-06-20 05:40:28 +0000, olcott said:
>>>>>>>
>>>>>>>> On 6/20/2024 12:29 AM, Mikko wrote:
>>>>>>>>> On 2024-06-19 14:05:29 +0000, olcott said:
>>>>>>>>>
>>>>>>>>>> On 6/19/2024 4:29 AM, Alan Mackenzie wrote:
>>>>>>>>>>> olcott <polcott333@gmail.com> wrote:
>>>>>>>>>>>> On 6/18/2024 4:36 PM, Alan Mackenzie wrote:
>>>>>>>>>>>>> [ Followup-To: set ]
>>>>>>>>>>>
>>>>>>>>>>>>> In comp.theory olcott <polcott333@gmail.com> wrote:
>>>>>>>>>>>>>> On 6/18/2024 12:57 PM, joes wrote:
>>>>>>>>>>>>>>> Am Tue, 18 Jun 2024 12:25:44 -0500 schrieb olcott:
>>>>>>>>>>>>>>>> On 6/18/2024 12:06 PM, joes wrote:
>>>>>>>>>>>>>>>> void DDD()
>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>> H0(DDD);
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>> DDD correctly simulated by any H0 cannot possibly halt.
>>>>>>>>>>>>>>>>> DDD halts iff H0 halts.
>>>>>>>>>>>
>>>>>>>>>>>>>>> So H0 returns "doesn't halt" to DDD, which then stops
>>>>>>>>>>>>>>> running,
>>>>>>>>>>>>>>> so H0 should have returned "halts".
>>>>>>>>>>>
>>>>>>>>>>>>>> This was three messages ago.
>>>>>>>>>>>>>> I had to make sure that you understood that halting
>>>>>>>>>>>>>> does not mean stopping for any reason and only includes
>>>>>>>>>>>>>> the equivalent of terminating normally.
>>>>>>>>>>>
>>>>>>>>>>>>> No. You're wrong, here. A turing machine is either
>>>>>>>>>>>>> running or it's
>>>>>>>>>>>>> halted. There's no third alternative. If your C programs
>>>>>>>>>>>>> are not in one
>>>>>>>>>>>>> of these two states, they're not equivalent to turing
>>>>>>>>>>>>> machines.
>>>>>>>>>>>
>>>>>>>>>>>> Although I agree with this there seems to be nuances of
>>>>>>>>>>>> disagreement across the experts.
>>>>>>>>>>>
>>>>>>>>>>> I doubt that very much. The whole point of turing machines
>>>>>>>>>>> is to remove
>>>>>>>>>>> ambiguity and unneeded features from the theory of
>>>>>>>>>>> computation. A third
>>>>>>>>>>> alternative state is unneeded.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Some people say that a TM can halt in a non-final state.
>>>>>>>>>
>>>>>>>>> People may use different words to express the same facts. What
>>>>>>>>> some
>>>>>>>>> people call "halting in a non-final state" is called
>>>>>>>>> "rejecting" by
>>>>>>>>> some other people. But the facts are what they are
>>>>>>>>> independently of
>>>>>>>>> the words used to express them.
>>>>>>>>
>>>>>>>> Ambiguity and vagueness make communication less effective.
>>>>>>>
>>>>>>> As does use of common words and expressions for uncommon meanings.
>>>>>>>
>>>>>>>> I use C because there are zero gaps in exactly what it means.
>>>>>>>
>>>>>>> THere are lont of gaps in C. Some are mistakes that are corrected in
>>>>>>> technical corrigenda. Others are undefined and implementation
>>>>>>> defined
>>>>>>> behaviour. Your program uses non-standard extensions to C so it does
>>>>>>> not communicate well. If also is too big to be a part of a
>>>>>>> publishable
>>>>>>> article.
>>>>>>>
>>>>>>
>>>>>> *There are zero gaps in the behavior of DDD correctly simulated by
>>>>>> HH0*
>>>>>> https://liarparadox.org/HH0_(DDD)_Full_Trace.pdf
>>>>>>
>>>>>> _DDD()
>>>>>> [00002093] 55 push ebp
>>>>>> [00002094] 8bec mov ebp,esp
>>>>>> [00002096] 6893200000 push 00002093 ; push DDD
>>>>>> [0000209b] e853f4ffff call 000014f3 ; call HH0
>>>>>> [000020a0] 83c404 add esp,+04
>>>>>> [000020a3] 5d pop ebp
>>>>>> [000020a4] c3 ret
>>>>>> Size in bytes:(0018) [000020a4]
>>>>>>
>>>>>> Whereas the Linz specification of Ĥ says that embedded_H
>>>>>> does something or other that is totally unspecified:
>>>>>>
>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>
>>>>> Linz Ĥ is fully defined in terms of H, so its behaviour can be
>>>>> inferred
>>>>> from the behaviour of H. Therefore Linz can prove about the
>>>>> behaviour of
>>>>> both Ĥ and H what needs be proven.
>>>>
>>>> (a) Ĥ copies its input ⟨Ĥ⟩
>>>> (b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
>>>> (c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
>>>> (d) simulated ⟨Ĥ⟩ copies its input ⟨Ĥ⟩
>>>> (e) simulated ⟨Ĥ⟩ invokes simulated embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
>>>> (f) simulated embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
>>>> (g) goto (d) with one more level of simulation
>>>
>>> Linz says nothing about simulations
>>
>> I am the sole inventor of the simulating halt decider.
>>
>> Ben Bacarisse contacted professor Sipser to verify that he
>> really did says this. The details are in this forum about
>> the same date.
>>
>> https://www.amazon.com/Introduction-Theory-Computation-Michael-Sipser/dp/113318779X/
>>
>> <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>> If simulating halt decider H correctly simulates its input D
>> until H correctly determines that its simulated D would never
>> stop running unless aborted then
>>
>> H can abort its simulation of D and correctly report that D
>> specifies a non-halting sequence of configurations.
>> </MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>
> And, as I remember, he also verified that he disagrees with your
> definition of correct simulation.
>
>>
>> *Ben also verified that the criteria have been met*
>> On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
>> > I don't think that is the shell game. PO really /has/ an H
>> > (it's trivial to do for this one case) that correctly determines
>> > that P(P) *would* never stop running *unless* aborted.
>
> Right, Ben was willing to do what I am not that you can prove that, by
> your definition, H can show that it "must" abort its simulation or the
> input will run forever.
>
> But, just like me, he also agrees that this is NOT the defintion of
> Halting, so H is just shown to be a correct (partial) POOP decider but
> ot a Halt Decider, not even for that one input.
>
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
> I don't think that is the shell game. PO really /has/ an H
> (it's trivial to do for this one case) that correctly determines
> that P(P) *would* never stop running *unless* aborted.
>
> He knows and accepts that P(P) actually does stop. The
> wrong answer is justified by what would happen if H
> (and hence a different P) where not what they actually are.
>
*Ben agrees that the criteria is met for the input*
Computable functions are the formalized analogue of the
intuitive notion of algorithms, in the sense that a function
is computable if there exists an algorithm that can do the
job of the function, i.e. *given an input of the function*
*domain it can return the corresponding output*
https://en.wikipedia.org/wiki/Computable_function
*Ben disagrees that the criteria is met for the non-input*
Yet no one here can stay focused on the fact that non-inputs
*DO NOT COUNT*
void DDD()
{
HHH0(DDD);
}
int main()
{
Output("Input_Halts = ", HHH0(DDD));
Output("Input_Halts = ", HHH1(DDD));
}
It is a verified fact that the behavior that finite string DDD
presents to HH0 is that when DDD correctly simulated by HH0
calls HH0(DDD) that this call DOES NOT RETURN.
It is a verified fact that the behavior that finite string DDD
presents to HH1 is that when DDD correctly simulated by HH1
calls HH0(DDD) that this call DOES RETURN.
*I don't get why people here insist on lying about verified facts*
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-22 10:20 -0400 |
| Subject | Re: Simulating termination analyzers by dummies --- criteria is met |
| Message-ID | <v56mis$onl4$8@i2pn2.org> |
| In reply to | #107614 |
On 6/22/24 10:11 AM, olcott wrote:
> On 6/22/2024 8:27 AM, Richard Damon wrote:
>> On 6/22/24 9:04 AM, olcott wrote:
>>> On 6/22/2024 3:05 AM, Mikko wrote:
>>>> On 2024-06-21 13:19:28 +0000, olcott said:
>>>>
>>>>> On 6/21/2024 2:11 AM, Mikko wrote:
>>>>>> On 2024-06-20 15:23:09 +0000, olcott said:
>>>>>>
>>>>>>> On 6/20/2024 10:08 AM, Mikko wrote:
>>>>>>>> On 2024-06-20 05:40:28 +0000, olcott said:
>>>>>>>>
>>>>>>>>> On 6/20/2024 12:29 AM, Mikko wrote:
>>>>>>>>>> On 2024-06-19 14:05:29 +0000, olcott said:
>>>>>>>>>>
>>>>>>>>>>> On 6/19/2024 4:29 AM, Alan Mackenzie wrote:
>>>>>>>>>>>> olcott <polcott333@gmail.com> wrote:
>>>>>>>>>>>>> On 6/18/2024 4:36 PM, Alan Mackenzie wrote:
>>>>>>>>>>>>>> [ Followup-To: set ]
>>>>>>>>>>>>
>>>>>>>>>>>>>> In comp.theory olcott <polcott333@gmail.com> wrote:
>>>>>>>>>>>>>>> On 6/18/2024 12:57 PM, joes wrote:
>>>>>>>>>>>>>>>> Am Tue, 18 Jun 2024 12:25:44 -0500 schrieb olcott:
>>>>>>>>>>>>>>>>> On 6/18/2024 12:06 PM, joes wrote:
>>>>>>>>>>>>>>>>> void DDD()
>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>> H0(DDD);
>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>> DDD correctly simulated by any H0 cannot possibly halt.
>>>>>>>>>>>>>>>>>> DDD halts iff H0 halts.
>>>>>>>>>>>>
>>>>>>>>>>>>>>>> So H0 returns "doesn't halt" to DDD, which then stops
>>>>>>>>>>>>>>>> running,
>>>>>>>>>>>>>>>> so H0 should have returned "halts".
>>>>>>>>>>>>
>>>>>>>>>>>>>>> This was three messages ago.
>>>>>>>>>>>>>>> I had to make sure that you understood that halting
>>>>>>>>>>>>>>> does not mean stopping for any reason and only includes
>>>>>>>>>>>>>>> the equivalent of terminating normally.
>>>>>>>>>>>>
>>>>>>>>>>>>>> No. You're wrong, here. A turing machine is either
>>>>>>>>>>>>>> running or it's
>>>>>>>>>>>>>> halted. There's no third alternative. If your C programs
>>>>>>>>>>>>>> are not in one
>>>>>>>>>>>>>> of these two states, they're not equivalent to turing
>>>>>>>>>>>>>> machines.
>>>>>>>>>>>>
>>>>>>>>>>>>> Although I agree with this there seems to be nuances of
>>>>>>>>>>>>> disagreement across the experts.
>>>>>>>>>>>>
>>>>>>>>>>>> I doubt that very much. The whole point of turing machines
>>>>>>>>>>>> is to remove
>>>>>>>>>>>> ambiguity and unneeded features from the theory of
>>>>>>>>>>>> computation. A third
>>>>>>>>>>>> alternative state is unneeded.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Some people say that a TM can halt in a non-final state.
>>>>>>>>>>
>>>>>>>>>> People may use different words to express the same facts. What
>>>>>>>>>> some
>>>>>>>>>> people call "halting in a non-final state" is called
>>>>>>>>>> "rejecting" by
>>>>>>>>>> some other people. But the facts are what they are
>>>>>>>>>> independently of
>>>>>>>>>> the words used to express them.
>>>>>>>>>
>>>>>>>>> Ambiguity and vagueness make communication less effective.
>>>>>>>>
>>>>>>>> As does use of common words and expressions for uncommon meanings.
>>>>>>>>
>>>>>>>>> I use C because there are zero gaps in exactly what it means.
>>>>>>>>
>>>>>>>> THere are lont of gaps in C. Some are mistakes that are
>>>>>>>> corrected in
>>>>>>>> technical corrigenda. Others are undefined and implementation
>>>>>>>> defined
>>>>>>>> behaviour. Your program uses non-standard extensions to C so it
>>>>>>>> does
>>>>>>>> not communicate well. If also is too big to be a part of a
>>>>>>>> publishable
>>>>>>>> article.
>>>>>>>>
>>>>>>>
>>>>>>> *There are zero gaps in the behavior of DDD correctly simulated
>>>>>>> by HH0*
>>>>>>> https://liarparadox.org/HH0_(DDD)_Full_Trace.pdf
>>>>>>>
>>>>>>> _DDD()
>>>>>>> [00002093] 55 push ebp
>>>>>>> [00002094] 8bec mov ebp,esp
>>>>>>> [00002096] 6893200000 push 00002093 ; push DDD
>>>>>>> [0000209b] e853f4ffff call 000014f3 ; call HH0
>>>>>>> [000020a0] 83c404 add esp,+04
>>>>>>> [000020a3] 5d pop ebp
>>>>>>> [000020a4] c3 ret
>>>>>>> Size in bytes:(0018) [000020a4]
>>>>>>>
>>>>>>> Whereas the Linz specification of Ĥ says that embedded_H
>>>>>>> does something or other that is totally unspecified:
>>>>>>>
>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>
>>>>>> Linz Ĥ is fully defined in terms of H, so its behaviour can be
>>>>>> inferred
>>>>>> from the behaviour of H. Therefore Linz can prove about the
>>>>>> behaviour of
>>>>>> both Ĥ and H what needs be proven.
>>>>>
>>>>> (a) Ĥ copies its input ⟨Ĥ⟩
>>>>> (b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>> (c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>> (d) simulated ⟨Ĥ⟩ copies its input ⟨Ĥ⟩
>>>>> (e) simulated ⟨Ĥ⟩ invokes simulated embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>> (f) simulated embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>> (g) goto (d) with one more level of simulation
>>>>
>>>> Linz says nothing about simulations
>>>
>>> I am the sole inventor of the simulating halt decider.
>>>
>>> Ben Bacarisse contacted professor Sipser to verify that he
>>> really did says this. The details are in this forum about
>>> the same date.
>>>
>>> https://www.amazon.com/Introduction-Theory-Computation-Michael-Sipser/dp/113318779X/
>>>
>>> <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>> If simulating halt decider H correctly simulates its input D
>>> until H correctly determines that its simulated D would never
>>> stop running unless aborted then
>>>
>>> H can abort its simulation of D and correctly report that D
>>> specifies a non-halting sequence of configurations.
>>> </MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>
>> And, as I remember, he also verified that he disagrees with your
>> definition of correct simulation.
>>
>>>
>>> *Ben also verified that the criteria have been met*
>>> On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
>>> > I don't think that is the shell game. PO really /has/ an H
>>> > (it's trivial to do for this one case) that correctly determines
>>> > that P(P) *would* never stop running *unless* aborted.
>>
>> Right, Ben was willing to do what I am not that you can prove that, by
>> your definition, H can show that it "must" abort its simulation or the
>> input will run forever.
>>
>> But, just like me, he also agrees that this is NOT the defintion of
>> Halting, so H is just shown to be a correct (partial) POOP decider but
>> ot a Halt Decider, not even for that one input.
>>
>
> On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
> > I don't think that is the shell game. PO really /has/ an H
> > (it's trivial to do for this one case) that correctly determines
> > that P(P) *would* never stop running *unless* aborted.
> >
> > He knows and accepts that P(P) actually does stop. The
> > wrong answer is justified by what would happen if H
> > (and hence a different P) where not what they actually are.
> >
> *Ben agrees that the criteria is met for the input*
>
> Computable functions are the formalized analogue of the
> intuitive notion of algorithms, in the sense that a function
> is computable if there exists an algorithm that can do the
> job of the function, i.e. *given an input of the function*
> *domain it can return the corresponding output*
> https://en.wikipedia.org/wiki/Computable_function
>
> *Ben disagrees that the criteria is met for the non-input*
> Yet no one here can stay focused on the fact that non-inputs
> *DO NOT COUNT*
No, you don't understand the words he is using because you have
distroted the meaning of too many words.
He is agreeing that H can correctly decide the POOP criteria, the it can
say that "no H can correctly simulate that input to a final state", but
he does NOT agree that it means it doesn't HALT, because that isn't the
meaning of Halting, and your definition of Correct Simulation isn't what
Professor Sipser was using, so you can't use that.
So, you are just stuck in your lies.
>
> void DDD()
> {
> HHH0(DDD);
> }
>
> int main()
> {
> Output("Input_Halts = ", HHH0(DDD));
> Output("Input_Halts = ", HHH1(DDD));
> }
>
> It is a verified fact that the behavior that finite string DDD
> presents to HH0 is that when DDD correctly simulated by HH0
> calls HH0(DDD) that this call DOES NOT RETURN.
>
> It is a verified fact that the behavior that finite string DDD
> presents to HH1 is that when DDD correctly simulated by HH1
> calls HH0(DDD) that this call DOES RETURN.
>
> *I don't get why people here insist on lying about verified facts*
>
>
The problem is that the "behavior" that the finite string DDD presents
to HH0, is DEFINED by the problem. And if that problem is the Halting
Problem, that behavior is the behavior of the machine the input
represents. If HH0 treats the input as having a different behavior, then
HH0 just isn't a Halting Decider, but something else.
If HH0 is supposed to be a Halting decider, but uses a method that makes
it see something other than that behavior, then it is just an incorrect
Halting Decider, and its algorithm just creates an incorrect recreation
of the property of the input it is supposed to be working on.
A bit of a side note, the actual "Input" to HH0, is a pointer to memory,
and as such it passes a reference to ALL of memory considering the
starting point to be that address, so your "Input" isn't actually the
few bytes of DDD, but ALL of memory and a starting point. If you
actually mean that the input is just those few bytes pointed to by the
address, then the input is improperly formed and is NOT a proper
representation of the input machine, becuase it is incomplete.
The fact you don't understand this, seems to imply you are lacking the
basic knowledge to be talking about this sort of thing.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-22 09:42 -0500 |
| Subject | Re: Simulating termination analyzers by dummies --- criteria is met |
| Message-ID | <v56nsv$3pr25$2@dont-email.me> |
| In reply to | #107615 |
On 6/22/2024 9:20 AM, Richard Damon wrote:
> On 6/22/24 10:11 AM, olcott wrote:
>> On 6/22/2024 8:27 AM, Richard Damon wrote:
>>> On 6/22/24 9:04 AM, olcott wrote:
>>>>
>>>> https://www.amazon.com/Introduction-Theory-Computation-Michael-Sipser/dp/113318779X/
>>>>
>>>> <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>>> If simulating halt decider H correctly simulates its input D
>>>> until H correctly determines that its simulated D would never
>>>> stop running unless aborted then
>>>>
>>>> H can abort its simulation of D and correctly report that D
>>>> specifies a non-halting sequence of configurations.
>>>> </MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>>
>>> And, as I remember, he also verified that he disagrees with your
>>> definition of correct simulation.
>>>
>>>>
>>>> *Ben also verified that the criteria have been met*
>>>> On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
>>>> > I don't think that is the shell game. PO really /has/ an H
>>>> > (it's trivial to do for this one case) that correctly determines
>>>> > that P(P) *would* never stop running *unless* aborted.
>>>
>>> Right, Ben was willing to do what I am not that you can prove that,
>>> by your definition, H can show that it "must" abort its simulation or
>>> the input will run forever.
>>>
>>> But, just like me, he also agrees that this is NOT the defintion of
>>> Halting, so H is just shown to be a correct (partial) POOP decider
>>> but ot a Halt Decider, not even for that one input.
>>>
>>
>> On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
>> > I don't think that is the shell game. PO really /has/ an H
>> > (it's trivial to do for this one case) that correctly determines
>> > that P(P) *would* never stop running *unless* aborted.
>> >
>> > He knows and accepts that P(P) actually does stop. The
>> > wrong answer is justified by what would happen if H
>> > (and hence a different P) where not what they actually are.
>> >
>> *Ben agrees that the criteria is met for the input*
>>
>> Computable functions are the formalized analogue of the
>> intuitive notion of algorithms, in the sense that a function
>> is computable if there exists an algorithm that can do the
>> job of the function, i.e. *given an input of the function*
>> *domain it can return the corresponding output*
>> https://en.wikipedia.org/wiki/Computable_function
>>
>> *Ben disagrees that the criteria is met for the non-input*
>> Yet no one here can stay focused on the fact that non-inputs
>> *DO NOT COUNT*
>
> No, you don't understand the words he is using because you have
> distroted the meaning of too many words.
>
> He is agreeing that H can correctly decide the POOP criteria, the it can
The criteria that professor Sipser agreed is correct
and agreed that I can quote his agreement.
> say that "no H can correctly simulate that input to a final state", but
> he does NOT agree that it means it doesn't HALT,
He also agreed that
>>>> H can abort its simulation of D and correctly report that D
>>>> specifies a non-halting sequence of configurations.
*So yet again you try to get away with denying verified facts*
and are busted.
> because that isn't the
> meaning of Halting, and your definition of Correct Simulation isn't what
> Professor Sipser was using, so you can't use that.
>
> So, you are just stuck in your lies.
>
>>
>> void DDD()
>> {
>> HHH0(DDD);
>> }
>>
>> int main()
>> {
>> Output("Input_Halts = ", HHH0(DDD));
>> Output("Input_Halts = ", HHH1(DDD));
>> }
>>
>> It is a verified fact that the behavior that finite string DDD
>> presents to HH0 is that when DDD correctly simulated by HH0
>> calls HH0(DDD) that this call DOES NOT RETURN.
>>
>> It is a verified fact that the behavior that finite string DDD
>> presents to HH1 is that when DDD correctly simulated by HH1
>> calls HH0(DDD) that this call DOES RETURN.
>>
>> *I don't get why people here insist on lying about verified facts*
>>
>>
>
>
> The problem is that the "behavior" that the finite string DDD presents
> to HH0, is DEFINED by the problem.
*Not not at all, not in the least little bit*
No textbook is allowed to override and supersede
the semantics of the x86 programming language.
Unlike you this does seem to be an honest mistake
on their part.
> And if that problem is the Halting
> Problem, that behavior is the behavior of the machine the input
> represents.
Some abstract idea that contradicts the semantics of the x86
programming language IS WRONG.
I have had enough of your willful deception for one post.
> If HH0 treats the input as having a different behavior, then
> HH0 just isn't a Halting Decider, but something else.
>
> If HH0 is supposed to be a Halting decider, but uses a method that makes
> it see something other than that behavior, then it is just an incorrect
> Halting Decider, and its algorithm just creates an incorrect recreation
> of the property of the input it is supposed to be working on.
>
>
> A bit of a side note, the actual "Input" to HH0, is a pointer to memory,
> and as such it passes a reference to ALL of memory considering the
> starting point to be that address, so your "Input" isn't actually the
> few bytes of DDD, but ALL of memory and a starting point. If you
> actually mean that the input is just those few bytes pointed to by the
> address, then the input is improperly formed and is NOT a proper
> representation of the input machine, becuase it is incomplete.
>
> The fact you don't understand this, seems to imply you are lacking the
> basic knowledge to be talking about this sort of thing.
>
--
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-22 11:08 -0400 |
| Subject | Re: Simulating termination analyzers by dummies --- criteria is met |
| Message-ID | <v56pcm$onl3$8@i2pn2.org> |
| In reply to | #107619 |
On 6/22/24 10:42 AM, olcott wrote:
> On 6/22/2024 9:20 AM, Richard Damon wrote:
>> On 6/22/24 10:11 AM, olcott wrote:
>>> On 6/22/2024 8:27 AM, Richard Damon wrote:
>>>> On 6/22/24 9:04 AM, olcott wrote:
>>>>>
>>>>> https://www.amazon.com/Introduction-Theory-Computation-Michael-Sipser/dp/113318779X/
>>>>>
>>>>> <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>>>> If simulating halt decider H correctly simulates its input D
>>>>> until H correctly determines that its simulated D would never
>>>>> stop running unless aborted then
>>>>>
>>>>> H can abort its simulation of D and correctly report that D
>>>>> specifies a non-halting sequence of configurations.
>>>>> </MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>>>
>>>> And, as I remember, he also verified that he disagrees with your
>>>> definition of correct simulation.
>>>>
>>>>>
>>>>> *Ben also verified that the criteria have been met*
>>>>> On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
>>>>> > I don't think that is the shell game. PO really /has/ an H
>>>>> > (it's trivial to do for this one case) that correctly determines
>>>>> > that P(P) *would* never stop running *unless* aborted.
>>>>
>>>> Right, Ben was willing to do what I am not that you can prove that,
>>>> by your definition, H can show that it "must" abort its simulation
>>>> or the input will run forever.
>>>>
>>>> But, just like me, he also agrees that this is NOT the defintion of
>>>> Halting, so H is just shown to be a correct (partial) POOP decider
>>>> but ot a Halt Decider, not even for that one input.
>>>>
>>>
>>> On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
>>> > I don't think that is the shell game. PO really /has/ an H
>>> > (it's trivial to do for this one case) that correctly determines
>>> > that P(P) *would* never stop running *unless* aborted.
>>> >
>>> > He knows and accepts that P(P) actually does stop. The
>>> > wrong answer is justified by what would happen if H
>>> > (and hence a different P) where not what they actually are.
>>> >
>>> *Ben agrees that the criteria is met for the input*
>>>
>>> Computable functions are the formalized analogue of the
>>> intuitive notion of algorithms, in the sense that a function
>>> is computable if there exists an algorithm that can do the
>>> job of the function, i.e. *given an input of the function*
>>> *domain it can return the corresponding output*
>>> https://en.wikipedia.org/wiki/Computable_function
>>>
>>> *Ben disagrees that the criteria is met for the non-input*
>>> Yet no one here can stay focused on the fact that non-inputs
>>> *DO NOT COUNT*
>>
>> No, you don't understand the words he is using because you have
>> distroted the meaning of too many words.
>>
>> He is agreeing that H can correctly decide the POOP criteria, the it can
>
> The criteria that professor Sipser agreed is correct
> and agreed that I can quote his agreement.
>
>> say that "no H can correctly simulate that input to a final state",
>> but he does NOT agree that it means it doesn't HALT,
And the ONLY meaning that Professor Sipser has for "Correctly Simulate"
is a simulation that EXACTLY reproduces the behavior of the input, and
that means doesn't abort. Which H doesn't do.
Also, the input to a Halt Decider is the representation of a COMPLETE
PROGRAM, so in your case, the D specifies an exact H that it uses.
So, when you use his statement to "change H", you change JUST the H
doing the deciding, and NOT the H that is used by D, that is still the
original H.
When we do this, your hypothetical H doing the simulating WILL SEE (if
it runs long enough) the simulate original-H deciding it can use the
criteria to abort, and then return 0 to the D that called it and D halting.
Thus, original-H is INCORRECT in thinking that it can correctly decide
that "NO H" can never correctly simulate THIS INPUT to a final state, as
some alternate Hs can.
>
> He also agreed that
> >>>> H can abort its simulation of D and correctly report that D
> >>>> specifies a non-halting sequence of configurations.
But only if it proved the first step.
>
> *So yet again you try to get away with denying verified facts*
> and are busted.
>
Nope, your lies are exposed an YOU are busted.
You fundamentally don't understand the rules of the game you are trying
to play, and keep on making illegal moves and complaing that the other
player, who does know the rules, is cheating by not letting you make the
illegal moves.
>> because that isn't the meaning of Halting, and your definition of
>> Correct Simulation isn't what Professor Sipser was using, so you can't
>> use that.
>>
>> So, you are just stuck in your lies.
>>
>>>
>>> void DDD()
>>> {
>>> HHH0(DDD);
>>> }
>>>
>>> int main()
>>> {
>>> Output("Input_Halts = ", HHH0(DDD));
>>> Output("Input_Halts = ", HHH1(DDD));
>>> }
>>>
>>> It is a verified fact that the behavior that finite string DDD
>>> presents to HH0 is that when DDD correctly simulated by HH0
>>> calls HH0(DDD) that this call DOES NOT RETURN.
>>>
>>> It is a verified fact that the behavior that finite string DDD
>>> presents to HH1 is that when DDD correctly simulated by HH1
>>> calls HH0(DDD) that this call DOES RETURN.
>>>
>>> *I don't get why people here insist on lying about verified facts*
>>>
>>>
>>
>>
>> The problem is that the "behavior" that the finite string DDD presents
>> to HH0, is DEFINED by the problem.
>
> *Not not at all, not in the least little bit*
>
> No textbook is allowed to override and supersede
> the semantics of the x86 programming language.
So, what in the x86 programming language says ANYTHING about "Halt
Deciding"? (citation please, or you admit to making that up)
And, as has been shown, the ACTUAL behavior of a correct simulation of
the x86 code EXACTLY REPRODUCES the behavior of the input directly
executed. The "difference" you see are when you don't actually simulate
an instruction by try to argue (incorrectly) what it must be the
equivalent of.,
for instance, a CALL H instruction, since H WILL return 0 when directly
called, WILL eventally see a return with the value of 0.
The fact the simulator can't simulate to that point for any version of H
you try to make doesn't change that behavior, it just means that no H
can KNOW what the will do before it decides it needs to stop to give an
answer.
it can't just assume it will not return, THAT is incorrect logic.
>
> Unlike you this does seem to be an honest mistake
> on their part.
Nope, just shows you don't know what you are talking about.
>
>> And if that problem is the Halting Problem, that behavior is the
>> behavior of the machine the input represents.
>
> Some abstract idea that contradicts the semantics of the x86
> programming language IS WRONG.
>
> I have had enough of your willful deception for one post.
>
>> If HH0 treats the input as having a different behavior, then HH0 just
>> isn't a Halting Decider, but something else.
>>
>> If HH0 is supposed to be a Halting decider, but uses a method that
>> makes it see something other than that behavior, then it is just an
>> incorrect Halting Decider, and its algorithm just creates an incorrect
>> recreation of the property of the input it is supposed to be working on.
>>
>>
>> A bit of a side note, the actual "Input" to HH0, is a pointer to
>> memory, and as such it passes a reference to ALL of memory considering
>> the starting point to be that address, so your "Input" isn't actually
>> the few bytes of DDD, but ALL of memory and a starting point. If you
>> actually mean that the input is just those few bytes pointed to by the
>> address, then the input is improperly formed and is NOT a proper
>> representation of the input machine, becuase it is incomplete.
>>
>> The fact you don't understand this, seems to imply you are lacking the
>> basic knowledge to be talking about this sort of thing.
>>
>
[toc] | [prev] | [next] | [standalone]
| From | joes <noreply@example.com> |
|---|---|
| Date | 2024-06-22 14:53 +0000 |
| Subject | Re: Simulating termination analyzers by dummies --- criteria is met |
| Message-ID | <v56oi2$p1du$1@i2pn2.org> |
| In reply to | #107614 |
Am Sat, 22 Jun 2024 09:11:28 -0500 schrieb olcott:
> On 6/22/2024 8:27 AM, Richard Damon wrote:
>> On 6/22/24 9:04 AM, olcott wrote:
>>> On 6/22/2024 3:05 AM, Mikko wrote:
>>>> On 2024-06-21 13:19:28 +0000, olcott said:
>>>>> On 6/21/2024 2:11 AM, Mikko wrote:
>>>>>> On 2024-06-20 15:23:09 +0000, olcott said:
>>>>>>> On 6/20/2024 10:08 AM, Mikko wrote:
>>>>>>>> On 2024-06-20 05:40:28 +0000, olcott said:
>>>>>>>>> On 6/20/2024 12:29 AM, Mikko wrote:
>>>>>>>>>> On 2024-06-19 14:05:29 +0000, olcott said:
>>>>>>>>>>> On 6/19/2024 4:29 AM, Alan Mackenzie wrote:
>>>>>>>>>>>> olcott <polcott333@gmail.com> wrote:
>>>>>>>>>>>>> On 6/18/2024 4:36 PM, Alan Mackenzie wrote:
>>>>>>>>>>>>>> In comp.theory olcott <polcott333@gmail.com> wrote:
>>>>>>>>>>>>>>> On 6/18/2024 12:57 PM, joes wrote:
>>>>>>>>>>>>>>>> Am Tue, 18 Jun 2024 12:25:44 -0500 schrieb olcott:
>>>>>>>>>>>>>>>>> On 6/18/2024 12:06 PM, joes wrote:
>>>>>>>>> I use C because there are zero gaps in exactly what it means.
>>>>>>>>
>>>>>>>> THere are lont of gaps in C. Some are mistakes that are corrected
>>>>>>>> in technical corrigenda. Others are undefined and implementation
>>>>>>>> defined behaviour. Your program uses non-standard extensions to C
>>>>>>>> so it does not communicate well. If also is too big to be a part
>>>>>>>> of a publishable article.
>>>>>>>>
>>>>>>> *There are zero gaps in the behavior of DDD correctly simulated by
>>>>>>> HH0*
That is a completely different statement. Still wrong, as HH0 can't
simulate itself.
>>>>>> Linz Ĥ is fully defined in terms of H, so its behaviour can be
>>>>>> inferred from the behaviour of H. Therefore Linz can prove about
>>>>>> the behaviour of both Ĥ and H what needs be proven.
>>> Ben Bacarisse contacted professor Sipser to verify that he really did
>>> says this. The details are in this forum about the same date.
>> And, as I remember, he also verified that he disagrees with your
>> definition of correct simulation.
>>> On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
>>> > I don't think that is the shell game. PO really /has/ an H (it's
>>> > trivial to do for this one case) that correctly determines that
>>> > P(P) *would* never stop running *unless* aborted.
>> Right, Ben was willing to do what I am not that you can prove that, by
>> your definition, H can show that it "must" abort its simulation or the
>> input will run forever.
>> But, just like me, he also agrees that this is NOT the defintion of
>> Halting, so H is just shown to be a correct (partial) POOP decider but
>> ot a Halt Decider, not even for that one input.
> On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
> > He knows and accepts that P(P) actually does stop. The wrong answer
> > is justified by what would happen if H (and hence a different P)
> > were not what they actually are.
> *Ben agrees that the criteria is met for the input*
> *Ben disagrees that the criteria is met for the non-input*
> Yet no one here can stay focused on the fact that non-inputs *DO NOT
> COUNT*
The input is always just DDD, along with its embedded "decider".
> void DDD()
> {
> HHH0(DDD);
> }
> int main()
> {
> Output("Input_Halts = ", HHH0(DDD));
> Output("Input_Halts = ", HHH1(DDD));
> }
>
> It is a verified fact that the behavior that finite string DDD presents
> to HH0 is that when DDD correctly simulated by HH0 calls HH0(DDD) that
> this call DOES NOT RETURN.
Making DDD's halting undecidable.
> It is a verified fact that the behavior that finite string DDD presents
> to HH1 is that when DDD correctly simulated by HH1 calls HH0(DDD) that
> this call DOES RETURN.
This is the correct behaviour.
--
Man kann mit dunklen Zahlen nicht rechnen. Für die eigentliche Mathematik
sind sie vollkommen nutzlos. --Wolfgang Mückenheim
[toc] | [prev] | [next] | [standalone]
| From | Mikko <mikko.levanto@iki.fi> |
|---|---|
| Date | 2024-06-23 10:57 +0300 |
| Subject | Re: Simulating termination analyzers by dummies --- criteria is met |
| Message-ID | <v58ki1$8e51$1@dont-email.me> |
| In reply to | #107614 |
On 2024-06-22 14:11:28 +0000, olcott said:
> On 6/22/2024 8:27 AM, Richard Damon wrote:
>> On 6/22/24 9:04 AM, olcott wrote:
>>> On 6/22/2024 3:05 AM, Mikko wrote:
>>>> On 2024-06-21 13:19:28 +0000, olcott said:
>>>>
>>>>> On 6/21/2024 2:11 AM, Mikko wrote:
>>>>>> On 2024-06-20 15:23:09 +0000, olcott said:
>>>>>>
>>>>>>> On 6/20/2024 10:08 AM, Mikko wrote:
>>>>>>>> On 2024-06-20 05:40:28 +0000, olcott said:
>>>>>>>>
>>>>>>>>> On 6/20/2024 12:29 AM, Mikko wrote:
>>>>>>>>>> On 2024-06-19 14:05:29 +0000, olcott said:
>>>>>>>>>>
>>>>>>>>>>> On 6/19/2024 4:29 AM, Alan Mackenzie wrote:
>>>>>>>>>>>> olcott <polcott333@gmail.com> wrote:
>>>>>>>>>>>>> On 6/18/2024 4:36 PM, Alan Mackenzie wrote:
>>>>>>>>>>>>>> [ Followup-To: set ]
>>>>>>>>>>>>
>>>>>>>>>>>>>> In comp.theory olcott <polcott333@gmail.com> wrote:
>>>>>>>>>>>>>>> On 6/18/2024 12:57 PM, joes wrote:
>>>>>>>>>>>>>>>> Am Tue, 18 Jun 2024 12:25:44 -0500 schrieb olcott:
>>>>>>>>>>>>>>>>> On 6/18/2024 12:06 PM, joes wrote:
>>>>>>>>>>>>>>>>> void DDD()
>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>> H0(DDD);
>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>> DDD correctly simulated by any H0 cannot possibly halt.
>>>>>>>>>>>>>>>>>> DDD halts iff H0 halts.
>>>>>>>>>>>>
>>>>>>>>>>>>>>>> So H0 returns "doesn't halt" to DDD, which then stops running,
>>>>>>>>>>>>>>>> so H0 should have returned "halts".
>>>>>>>>>>>>
>>>>>>>>>>>>>>> This was three messages ago.
>>>>>>>>>>>>>>> I had to make sure that you understood that halting
>>>>>>>>>>>>>>> does not mean stopping for any reason and only includes
>>>>>>>>>>>>>>> the equivalent of terminating normally.
>>>>>>>>>>>>
>>>>>>>>>>>>>> No. You're wrong, here. A turing machine is either running or it's
>>>>>>>>>>>>>> halted. There's no third alternative. If your C programs are not in one
>>>>>>>>>>>>>> of these two states, they're not equivalent to turing machines.
>>>>>>>>>>>>
>>>>>>>>>>>>> Although I agree with this there seems to be nuances of
>>>>>>>>>>>>> disagreement across the experts.
>>>>>>>>>>>>
>>>>>>>>>>>> I doubt that very much. The whole point of turing machines is to remove
>>>>>>>>>>>> ambiguity and unneeded features from the theory of computation. A third
>>>>>>>>>>>> alternative state is unneeded.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Some people say that a TM can halt in a non-final state.
>>>>>>>>>>
>>>>>>>>>> People may use different words to express the same facts. What some
>>>>>>>>>> people call "halting in a non-final state" is called "rejecting" by
>>>>>>>>>> some other people. But the facts are what they are independently of
>>>>>>>>>> the words used to express them.
>>>>>>>>>
>>>>>>>>> Ambiguity and vagueness make communication less effective.
>>>>>>>>
>>>>>>>> As does use of common words and expressions for uncommon meanings.
>>>>>>>>
>>>>>>>>> I use C because there are zero gaps in exactly what it means.
>>>>>>>>
>>>>>>>> THere are lont of gaps in C. Some are mistakes that are corrected in
>>>>>>>> technical corrigenda. Others are undefined and implementation defined
>>>>>>>> behaviour. Your program uses non-standard extensions to C so it does
>>>>>>>> not communicate well. If also is too big to be a part of a publishable
>>>>>>>> article.
>>>>>>>>
>>>>>>>
>>>>>>> *There are zero gaps in the behavior of DDD correctly simulated by HH0*
>>>>>>> https://liarparadox.org/HH0_(DDD)_Full_Trace.pdf
>>>>>>>
>>>>>>> _DDD()
>>>>>>> [00002093] 55 push ebp
>>>>>>> [00002094] 8bec mov ebp,esp
>>>>>>> [00002096] 6893200000 push 00002093 ; push DDD
>>>>>>> [0000209b] e853f4ffff call 000014f3 ; call HH0
>>>>>>> [000020a0] 83c404 add esp,+04
>>>>>>> [000020a3] 5d pop ebp
>>>>>>> [000020a4] c3 ret
>>>>>>> Size in bytes:(0018) [000020a4]
>>>>>>>
>>>>>>> Whereas the Linz specification of Ĥ says that embedded_H
>>>>>>> does something or other that is totally unspecified:
>>>>>>>
>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>
>>>>>> Linz Ĥ is fully defined in terms of H, so its behaviour can be inferred
>>>>>> from the behaviour of H. Therefore Linz can prove about the behaviour of
>>>>>> both Ĥ and H what needs be proven.
>>>>>
>>>>> (a) Ĥ copies its input ⟨Ĥ⟩
>>>>> (b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>> (c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>> (d) simulated ⟨Ĥ⟩ copies its input ⟨Ĥ⟩
>>>>> (e) simulated ⟨Ĥ⟩ invokes simulated embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>> (f) simulated embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>> (g) goto (d) with one more level of simulation
>>>>
>>>> Linz says nothing about simulations
>>>
>>> I am the sole inventor of the simulating halt decider.
>>>
>>> Ben Bacarisse contacted professor Sipser to verify that he
>>> really did says this. The details are in this forum about
>>> the same date.
>>>
>>> https://www.amazon.com/Introduction-Theory-Computation-Michael-Sipser/dp/113318779X/
>>>
>>>
>>> <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>> If simulating halt decider H correctly simulates its input D
>>> until H correctly determines that its simulated D would never
>>> stop running unless aborted then
>>>
>>> H can abort its simulation of D and correctly report that D
>>> specifies a non-halting sequence of configurations.
>>> </MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>
>> And, as I remember, he also verified that he disagrees with your
>> definition of correct simulation.
>>
>>>
>>> *Ben also verified that the criteria have been met*
>>> On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
>>> > I don't think that is the shell game. PO really /has/ an H
>>> > (it's trivial to do for this one case) that correctly determines
>>> > that P(P) *would* never stop running *unless* aborted.
>>
>> Right, Ben was willing to do what I am not that you can prove that, by
>> your definition, H can show that it "must" abort its simulation or the
>> input will run forever.
>>
>> But, just like me, he also agrees that this is NOT the defintion of
>> Halting, so H is just shown to be a correct (partial) POOP decider but
>> ot a Halt Decider, not even for that one input.
>>
>
> On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
> > I don't think that is the shell game. PO really /has/ an H
> > (it's trivial to do for this one case) that correctly determines
> > that P(P) *would* never stop running *unless* aborted.
> >
> > He knows and accepts that P(P) actually does stop. The
> > wrong answer is justified by what would happen if H
> > (and hence a different P) where not what they actually are.
> >
> *Ben agrees that the criteria is met for the input*
>
> Computable functions are the formalized analogue of the
> intuitive notion of algorithms, in the sense that a function
> is computable if there exists an algorithm that can do the
> job of the function, i.e. *given an input of the function*
> *domain it can return the corresponding output*
> https://en.wikipedia.org/wiki/Computable_function
>
> *Ben disagrees that the criteria is met for the non-input*
> Yet no one here can stay focused on the fact that non-inputs
> *DO NOT COUNT*
In particular, you can't. You have insisted that your "decider"
or "anlyzer" (or whatever word you happen to use) H or HH (or
hwatever name you happen to use) must return false because a
non-input (where instead of the actually called function another
function that does not halt is called) does not halt.
> void DDD()
> {
> HHH0(DDD);
> }
>
> int main()
> {
> Output("Input_Halts = ", HHH0(DDD));
> Output("Input_Halts = ", HHH1(DDD));
> }
>
> It is a verified fact that the behavior that finite string DDD
> presents to HH0 is that when DDD correctly simulated by HH0
> calls HH0(DDD) that this call DOES NOT RETURN.
>
> It is a verified fact that the behavior that finite string DDD
> presents to HH1 is that when DDD correctly simulated by HH1
> calls HH0(DDD) that this call DOES RETURN.
--
Mikko
[toc] | [prev] | [next] | [standalone]
Page 5 of 9 — ← Prev page 1 2 3 4 [5] 6 7 8 9 Next page →
Back to top | Article view | comp.theory
csiph-web