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 4 of 9 — ← Prev page 1 2 3 [4] 5 6 7 8 9 Next page →
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-17 22:01 -0500 |
| Message-ID | <v4qtaa$15gc5$1@dont-email.me> |
| In reply to | #107348 |
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.
--
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-17 23:15 -0400 |
| Message-ID | <v4qu3p$a0nm$7@i2pn2.org> |
| In reply to | #107349 |
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.
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.
Do that just makes you a LIAR, and so that is what you are.
You have been told this many times, but you think that just because the
definitions don't let you do something you think you should you get to
CHEAT and change things.
It doesn't.
If you show an ACTUAL PROBLEM that people agree is a problem that breaks
the logic system, like Russel's set of all sets that don't contain
themselves just broke Naive Set Theory, then perhaps people might be
interested in an alternate form of computation theory.
Just the fact that you think there is something wrong with the fact that
Halting is not computable, isn't that sort of error, as the whole point
of Computation Theory is to find out which Functions (aka maps) are
computable and which are not.
It is KNOWN that many maps are not computable, in fact it turns out that
almost all arbitrary maps are not computable. In one sense, it is a bit
surprizing that so many of the maps we want to look at are computable.
But that turns out to be that a lot of the problems we want to look at
have enough structure that they happen to be computable.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-17 22:28 -0500 |
| Message-ID | <v4quti$15nn8$1@dont-email.me> |
| In reply to | #107350 |
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.
> 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.
If the halting problem is correct then truth itself
is broken. Since truth itself cannot be broken then
the halting problem cannot be correct.
This is all anchored in the details of truthmaker
maximalism.
> 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*
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.
Perhaps you are too ignorant to understand that bias
is a systematic error.
--
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-18 07:36 -0400 |
| Message-ID | <v4rrge$bivn$1@i2pn2.org> |
| In reply to | #107351 |
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.
An ad-hominen that tries to avoid showing that you have nothing by
claiming the other couldn't understand it.
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.
>
>> 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 you had a fundamental flaw that actually broke the system, you could
just show it.
>
> 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.
It isn't that everyone else is wrong, it is YOU are wrong, but are too
bulheaded to accept it.
>
> This is all anchored in the details of truthmaker
> maximalism.
Which, as we just showed, you don't understand.
Yes, your problem is YOU, and your refusal to actually look at what is
being shown to you.
You are worse than the election deniers that you put down.
>
>> 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.
Truth seems to be something beyound your understanding since you have
lied to yourself so long.
>
> 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.
>
> 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.
If you don't see how claiming that an answer that is wrong by definition
is right is illogical, you are just beyound hope.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-18 08:21 -0500 |
| Message-ID | <v4s1l0$1boeu$6@dont-email.me> |
| In reply to | #107358 |
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.
> 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.
> 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.
>
>
>>
>>> 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.
> 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.
>>
>> 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.
> 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.
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
>>
>> 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."
> 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.
> You are worse than the election deniers that you put down.
>
Yet I have two PhD computer science professors that agree with me.
>>
>>> 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.
> Truth seems to be something beyound your understanding since you have
> lied to yourself so long.
>
Two PhD computer science professors agree with me.
>>
>> 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.
>>
>> 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.
> 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.
--
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-18 17:06 +0000 |
| Subject | Re: Simulating termination analyzers by dummies |
| Message-ID | <v4seq5$cbcu$1@i2pn2.org> |
| In reply to | #107367 |
Am Tue, 18 Jun 2024 08:21:35 -0500 schrieb olcott:
> 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:
>>>>>> 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.
DDD halts iff H0 halts.
>>>> 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.
Yes it is.
>> 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.
Then you should be able to explain it.
>> 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.
1
Something? What is it then?
>> If you had a fundamental flaw that actually broke the system, you could
>> just show it.
But you can't.
> I and two PhD computer science professors did show yet you are so
> convinced that they are wrong that you refuse to pay attention.
2
>> 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.
You are SO close.
> 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."
Do you think that sentence is true?
>>>> 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.
This is just perfect.
>> Truth seems to be something beyound your understanding since you have
>> lied to yourself so long.
> Two PhD computer science professors agree with me.
3 arguments from authority.
>>> 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.
Funny how you bring up religion.
>> 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.
That is how logic works. It's the best tool we have for truth.
>> 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.
Exactly. Like that simulators can just not simulate. The definition of the
halting problem is perfectly well-defined.
--
joes
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-18 12:25 -0500 |
| Subject | Re: Simulating termination analyzers by dummies --- What does halting mean? |
| Message-ID | <v4sfuo$1enie$1@dont-email.me> |
| In reply to | #107392 |
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.
--
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-18 17:57 +0000 |
| Subject | Re: Simulating termination analyzers by dummies --- What does halting mean? |
| Message-ID | <v4shpp$cbcu$2@i2pn2.org> |
| In reply to | #107393 |
Am Tue, 18 Jun 2024 12:25:44 -0500 schrieb olcott:
> On 6/18/2024 12:06 PM, joes wrote:
> void DDD()
> {
> H0(DDD);
> }
> DDD correctly simulated by any H0 cannot possibly halt.
>> DDD halts iff H0 halts.
So H0 returns "doesn't halt" to DDD, which then stops running,
so H0 should have returned "halts".
> 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.
Some TMs do not loop and do not halt.
> 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.
Yes. We also cannot say that that input was simulated correctly.
--
joes
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-18 13:16 -0500 |
| Subject | Re: Simulating termination analyzers by dummies --- What does halting mean? |
| Message-ID | <v4siua$1fchn$1@dont-email.me> |
| In reply to | #107394 |
On 6/18/2024 12:57 PM, joes wrote:
> Am Tue, 18 Jun 2024 12:25:44 -0500 schrieb olcott:
>> On 6/18/2024 12:06 PM, joes wrote:
>> void DDD()
>> {
>> H0(DDD);
>> }
>> DDD correctly simulated by any H0 cannot possibly halt.
>>> DDD halts iff H0 halts.
> So H0 returns "doesn't halt" to DDD, which then stops running,
> so H0 should have returned "halts".
>
>> 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.
> Some TMs do not loop and do not halt.
>
Different people define these terms differently and that
gets stuck in the infinite loop of the meaning of words.
>> 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.
> Yes. We also cannot say that that input was simulated correctly.
>
Yes everyone does that thinking that their unsupported
proclamation proves itself until I ask them:
Exactly which step was simulated incorrectly?
Then they clam up and use double-talk and change the subject.
_DDD()
[000020a2] 55 push ebp
[000020a3] 8bec mov ebp,esp
[000020a5] 68a2200000 push 000020a2
[000020aa] e8f3f9ffff call 00001aa2
[000020af] 83c404 add esp,+04
[000020b2] 5d pop ebp
[000020b3] c3 ret
Size in bytes:(0018) [000020b3]
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | joes <noreply@example.com> |
|---|---|
| Date | 2024-06-18 20:37 +0000 |
| Subject | Re: Simulating termination analyzers by dummies --- What does halting mean? |
| Message-ID | <v4sr5n$cs3v$1@i2pn2.org> |
| In reply to | #107395 |
Am Tue, 18 Jun 2024 13:16:42 -0500 schrieb olcott:
> On 6/18/2024 12:57 PM, joes wrote:
>> Am Tue, 18 Jun 2024 12:25:44 -0500 schrieb olcott:
>>> On 6/18/2024 12:06 PM, joes wrote:
>>> void DDD()
>>> {
>>> H0(DDD);
>>> }
>>> DDD correctly simulated by any H0 cannot possibly halt.
>>>> DDD halts iff H0 halts.
>> So H0 returns "doesn't halt" to DDD, which then stops running, so H0
>> should have returned "halts".
No counterargument?
>>> 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.
>> Some TMs do not loop and do not halt.
> Different people define these terms differently and that gets stuck in
> the infinite loop of the meaning of words.
"Looping" means returning to the same combined state of TM+tape.
Halting means arriving at an internal state marked final (no successors).
>>> 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.
>> Yes. We also cannot say that that input was simulated correctly.
> Yes everyone does that thinking that their unsupported proclamation
> proves itself until I ask them:
> Exactly which step was simulated incorrectly?
> Then they clam up and use double-talk and change the subject.
Fuck you. The simulation must be complete. The steps that follow and
weren't simulated at all were "simulated incorrectly".
--
joes
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-18 16:29 -0500 |
| Subject | Re: Simulating termination analyzers by dummies --- What does halting mean? |
| Message-ID | <v4su89$1hjnp$2@dont-email.me> |
| In reply to | #107398 |
On 6/18/2024 3:37 PM, joes wrote:
> Am Tue, 18 Jun 2024 13:16:42 -0500 schrieb olcott:
>> On 6/18/2024 12:57 PM, joes wrote:
>>> Am Tue, 18 Jun 2024 12:25:44 -0500 schrieb olcott:
>>>> On 6/18/2024 12:06 PM, joes wrote:
>>>> void DDD()
>>>> {
>>>> H0(DDD);
>>>> }
>>>> DDD correctly simulated by any H0 cannot possibly halt.
>>>>> DDD halts iff H0 halts.
>>> So H0 returns "doesn't halt" to DDD, which then stops running, so H0
>>> should have returned "halts".
> No counterargument?
>
>>>> 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.
>>> Some TMs do not loop and do not halt.
>> Different people define these terms differently and that gets stuck in
>> the infinite loop of the meaning of words.
> "Looping" means returning to the same combined state of TM+tape.
> Halting means arriving at an internal state marked final (no successors).
>
>>>> 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.
>>> Yes. We also cannot say that that input was simulated correctly.
>> Yes everyone does that thinking that their unsupported proclamation
>> proves itself until I ask them:
>> Exactly which step was simulated incorrectly?
>> Then they clam up and use double-talk and change the subject.
> Fuck you. The simulation must be complete. The steps that follow and
> weren't simulated at all were "simulated incorrectly".
>
Yes I forgot that another part of this double-talk, clamming
up and changing the subject is erasing the original question.
Resorting to vulgarities is something new. Fake
rebuttals that are pure ad hominem and insults is old hat.
void DDD()
{
H0(DDD);
}
_DDD()
[000020a2] 55 push ebp ; housekeeping
[000020a3] 8bec mov ebp,esp ; housekeeping
[000020a5] 68a2200000 push 000020a2 ; push DDD
[000020aa] e8f3f9ffff call 00001aa2 ; call H0
[000020af] 83c404 add esp,+04 ; housekeeping
[000020b2] 5d pop ebp ; housekeeping
[000020b3] c3 ret ; never gets here
Size in bytes:(0018) [000020b3]
Exactly which step of DDD emulated by H0 was emulated
incorrectly such that this emulation would be complete?
AKA DDD emulated by H0 reaches machine address [000020b3]
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | joes <noreply@example.com> |
|---|---|
| Date | 2024-06-19 08:48 +0000 |
| Subject | Re: Simulating termination analyzers by dummies --- What does halting mean? |
| Message-ID | <v4u604$ec9m$1@i2pn2.org> |
| In reply to | #107400 |
Am Tue, 18 Jun 2024 16:29:45 -0500 schrieb olcott:
> On 6/18/2024 3:37 PM, joes wrote:
>> Am Tue, 18 Jun 2024 13:16:42 -0500 schrieb olcott:
>>> On 6/18/2024 12:57 PM, joes wrote:
>>>> Am Tue, 18 Jun 2024 12:25:44 -0500 schrieb olcott:
>>>>> On 6/18/2024 12:06 PM, joes wrote:
>>>>> void DDD()
>>>>> {
>>>>> H0(DDD);
>>>>> }
>>>>> DDD correctly simulated by any H0 cannot possibly halt.
>>>>>> DDD halts iff H0 halts.
>>>> So H0 returns "doesn't halt" to DDD, which then stops running, so H0
>>>> should have returned "halts".
>> No counterargument?
Apparently not.
>>>>> 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.
>>>> Some TMs do not loop and do not halt.
>>> Different people define these terms differently and that gets stuck in
>>> the infinite loop of the meaning of words.
>> "Looping" means returning to the same combined state of TM+tape.
>> Halting means arriving at an internal state marked final (no
>> successors).
Do you agree?
>>>>> 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.
>>>> Yes. We also cannot say that that input was simulated correctly.
>>> Yes everyone does that thinking that their unsupported proclamation
>>> proves itself until I ask them:
>>> Exactly which step was simulated incorrectly?
>>> Then they clam up and use double-talk and change the subject.
>> Fuck you. The simulation must be complete. The steps that follow and
>> weren't simulated at all were "simulated incorrectly".
> Yes I forgot that another part of this double-talk, clamming up and
> changing the subject is erasing the original question.
I erased only the misleading assembly code that you spam everywhere.
> void DDD()
> {
> H0(DDD);
> }
> _DDD()
> [000020a2] 55 push ebp ; housekeeping
> [000020a3] 8bec mov ebp,esp ; housekeeping
> [000020a5] 68a2200000 push 000020a2 ; push DDD
> [000020aa] e8f3f9ffff call 00001aa2 ; call H0
> [000020af] 83c404 add esp,+04 ; housekeeping
> [000020b2] 5d pop ebp ; housekeeping
> [000020b3] c3 ret ; never gets here
> Size in bytes:(0018) [000020b3]
>
> Exactly which step of DDD emulated by H0 was emulated incorrectly such
> that this emulation would be complete?
> AKA DDD emulated by H0 reaches machine address [000020b3]
Exactly which steps prevents it from getting there? We know that H0 halts.
--
joes
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-19 08:12 -0500 |
| Subject | Re: Simulating termination analyzers by dummies --- test of dishonesty |
| Message-ID | <v4ulgg$1vpm0$4@dont-email.me> |
| In reply to | #107417 |
On 6/19/2024 3:48 AM, joes wrote:
> Am Tue, 18 Jun 2024 16:29:45 -0500 schrieb olcott:
>> On 6/18/2024 3:37 PM, joes wrote:
>>> Am Tue, 18 Jun 2024 13:16:42 -0500 schrieb olcott:
>>>> On 6/18/2024 12:57 PM, joes wrote:
>>>>> Am Tue, 18 Jun 2024 12:25:44 -0500 schrieb olcott:
>>>>>> On 6/18/2024 12:06 PM, joes wrote:
>>>>>> void DDD()
>>>>>> {
>>>>>> H0(DDD);
>>>>>> }
>>>>>> DDD correctly simulated by any H0 cannot possibly halt.
>>>>>>> DDD halts iff H0 halts.
>>>>> So H0 returns "doesn't halt" to DDD, which then stops running, so H0
>>>>> should have returned "halts".
>>> No counterargument?
> Apparently not.
>
>>>>>> 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.
>>>>> Some TMs do not loop and do not halt.
>>>> Different people define these terms differently and that gets stuck in
>>>> the infinite loop of the meaning of words.
>>> "Looping" means returning to the same combined state of TM+tape.
>>> Halting means arriving at an internal state marked final (no
>>> successors).
> Do you agree?
>
>>>>>> 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.
>>>>> Yes. We also cannot say that that input was simulated correctly.
>>>> Yes everyone does that thinking that their unsupported proclamation
>>>> proves itself until I ask them:
>>>> Exactly which step was simulated incorrectly?
>>>> Then they clam up and use double-talk and change the subject.
>>> Fuck you. The simulation must be complete. The steps that follow and
>>> weren't simulated at all were "simulated incorrectly".
>> Yes I forgot that another part of this double-talk, clamming up and
>> changing the subject is erasing the original question.
> I erased only the misleading assembly code that you spam everywhere.
>
>> void DDD()
>> {
>> H0(DDD);
>> }
>> _DDD()
>> [000020a2] 55 push ebp ; housekeeping
>> [000020a3] 8bec mov ebp,esp ; housekeeping
>> [000020a5] 68a2200000 push 000020a2 ; push DDD
>> [000020aa] e8f3f9ffff call 00001aa2 ; call H0
>> [000020af] 83c404 add esp,+04 ; housekeeping
>> [000020b2] 5d pop ebp ; housekeeping
>> [000020b3] c3 ret ; never gets here
>> Size in bytes:(0018) [000020b3]
>>
>> Exactly which step of DDD emulated by H0 was emulated incorrectly such
>> that this emulation would be complete?
>> AKA DDD emulated by H0 reaches machine address [000020b3]
> Exactly which steps prevents it from getting there? We know that H0 halts.
>
void DDD()
{
H0(DDD);
}
_DDD()
[000020a2] 55 push ebp ; housekeeping
[000020a3] 8bec mov ebp,esp ; housekeeping
[000020a5] 68a2200000 push 000020a2 ; push DDD
[000020aa] e8f3f9ffff call 00001aa2 ; call H0
[000020af] 83c404 add esp,+04 ; housekeeping
[000020b2] 5d pop ebp ; housekeeping
[000020b3] c3 ret ; never gets here
Size in bytes:(0018) [000020b3]
Exactly which step of DDD emulated by H0 was emulated
incorrectly such that this emulation would be complete?
AKA DDD emulated by H0 reaches machine address [000020b3]
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-18 16:08 -0500 |
| Subject | Re: Simulating termination analyzers by dummies --- What does halting mean? |
| Message-ID | <v4st0g$1hjnp$1@dont-email.me> |
| In reply to | #107394 |
On 6/18/2024 12:57 PM, joes wrote:
> Am Tue, 18 Jun 2024 12:25:44 -0500 schrieb olcott:
>> On 6/18/2024 12:06 PM, joes wrote:
>> void DDD()
>> {
>> H0(DDD);
>> }
>> DDD correctly simulated by any H0 cannot possibly halt.
>>> DDD halts iff H0 halts.
> So H0 returns "doesn't halt" to DDD, which then stops running,
> so H0 should have returned "halts".
>
This was three messages ago.
I had to make sure that you understood that halting
does not mean stopping for any reason and only includes
the equivalent of terminating normally.
DDD correctly emulated by H0 DOES NOT TERMINATE NORMALLY.
>> 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.
> Some TMs do not loop and do not halt.
>
>> 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.
> Yes. We also cannot say that that input was simulated correctly.
>
--
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 | Alan Mackenzie <acm@muc.de> |
|---|---|
| Date | 2024-06-18 21:36 +0000 |
| Subject | Re: Simulating termination analyzers by dummies --- What does halting mean? |
| Message-ID | <v4sull$2f03$1@news.muc.de> |
| In reply to | #107399 |
[ Followup-To: set ]
In comp.theory olcott <polcott333@gmail.com> wrote:
> On 6/18/2024 12:57 PM, joes wrote:
>> Am Tue, 18 Jun 2024 12:25:44 -0500 schrieb olcott:
>>> On 6/18/2024 12:06 PM, joes wrote:
>>> void DDD()
>>> {
>>> H0(DDD);
>>> }
>>> DDD correctly simulated by any H0 cannot possibly halt.
>>>> DDD halts iff H0 halts.
>> So H0 returns "doesn't halt" to DDD, which then stops running,
>> so H0 should have returned "halts".
> This was three messages ago.
> I had to make sure that you understood that halting
> does not mean stopping for any reason and only includes
> the equivalent of terminating normally.
No. You're wrong, here. A turing machine is either running or it's
halted. There's no third alternative. If your C programs are not in one
of these two states, they're not equivalent to turing machines.
> DDD correctly emulated by H0 DOES NOT TERMINATE NORMALLY.
There is no concept of "normal" termination in a turing machine. The
thing is either running or it's halted.
>>> 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.
>> Some TMs do not loop and do not halt.
>>> A UTM can be adapted so that it only simulates a fixed number of
>>> iterations of an input that loops.
As has often been said, it is then no longer a universal turing machine.
>>> When this UTM stops simulating this Turing machine description we
>>> cannot correctly say that this looping input halted.
Yes, we can. It has been designed to count to 42 then halt. It is then
in the halted state.
>> Yes. We also cannot say that that input was simulated correctly.
Indeed, not.
> --
> Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
> hits a target no one else can see." Arthur Schopenhauer
--
Alan Mackenzie (Nuremberg, Germany).
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-18 16:54 -0500 |
| Subject | Re: Simulating termination analyzers by dummies --- What does halting mean? |
| Message-ID | <v4svmn$1i267$1@dont-email.me> |
| In reply to | #107401 |
On 6/18/2024 4:36 PM, Alan Mackenzie wrote:
> [ Followup-To: set ]
>
> In comp.theory olcott <polcott333@gmail.com> wrote:
>> On 6/18/2024 12:57 PM, joes wrote:
>>> Am Tue, 18 Jun 2024 12:25:44 -0500 schrieb olcott:
>>>> On 6/18/2024 12:06 PM, joes wrote:
>>>> void DDD()
>>>> {
>>>> H0(DDD);
>>>> }
>>>> DDD correctly simulated by any H0 cannot possibly halt.
>>>>> DDD halts iff H0 halts.
>
>>> So H0 returns "doesn't halt" to DDD, which then stops running,
>>> so H0 should have returned "halts".
>
>> This was three messages ago.
>> I had to make sure that you understood that halting
>> does not mean stopping for any reason and only includes
>> the equivalent of terminating normally.
>
> No. You're wrong, here. A turing machine is either running or it's
> halted. There's no third alternative. If your C programs are not in one
> of these two states, they're not equivalent to turing machines.
>
Although I agree with this there seems to be nuances of
disagreement across the experts.
>> DDD correctly emulated by H0 DOES NOT TERMINATE NORMALLY.
>
> There is no concept of "normal" termination in a turing machine. The
> thing is either running or it's halted.
>
I develop one within the conventional notions below.
>>>> 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.
>>> Some TMs do not loop and do not halt.
>
>>>> A UTM can be adapted so that it only simulates a fixed number of
>>>> iterations of an input that loops.
>
> As has often been said, it is then no longer a universal turing machine.
>
None-the-less it does derive the notion of abnormal termination
as applied to Turing Machines.
>>>> When this UTM stops simulating this Turing machine description we
>>>> cannot correctly say that this looping input halted.
>
> Yes, we can. It has been designed to count to 42 then halt. It is then
> in the halted state.
>
Two different machines.
(a) The TM description of a looping machine.
(b) A UTM that has been adapted to count to five repeating
states before it aborts its simulation of the looping machine.
>>> Yes. We also cannot say that that input was simulated correctly.
>
> Indeed, not.
>
It is a mistake for a simulating termination analyzer
to simulate infinite repeating states.
>> --
>> Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
>> hits a target no one else can see." Arthur Schopenhauer
>
--
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 | Alan Mackenzie <acm@muc.de> |
|---|---|
| Date | 2024-06-19 09:29 +0000 |
| Subject | Re: Simulating termination analyzers by dummies --- What does halting mean? |
| Message-ID | <v4u8cu$1o15$1@news.muc.de> |
| In reply to | #107402 |
olcott <polcott333@gmail.com> wrote:
> On 6/18/2024 4:36 PM, Alan Mackenzie wrote:
>> [ Followup-To: set ]
>> In comp.theory olcott <polcott333@gmail.com> wrote:
>>> On 6/18/2024 12:57 PM, joes wrote:
>>>> Am Tue, 18 Jun 2024 12:25:44 -0500 schrieb olcott:
>>>>> On 6/18/2024 12:06 PM, joes wrote:
>>>>> void DDD()
>>>>> {
>>>>> H0(DDD);
>>>>> }
>>>>> DDD correctly simulated by any H0 cannot possibly halt.
>>>>>> DDD halts iff H0 halts.
>>>> So H0 returns "doesn't halt" to DDD, which then stops running,
>>>> so H0 should have returned "halts".
>>> This was three messages ago.
>>> I had to make sure that you understood that halting
>>> does not mean stopping for any reason and only includes
>>> the equivalent of terminating normally.
>> No. You're wrong, here. A turing machine is either running or it's
>> halted. There's no third alternative. If your C programs are not in one
>> of these two states, they're not equivalent to turing machines.
> Although I agree with this there seems to be nuances of
> disagreement across the experts.
I doubt that very much. The whole point of turing machines is to remove
ambiguity and unneeded features from the theory of computation. A third
alternative state is unneeded.
>>> DDD correctly emulated by H0 DOES NOT TERMINATE NORMALLY.
>> There is no concept of "normal" termination in a turing machine. The
>> thing is either running or it's halted.
> I develop one within the conventional notions below.
You don't need it. You just confuse yourself (and possibly others) with
it. What you call the "aborted state" is just one more final state for
the TM to halt in.
>>>>> 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.
>>>> Some TMs do not loop and do not halt.
>>>>> A UTM can be adapted so that it only simulates a fixed number of
>>>>> iterations of an input that loops.
>> As has often been said, it is then no longer a universal turing machine.
> None-the-less it does derive the notion of abnormal termination
> as applied to Turing Machines.
As I said, that is not a useful notion. It just confuses.
>>>>> When this UTM stops simulating this Turing machine description we
>>>>> cannot correctly say that this looping input halted.
>> Yes, we can. It has been designed to count to 42 then halt. It is then
>> in the halted state.
> Two different machines.
> (a) The TM description of a looping machine.
> (b) A UTM that has been adapted to count to five repeating
> states before it aborts its simulation of the looping machine.
(b) is not a universal turing machine. It is a TM, one of whose halting
states is having counted five repeating states.
>>>> Yes. We also cannot say that that input was simulated correctly.
>> Indeed, not.
> It is a mistake for a simulating termination analyzer
> to simulate infinite repeating states.
How can that be a "mistake" if it's what the thing is programmed to do?
> --
> Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
> hits a target no one else can see." Arthur Schopenhauer
--
Alan Mackenzie (Nuremberg, Germany).
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-19 09:05 -0500 |
| Subject | Re: Simulating termination analyzers by dummies --- What does halting mean? |
| Message-ID | <v4uoj9$1vpm0$10@dont-email.me> |
| In reply to | #107420 |
On 6/19/2024 4:29 AM, Alan Mackenzie wrote:
> olcott <polcott333@gmail.com> wrote:
>> On 6/18/2024 4:36 PM, Alan Mackenzie wrote:
>>> [ Followup-To: set ]
>
>>> In comp.theory olcott <polcott333@gmail.com> wrote:
>>>> On 6/18/2024 12:57 PM, joes wrote:
>>>>> Am Tue, 18 Jun 2024 12:25:44 -0500 schrieb olcott:
>>>>>> On 6/18/2024 12:06 PM, joes wrote:
>>>>>> void DDD()
>>>>>> {
>>>>>> H0(DDD);
>>>>>> }
>>>>>> DDD correctly simulated by any H0 cannot possibly halt.
>>>>>>> DDD halts iff H0 halts.
>
>>>>> So H0 returns "doesn't halt" to DDD, which then stops running,
>>>>> so H0 should have returned "halts".
>
>>>> This was three messages ago.
>>>> I had to make sure that you understood that halting
>>>> does not mean stopping for any reason and only includes
>>>> the equivalent of terminating normally.
>
>>> No. You're wrong, here. A turing machine is either running or it's
>>> halted. There's no third alternative. If your C programs are not in one
>>> of these two states, they're not equivalent to turing machines.
>
>> Although I agree with this there seems to be nuances of
>> disagreement across the experts.
>
> I doubt that very much. The whole point of turing machines is to remove
> ambiguity and unneeded features from the theory of computation. A third
> alternative state is unneeded.
>
Some people say that a TM can halt in a non-final state.
>>>> DDD correctly emulated by H0 DOES NOT TERMINATE NORMALLY.
>
>>> There is no concept of "normal" termination in a turing machine. The
>>> thing is either running or it's halted.
>
>
>> I develop one within the conventional notions below.
>
> You don't need it. You just confuse yourself (and possibly others) with
> it. What you call the "aborted state" is just one more final state for
> the TM to halt in.
>
When the adapted UTM halts after simulating ten state transitions
of a Turing Machine Description that only loops we cannot correctly
say that the looping input has halted.
When the adapted UTM halts after recognizing the repeating state
of a Turing Machine Description that only loops and transitions to
its reject state then this adapted UTM is a halt decider for
inputs that only loop.
>>>>>> 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.
>>>>> Some TMs do not loop and do not halt.
>
>>>>>> A UTM can be adapted so that it only simulates a fixed number of
>>>>>> iterations of an input that loops.
>
>>> As has often been said, it is then no longer a universal turing machine.
>
So what?
>
>> None-the-less it does derive the notion of abnormal termination
>> as applied to Turing Machines.
>
> As I said, that is not a useful notion. It just confuses.
>
It is a perfectly useful notion as I have defined above
because the adapted UTM becomes a halt decider for inputs
that only loop.
>>>>>> When this UTM stops simulating this Turing machine description we
>>>>>> cannot correctly say that this looping input halted.
>
>>> Yes, we can. It has been designed to count to 42 then halt. It is then
>>> in the halted state.
>
>
>> Two different machines.
>> (a) The TM description of a looping machine.
>> (b) A UTM that has been adapted to count to five repeating
>> states before it aborts its simulation of the looping machine.
>
> (b) is not a universal turing machine. It is a TM, one of whose halting
> states is having counted five repeating states.
>
>>>>> Yes. We also cannot say that that input was simulated correctly.
>
>>> Indeed, not.
>
>
>> It is a mistake for a simulating termination analyzer
>> to simulate infinite repeating states.
>
> How can that be a "mistake" if it's what the thing is programmed to do?
>
Termination analyzers are required to halt so it fails
to meet its spec.
>> --
>> Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
>> hits a target no one else can see." Arthur Schopenhauer
>
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | joes <noreply@example.com> |
|---|---|
| Date | 2024-06-19 17:51 +0000 |
| Subject | Re: Simulating termination analyzers by dummies --- What does halting mean? |
| Message-ID | <v4v5qu$fhqs$9@i2pn2.org> |
| In reply to | #107434 |
Am Wed, 19 Jun 2024 09:05:29 -0500 schrieb olcott: > On 6/19/2024 4:29 AM, Alan Mackenzie wrote: >> olcott <polcott333@gmail.com> wrote: >>> On 6/18/2024 4:36 PM, Alan Mackenzie wrote: >>>> In comp.theory olcott <polcott333@gmail.com> wrote: >>>>> On 6/18/2024 12:57 PM, joes wrote: >>>>>> Am Tue, 18 Jun 2024 12:25:44 -0500 schrieb olcott: >>>>>>> On 6/18/2024 12:06 PM, joes wrote: >>>> No. You're wrong, here. A turing machine is either running or it's >>>> halted. There's no third alternative. If your C programs are not in >>>> one of these two states, they're not equivalent to turing machines. >>> Although I agree with this there seems to be nuances of disagreement >>> across the experts. >> I doubt that very much. The whole point of turing machines is to >> remove ambiguity and unneeded features from the theory of computation. >> A third alternative state is unneeded. > Some people say that a TM can halt in a non-final state. None here do. End of thread. >>>>> DDD correctly emulated by H0 DOES NOT TERMINATE NORMALLY. >>>> There is no concept of "normal" termination in a turing machine. The >>>> thing is either running or it's halted. >>> I develop one within the conventional notions below. >> You don't need it. You just confuse yourself (and possibly others) >> with it. What you call the "aborted state" is just one more final >> state for the TM to halt in. > When the adapted UTM halts after simulating ten state transitions of a > Turing Machine Description that only loops we cannot correctly say that > the looping input has halted. Yes! > When the adapted UTM halts after recognizing the repeating state of a > Turing Machine Description that only loops and transitions to its reject > state then this adapted UTM is a halt decider for inputs that only loop. But not a simulator. >>>>>>> A UTM can be adapted so that it only simulates a fixed number of >>>>>>> iterations of an input that loops. >>>> As has often been said, it is then no longer a universal turing >>>> machine. > So what? You wanted to simulate the input. >>> None-the-less it does derive the notion of abnormal termination as >>> applied to Turing Machines. >> As I said, that is not a useful notion. It just confuses. > It is a perfectly useful notion as I have defined above because the > adapted UTM becomes a halt decider for inputs that only loop. >>>>>>> When this UTM stops simulating this Turing machine description we >>>>>>> cannot correctly say that this looping input halted. >>> (a) The TM description of a looping machine. >>> (b) A UTM that has been adapted to count to five repeating states >>> before it aborts its simulation of the looping machine. >> (b) is not a universal turing machine. It is a TM, one of whose >> halting states is having counted five repeating states. >>> It is a mistake for a simulating termination analyzer to simulate >>> infinite repeating states. >> How can that be a "mistake" if it's what the thing is programmed to do? > Termination analyzers are required to halt so it fails to meet its spec. What use is an analyser that can't deal with possible loops? -- joes
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-19 12:52 -0500 |
| Subject | Re: Simulating termination analyzers by dummies --- The only reply until addressed |
| Message-ID | <v4v5tr$238f5$1@dont-email.me> |
| In reply to | #107458 |
On 6/19/2024 12:51 PM, joes wrote:
> Am Wed, 19 Jun 2024 09:05:29 -0500 schrieb olcott:
>> On 6/19/2024 4:29 AM, Alan Mackenzie wrote:
>>> olcott <polcott333@gmail.com> wrote:
>>>> On 6/18/2024 4:36 PM, Alan Mackenzie wrote:
>>>>> In comp.theory olcott <polcott333@gmail.com> wrote:
>>>>>> On 6/18/2024 12:57 PM, joes wrote:
>>>>>>> Am Tue, 18 Jun 2024 12:25:44 -0500 schrieb olcott:
>>>>>>>> On 6/18/2024 12:06 PM, joes wrote:
>
>>>>> No. You're wrong, here. A turing machine is either running or it's
>>>>> halted. There's no third alternative. If your C programs are not in
>>>>> one of these two states, they're not equivalent to turing machines.
>>>> Although I agree with this there seems to be nuances of disagreement
>>>> across the experts.
>>> I doubt that very much. The whole point of turing machines is to
>>> remove ambiguity and unneeded features from the theory of computation.
>>> A third alternative state is unneeded.
>> Some people say that a TM can halt in a non-final state.
> None here do. End of thread.
>
>>>>>> DDD correctly emulated by H0 DOES NOT TERMINATE NORMALLY.
>>>>> There is no concept of "normal" termination in a turing machine. The
>>>>> thing is either running or it's halted.
>>>> I develop one within the conventional notions below.
>>> You don't need it. You just confuse yourself (and possibly others)
>>> with it. What you call the "aborted state" is just one more final
>>> state for the TM to halt in.
>> When the adapted UTM halts after simulating ten state transitions of a
>> Turing Machine Description that only loops we cannot correctly say that
>> the looping input has halted.
> Yes!
>> When the adapted UTM halts after recognizing the repeating state of a
>> Turing Machine Description that only loops and transitions to its reject
>> state then this adapted UTM is a halt decider for inputs that only loop.
> But not a simulator.
>
>>>>>>>> A UTM can be adapted so that it only simulates a fixed number of
>>>>>>>> iterations of an input that loops.
>>>>> As has often been said, it is then no longer a universal turing
>>>>> machine.
>> So what?
> You wanted to simulate the input.
>
>>>> None-the-less it does derive the notion of abnormal termination as
>>>> applied to Turing Machines.
>>> As I said, that is not a useful notion. It just confuses.
>> It is a perfectly useful notion as I have defined above because the
>> adapted UTM becomes a halt decider for inputs that only loop.
>
>>>>>>>> When this UTM stops simulating this Turing machine description we
>>>>>>>> cannot correctly say that this looping input halted.
>
>>>> (a) The TM description of a looping machine.
>>>> (b) A UTM that has been adapted to count to five repeating states
>>>> before it aborts its simulation of the looping machine.
>>> (b) is not a universal turing machine. It is a TM, one of whose
>>> halting states is having counted five repeating states.
>
>
>>>> It is a mistake for a simulating termination analyzer to simulate
>>>> infinite repeating states.
>>> How can that be a "mistake" if it's what the thing is programmed to do?
>> Termination analyzers are required to halt so it fails to meet its spec.
> What use is an analyser that can't deal with possible loops?
>
void DDD()
{
H0(DDD);
}
_DDD()
[000020a2] 55 push ebp ; housekeeping
[000020a3] 8bec mov ebp,esp ; housekeeping
[000020a5] 68a2200000 push 000020a2 ; push DDD
[000020aa] e8f3f9ffff call 00001aa2 ; call H0
[000020af] 83c404 add esp,+04 ; housekeeping
[000020b2] 5d pop ebp ; housekeeping
[000020b3] c3 ret ; never gets here
Size in bytes:(0018) [000020b3]
Exactly which step of DDD emulated by H0 was emulated
incorrectly such that this emulation would be complete?
AKA DDD emulated by H0 reaches machine address [000020b3]
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
Page 4 of 9 — ← Prev page 1 2 3 [4] 5 6 7 8 9 Next page →
Back to top | Article view | comp.theory
csiph-web