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 7 of 9 — ← Prev page 1 2 3 4 5 6 [7] 8 9 Next page →
| From | joes <noreply@example.com> |
|---|---|
| Date | 2024-06-19 17:43 +0000 |
| Subject | Re: Simulating termination analyzers by dummies --- What does halting mean? |
| Message-ID | <v4v5bm$fhqs$7@i2pn2.org> |
| In reply to | #107428 |
Am Wed, 19 Jun 2024 08:31:24 -0500 schrieb olcott: > On 6/19/2024 4:08 AM, joes wrote: >> Am Tue, 18 Jun 2024 21:51:56 -0500 schrieb olcott: >>> On 6/18/2024 9:41 PM, Richard Damon wrote: >>>> On 6/18/24 10:30 PM, olcott wrote: >>>>> On 6/18/2024 9:16 PM, Richard Damon wrote: >>>>>> On 6/18/24 1:25 PM, olcott wrote: >>>>>>> On 6/18/2024 12:06 PM, joes wrote: >>>> Terminating is a property of the actual machine, and not a simulation >>>> of it. Still true. >>> Thus according to your faulty reasoning when the source-code of a C >>> program is simulated by interpreter this is mere nonsense gibberish >>> having nothing to do what the behavior that this source-code >>> specifies. >> YOUR partial decider makes everything halt, even that which doesn't. >> So yes, it can't simulate infinite loops. > My partial decider makes everything stop running this is not at all the > same as halting. Novices get very confused about this. Your nonsimulator halts even when given nonterminating input. >>>> You could say the SIMULATION didn't terminate normally, but you can't >>>> say the machine didn't or even the Turing Machine Description, as you >>>> could give that exact same TMD to a real UTM and find out the actual >>>> behaviof or the input. >>> Sure you can otherwise interpreters of source-code would be a bogus >>> concept. >> When I write an infinite loop, I want it to be interpreted as an >> infinite loop. Your H0 is bogus. [deflection snipped] >>>> You just have lost track of the defintions of what is REALITY (the >>>> actual behavior of the machine) and what is just imagination. > (a) If the simulation of the x86 machine language of the > function does not prove the actual behavior that this finite string > specifies then source-code interpreters are a bogus concept. > (b) source-code interpreters are NOT a bogus concept. Your H0 is not an interpreter. It aborts infinite loops. >>>>> Every C programmer that knows what an x86 emulator is knows that >>>>> when H0 emulates the machine language of Infinite_Loop, >>>>> Infinite_Recursion, >>>>> and DDD that it must abort these emulations so that itself can >>>>> terminate normally. >>>> Which doesn't mean the program DDD needs to be abort to have it halt. >>> The verified that that it does need to be aborted contradicts your >>> nonsense to the contrary. >> [The verification that it ... ?] >> If H0 halts, so does DDD (which only calls it). > My partial decider makes everything stop running this is not at all the > same as halting. Novices get very confused about this. I was talking about DDD. It calls H0, which shall halt. Then DDD returns, having terminated. -- joes
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-19 12:48 -0500 |
| Subject | Re: Simulating termination analyzers by dummies --- the only reply until addressed |
| Message-ID | <v4v5l2$236bi$1@dont-email.me> |
| In reply to | #107454 |
On 6/19/2024 12:43 PM, joes wrote:
> Am Wed, 19 Jun 2024 08:31:24 -0500 schrieb olcott:
>> On 6/19/2024 4:08 AM, joes wrote:
>>> Am Tue, 18 Jun 2024 21:51:56 -0500 schrieb olcott:
>>>> On 6/18/2024 9:41 PM, Richard Damon wrote:
>>>>> On 6/18/24 10:30 PM, olcott wrote:
>>>>>> On 6/18/2024 9:16 PM, Richard Damon wrote:
>>>>>>> On 6/18/24 1:25 PM, olcott wrote:
>>>>>>>> On 6/18/2024 12:06 PM, joes wrote:
>
>>>>> Terminating is a property of the actual machine, and not a simulation
>>>>> of it.
> Still true.
>
>>>> Thus according to your faulty reasoning when the source-code of a C
>>>> program is simulated by interpreter this is mere nonsense gibberish
>>>> having nothing to do what the behavior that this source-code
>>>> specifies.
>>> YOUR partial decider makes everything halt, even that which doesn't.
>>> So yes, it can't simulate infinite loops.
>> My partial decider makes everything stop running this is not at all the
>> same as halting. Novices get very confused about this.
> Your nonsimulator halts even when given nonterminating input.
>
>>>>> You could say the SIMULATION didn't terminate normally, but you can't
>>>>> say the machine didn't or even the Turing Machine Description, as you
>>>>> could give that exact same TMD to a real UTM and find out the actual
>>>>> behaviof or the input.
>>>> Sure you can otherwise interpreters of source-code would be a bogus
>>>> concept.
>>> When I write an infinite loop, I want it to be interpreted as an
>>> infinite loop. Your H0 is bogus.
> [deflection snipped]
>
>>>>> You just have lost track of the defintions of what is REALITY (the
>>>>> actual behavior of the machine) and what is just imagination.
>> (a) If the simulation of the x86 machine language of the
>> function does not prove the actual behavior that this finite string
>> specifies then source-code interpreters are a bogus concept.
>> (b) source-code interpreters are NOT a bogus concept.
> Your H0 is not an interpreter. It aborts infinite loops.
>
>>>>>> Every C programmer that knows what an x86 emulator is knows that
>>>>>> when H0 emulates the machine language of Infinite_Loop,
>>>>>> Infinite_Recursion,
>>>>>> and DDD that it must abort these emulations so that itself can
>>>>>> terminate normally.
>>>>> Which doesn't mean the program DDD needs to be abort to have it halt.
>>>> The verified that that it does need to be aborted contradicts your
>>>> nonsense to the contrary.
>>> [The verification that it ... ?]
>>> If H0 halts, so does DDD (which only calls it).
>> My partial decider makes everything stop running this is not at all the
>> same as halting. Novices get very confused about this.
> I was talking about DDD. It calls H0, which shall halt. Then DDD returns,
> having terminated.
>
void DDD()
{
H0(DDD);
}
_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]
Exactly which step of DDD emulated by H0 was emulated
incorrectly such that this emulation would be complete?
AKA DDD emulated by H0 reaches machine address [000020b3]
--
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-19 17:59 +0000 |
| Subject | Re: Simulating termination analyzers by dummies --- the only reply until addressed |
| Message-ID | <v4v6al$fhqs$10@i2pn2.org> |
| In reply to | #107456 |
Am Wed, 19 Jun 2024 12:48:18 -0500 schrieb olcott: > On 6/19/2024 12:43 PM, joes wrote: >> Am Wed, 19 Jun 2024 08:31:24 -0500 schrieb olcott: >>> On 6/19/2024 4:08 AM, joes wrote: >>>> Am Tue, 18 Jun 2024 21:51:56 -0500 schrieb olcott: >>>>> On 6/18/2024 9:41 PM, Richard Damon wrote: >>>>>> On 6/18/24 10:30 PM, olcott wrote: >>>>>>> On 6/18/2024 9:16 PM, Richard Damon wrote: >>>>>>>> On 6/18/24 1:25 PM, olcott wrote: >>>>>>>>> On 6/18/2024 12:06 PM, joes wrote: Please actually reply to my points instead of spamming. Which were: >>>>>> Terminating is a property of the actual machine, and not a >>>>>> simulation of it. >>>> YOUR partial decider makes everything halt, even that which doesn't. >>>> So yes, it can't simulate infinite loops. >> Your nonsimulator halts even when given nonterminating input. >>>>>> You could say the SIMULATION didn't terminate normally, but you >>>>>> can't say the machine didn't or even the Turing Machine >>>>>> Description, as you could give that exact same TMD to a real UTM >>>>>> and find out the actual behaviof or the input. >>>>> Sure you can otherwise interpreters of source-code would be a bogus >>>>> concept. >>>> When I write an infinite loop, I want it to be interpreted as an >>>> infinite loop. Your H0 is bogus. >>> If the simulation of the x86 machine language of the function does >>> not prove the actual behavior that this finite string specifies then >>> source-code interpreters are a bogus concept. >> Your H0 is not an interpreter. It aborts infinite loops. >>>>>> Which doesn't mean the program DDD needs to be abort to have it >>>>>> halt. >>>>> The verified that that it does need to be aborted contradicts your >>>>> nonsense to the contrary. >>>> [The verification that it ... ?] >>>> If H0 halts, so does DDD (which only calls it). >> I was talking about DDD. It calls H0, which shall halt. Then DDD >> returns, having terminated. > Exactly which step of DDD emulated by H0 was emulated incorrectly such > that this emulation would be complete? AKA DDD emulated by H0 reaches > machine address [000020b3] It was aborted before it reached there.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-19 07:30 -0400 |
| Subject | Re: Simulating termination analyzers by dummies --- What does halting mean? |
| Message-ID | <v4ufgk$eqfo$1@i2pn2.org> |
| In reply to | #107411 |
On 6/18/24 10:51 PM, olcott wrote:
> On 6/18/2024 9:41 PM, Richard Damon wrote:
>> On 6/18/24 10:30 PM, olcott wrote:
>>> On 6/18/2024 9:16 PM, Richard Damon wrote:
>>>> On 6/18/24 1:25 PM, olcott wrote:
>>>>> 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.
>>>>>
>>>>> Halting is a technical term-of-the-art that corresponds
>>>>> to terminates normally. Because Turing machines are
>>>>> abstract mathematical objects there has been no notion
>>>>> of abnormal termination for a Turing machine.
>>>>
>>>> No "normally" as Turing Machine have no "abnormal terminatiom"
>>>>
>>>> You just don't understand what they are.
>>>>
>>>>>
>>>>> We can derive a notion of abnormal termination for Turing
>>>>> machines from the standard terms-of-the-art.
>>>>
>>>> How?
>>>>
>>>>>
>>>>> Some TM's loop and thus never stop running, this is classical
>>>>> non-halting behavior. UTM's simulate Turing machine descriptions.
>>>>> This is the same thing as an interpreter interpreting the
>>>>> source-code of a program.
>>>>>
>>>>> A UTM can be adapted so that it only simulates a fixed number
>>>>> of iterations of an input that loops. When this UTM stops
>>>>> simulating this Turing machine description we cannot correctly
>>>>> say that this looping input halted.
>>>>>
>>>>
>>>> And then are no longer UTMs, and YES, if a machine based on such am
>>>> modifed UTM (so it is no long a UTM) when the UTM stops simulating,
>>>> we can not say the input halted, nor can we say it didn't halt.
>>>>
>>>
>>> When such a UTM has been adapted to only simulate
>>> the first ten states of its input TMD, then every
>>> simulated TMD with more than ten states did not
>>> terminate normally.
>>
>> Then it is no longer a UTM.
>>
>> And its simulation say NOTHING about the machine not terminating,
>> normally nor not.
>>
>> Terminating is a property of the actual machine, and not a sumulation
>> of it.
>>
>
> Thus according to your faulty reasoning when the source-code
> of a C program is simulated by interpreter this is mere nonsense
> gibberish having nothing to do what the behavior that this
> source-code specifies.
>
Not at all, and just shows you don't understand the meaning of words, or
how logic works.
IF you can show that a given simulation will produce the exact same
results as the direct execution of the program, then the simulation will
show the actual behavior of the program.
Now, if it doesn't. then it is gibberish.
>> You could say the SIMULATION didn't terminate normally, but you can't
>> say the machine didn't or even the Turing Machine Description, as you
>> could give that exact same TMD to a real UTM and find out the actual
>> behaviof or the input.
>>
>
> Sure you can otherwise interpreters of source-code would be
> a bogus concept.
Right, a CORRECT simulation is one that produces the same result as the
original.
When we are talking about halting, then it means that the simulator
can't stop until it gets to the final state of the program it is simulating.
This means the "Correct Simulation" of a non-halting program will be
non-halting itself.
This means that a program that is a correct simulator can't be a halt
decider, as it could never answer non-halting, since it never finishes
the simulation.
It might be able to use a PARTIAL simulation, if it can show that if
this exact input was given to a complete and correct simulator, it would
not halt. This is NOT what you claim about your "Halt Deciders", which
don't even take actual descriptions of programs.
>
>> You just have lost track of the defintions of what is REALITY (the
>> actual behavior of the machine) and what is just imagination.
>>
> Not I but you.
Who is it that thinks that a Halting Program can be correctly decided as
Non-Halting?
>
>>>
>>>> The not-a-UTM just came to a no-answer state.
>>>>
>>>
>>> I have to go one-step-at-a-time with everyone or
>>> they get overwhelmed and leap to the conclusion
>>> that I am wrong.
>>
>> Nope, you just forget about what is defined to be real.
>>
>>>
>>>> The answer will be provided by useing an ACTUAL UTM that keeps on
>>>> going, or the direct execution of the machine,
>>>>
>>>> You are just stuck in your idea that Lies are sometimes ok.
>>>
>>> You are stuck on the idea that repeating states cannot
>>> be recognized in a finite number of steps.
>>
>> No, ACTUAL REPEATING states can be recognised, but I guess you are too
>> stupid to understand my description of it.
>>
>>>
>>> void Infinite_Loop()
>>> {
>>> HERE: goto HERE;
>>> }
>>>
>>> void Infinite_Recursion()
>>> {
>>> Infinite_Recursion();
>>> }
>>>
>>> void DDD()
>>> {
>>> H0(DDD);
>>> }
>>>
>>> Every C programmer that knows what an x86 emulator is knows
>>> that when H0 emulates the machine language of Infinite_Loop,
>>> Infinite_Recursion, and DDD that it must abort these emulations
>>> so that itself can terminate normally.
>>
>> Which doesn't mean the program DDD needs to be abort to have it halt.
>>
>
> The verified that that it does need to be aborted contradicts
> your nonsense to the contrary.
Nope. That hasn't been verified, you have tricked yourself to look at
the wrong input.
Remember, Program behavior deciders (like Halt Deciders) take in
representations of full programs, not templates, so when H takes in the
description of D, it must get ALL the code of D, including the H that it
calls. Yours claims that isn't what the input is, so you are living in a
world of wrong definitions,
>
>> That is just a figment of your imagination that doesn't understand the
>> difference between truth and lies.
>>
>>>
>>> This was recently confirmed in the C group.
>>>
>>
>> Yes, by Bonita, whose confirmation is, if anything a mark against the
>> statement.
>
> Are you sure that you are not a liar?
> I have had numerous experts in C confirm this.
> Bonita confirmed this: "Everything correct"
>
Yes.
Your problem is you are using poorly defined words to phrase your
question to have it mean something that it doesn't actually mean.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-19 09:23 -0500 |
| Subject | Re: Simulating termination analyzers by dummies --- What does halting mean? |
| Message-ID | <v4upk8$1vpm0$11@dont-email.me> |
| In reply to | #107422 |
On 6/19/2024 6:30 AM, Richard Damon wrote:
> On 6/18/24 10:51 PM, olcott wrote:
>>
>> Thus according to your faulty reasoning when the source-code
>> of a C program is simulated by interpreter this is mere nonsense
>> gibberish having nothing to do what the behavior that this
>> source-code specifies.
>>
>
> Not at all, and just shows you don't understand the meaning of words, or
> how logic works.
>
> IF you can show that a given simulation will produce the exact same
> results as the direct execution of the program, then the simulation will
> show the actual behavior of the program.
>
> Now, if it doesn't. then it is gibberish.
>
No matter how much you try to simply ignore the verified fact that
the pathological relationship between an input and its termination
analyzer changes the behavior of this emulated input relative to
the behavior of its direct execution
THIS VERIFIED FACT WILL NOT GO AWAY.
>>> You could say the SIMULATION didn't terminate normally, but you can't
>>> say the machine didn't or even the Turing Machine Description, as you
>>> could give that exact same TMD to a real UTM and find out the actual
>>> behaviof or the input.
>>>
>>
>> Sure you can otherwise interpreters of source-code would be
>> a bogus concept.
>
> Right, a CORRECT simulation is one that produces the same result as the
> original.
>
No. A correctly simulation is when each machine language instruction
of the input is correctly simulated and simulated in the correct order.
_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]
The call to the emulated H0 from DDD correctly emulated
by H0 CANNOT POSSIBLY RETURN.
The call to the directly executed H0 from the executed
DDD does return because
the directly executed D(D) is essentially the first call
in a recursive chain where the second call is always aborted.
> When we are talking about halting, then it means that the simulator
> can't stop until it gets to the final state of the program it is
> simulating.
>
Why contradict the definition of a decider that must always halt?
> This means the "Correct Simulation" of a non-halting program will be
> non-halting itself.
>
Why contradict the definition of a decider that must always halt?
> This means that a program that is a correct simulator can't be a halt
> decider, as it could never answer non-halting, since it never finishes
> the simulation.
>
> It might be able to use a PARTIAL simulation, if it can show that if
> this exact input was given to a complete and correct simulator, it would
> not halt. This is NOT what you claim about your "Halt Deciders", which
> don't even take actual descriptions of programs.
>
void Infinite_Loop()
{
HERE: goto HERE;
}
void Infinite_Recursion()
{
Infinite_Recursion();
}
void DDD()
{
H0(DDD);
}
Every C programmer that knows what an x86 emulator is knows
that when H0 emulates the machine language of Infinite_Loop,
Infinite_Recursion, and DDD that it must abort these emulations
so that itself can terminate normally.
If you don't know this then you simply lack the mandatory prerequisites.
>>> Yes, by Bonita, whose confirmation is, if anything a mark against the
>>> statement.
>>
>> Are you sure that you are not a liar?
>> I have had numerous experts in C confirm this.
>> Bonita confirmed this: "Everything correct"
>>
>
> Yes.
>
Then you would not have lied about this:
Bonita confirmed this: "Everything correct"
--
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-19 16:43 +0000 |
| Subject | Re: Simulating termination analyzers by dummies --- What does halting mean? |
| Message-ID | <v4v1r2$fhqs$2@i2pn2.org> |
| In reply to | #107436 |
Am Wed, 19 Jun 2024 09:23:04 -0500 schrieb olcott: > On 6/19/2024 6:30 AM, Richard Damon wrote: >> On 6/18/24 10:51 PM, olcott wrote: >>> >>> Thus according to your faulty reasoning when the source-code of a C >>> program is simulated by interpreter this is mere nonsense gibberish >>> having nothing to do what the behavior that this source-code >>> specifies. >> IF you can show that a given simulation will produce the exact same >> results as the direct execution of the program, then the simulation >> will show the actual behavior of the program. >> Now, if it doesn't. then it is gibberish. > No matter how much you try to simply ignore the verified fact that the > pathological relationship between an input and its termination analyzer > changes the behavior of this emulated input relative to the behavior of > its direct execution THIS VERIFIED FACT WILL NOT GO AWAY. That's just wrong. A program/machine has a fixed behaviour. >>>> You could say the SIMULATION didn't terminate normally, but you can't >>>> say the machine didn't or even the Turing Machine Description, as you >>>> could give that exact same TMD to a real UTM and find out the actual >>>> behavior of the input. >>> Sure you can otherwise interpreters of source-code would be a bogus >>> concept. >> Right, a CORRECT simulation is one that produces the same result as the >> original. > No. A correctly simulation is when each machine language instruction of > the input is correctly simulated and simulated in the correct order. And completely. > The call to the emulated H0 from DDD correctly emulated by H0 CANNOT > POSSIBLY RETURN. As a decider, H0 MUST return. > The call to the directly executed H0 from the executed DDD does return > because > the directly executed D(D) is essentially the first call in a recursive > chain where the second call is always aborted. >> When we are talking about halting, then it means that the simulator >> can't stop until it gets to the final state of the program it is >> simulating. > Why contradict the definition of a decider that must always halt? The requirements of being a simulator AND a decider contradict each other. That means that such a program cannot exist. >> This means the "Correct Simulation" of a non-halting program will be >> non-halting itself. > Why contradict the definition of a decider that must always halt? A nonterminating program doesn't suddenly become one that does. >> This means that a program that is a correct simulator can't be a halt >> decider, as it could never answer non-halting, since it never finishes >> the simulation. This is the core issue. >> It might be able to use a PARTIAL simulation, if it can show that if >> this exact input was given to a complete and correct simulator, it >> would not halt. This is NOT what you claim about your "Halt Deciders", >> which don't even take actual descriptions of programs. > Every C programmer that knows what an x86 emulator is knows that when H0 > emulates the machine language of Infinite_Loop, Infinite_Recursion, and > DDD that it must abort these emulations so that itself can terminate > normally. > If you don't know this then you simply lack the mandatory prerequisites. Nobody is disputing that part. It's not a simulation, though. >>>> Yes, by Bonita, whose confirmation is, if anything a mark against the >>>> statement. -- joes
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-19 12:09 -0500 |
| Subject | Re: Simulating termination analyzers by dummies --- What does halting mean? |
| Message-ID | <v4v3bv$22khl$2@dont-email.me> |
| In reply to | #107448 |
On 6/19/2024 11:43 AM, joes wrote: > Am Wed, 19 Jun 2024 09:23:04 -0500 schrieb olcott: >> On 6/19/2024 6:30 AM, Richard Damon wrote: >>> On 6/18/24 10:51 PM, olcott wrote: >>>> >>>> Thus according to your faulty reasoning when the source-code of a C >>>> program is simulated by interpreter this is mere nonsense gibberish >>>> having nothing to do what the behavior that this source-code >>>> specifies. >>> IF you can show that a given simulation will produce the exact same >>> results as the direct execution of the program, then the simulation >>> will show the actual behavior of the program. >>> Now, if it doesn't. then it is gibberish. >> No matter how much you try to simply ignore the verified fact that the >> pathological relationship between an input and its termination analyzer >> changes the behavior of this emulated input relative to the behavior of >> its direct execution THIS VERIFIED FACT WILL NOT GO AWAY. > That's just wrong. A program/machine has a fixed behaviour. > Ignoring my conclusive proof that DDD correctly simulated by HH0 has different behavior that DDD() is simply deception. -- Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-19 20:24 -0400 |
| Subject | Re: Simulating termination analyzers by dummies --- What does halting mean? |
| Message-ID | <v4vsr1$ggem$3@i2pn2.org> |
| In reply to | #107450 |
On 6/19/24 1:09 PM, olcott wrote: > On 6/19/2024 11:43 AM, joes wrote: >> Am Wed, 19 Jun 2024 09:23:04 -0500 schrieb olcott: >>> On 6/19/2024 6:30 AM, Richard Damon wrote: >>>> On 6/18/24 10:51 PM, olcott wrote: >>>>> >>>>> Thus according to your faulty reasoning when the source-code of a C >>>>> program is simulated by interpreter this is mere nonsense gibberish >>>>> having nothing to do what the behavior that this source-code >>>>> specifies. >>>> IF you can show that a given simulation will produce the exact same >>>> results as the direct execution of the program, then the simulation >>>> will show the actual behavior of the program. >>>> Now, if it doesn't. then it is gibberish. >>> No matter how much you try to simply ignore the verified fact that the >>> pathological relationship between an input and its termination analyzer >>> changes the behavior of this emulated input relative to the behavior of >>> its direct execution THIS VERIFIED FACT WILL NOT GO AWAY. >> That's just wrong. A program/machine has a fixed behaviour. >> > > Ignoring my conclusive proof that DDD correctly simulated by HH0 > has different behavior that DDD() is simply deception. > > You mean your lie that H0 even correctly simulated the input? SInce the trace it gives didn't go into H0, it is proven to be an incorrect trace, and that you are just ignorant of the actual behavior of the machines you are talking about.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-19 12:16 -0500 |
| Subject | Re: Simulating termination analyzers by dummies --- What does halting mean? |
| Message-ID | <v4v3pd$22qul$1@dont-email.me> |
| In reply to | #107448 |
On 6/19/2024 11:43 AM, joes wrote: > Am Wed, 19 Jun 2024 09:23:04 -0500 schrieb olcott: >> On 6/19/2024 6:30 AM, Richard Damon wrote: >>> On 6/18/24 10:51 PM, olcott wrote: >>>> >>>> Thus according to your faulty reasoning when the source-code of a C >>>> program is simulated by interpreter this is mere nonsense gibberish >>>> having nothing to do what the behavior that this source-code >>>> specifies. >>> IF you can show that a given simulation will produce the exact same >>> results as the direct execution of the program, then the simulation >>> will show the actual behavior of the program. >>> Now, if it doesn't. then it is gibberish. >> No matter how much you try to simply ignore the verified fact that the >> pathological relationship between an input and its termination analyzer >> changes the behavior of this emulated input relative to the behavior of >> its direct execution THIS VERIFIED FACT WILL NOT GO AWAY. > That's just wrong. A program/machine has a fixed behaviour. > >>>>> You could say the SIMULATION didn't terminate normally, but you can't >>>>> say the machine didn't or even the Turing Machine Description, as you >>>>> could give that exact same TMD to a real UTM and find out the actual >>>>> behavior of the input. >>>> Sure you can otherwise interpreters of source-code would be a bogus >>>> concept. >>> Right, a CORRECT simulation is one that produces the same result as the >>> original. >> No. A correctly simulation is when each machine language instruction of >> the input is correctly simulated and simulated in the correct order. > And completely. > *WRONG* Introduction to the Theory of Computation, by Michael Sipser 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 words10/13/2022> -- 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-19 17:32 +0000 |
| Subject | Re: Simulating termination analyzers by dummies --- What does halting mean? |
| Message-ID | <v4v4ne$fhqs$6@i2pn2.org> |
| In reply to | #107451 |
Am Wed, 19 Jun 2024 12:16:28 -0500 schrieb olcott: > On 6/19/2024 11:43 AM, joes wrote: >> Am Wed, 19 Jun 2024 09:23:04 -0500 schrieb olcott: >>> On 6/19/2024 6:30 AM, Richard Damon wrote: >>>> On 6/18/24 10:51 PM, olcott wrote: >>>> Right, a CORRECT simulation is one that produces the same result as >>>> the original. >>> No. A correctly simulation is when each machine language instruction >>> of the input is correctly simulated and simulated in the correct >>> order. >> And completely. > *WRONG* > [blah blah Sipser] Oh, a simulator can just say "lemme stop your infinite loop"? Your H is unable to produce identical behaviour. -- joes
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-19 12:40 -0500 |
| Subject | Re: Simulating termination analyzers by dummies --- What does halting mean? |
| Message-ID | <v4v56j$22qul$2@dont-email.me> |
| In reply to | #107452 |
On 6/19/2024 12:32 PM, joes wrote: > Am Wed, 19 Jun 2024 12:16:28 -0500 schrieb olcott: >> On 6/19/2024 11:43 AM, joes wrote: >>> Am Wed, 19 Jun 2024 09:23:04 -0500 schrieb olcott: >>>> On 6/19/2024 6:30 AM, Richard Damon wrote: >>>>> On 6/18/24 10:51 PM, olcott wrote: > >>>>> Right, a CORRECT simulation is one that produces the same result as >>>>> the original. >>>> No. A correctly simulation is when each machine language instruction >>>> of the input is correctly simulated and simulated in the correct >>>> order. >>> And completely. >> *WRONG* >> [blah blah Sipser] > Oh, a simulator can just say "lemme stop your infinite loop"? > Your H is unable to produce identical behaviour. > Professor Sipser is not wrong. After Professor Sipser agreed with me Ben Bacarisse was so upset that he was wrong for all of these years that he made a very active campaign to get people to stop talking to me. On 10/14/2022 7:44 PM, Ben Bacarisse wrote: > I don't think that is the shell game. PO really /has/ an H > (it's trivial to do for this one case) that correctly determines > that P(P) *would* never stop running *unless* aborted. -- Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-19 20:24 -0400 |
| Subject | Re: Simulating termination analyzers by dummies --- What does halting mean? |
| Message-ID | <v4vsr3$ggem$4@i2pn2.org> |
| In reply to | #107451 |
On 6/19/24 1:16 PM, olcott wrote: > On 6/19/2024 11:43 AM, joes wrote: >> Am Wed, 19 Jun 2024 09:23:04 -0500 schrieb olcott: >>> On 6/19/2024 6:30 AM, Richard Damon wrote: >>>> On 6/18/24 10:51 PM, olcott wrote: >>>>> >>>>> Thus according to your faulty reasoning when the source-code of a C >>>>> program is simulated by interpreter this is mere nonsense gibberish >>>>> having nothing to do what the behavior that this source-code >>>>> specifies. >>>> IF you can show that a given simulation will produce the exact same >>>> results as the direct execution of the program, then the simulation >>>> will show the actual behavior of the program. >>>> Now, if it doesn't. then it is gibberish. >>> No matter how much you try to simply ignore the verified fact that the >>> pathological relationship between an input and its termination analyzer >>> changes the behavior of this emulated input relative to the behavior of >>> its direct execution THIS VERIFIED FACT WILL NOT GO AWAY. >> That's just wrong. A program/machine has a fixed behaviour. >> >>>>>> You could say the SIMULATION didn't terminate normally, but you can't >>>>>> say the machine didn't or even the Turing Machine Description, as you >>>>>> could give that exact same TMD to a real UTM and find out the actual >>>>>> behavior of the input. >>>>> Sure you can otherwise interpreters of source-code would be a bogus >>>>> concept. >>>> Right, a CORRECT simulation is one that produces the same result as the >>>> original. >>> No. A correctly simulation is when each machine language instruction of >>> the input is correctly simulated and simulated in the correct order. >> And completely. >> > > *WRONG* > > Introduction to the Theory of Computation, by Michael Sipser > 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 words10/13/2022> > > And his definition of "Correctly Simulated" is a simulation that completely recreates the behavior of the input, which H does not do, nor does it correctly predicts about, since the input Halts because your decider says it doesn't So, you are just caught repeating the lie that you have had explained a number of times, and thus can't be an honest mistale, but just evidence that you are nothing but an ignorant Pathological Liar.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-19 20:24 -0400 |
| Subject | Re: Simulating termination analyzers by dummies --- What does halting mean? |
| Message-ID | <v4vsr0$ggem$2@i2pn2.org> |
| In reply to | #107436 |
On 6/19/24 10:23 AM, olcott wrote:
> On 6/19/2024 6:30 AM, Richard Damon wrote:
>> On 6/18/24 10:51 PM, olcott wrote:
>>>
>>> Thus according to your faulty reasoning when the source-code
>>> of a C program is simulated by interpreter this is mere nonsense
>>> gibberish having nothing to do what the behavior that this
>>> source-code specifies.
>>>
>>
>> Not at all, and just shows you don't understand the meaning of words,
>> or how logic works.
>>
>> IF you can show that a given simulation will produce the exact same
>> results as the direct execution of the program, then the simulation
>> will show the actual behavior of the program.
>>
>> Now, if it doesn't. then it is gibberish.
>>
>
> No matter how much you try to simply ignore the verified fact that
> the pathological relationship between an input and its termination
> analyzer changes the behavior of this emulated input relative to
> the behavior of its direct execution
> THIS VERIFIED FACT WILL NOT GO AWAY.
BUT IT HASN'T BEEN VERIFIED.
Your "Proof" has been shown to be based on a LIE, because your decider
never has been shown actually meet your requirements to correctly
simulate the input.
>
>>>> You could say the SIMULATION didn't terminate normally, but you
>>>> can't say the machine didn't or even the Turing Machine Description,
>>>> as you could give that exact same TMD to a real UTM and find out the
>>>> actual behaviof or the input.
>>>>
>>>
>>> Sure you can otherwise interpreters of source-code would be
>>> a bogus concept.
>>
>> Right, a CORRECT simulation is one that produces the same result as
>> the original.
>>
>
> No. A correctly simulation is when each machine language instruction
> of the input is correctly simulated and simulated in the correct order.
>
> _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]
So, the instruction at 00020A5, needs to be followed by the simulation
of the instruction at 000020AA, which since that is a call to 00001AA2,
needs to be followed by the simulation of the instruction as 00001AA2
>
> The call to the emulated H0 from DDD correctly emulated
> by H0 CANNOT POSSIBLY RETURN.
Why do you say that?
Are you admitting that the REAL H0(DDD) won't return?
>
> The call to the directly executed H0 from the executed
> DDD does return because
>
> the directly executed D(D) is essentially the first call
> in a recursive chain where the second call is always aborted.
Which is exactly what a CORRECT SIMULATION of that exact same
instruction set will show.
H0, if it DOES correctly simulate the input, will see the EXACT SAME set
of instructions, and thus the exact same behavior until it gives up and
stops simulating.
You have NEVER shown a simulation that shows a simulation that matches
your definition of a correct simulation, so you have no grounds to claim
it is correct. You did finally publish one trace that you claimed to
show it, until I pointed out after a quick look, that it wasn't the
simulation you were claiming, and thus obviously you never really looked
at it to confirm that it did verify what you claimed.
Thus, it has been FIRMLY ESTABLISHED, that you are NOT a "reliable
source" to use for verification.
>
>> When we are talking about halting, then it means that the simulator
>> can't stop until it gets to the final state of the program it is
>> simulating.
>>
>
> Why contradict the definition of a decider that must always halt?
I'm not, but a decider must also give the correct answer according to
the question it is DEFINED to be answering.
Which if it is a Halt Decider, is the behavior of the directly executied
machine.
If it can't do both, give an answer in finite time, and make that answer
correct, it is just an incorrect decider and fails at it one job.
You seem to think that it is ok to LIE at what you are doing in order to
make it look like you are doing what you are supposed to be doing.
>
>> This means the "Correct Simulation" of a non-halting program will be
>> non-halting itself.
>>
> Why contradict the definition of a decider that must always halt?
I don't. but needed to halt doesn't excuss for not giving the right answer.
You are just showing you think LIES are just normal activities.
>
>> This means that a program that is a correct simulator can't be a halt
>> decider, as it could never answer non-halting, since it never finishes
>> the simulation.
>>
>> It might be able to use a PARTIAL simulation, if it can show that if
>> this exact input was given to a complete and correct simulator, it
>> would not halt. This is NOT what you claim about your "Halt Deciders",
>> which don't even take actual descriptions of programs.
>>
>
> void Infinite_Loop()
> {
> HERE: goto HERE;
> }
>
> void Infinite_Recursion()
> {
> Infinite_Recursion();
> }
>
> void DDD()
> {
> H0(DDD);
> }
>
> Every C programmer that knows what an x86 emulator is knows
> that when H0 emulates the machine language of Infinite_Loop,
> Infinite_Recursion, and DDD that it must abort these emulations
> so that itself can terminate normally.
>
> If you don't know this then you simply lack the mandatory prerequisites.
But that isn't the question, so you are just tilting strawmen, and
proving that you are just talking about POOP and not Halting, and don;t
understand the differece.
>
>>>> Yes, by Bonita, whose confirmation is, if anything a mark against
>>>> the statement.
>>>
>>> Are you sure that you are not a liar?
>>> I have had numerous experts in C confirm this.
>>> Bonita confirmed this: "Everything correct"
>>>
>>
>> Yes.
>>
>
> Then you would not have lied about this:
> Bonita confirmed this: "Everything correct"
>
Because they are not an expert in C, as they have proven.
Just like you, they THINK they are, but aren't.
[toc] | [prev] | [next] | [standalone]
| From | joes <noreply@example.com> |
|---|---|
| Date | 2024-06-19 08:57 +0000 |
| Subject | Re: Simulating termination analyzers by dummies --- What does halting mean? |
| Message-ID | <v4u6i3$ec9m$2@i2pn2.org> |
| In reply to | #107409 |
Am Tue, 18 Jun 2024 21:30:43 -0500 schrieb olcott: > On 6/18/2024 9:16 PM, Richard Damon wrote: >> On 6/18/24 1:25 PM, olcott wrote: >>> On 6/18/2024 12:06 PM, joes wrote: >>> Some TM's loop and thus never stop running, this is classical >>> non-halting behavior. UTM's simulate Turing machine descriptions. >>> This is the same thing as an interpreter interpreting the source-code >>> of a program. >>> A UTM can be adapted so that it only simulates a fixed number of >>> iterations of an input that loops. When this UTM stops simulating this >>> Turing machine description we cannot correctly say that this looping >>> input halted. >> And then are no longer UTMs, and YES, if a machine based on such am >> modifed UTM (so it is no long a UTM) when the UTM stops simulating, we >> can not say the input halted, nor can we say it didn't halt. > When such a UTM has been adapted to only simulate the first ten states > of its input TMD, then every simulated TMD with more than ten states did > not terminate normally. You are confusing the machines with their simulators. No longer simulating has nothing to do with the simulatee. It does not "know" it is being simulated. That is entirely in the power of the simulator. Only it can freely choose to simulate more steps. The simulated machine then proceeds. >> The not-a-UTM just came to a no-answer state. > I have to go one-step-at-a-time with everyone or they get overwhelmed > and leap to the conclusion that I am wrong. >> The answer will be provided by useing an ACTUAL UTM that keeps on >> going, or the direct execution of the machine, > You are stuck on the idea that repeating states cannot be recognized in > a finite number of steps. Oh, they can. It's just that repeating states don't halt in a finite number of steps. -- joes
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-19 08:20 -0500 |
| Subject | Re: Simulating termination analyzers by dummies --- What does halting mean? |
| Message-ID | <v4ulus$1vpm0$5@dont-email.me> |
| In reply to | #107418 |
On 6/19/2024 3:57 AM, joes wrote:
> Am Tue, 18 Jun 2024 21:30:43 -0500 schrieb olcott:
>> On 6/18/2024 9:16 PM, Richard Damon wrote:
>>> On 6/18/24 1:25 PM, olcott wrote:
>>>> On 6/18/2024 12:06 PM, joes wrote:
>
>>>> Some TM's loop and thus never stop running, this is classical
>>>> non-halting behavior. UTM's simulate Turing machine descriptions.
>>>> This is the same thing as an interpreter interpreting the source-code
>>>> of a program.
>>>> A UTM can be adapted so that it only simulates a fixed number of
>>>> iterations of an input that loops. When this UTM stops simulating this
>>>> Turing machine description we cannot correctly say that this looping
>>>> input halted.
>>> And then are no longer UTMs, and YES, if a machine based on such am
>>> modifed UTM (so it is no long a UTM) when the UTM stops simulating, we
>>> can not say the input halted, nor can we say it didn't halt.
>> When such a UTM has been adapted to only simulate the first ten states
>> of its input TMD, then every simulated TMD with more than ten states did
>> not terminate normally.
> You are confusing the machines with their simulators. No longer simulating
> has nothing to do with the simulatee. It does not "know" it is being
> simulated. That is entirely in the power of the simulator. Only it can
> freely choose to simulate more steps. The simulated machine then proceeds.
>
>>> The not-a-UTM just came to a no-answer state.
>> I have to go one-step-at-a-time with everyone or they get overwhelmed
>> and leap to the conclusion that I am wrong.
>
I am establishing the notion of abnormal termination for Turing
machines within the standard terms of the art.
>
>>> The answer will be provided by useing an ACTUAL UTM that keeps on
>>> going, or the direct execution of the machine,
>> You are stuck on the idea that repeating states cannot be recognized in
>> a finite number of steps.
> Oh, they can. It's just that repeating states don't halt in a finite
> number of steps.
>
void DDD()
{
H0(DDD);
}
Richard cannot understand that H0 can correctly determine in a
finite number of steps that DDD correctly emulated by H0 cannot
halt in a finite number of steps. I used to think that he was
lying about this. It seems that the actual case is that I
overestimated his skill level.
Now that he says that when Bonita said "Everything correct"
he is taking this to mean something is wrong I am back to
thinking that he might be a liar.
--
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-19 16:25 +0000 |
| Subject | Re: Simulating termination analyzers by dummies --- What does halting mean? |
| Message-ID | <v4v0pc$fhqs$1@i2pn2.org> |
| In reply to | #107427 |
Am Wed, 19 Jun 2024 08:20:28 -0500 schrieb olcott:
> On 6/19/2024 3:57 AM, joes wrote:
>> Am Tue, 18 Jun 2024 21:30:43 -0500 schrieb olcott:
>>> On 6/18/2024 9:16 PM, Richard Damon wrote:
>>>> On 6/18/24 1:25 PM, olcott wrote:
>>>>> On 6/18/2024 12:06 PM, joes wrote:
>>>> And then are no longer UTMs, and YES, if a machine based on such am
>>>> modifed UTM (so it is no long a UTM) when the UTM stops simulating,
>>>> we can not say the input halted, nor can we say it didn't halt.
>>> When such a UTM has been adapted to only simulate the first ten states
>>> of its input TMD, then every simulated TMD with more than ten states
>>> did not terminate normally.
>> You are confusing the machines with their simulators. No longer
>> simulating has nothing to do with the simulatee. It does not "know" it
>> is being simulated. That is entirely in the power of the simulator.
>> Only it can freely choose to simulate more steps. The simulated machine
>> then proceeds.
Can you accept this?
>>>> The not-a-UTM just came to a no-answer state.
>>> I have to go one-step-at-a-time with everyone or they get overwhelmed
>>> and leap to the conclusion that I am wrong.
> I am establishing the notion of abnormal termination for Turing machines
> within the standard terms of the art.
The TM does not halt/terminate. The simulator does. Otherwise it would
continue. Whether the machine halts does not depend on how far you want
to calculate what it does.
>>>> The answer will be provided by useing an ACTUAL UTM that keeps on
>>>> going, or the direct execution of the machine,
>>> You are stuck on the idea that repeating states cannot be recognized
>>> in a finite number of steps.
>> Oh, they can. It's just that repeating states don't halt in a finite
>> number of steps.
> void DDD()
> {
> H0(DDD);
> }
> Richard cannot understand that H0 can determine in a finite
> number of steps that DDD correctly emulated by H0 cannot halt in a
> finite number of steps. I used to think that he was lying about this. It
> seems that the actual case is that I overestimated his skill level.
No, that part is correct.
Stop it with the insults.
> Now that he says that when Bonita said "Everything correct"
> he is taking this to mean something is wrong I am back to thinking that
> he might be a liar.
The continuation "no further questions allowed" makes it sarcastic. They
know you and want to keep you from spamming their group.
--
joes
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-19 20:24 -0400 |
| Subject | Re: Simulating termination analyzers by dummies --- What does halting mean? |
| Message-ID | <v4vsr6$ggem$5@i2pn2.org> |
| In reply to | #107427 |
On 6/19/24 9:20 AM, olcott wrote:
> On 6/19/2024 3:57 AM, joes wrote:
>> Am Tue, 18 Jun 2024 21:30:43 -0500 schrieb olcott:
>>> On 6/18/2024 9:16 PM, Richard Damon wrote:
>>>> On 6/18/24 1:25 PM, olcott wrote:
>>>>> On 6/18/2024 12:06 PM, joes wrote:
>>
>>>>> Some TM's loop and thus never stop running, this is classical
>>>>> non-halting behavior. UTM's simulate Turing machine descriptions.
>>>>> This is the same thing as an interpreter interpreting the source-code
>>>>> of a program.
>>>>> A UTM can be adapted so that it only simulates a fixed number of
>>>>> iterations of an input that loops. When this UTM stops simulating this
>>>>> Turing machine description we cannot correctly say that this looping
>>>>> input halted.
>>>> And then are no longer UTMs, and YES, if a machine based on such am
>>>> modifed UTM (so it is no long a UTM) when the UTM stops simulating, we
>>>> can not say the input halted, nor can we say it didn't halt.
>>> When such a UTM has been adapted to only simulate the first ten states
>>> of its input TMD, then every simulated TMD with more than ten states did
>>> not terminate normally.
>
>> You are confusing the machines with their simulators. No longer
>> simulating
>> has nothing to do with the simulatee. It does not "know" it is being
>> simulated. That is entirely in the power of the simulator. Only it can
>> freely choose to simulate more steps. The simulated machine then
>> proceeds.
>>
>>>> The not-a-UTM just came to a no-answer state.
>>> I have to go one-step-at-a-time with everyone or they get overwhelmed
>>> and leap to the conclusion that I am wrong.
>>
>
> I am establishing the notion of abnormal termination for Turing
> machines within the standard terms of the art.
>
>>
>>>> The answer will be provided by useing an ACTUAL UTM that keeps on
>>>> going, or the direct execution of the machine,
>>> You are stuck on the idea that repeating states cannot be recognized in
>>> a finite number of steps.
>
>> Oh, they can. It's just that repeating states don't halt in a finite
>> number of steps.
>>
>
> void DDD()
> {
> H0(DDD);
> }
>
> Richard cannot understand that H0 can correctly determine in a
> finite number of steps that DDD correctly emulated by H0 cannot
> halt in a finite number of steps. I used to think that he was
> lying about this. It seems that the actual case is that I
> overestimated his skill level.
>
L IIIII EEEEE
L I E
L I EEEE
L I E
LLLLL IIIII EEEEE
I fully understand how a decider can correctly determine in a finite
number of steps how inputs like infinite_loop or infinite_recursion can
be detected.
What is an illogical statement is about DDD correctly simulated by H0,
since it doesn't DO an actual correct simulation, only a partial one,
and you can't even show it does that (sincd you never show it simulating
into H0).
Then you try to LIE with invalid logic of looking at DIFFERENT inputs of
DDD's built on DIFFERENT version of H0, whoich just shows you don't
understand the elementary basics of the field you are trying to talk about.
> Now that he says that when Bonita said "Everything correct"
> he is taking this to mean something is wrong I am back to
> thinking that he might be a liar.
>
Nope, they are just showing they are as ignorant of the topic as you are.
You seemed to have missed the class on Logical Fallacies, and the error
of Arguemnt by (False) Authority.
[toc] | [prev] | [next] | [standalone]
| From | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2024-06-19 10:18 +0200 |
| Subject | Re: Simulating termination analyzers by dummies --- What does halting mean? |
| Message-ID | <v4u48g$1rrod$3@dont-email.me> |
| In reply to | #107393 |
Op 18.jun.2024 om 19:25 schreef 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.
>
> Halting is a technical term-of-the-art that corresponds
> to terminates normally. Because Turing machines are
> abstract mathematical objects there has been no notion
> of abnormal termination for a Turing machine.
>
> We can derive a notion of abnormal termination for Turing
> machines from the standard terms-of-the-art.
>
> Some TM's loop and thus never stop running, this is classical
> non-halting behavior. UTM's simulate Turing machine descriptions.
> This is the same thing as an interpreter interpreting the
> source-code of a program.
>
> A UTM can be adapted so that it only simulates a fixed number
> of iterations of an input that loops. When this UTM stops
> simulating this Turing machine description we cannot correctly
> say that this looping input halted.
>
If the code specifies 5 iterations and the simulator simulates only 3
iterations, it is incorrect to conclude that the repetition show
non-halting behaviour.
Similarly, when your H, H0, or other H simulates itself, its simulation
aborts one cycle too early and therefore the non-halting conclusion is
incorrect.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-19 08:11 -0500 |
| Subject | Re: Simulating termination analyzers by dummies --- What does halting mean? |
| Message-ID | <v4ulde$1vpm0$3@dont-email.me> |
| In reply to | #107415 |
On 6/19/2024 3:18 AM, Fred. Zwarts wrote:
> Op 18.jun.2024 om 19:25 schreef 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.
>>
>> Halting is a technical term-of-the-art that corresponds
>> to terminates normally. Because Turing machines are
>> abstract mathematical objects there has been no notion
>> of abnormal termination for a Turing machine.
>>
>> We can derive a notion of abnormal termination for Turing
>> machines from the standard terms-of-the-art.
>>
>> Some TM's loop and thus never stop running, this is classical
>> non-halting behavior. UTM's simulate Turing machine descriptions.
>> This is the same thing as an interpreter interpreting the
>> source-code of a program.
>>
>> A UTM can be adapted so that it only simulates a fixed number
>> of iterations of an input that loops. When this UTM stops
>> simulating this Turing machine description we cannot correctly
>> say that this looping input halted.
>>
>
> If the code specifies 5 iterations and the simulator simulates only 3
> iterations, it is incorrect to conclude that the repetition show
> non-halting behaviour.
It is correct do say that the simulated input did not terminate
normally, thus defining the notion of abnormal termination
within Turing machines.
> Similarly, when your H, H0, or other H simulates itself, its simulation
> aborts one cycle too early and therefore the non-halting conclusion is
> incorrect.
I was confused bout this for three days four years ago and then I
got over it. No simulating termination analyzer can wait for an
inner instance of itself to abort the simulation or it waits forever.
Whenever the outer directly executed simulating termination analyzer
waits for any fixed number of repeating states it remains permanently
ahead of the next inner instance by exactly one repeating state. If
this is going to be permanently over your head then we need to stop
talking.
I only have three months of good health left before I will be on
a medicine that has a side effect of low blood counts for a year.
Chemotherapy was supposed to permanently ruin my T4 counts yet
I lucked out on that one.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2024-06-19 16:11 +0200 |
| Subject | Re: Simulating termination analyzers by dummies --- What does halting mean? |
| Message-ID | <v4uou1$1vtc8$3@dont-email.me> |
| In reply to | #107425 |
Op 19.jun.2024 om 15:11 schreef olcott:
> On 6/19/2024 3:18 AM, Fred. Zwarts wrote:
>> Op 18.jun.2024 om 19:25 schreef 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.
>>>
>>> Halting is a technical term-of-the-art that corresponds
>>> to terminates normally. Because Turing machines are
>>> abstract mathematical objects there has been no notion
>>> of abnormal termination for a Turing machine.
>>>
>>> We can derive a notion of abnormal termination for Turing
>>> machines from the standard terms-of-the-art.
>>>
>>> Some TM's loop and thus never stop running, this is classical
>>> non-halting behavior. UTM's simulate Turing machine descriptions.
>>> This is the same thing as an interpreter interpreting the
>>> source-code of a program.
>>>
>>> A UTM can be adapted so that it only simulates a fixed number
>>> of iterations of an input that loops. When this UTM stops
>>> simulating this Turing machine description we cannot correctly
>>> say that this looping input halted.
>>>
>>
>> If the code specifies 5 iterations and the simulator simulates only 3
>> iterations, it is incorrect to conclude that the repetition show
>> non-halting behaviour.
>
> It is correct do say that the simulated input did not terminate
> normally, thus defining the notion of abnormal termination
> within Turing machines.
>
>> Similarly, when your H, H0, or other H simulates itself, its
>> simulation aborts one cycle too early and therefore the non-halting
>> conclusion is incorrect.
>
> I was confused bout this for three days four years ago and then I
> got over it. No simulating termination analyzer can wait for an
> inner instance of itself to abort the simulation or it waits forever.
>
> Whenever the outer directly executed simulating termination analyzer
> waits for any fixed number of repeating states it remains permanently
> ahead of the next inner instance by exactly one repeating state. If
> this is going to be permanently over your head then we need to stop
> talking.
No, I understand it perfectly, but it seems to be over your head. We
agree that H needs to stop to prevent infinite recursion, but it is over
your head to see that when it stops, it misses the part of itself where
its simulation also stops, one repeating state further. So, the
non-halting conclusion is wrong, because the abort is premature.
So, your reasoning must lead to the only possible conclusion that a
simulator is unable to simulate itself properly, which causes false
negatives if its return value must be interpreted as a non-halting
behaviour. Instead, a return value of 'false' indicates an 'unable to
simulate' state of the simulator, which is not equivalent to 'non-halting'.
[toc] | [prev] | [next] | [standalone]
Page 7 of 9 — ← Prev page 1 2 3 4 5 6 [7] 8 9 Next page →
Back to top | Article view | comp.theory
csiph-web