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 8 of 9 — ← Prev page 1 2 3 4 5 6 7 [8] 9 Next page →
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-19 10:07 -0500 |
| Subject | Re: Simulating termination analyzers by dummies --- What does halting mean? |
| Message-ID | <v4us79$21810$3@dont-email.me> |
| In reply to | #107435 |
On 6/19/2024 9:11 AM, Fred. Zwarts wrote:
> 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.
typedef void (*ptr)();
int H0(ptr P);
void Infinite_Loop()
{
HERE: goto HERE;
}
void Infinite_Recursion()
{
Infinite_Recursion();
}
void DDD()
{
H0(DDD);
}
int main()
{
H0(Infinite_Loop);
H0(Infinite_Recursion);
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.
Every C programmer has agreed thus you simply don't know these things
well enough.
> 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'.
--
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 17:50 +0200 |
| Subject | Re: Simulating termination analyzers by dummies --- What does halting mean? |
| Message-ID | <v4uuor$1vtc8$6@dont-email.me> |
| In reply to | #107439 |
Op 19.jun.2024 om 17:07 schreef olcott:
> On 6/19/2024 9:11 AM, Fred. Zwarts wrote:
>> 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.
>
> typedef void (*ptr)();
> int H0(ptr P);
>
> void Infinite_Loop()
> {
> HERE: goto HERE;
> }
>
> void Infinite_Recursion()
> {
> Infinite_Recursion();
> }
>
> void DDD()
> {
> H0(DDD);
> }
>
> int main()
> {
> H0(Infinite_Loop);
> H0(Infinite_Recursion);
> 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.
That might be true, but every competent C programmer also knows that
such an abort would cause an incorrect simulation.
You don't see that both aborting and not aborting is wrong. Why are you
stuck in rebuttal mode?
>
> Every C programmer has agreed thus you simply don't know these things
> well enough.
>
>> 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]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-19 11:10 -0500 |
| Subject | Re: Simulating termination analyzers by dummies --- What does halting mean? |
| Message-ID | <v4uvu0$21os1$4@dont-email.me> |
| In reply to | #107443 |
On 6/19/2024 10:50 AM, Fred. Zwarts wrote:
> Op 19.jun.2024 om 17:07 schreef olcott:
>> On 6/19/2024 9:11 AM, Fred. Zwarts wrote:
>>> 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.
>>
>> typedef void (*ptr)();
>> int H0(ptr P);
>>
>> void Infinite_Loop()
>> {
>> HERE: goto HERE;
>> }
>>
>> void Infinite_Recursion()
>> {
>> Infinite_Recursion();
>> }
>>
>> void DDD()
>> {
>> H0(DDD);
>> }
>>
>> int main()
>> {
>> H0(Infinite_Loop);
>> H0(Infinite_Recursion);
>> 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.
>
> That might be true, but every competent C programmer also knows that
> such an abort would cause an incorrect simulation.
*Not at all*
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 | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2024-06-20 10:23 +0200 |
| Subject | Re: Simulating termination analyzers by dummies --- What does halting mean? |
| Message-ID | <v50ot4$2fh9b$1@dont-email.me> |
| In reply to | #107445 |
Op 19.jun.2024 om 18:10 schreef olcott:
> On 6/19/2024 10:50 AM, Fred. Zwarts wrote:
>> Op 19.jun.2024 om 17:07 schreef olcott:
>>> On 6/19/2024 9:11 AM, Fred. Zwarts wrote:
>>>> 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.
>>>
>>> typedef void (*ptr)();
>>> int H0(ptr P);
>>>
>>> void Infinite_Loop()
>>> {
>>> HERE: goto HERE;
>>> }
>>>
>>> void Infinite_Recursion()
>>> {
>>> Infinite_Recursion();
>>> }
>>>
>>> void DDD()
>>> {
>>> H0(DDD);
>>> }
>>>
>>> int main()
>>> {
>>> H0(Infinite_Loop);
>>> H0(Infinite_Recursion);
>>> 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.
>>
>> That might be true, but every competent C programmer also knows that
>> such an abort would cause an incorrect simulation.
>
> *Not at all*
>
> 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>
It seems you never learn. There is no correct simulation, so Sipser
words do not apply. You keep ignoring that it has been proved many times
that there is no correct simulation.
Repeating your claims show that this matter is over your head.
Every competent C programmer knows that such an abort would cause an
incorrect simulation.
You don't see that both aborting and not aborting is incorrect. Why are
you stuck in rebuttal mode?
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-20 09:16 -0500 |
| Subject | Re: Simulating termination analyzers by dummies --- What does halting mean? |
| Message-ID | <v51dk0$2jmrd$2@dont-email.me> |
| In reply to | #107487 |
On 6/20/2024 3:23 AM, Fred. Zwarts wrote:
> Op 19.jun.2024 om 18:10 schreef olcott:
>> On 6/19/2024 10:50 AM, Fred. Zwarts wrote:
>>> Op 19.jun.2024 om 17:07 schreef olcott:
>>>> On 6/19/2024 9:11 AM, Fred. Zwarts wrote:
>>>>> 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.
>>>>
>>>> typedef void (*ptr)();
>>>> int H0(ptr P);
>>>>
>>>> void Infinite_Loop()
>>>> {
>>>> HERE: goto HERE;
>>>> }
>>>>
>>>> void Infinite_Recursion()
>>>> {
>>>> Infinite_Recursion();
>>>> }
>>>>
>>>> void DDD()
>>>> {
>>>> H0(DDD);
>>>> }
>>>>
>>>> int main()
>>>> {
>>>> H0(Infinite_Loop);
>>>> H0(Infinite_Recursion);
>>>> 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.
>>>
>>> That might be true, but every competent C programmer also knows that
>>> such an abort would cause an incorrect simulation.
>>
>> *Not at all*
>>
>> 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>
>
> It seems you never learn. There is no correct simulation,
*You must have a reading comprehension problem*
*H correctly simulates its input D*
*until H correctly determines that its simulated D*
*would never stop running unless aborted then*
*This is simulating a finite number of steps of a non-terminating input*
> so Sipser
> words do not apply.
Either not paying attention or deliberately deceptive.
> You keep ignoring that it has been proved many times
> that there is no correct simulation.
> Repeating your claims show that this matter is over your head.
>
> Every competent C programmer knows that such an abort would cause an
> incorrect simulation.
> You don't see that both aborting and not aborting is incorrect. Why are
> you stuck in rebuttal mode?
>
--
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:29 +0000 |
| Subject | Re: Simulating termination analyzers by dummies --- What does halting mean? |
| Message-ID | <v51ldd$inq6$2@i2pn2.org> |
| In reply to | #107491 |
Am Thu, 20 Jun 2024 09:16:32 -0500 schrieb olcott:
> On 6/20/2024 3:23 AM, Fred. Zwarts wrote:
>> Op 19.jun.2024 om 18:10 schreef olcott:
>>> On 6/19/2024 10:50 AM, Fred. Zwarts wrote:
>>>> Op 19.jun.2024 om 17:07 schreef olcott:
>>>>> On 6/19/2024 9:11 AM, Fred. Zwarts wrote:
>>>>>> 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 halts iff H0 halts.
>>>>>>>>> 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.
>>>>>>>
>>>>>>> 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.
>>>>>> 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.
>>>>>
>>>>> typedef void (*ptr)();
>>>>> int H0(ptr P);
>>>>>
>>>>> void DDD()
>>>>> {
>>>>> H0(DDD);
>>>>> }
>>>>> int main()
>>>>> {
>>>>> H0(DDD);
>>>>> }
>>>>>
>>>>> Every C programmer that knows what an x86 emulator is knows that
>>>>> when H0 emulates the machine language of
>>>>> DDD that it must abort these emulations so that itself can
>>>>> terminate normally.
>>>>
>>>> That might be true, but every competent C programmer also knows that
>>>> such an abort would cause an incorrect simulation.
>>>
>>> *Not at all*
>>> [blah blah Sipser]
>>
>> It seems you never learn. There is no correct simulation,
>> so Sipser words do not apply.
> Either not paying attention or deliberately deceptive.
> *H correctly simulates its input D*
> *until H correctly determines that its simulated D*
whence it stops simulating (correctly, or at all)
> *would never stop running unless aborted then*
stops simulating the following steps.
> *This is simulating a finite number of steps of a non-terminating input*
I.e. not a full simulation.
--
Man kann mit dunklen Zahlen nicht rechnen. Für die eigentliche Mathematik
sind sie vollkommen nutzlos. --Wolfgang Mückenheim
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-20 11:35 -0500 |
| Subject | Re: Simulating termination analyzers by dummies --- What does halting mean? |
| Message-ID | <v51lo1$2kst7$2@dont-email.me> |
| In reply to | #107502 |
On 6/20/2024 11:29 AM, joes wrote:
> Am Thu, 20 Jun 2024 09:16:32 -0500 schrieb olcott:
>> On 6/20/2024 3:23 AM, Fred. Zwarts wrote:
>>> Op 19.jun.2024 om 18:10 schreef olcott:
>>>> On 6/19/2024 10:50 AM, Fred. Zwarts wrote:
>>>>> Op 19.jun.2024 om 17:07 schreef olcott:
>>>>>> On 6/19/2024 9:11 AM, Fred. Zwarts wrote:
>>>>>>> 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 halts iff H0 halts.
>
>>>>>>>>>> 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.
>>>>>>>>
>>>>>>>> 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.
>
>>>>>>> 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.
>>>>>>
>>>>>> typedef void (*ptr)();
>>>>>> int H0(ptr P);
>>>>>>
>>>>>> void DDD()
>>>>>> {
>>>>>> H0(DDD);
>>>>>> }
>>>>>> int main()
>>>>>> {
>>>>>> H0(DDD);
>>>>>> }
>>>>>>
>>>>>> Every C programmer that knows what an x86 emulator is knows that
>>>>>> when H0 emulates the machine language of
>>>>>> DDD that it must abort these emulations so that itself can
>>>>>> terminate normally.
>>>>>
>>>>> That might be true, but every competent C programmer also knows that
>>>>> such an abort would cause an incorrect simulation.
>>>>
>>>> *Not at all*
>>>> [blah blah Sipser]
>>>
>>> It seems you never learn. There is no correct simulation,
>>> so Sipser words do not apply.
>> Either not paying attention or deliberately deceptive.
>
>> *H correctly simulates its input D*
>> *until H correctly determines that its simulated D*
> whence it stops simulating (correctly, or at all)
>> *would never stop running unless aborted then*
> stops simulating the following steps.
>> *This is simulating a finite number of steps of a non-terminating input*
> I.e. not a full simulation.
>
*Yet sufficient to conclude*
<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>
--
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-21 09:58 +0200 |
| Subject | Re: Simulating termination analyzers by dummies --- What does halting mean? |
| Message-ID | <v53bqv$324b5$1@dont-email.me> |
| In reply to | #107491 |
Op 20.jun.2024 om 16:16 schreef olcott:
> On 6/20/2024 3:23 AM, Fred. Zwarts wrote:
>> Op 19.jun.2024 om 18:10 schreef olcott:
>>> On 6/19/2024 10:50 AM, Fred. Zwarts wrote:
>>>> Op 19.jun.2024 om 17:07 schreef olcott:
>>>>> On 6/19/2024 9:11 AM, Fred. Zwarts wrote:
>>>>>> 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.
>>>>>
>>>>> typedef void (*ptr)();
>>>>> int H0(ptr P);
>>>>>
>>>>> void Infinite_Loop()
>>>>> {
>>>>> HERE: goto HERE;
>>>>> }
>>>>>
>>>>> void Infinite_Recursion()
>>>>> {
>>>>> Infinite_Recursion();
>>>>> }
>>>>>
>>>>> void DDD()
>>>>> {
>>>>> H0(DDD);
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>> H0(Infinite_Loop);
>>>>> H0(Infinite_Recursion);
>>>>> 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.
>>>>
>>>> That might be true, but every competent C programmer also knows that
>>>> such an abort would cause an incorrect simulation.
>>>
>>> *Not at all*
>>>
>>> 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>
>>
>> It seems you never learn. There is no correct simulation,
>
> *You must have a reading comprehension problem*
> *H correctly simulates its input D*
> *until H correctly determines that its simulated D*
> *would never stop running unless aborted then*
Each time again you tell things we already know. That does not help,
because it is beside the point. Yes, It must abort, but when it aborts
it is unable to see how the simulation would end. Because the simulated
H is only one cycle behind the simulating H, so one cycle later the
simulated H would come to an end and halt as well, if the simulation
were correct. This is the fate of a simulating decider: not aborting is
wrong and aborting is always too early.
>
> *This is simulating a finite number of steps of a non-terminating input*
But a finite number of steps in insufficient for this conclusion.
Because it is not a non-terminating input. The idea that it is
non-terminating when it aborts is an incorrect wild-guess.
Why is it so difficult for you to see that an aborting H0, when
correctly simulated, also halts?
>
>> so Sipser words do not apply.
>
> Either not paying attention or deliberately deceptive.
>
>> You keep ignoring that it has been proved many times that there is no
>> correct simulation.
>> Repeating your claims show that this matter is over your head.
>>
>> Every competent C programmer knows that such an abort would cause an
>> incorrect simulation.
>> You don't see that both aborting and not aborting is incorrect. Why
>> are you stuck in rebuttal mode?
>>
>
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-21 08:12 -0500 |
| Subject | Re: Simulating termination analyzers by dummies --- What does halting mean? |
| Message-ID | <v53u8h$35vak$2@dont-email.me> |
| In reply to | #107531 |
On 6/21/2024 2:58 AM, Fred. Zwarts wrote:
> Op 20.jun.2024 om 16:16 schreef olcott:
>> On 6/20/2024 3:23 AM, Fred. Zwarts wrote:
>>> Op 19.jun.2024 om 18:10 schreef olcott:
>>>> On 6/19/2024 10:50 AM, Fred. Zwarts wrote:
>>>>> Op 19.jun.2024 om 17:07 schreef olcott:
>>>>>> On 6/19/2024 9:11 AM, Fred. Zwarts wrote:
>>>>>>> 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.
>>>>>>
>>>>>> typedef void (*ptr)();
>>>>>> int H0(ptr P);
>>>>>>
>>>>>> void Infinite_Loop()
>>>>>> {
>>>>>> HERE: goto HERE;
>>>>>> }
>>>>>>
>>>>>> void Infinite_Recursion()
>>>>>> {
>>>>>> Infinite_Recursion();
>>>>>> }
>>>>>>
>>>>>> void DDD()
>>>>>> {
>>>>>> H0(DDD);
>>>>>> }
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>> H0(Infinite_Loop);
>>>>>> H0(Infinite_Recursion);
>>>>>> 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.
>>>>>
>>>>> That might be true, but every competent C programmer also knows
>>>>> that such an abort would cause an incorrect simulation.
>>>>
>>>> *Not at all*
>>>>
>>>> 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>
>>>
>>> It seems you never learn. There is no correct simulation,
>>
>> *You must have a reading comprehension problem*
>> *H correctly simulates its input D*
>> *until H correctly determines that its simulated D*
>> *would never stop running unless aborted then*
>
> Each time again you tell things we already know. That does not help,
> because it is beside the point. Yes, It must abort, but when it aborts
> it is unable to see how the simulation would end.
Must abort means that it knows that simulation will
not otherwise end. You can't even pay attention to
the meaning of words.
> Because the simulated
> H is only one cycle behind the simulating H, so one cycle later the
> simulated H would come to an end and halt as well, if the simulation
> were correct. This is the fate of a simulating decider: not aborting is
> wrong and aborting is always too early.
>
>>
>> *This is simulating a finite number of steps of a non-terminating input*
>
> But a finite number of steps in insufficient for this conclusion.
> Because it is not a non-terminating input. The idea that it is
> non-terminating when it aborts is an incorrect wild-guess.
> Why is it so difficult for you to see that an aborting H0, when
> correctly simulated, also halts?
>
>
>>
>>> so Sipser words do not apply.
>>
>> Either not paying attention or deliberately deceptive.
>>
>>> You keep ignoring that it has been proved many times that there is no
>>> correct simulation.
>>> Repeating your claims show that this matter is over your head.
>>>
>>> Every competent C programmer knows that such an abort would cause an
>>> incorrect simulation.
>>> You don't see that both aborting and not aborting is incorrect. Why
>>> are you stuck in rebuttal mode?
>>>
>>
--
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:11 -0400 |
| Subject | Re: Simulating termination analyzers by dummies --- What does halting mean? |
| Message-ID | <v541mq$lkkb$1@i2pn2.org> |
| In reply to | #107534 |
On 6/21/24 9:12 AM, olcott wrote:
> On 6/21/2024 2:58 AM, Fred. Zwarts wrote:
>> Op 20.jun.2024 om 16:16 schreef olcott:
>>> On 6/20/2024 3:23 AM, Fred. Zwarts wrote:
>>>> Op 19.jun.2024 om 18:10 schreef olcott:
>>>>> On 6/19/2024 10:50 AM, Fred. Zwarts wrote:
>>>>>> Op 19.jun.2024 om 17:07 schreef olcott:
>>>>>>> On 6/19/2024 9:11 AM, Fred. Zwarts wrote:
>>>>>>>> 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.
>>>>>>>
>>>>>>> typedef void (*ptr)();
>>>>>>> int H0(ptr P);
>>>>>>>
>>>>>>> void Infinite_Loop()
>>>>>>> {
>>>>>>> HERE: goto HERE;
>>>>>>> }
>>>>>>>
>>>>>>> void Infinite_Recursion()
>>>>>>> {
>>>>>>> Infinite_Recursion();
>>>>>>> }
>>>>>>>
>>>>>>> void DDD()
>>>>>>> {
>>>>>>> H0(DDD);
>>>>>>> }
>>>>>>>
>>>>>>> int main()
>>>>>>> {
>>>>>>> H0(Infinite_Loop);
>>>>>>> H0(Infinite_Recursion);
>>>>>>> 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.
>>>>>>
>>>>>> That might be true, but every competent C programmer also knows
>>>>>> that such an abort would cause an incorrect simulation.
>>>>>
>>>>> *Not at all*
>>>>>
>>>>> 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>
>>>>
>>>> It seems you never learn. There is no correct simulation,
>>>
>>> *You must have a reading comprehension problem*
>>> *H correctly simulates its input D*
>>> *until H correctly determines that its simulated D*
>>> *would never stop running unless aborted then*
>>
>> Each time again you tell things we already know. That does not help,
>> because it is beside the point. Yes, It must abort, but when it aborts
>> it is unable to see how the simulation would end.
>
> Must abort means that it knows that simulation will
> not otherwise end. You can't even pay attention to
> the meaning of words.
But that is meaningless in your context.
You break your logic by making your argument change that which is being
simulated as you step through it. That just shows you are lying.
Remember, A MACHINE/PROGRAM has behavior, but not a "template", as you
can't just run the template, but only an instance of it,
And the "Correct Simulation" of this input, will halt, so H didn't have
to abort it, but does.
If the mere fact that H aborting its simulation allows it to claim that
it "must" then the condition of "must" is trivially derived.
>
>> Because the simulated H is only one cycle behind the simulating H, so
>> one cycle later the simulated H would come to an end and halt as well,
>> if the simulation were correct. This is the fate of a simulating
>> decider: not aborting is wrong and aborting is always too early.
>>
>>>
>>> *This is simulating a finite number of steps of a non-terminating input*
>>
>> But a finite number of steps in insufficient for this conclusion.
>> Because it is not a non-terminating input. The idea that it is
>> non-terminating when it aborts is an incorrect wild-guess.
>> Why is it so difficult for you to see that an aborting H0, when
>> correctly simulated, also halts?
>>
>>
>>>
>>>> so Sipser words do not apply.
>>>
>>> Either not paying attention or deliberately deceptive.
>>>
>>>> You keep ignoring that it has been proved many times that there is
>>>> no correct simulation.
>>>> Repeating your claims show that this matter is over your head.
>>>>
>>>> Every competent C programmer knows that such an abort would cause an
>>>> incorrect simulation.
>>>> You don't see that both aborting and not aborting is incorrect. Why
>>>> are you stuck in rebuttal mode?
>>>>
>>>
>
[toc] | [prev] | [next] | [standalone]
| From | joes <noreply@example.com> |
|---|---|
| Date | 2024-06-20 22:54 +0000 |
| Subject | Re: Simulating termination analyzers by dummies --- What does halting mean? |
| Message-ID | <v52bv2$jdea$2@i2pn2.org> |
| In reply to | #107439 |
Am Wed, 19 Jun 2024 10:07:21 -0500 schrieb olcott: > On 6/19/2024 9:11 AM, Fred. Zwarts wrote: >> 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: >>> It is correct do say that the simulated input did not terminate >>> normally, thus defining the notion of abnormal termination within >>> Turing machines. The simulated input did not terminate at all, the simulator did. If it hadn't aborted (which the input gave no reason to, or even has the power), the simulation would have continued. >>>> 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. Exactly. It can never correctly abort. >> 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. > Every C programmer has agreed thus you simply don't know these things > well enough. Ad hominem is not an argument. It may abort if the input didn't halt; but it does, because it is the same as itself. >> 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'. -- joes
[toc] | [prev] | [next] | [standalone]
| From | Mikko <mikko.levanto@iki.fi> |
|---|---|
| Date | 2024-06-20 08:43 +0300 |
| Subject | Re: Simulating termination analyzers by dummies --- What does halting mean? |
| Message-ID | <v50fhs$2ehqj$1@dont-email.me> |
| In reply to | #107425 |
On 2024-06-19 13:11:10 +0000, olcott said:
> 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.
No, it is not. It is correct to say that the input was not simulated to its
normal termination. The input to the simulator is not a simulated input, it
is a real input.
You have not defined "abnormal termination" of a Turing machine, nor
presented any reason to do so.
--
Mikko
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-20 09:45 -0500 |
| Subject | Re: Simulating termination analyzers by dummies --- What does halting mean? |
| Message-ID | <v51f9t$2jmrd$3@dont-email.me> |
| In reply to | #107482 |
On 6/20/2024 12:43 AM, Mikko wrote:
> On 2024-06-19 13:11:10 +0000, olcott said:
>
>> 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.
>
> No, it is not. It is correct to say that the input was not simulated to its
> normal termination.
void Infinite_Loop()
{
HERE: goto HERE;
}
So infinite loops are beyond your comprehension.
> The input to the simulator is not a simulated input, it
> is a real input.
>
A finite number of state transitions of a Turing Machine
description that loops are correctly simulated by an adapted UTM.
This adapted UTM stops simulating this input when it correctly
determines in a finite number of steps that this input loops
thus never halts.
We cannot correctly say that this simulated looping input
terminated normally.
> You have not defined "abnormal termination" of a Turing machine, nor
> presented any reason to do so.
>
--
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-21 10:02 +0300 |
| Subject | Re: Simulating termination analyzers by dummies --- What does halting mean? |
| Message-ID | <v538ii$324lg$1@dont-email.me> |
| In reply to | #107493 |
On 2024-06-20 14:45:17 +0000, olcott said:
> On 6/20/2024 12:43 AM, Mikko wrote:
>> On 2024-06-19 13:11:10 +0000, olcott said:
>>
>>> 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.
>>
>> No, it is not. It is correct to say that the input was not simulated to its
>> normal termination.
>
> void Infinite_Loop()
> {
> HERE: goto HERE;
> }
>
> So infinite loops are beyond your comprehension.
That I can make a reasonable comment about one point does not mean that
other points are beyond my comprehension. You should not assume that
other people's mental abilities are as limited as yours.
>> The input to the simulator is not a simulated input, it
>> is a real input.
>
> A finite number of state transitions of a Turing Machine
> description that loops are correctly simulated by an adapted UTM.
>
> This adapted UTM stops simulating this input when it correctly
> determines in a finite number of steps that this input loops
> thus never halts.
If it can. If the simulated Turing machine never returns to a previous
configuration it is hard to determine whether it will ever stop. Even
a terminating computation may loop thorough the same internal states
but with a different tape content.
> We cannot correctly say that this simulated looping input
> terminated normally.
We needn't if we can say that it was stuck in a loop. But there is no
method that can detect all possible non-terminating behaviours.
>> You have not defined "abnormal termination" of a Turing machine, nor
>> presented any reason to do so.
--
Mikko
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-21 08:18 -0500 |
| Subject | Re: Simulating termination analyzers by dummies --- What does halting mean? |
| Message-ID | <v53uif$35vak$4@dont-email.me> |
| In reply to | #107527 |
On 6/21/2024 2:02 AM, Mikko wrote:
> On 2024-06-20 14:45:17 +0000, olcott said:
>
>> On 6/20/2024 12:43 AM, Mikko wrote:
>>> On 2024-06-19 13:11:10 +0000, olcott said:
>>>
>>>> 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.
>>>
>>> No, it is not. It is correct to say that the input was not simulated
>>> to its
>>> normal termination.
>>
>> void Infinite_Loop()
>> {
>> HERE: goto HERE;
>> }
>>
>> So infinite loops are beyond your comprehension.
>
> That I can make a reasonable comment about one point does not mean that
> other points are beyond my comprehension. You should not assume that
> other people's mental abilities are as limited as yours.
>
Bypassing my question.
I will assume that you do not understand that infinite loops
never terminate until you prove otherwise.
>>> The input to the simulator is not a simulated input, it
>>> is a real input.
>>
>> A finite number of state transitions of a Turing Machine
>> description that loops are correctly simulated by an adapted UTM.
>>
>> This adapted UTM stops simulating this input when it correctly
>> determines in a finite number of steps that this input loops
>> thus never halts.
>
> If it can. If the simulated Turing machine never returns to a previous
> configuration it is hard to determine whether it will ever stop.
The executed H see all.
> Even
> a terminating computation may loop thorough the same internal states
> but with a different tape content.
>
>> We cannot correctly say that this simulated looping input
>> terminated normally.
>
> We needn't if we can say that it was stuck in a loop. But there is no
> method that can detect all possible non-terminating behaviours.
>
To refute the halting problem proofs H decides that
P correctly simulated by H never halts.
typedef int (*ptr2)();
int H(ptr2 P, ptr2 I);
int P(ptr2 x)
{
int Halt_Status = H(x, x);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
H(P,P);
}
>>> You have not defined "abnormal termination" of a Turing machine, nor
>>> presented any reason to do so.
>
--
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:20 -0400 |
| Subject | Re: Simulating termination analyzers by dummies --- What does halting mean? |
| Message-ID | <v5426m$lkkb$2@i2pn2.org> |
| In reply to | #107536 |
On 6/21/24 9:18 AM, olcott wrote:
> On 6/21/2024 2:02 AM, Mikko wrote:
>> On 2024-06-20 14:45:17 +0000, olcott said:
>>
>>> On 6/20/2024 12:43 AM, Mikko wrote:
>>>> On 2024-06-19 13:11:10 +0000, olcott said:
>>>>
>>>>> 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.
>>>>
>>>> No, it is not. It is correct to say that the input was not simulated
>>>> to its
>>>> normal termination.
>>>
>>> void Infinite_Loop()
>>> {
>>> HERE: goto HERE;
>>> }
>>>
>>> So infinite loops are beyond your comprehension.
>>
>> That I can make a reasonable comment about one point does not mean that
>> other points are beyond my comprehension. You should not assume that
>> other people's mental abilities are as limited as yours.
>>
>
> Bypassing my question.
> I will assume that you do not understand that infinite loops
> never terminate until you prove otherwise.
I guess you are thus admiting that your understand of all the topics YOU
"bypassed" is inadiquite.
The problem is no one is interested in your question, because it is
based on invalid logic,
Remember, Turing Machine (and program behavior) is DEFINED based on its
direct execution. A simulation might help us see it, but is only correct
if the answer it gives matches the direct execution.
Turing Machines themselves NEVER "abnormally terminate", that is only a
result of a simulation that gives up and doesn't return a result on
behavior.
>
>>>> The input to the simulator is not a simulated input, it
>>>> is a real input.
>>>
>>> A finite number of state transitions of a Turing Machine
>>> description that loops are correctly simulated by an adapted UTM.
>>>
>>> This adapted UTM stops simulating this input when it correctly
>>> determines in a finite number of steps that this input loops
>>> thus never halts.
>>
>> If it can. If the simulated Turing machine never returns to a previous
>> configuration it is hard to determine whether it will ever stop.
>
> The executed H see all.
Nope, because it GIVES UP and aborts its simulation,
>
>> Even
>> a terminating computation may loop thorough the same internal states
>> but with a different tape content.
>>
>>> We cannot correctly say that this simulated looping input
>>> terminated normally.
>>
>> We needn't if we can say that it was stuck in a loop. But there is no
>> method that can detect all possible non-terminating behaviours.
>>
>
> To refute the halting problem proofs H decides that
> P correctly simulated by H never halts.
And thus makes itself wrong because it answsered the wrong question.
This seems to be a common happening in your logic, because you world
seems to be based on lies and incorrect definitions being considered
valid logic.
>
> typedef int (*ptr2)();
> int H(ptr2 P, ptr2 I);
>
> int P(ptr2 x)
> {
> int Halt_Status = H(x, x);
> if (Halt_Status)
> HERE: goto HERE;
> return Halt_Status;
> }
>
> int main()
> {
> H(P,P);
> }
>
>>>> You have not defined "abnormal termination" of a Turing machine, nor
>>>> presented any reason to do so.
>>
>
[toc] | [prev] | [next] | [standalone]
| From | Mikko <mikko.levanto@iki.fi> |
|---|---|
| Date | 2024-06-22 11:14 +0300 |
| Subject | Re: Simulating termination analyzers by dummies --- What does halting mean? |
| Message-ID | <v5614h$3ltsf$1@dont-email.me> |
| In reply to | #107536 |
On 2024-06-21 13:18:07 +0000, olcott said:
> On 6/21/2024 2:02 AM, Mikko wrote:
>> On 2024-06-20 14:45:17 +0000, olcott said:
>>
>>> On 6/20/2024 12:43 AM, Mikko wrote:
>>>> On 2024-06-19 13:11:10 +0000, olcott said:
>>>>
>>>>> 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.
>>>>
>>>> No, it is not. It is correct to say that the input was not simulated to its
>>>> normal termination.
>>>
>>> void Infinite_Loop()
>>> {
>>> HERE: goto HERE;
>>> }
>>>
>>> So infinite loops are beyond your comprehension.
>>
>> That I can make a reasonable comment about one point does not mean that
>> other points are beyond my comprehension. You should not assume that
>> other people's mental abilities are as limited as yours.
>>
>
> Bypassing my question.
Noboyd asked any question in any of the above quoteed text.
> I will assume that you do not understand that infinite loops
> never terminate until you prove otherwise.
It is not a good idea to assume too macuh. However, that particular
assumption is not about the main topic so it is probably harmless.
>>>> The input to the simulator is not a simulated input, it
>>>> is a real input.
>>>
>>> A finite number of state transitions of a Turing Machine
>>> description that loops are correctly simulated by an adapted UTM.
>>>
>>> This adapted UTM stops simulating this input when it correctly
>>> determines in a finite number of steps that this input loops
>>> thus never halts.
>>
>> If it can. If the simulated Turing machine never returns to a previous
>> configuration it is hard to determine whether it will ever stop.
>
> The executed H see all.
Not all, only what it already has looked.
--
Mikko
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-18 22:16 -0400 |
| Message-ID | <v4tf20$ddeo$4@i2pn2.org> |
| In reply to | #107367 |
On 6/18/24 9:21 AM, olcott wrote:
> On 6/18/2024 6:36 AM, Richard Damon wrote:
>> On 6/17/24 11:28 PM, olcott wrote:
>>> On 6/17/2024 10:15 PM, Richard Damon wrote:
>>>> On 6/17/24 11:01 PM, olcott wrote:
>>>>> On 6/17/2024 9:44 PM, Richard Damon wrote:
>>>>>> On 6/17/24 10:36 PM, olcott wrote:
>>>>>>> On 6/17/2024 9:33 PM, Richard Damon wrote:
>>>>>>>> On 6/17/24 10:04 PM, olcott wrote:
>>>>>>>>> On 6/17/2024 8:24 PM, Richard Damon wrote:
>>>>>>>>>> On 6/17/24 9:16 PM, olcott wrote:
>>>>>>>>>>> On 6/17/2024 5:42 PM, Richard Damon wrote:
>>>>>>>>>>>> On 6/17/24 8:20 AM, olcott wrote:
>>>>>>>>>>>>> On 6/17/2024 3:31 AM, Fred. Zwarts wrote:
>>>>>>>>>>>>>> Op 17.jun.2024 om 05:33 schreef olcott:
>>>>>>>>>>>>>>> To understand this analysis requires a sufficient
>>>>>>>>>>>>>>> knowledge of
>>>>>>>>>>>>>>> the C programming language and what an x86 emulator does.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Unless every single detail is made 100% explicit false
>>>>>>>>>>>>>>> assumptions
>>>>>>>>>>>>>>> always slip though the cracks. This is why it must be
>>>>>>>>>>>>>>> examined at
>>>>>>>>>>>>>>> the C level before it is examined at the Turing Machine
>>>>>>>>>>>>>>> level.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>>>>>>> int H0(ptr P);
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> void Infinite_Loop()
>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> void Infinite_Recursion()
>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>> Infinite_Recursion();
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> void DDD()
>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>> H0(DDD);
>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>> H0(Infinite_Loop);
>>>>>>>>>>>>>>> H0(Infinite_Recursion);
>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> When this is construed as non-halting criteria then
>>>>>>>>>>>>>>> simulating
>>>>>>>>>>>>>>> termination analyzer H0 is correct to reject these inputs
>>>>>>>>>>>>>>> as non-
>>>>>>>>>>>>>>> halting.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> For Infinite_Loop and Infinite_Recursion that might be
>>>>>>>>>>>>>> true, because there the simulator processes the whole input.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The H0 case is very different. For H0 there is indeed a
>>>>>>>>>>>>>> false assumption, as you mentioned. Here H0 needs to
>>>>>>>>>>>>>> simulate itself, but the simulation is never able to reach
>>>>>>>>>>>>>> the final state of the simulated self. The abort is always
>>>>>>>>>>>>>> one cycle too early, so that the simulating H0 misses the
>>>>>>>>>>>>>> abort. Therefore this results in a false negative.
>>>>>>>>>>>>>> (Note that H0 should process its input, which includes the
>>>>>>>>>>>>>> H0 that aborts, not a non-input with an H that does not
>>>>>>>>>>>>>> abort.)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This results in a impossible dilemma for the programmer.
>>>>>>>>>>>>>> It he creates a H that does not abort, it will not terminate.
>>>>>>>>>>>>>
>>>>>>>>>>>>> *Therefore what I said is correct*
>>>>>>>>>>>>> When every input that must be aborted is construed as
>>>>>>>>>>>>> non-halting
>>>>>>>>>>>>> then the input to H0(DDD) is correctly construed as
>>>>>>>>>>>>> non-halting.
>>>>>>>>>>>>
>>>>>>>>>>>> In other words, if you allow yourself to LIE, you can claim
>>>>>>>>>>>> the wrong answer is right.
>>>>>>>>>>>>
>>>>>>>>>>>> Since your "Needing to abort" is NOT the same as halting,
>>>>>>>>>>>> all you are doing is admitting that your whole logic system
>>>>>>>>>>>> is based on the principle that LIES ARE OK.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> "Needing to abort" <is> the same as a NOT halting input.
>>>>>>>>>>> You are simply too ignorant to understand this.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Nope, not if you are comparing DIFFERENT version of the input.
>>>>>>>>>>
>>>>>>>>> It is ALWAYS the exact same sequence of bytes.
>>>>>>>>
>>>>>>>> But if it doesn't include the bytes of H,
>>>>>>>
>>>>>>> It is like we know that N > 50 and you can't
>>>>>>> see that this also means N > 40.
>>>>>>>
>>>>>>
>>>>>> Nope.
>>>>>>
>>>>>> How do you simulate something you do not have?
>>>>>>
>>>>>> That is like says when the requirement is for N > 50 that you
>>>>>> claim 1 is ok, because 50 can be 5*0 just like xy is x*y.
>>>>>>
>>>>>> Again, how can you claim a "Correct Simulation" by the exact
>>>>>> definition of the x86 instruction set, when you omit the call H
>>>>>> instruction, and then "jump" to an addres that was never jumped to
>>>>>> at any point later in the program.
>>>>>>
>>>>>
>>>>> You just aren't bright enough to see simple truths that
>>>>> every programmer can see.
>>>>>
>>>>> void DDD()
>>>>> {
>>>>> H0(DDD);
>>>>> }
>>>>>
>>>>> DDD correctly simulated by any H0 cannot possibly halt.
>>>>> That this truth is so simple lead me to believe that
>>>>> you were lying about it instead of ordinary cluelessness.
>>>>>
>>>>>
>>>>
>>>> But the question isn't DDD correctly simulated by H0, but does DDD
>>>> itself, when run halt.
>>>>
>>>
>>> The proof that you are wrong is over your head.
>>
>> That is just a lying Dodge.
>> I have always only wanted what the actual truth really is.
> Your systematic error of bias has prevented you from paying
> enough attention to see this true, or maybe you simply are
> not bright enough, or some of both.
Nope, YOU are just full of errors because you refuse to look at the truth.
If the problem was my bias, then you could lay out a simple detailed
PROOF (actual, not just rhetoric) of your point.
But you only logic seems to be that the world must be wrong because it
doesn't believe in your ideas.
Nope, YOU are the one with "Bias" and inability to see the truth.
>
>> An ad-hominen that tries to avoid showing that you have nothing by
>> claiming the other couldn't understand it.
>>
> I calls em as I see em.
Yep, and since you have shown yourself unable to see logic, what you see
is just blindness.
Your logic is based on that you are "allowed" to lie about what the
problem is because you don't like the answer that the DEFINED problem gives.
>
>> The problem, as you have demonstrated, is that youj actually don't
>> even know the BASICS of the field, so clearly can't have grasps of
>> things above all others.
>>
>
> It is not at all that I don't know these things.
> It is that I professor Hehner and professor Stoddart
> pay enough attention to see that there is something
> wrong with the halting problem. Professor Hehner said
> that I could quote him as agreeing to those exact same
> words as they apply to himself.
Again, the BLIND leading the BLIND.
>
>>
>>
>>>
>>>> You have been stuck on the wrong question for ages, because you just
>>>> belive your own lies, and think you are allowed to change the
>>>> definitions of terms.
>>>>
>>> No that is not it. I have known the truth for two
>>> decades and am just now expressing it in words.
>>
>> Nope, you have lied to yourself about it for two decades, but can't
>> actually show it other, because it isn't true.
>>
>
> If it was merely me lying to myself then there would not be
> two PhD computer science professors that agree with me that
> there is something wrong with the halting problem.
No, you just found a couple of other people who believe the same lies.
>
>> If you had a fundamental flaw that actually broke the system, you
>> could just show it.
>>
>
> I and two PhD computer science professors did show yet you are
> so convinced that they are wrong that you refuse to pay attention.
But me and THOUSANDS of computer science professionals know you are just
wrong.
The fact that you even try to rebute with an appeal to authority,
>
>>>
>>> If the halting problem is correct then truth itself
>>> is broken. Since truth itself cannot be broken then
>>> the halting problem cannot be correct.
>>
>> No, truth as YOU think of it is broken, because your idea of Truth is
>> just wrong.
>>
>
> Actually you are the one person in the world that understands
> that it is correct.
>
> We can verify that expressions of language that are {true on the
> basis of their meaning} are true on the basis of a sequence of
> truth preserving operations from their meaning to this expression.
But that requires accepting the definitions of things, which you don't
Once definitions are just suggestions, your whole thoery falls apart.
>
>> It isn't that everyone else is wrong, it is YOU are wrong, but are too
>> bulheaded to accept it.
>>
> Everyone else is beguiled by the dogma and actively denigrates
> those that know the truth to the extent of ruining their careers.
But in system built by autthority, Dogma is correct.
>
> History of my Problems with the Halting Problem
> 2013 August 14, 2014 July 6, 2022 April 15
> Eric C.R. (Rick) Hehner
> https://www.cs.toronto.edu/~hehner/PHPhistory.pdf
Who shows he doesn't understand the basics of the field.
>
>>>
>>> This is all anchored in the details of truthmaker
>>> maximalism.
>>
>> Which, as we just showed, you don't understand.
>>
>
> Actually you understand it better than most experts in the field.
> The clueless ones believe that this sentence is a truth without
> a truthmaker: "This sentence has no truthmaker."
Nope, I don't think you understand what most people would think of that
sentence.
>
>> Yes, your problem is YOU, and your refusal to actually look at what is
>> being shown to you.
>>
> I am merely rejecting incorrect dogma. It is like you keep
> explaining to me that 2 + 3 does not equal 5, everyone
> "knows" that it equals 17.3.
But the "Dogma" isn't "Incorrect", it IS the definition.
You are welcome to try to show an actual problem with it, but first you
need to understadn what the "Dogma" actually means, which seems beyound
your understanding.
>
>> You are worse than the election deniers that you put down.
>>
> Yet I have two PhD computer science professors that agree with me.
And thousands who disagree, so YOU LOSE THE VOTE.
Just like all the election deniers. But there vote was closer.
>
>>>
>>>> Do that just makes you a LIAR, and so that is what you are.
>>>>
>>>
>>> *Calling me a liar may get you sent to actual Hell*
>>
>> Nope, since it is a truth, it isn't a lie.
>>
>
> Presuming yourself to be infallible may be blaspheming
> the Holy Spirit. I never made the mistake of presuming
> myself to be infallible.
I know it is the truth, because I know the defitions.
IF someone claimed that 2 + 3 was 17 in normal math, I could very
confidently claim they were incorrect.
That isn't a test of "infallibilty".
YOU claiming you are correct, is just based on you prsuming that you are
allowed to re-write the rules, which isn't allowed.
>
>> Truth seems to be something beyound your understanding since you have
>> lied to yourself so long.
>>
> Two PhD computer science professors agree with me.
And thousands disagree, so you lost the election.
By more than the election deniers.
>
>>>
>>> That you have a religious conviction that I am incorrect
>>> is a bias that prevents you from trying to actually
>>> understand what I am saying.
>>
>> It isn't a "religious" conviction, but a knowledge of how logic
>> actually works.
>>
> Logic is not the measure of truth. Classical and Symbolic
> logic has flaws. Truth preserving operations from expressions
> stipulated to be true corrects all of the errors of logic.
More of your double-talk.
PROVE your statement.
>
>>>
>>> Perhaps you are too ignorant to understand that bias
>>> is a systematic error.
>>>
>>
>> Nope. YOU are just stuck in YOUR bias, as proven by your clearly wrong
>> assertions.
>>
> You did not indicate that you have any idea what bias it.
Why should i have, I am not going to throw my pearls to the swine.
>
>> If you don't see how claiming that an answer that is wrong by
>> definition is right is illogical, you are just beyound hope.
>>
>
> When definitions derive incoherence that we know that
> they are incorrect.
>
Then try to actually SHOW the incoherence.
You tried that once, and FAILED, but decided you ideas must be correct,
so you accepted them without actually proving them.
THAT IS YOUR BIAS.
AND IGNORANCE.
[toc] | [prev] | [next] | [standalone]
| From | Python <python@invalid.org> |
|---|---|
| Date | 2024-06-18 13:52 +0200 |
| Message-ID | <v4rsdg$19r3f$3@dont-email.me> |
| In reply to | #107351 |
Le 18/06/2024 à 05:28, olcott a écrit : > On 6/17/2024 10:15 PM, Richard Damon wrote: ... > *Calling me a liar may get you sent to actual Hell* Then you could still argue with him! Is Hell connected to the Internet?
[toc] | [prev] | [next] | [standalone]
| From | Mikko <mikko.levanto@iki.fi> |
|---|---|
| Date | 2024-06-18 19:21 +0300 |
| Message-ID | <v4sc6v$1e9dc$1@dont-email.me> |
| In reply to | #107301 |
On 2024-06-17 03:33:50 +0000, olcott said:
> To understand this analysis requires a sufficient knowledge of
> the C programming language and what an x86 emulator does.
>
> Unless every single detail is made 100% explicit false assumptions
> always slip though the cracks. This is why it must be examined at
> the C level before it is examined at the Turing Machine level.
>
> typedef void (*ptr)();
> int H0(ptr P);
>
> void Infinite_Loop()
> {
> HERE: goto HERE;
> }
>
> void Infinite_Recursion()
> {
> Infinite_Recursion();
> }
>
> void DDD()
> {
> H0(DDD);
> return;
> }
>
> int main()
> {
> H0(Infinite_Loop);
> H0(Infinite_Recursion);
> 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.
>
> When this is construed as non-halting criteria then simulating
> termination analyzer H0 is correct to reject these inputs as non-
> halting.
The subject line is incorrect. The OP of "Simulating termination analyzers
for dummies" should tell what a "simulating termination analyzer" is.
The OP of this thread does not.
--
Mikko
[toc] | [prev] | [next] | [standalone]
Page 8 of 9 — ← Prev page 1 2 3 4 5 6 7 [8] 9 Next page →
Back to top | Article view | comp.theory
csiph-web