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 3 of 9 — ← Prev page 1 2 [3] 4 5 6 7 8 9 Next page →
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-20 21:55 -0400 |
| Message-ID | <v52mig$jund$3@i2pn2.org> |
| In reply to | #107508 |
On 6/20/24 6:52 PM, olcott wrote: > On 6/20/2024 5:48 PM, joes wrote: >> Am Wed, 19 Jun 2024 21:25:31 -0500 schrieb olcott: >>> On 6/19/2024 9:17 PM, Richard Damon wrote: >>>> On 6/19/24 10:02 PM, olcott wrote: >>>>> On 6/19/2024 8:39 PM, Richard Damon wrote: >>>>>> On 6/19/24 8:44 PM, olcott wrote: >>>>>>> On 6/19/2024 7:23 PM, Richard Damon wrote: >>>>>>>> On 6/19/24 9:00 AM, olcott wrote: >>>>>>>>> On 6/19/2024 3:08 AM, Fred. Zwarts wrote: >>>>>>>>>> Op 18.jun.2024 om 18:26 schreef olcott: >>>>>>>>>>> On 6/18/2024 10:47 AM, Fred. Zwarts wrote: >>>>>>>>>>>> Op 18.jun.2024 om 17:33 schreef olcott: >>>>>>>>>>>>> On 6/18/2024 10:20 AM, Fred. Zwarts wrote: >> >>>>>>>>>> It is easier to understand because a print statement was added. >>>>>>>>>> You proved that it halts, but H0 reports non-halting. >>>>>>>>>> So, it produces a false negative. >>>>>>>>>> So, now it has been proved that H, H0, etc produce false >>>>>>>>>> negatives, when used to determine halting behaviour, please, stop >>>>>>>>>> to call them halt-deciders, or termination-deciders. >>>>>>>>>> They might be "simulation deciders". When returning true, the >>>>>>>>>> simulation was correct, when false, the full simulation was not >>>>>>>>>> possible. >> >>>>>>>> Why does H0 NEED to be able to simulate its input? >> Yeah, why? That just adds a contradictory requirement. Not that it were >> possible otherwise. >> >>>>>>> Decider must compute the mapping from their finite string input to >>>>>>> the actual behavior that this finite string specifies. >> If possible. >>>>>>> They are not free to imagine the behavior that the authors of >>>>>>> textbooks expect. >> Nor crackpots. >> >>>>> The finite string input does not communicate the behavior that the >>>>> textbook authors expect it to communicate. >> Bullshit. Your neither-decider-nor-simulator just can't handle it. >> The direct execution of DDD is the measure of things. A simulation >> must behave identically. Of course you may be able to do analysis >> on whether it halts, but that's different. Simulation is dumb. >> >>>> The finite string certainly DOES communicate what is needed to >>>> determine the behavior, or it wasn't a correct representation. >> Deflection follows: >>> There is no sequence of truth preserving operations from the finite >>> string machine code of DDD that can correctly ignore the pathological >>> relationship between H0 and DDD as an aspect of the behavior that this >>> finite string specifies. >> Many other simulators or deciders work correctly with DDD, just not the >> one it calls. But they each get a different one wrong. >> What do you mean with "ignore the relationship"? >> >>> No one has noticed this before because no one ever thought to make every >>> single detail 100% concrete, thus leaving huge gaps in all prior >>> reasoning. >> We have a proof. >> > > You have dogmatic false assumptions. > It is an verified fact that the input to H(D,D) cannot > be mapped to the behavior of D(D). ???? But the Halting Function does that map. > > When I say "mapped" I don't mean look something > up in Google maps. > No, and you don't mean a defined mapping of the input to the output, you LIE by trying to mean only COMPUTABLE mappings, which is just a LIE. I guess you are just admitting that you are just a totally ignorant liar.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-20 21:29 -0500 |
| Message-ID | <v52oi7$2v5s6$2@dont-email.me> |
| In reply to | #107514 |
On 6/20/2024 8:55 PM, Richard Damon wrote: > On 6/20/24 6:52 PM, olcott wrote: >> On 6/20/2024 5:48 PM, joes wrote: >>> Am Wed, 19 Jun 2024 21:25:31 -0500 schrieb olcott: >>>> On 6/19/2024 9:17 PM, Richard Damon wrote: >>>>> On 6/19/24 10:02 PM, olcott wrote: >>>>>> On 6/19/2024 8:39 PM, Richard Damon wrote: >>>>>>> On 6/19/24 8:44 PM, olcott wrote: >>>>>>>> On 6/19/2024 7:23 PM, Richard Damon wrote: >>>>>>>>> On 6/19/24 9:00 AM, olcott wrote: >>>>>>>>>> On 6/19/2024 3:08 AM, Fred. Zwarts wrote: >>>>>>>>>>> Op 18.jun.2024 om 18:26 schreef olcott: >>>>>>>>>>>> On 6/18/2024 10:47 AM, Fred. Zwarts wrote: >>>>>>>>>>>>> Op 18.jun.2024 om 17:33 schreef olcott: >>>>>>>>>>>>>> On 6/18/2024 10:20 AM, Fred. Zwarts wrote: >>> >>>>>>>>>>> It is easier to understand because a print statement was added. >>>>>>>>>>> You proved that it halts, but H0 reports non-halting. >>>>>>>>>>> So, it produces a false negative. >>>>>>>>>>> So, now it has been proved that H, H0, etc produce false >>>>>>>>>>> negatives, when used to determine halting behaviour, please, >>>>>>>>>>> stop >>>>>>>>>>> to call them halt-deciders, or termination-deciders. >>>>>>>>>>> They might be "simulation deciders". When returning true, the >>>>>>>>>>> simulation was correct, when false, the full simulation was not >>>>>>>>>>> possible. >>> >>>>>>>>> Why does H0 NEED to be able to simulate its input? >>> Yeah, why? That just adds a contradictory requirement. Not that it were >>> possible otherwise. >>> >>>>>>>> Decider must compute the mapping from their finite string input to >>>>>>>> the actual behavior that this finite string specifies. >>> If possible. >>>>>>>> They are not free to imagine the behavior that the authors of >>>>>>>> textbooks expect. >>> Nor crackpots. >>> >>>>>> The finite string input does not communicate the behavior that the >>>>>> textbook authors expect it to communicate. >>> Bullshit. Your neither-decider-nor-simulator just can't handle it. >>> The direct execution of DDD is the measure of things. A simulation >>> must behave identically. Of course you may be able to do analysis >>> on whether it halts, but that's different. Simulation is dumb. >>> >>>>> The finite string certainly DOES communicate what is needed to >>>>> determine the behavior, or it wasn't a correct representation. >>> Deflection follows: >>>> There is no sequence of truth preserving operations from the finite >>>> string machine code of DDD that can correctly ignore the pathological >>>> relationship between H0 and DDD as an aspect of the behavior that this >>>> finite string specifies. >>> Many other simulators or deciders work correctly with DDD, just not the >>> one it calls. But they each get a different one wrong. >>> What do you mean with "ignore the relationship"? >>> >>>> No one has noticed this before because no one ever thought to make >>>> every >>>> single detail 100% concrete, thus leaving huge gaps in all prior >>>> reasoning. >>> We have a proof. >>> >> >> You have dogmatic false assumptions. >> It is an verified fact that the input to H(D,D) cannot >> be mapped to the behavior of D(D). > > > ???? > > But the Halting Function does that map. > I ask you to show the detailed steps of that map and you always dodge. This leads me to believe that you know you are lying. _DDD() [00002093] 55 push ebp [00002094] 8bec mov ebp,esp [00002096] 6893200000 push 00002093 ; push DDD [0000209b] e853f4ffff call 000014f3 ; call HH0 [000020a0] 83c404 add esp,+04 [000020a3] 5d pop ebp [000020a4] c3 ret Size in bytes:(0018) [000020a4] -- Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-20 22:43 -0400 |
| Message-ID | <v52pc4$jund$8@i2pn2.org> |
| In reply to | #107519 |
On 6/20/24 10:29 PM, olcott wrote: > On 6/20/2024 8:55 PM, Richard Damon wrote: >> On 6/20/24 6:52 PM, olcott wrote: >>> On 6/20/2024 5:48 PM, joes wrote: >>>> Am Wed, 19 Jun 2024 21:25:31 -0500 schrieb olcott: >>>>> On 6/19/2024 9:17 PM, Richard Damon wrote: >>>>>> On 6/19/24 10:02 PM, olcott wrote: >>>>>>> On 6/19/2024 8:39 PM, Richard Damon wrote: >>>>>>>> On 6/19/24 8:44 PM, olcott wrote: >>>>>>>>> On 6/19/2024 7:23 PM, Richard Damon wrote: >>>>>>>>>> On 6/19/24 9:00 AM, olcott wrote: >>>>>>>>>>> On 6/19/2024 3:08 AM, Fred. Zwarts wrote: >>>>>>>>>>>> Op 18.jun.2024 om 18:26 schreef olcott: >>>>>>>>>>>>> On 6/18/2024 10:47 AM, Fred. Zwarts wrote: >>>>>>>>>>>>>> Op 18.jun.2024 om 17:33 schreef olcott: >>>>>>>>>>>>>>> On 6/18/2024 10:20 AM, Fred. Zwarts wrote: >>>> >>>>>>>>>>>> It is easier to understand because a print statement was added. >>>>>>>>>>>> You proved that it halts, but H0 reports non-halting. >>>>>>>>>>>> So, it produces a false negative. >>>>>>>>>>>> So, now it has been proved that H, H0, etc produce false >>>>>>>>>>>> negatives, when used to determine halting behaviour, please, >>>>>>>>>>>> stop >>>>>>>>>>>> to call them halt-deciders, or termination-deciders. >>>>>>>>>>>> They might be "simulation deciders". When returning true, the >>>>>>>>>>>> simulation was correct, when false, the full simulation was not >>>>>>>>>>>> possible. >>>> >>>>>>>>>> Why does H0 NEED to be able to simulate its input? >>>> Yeah, why? That just adds a contradictory requirement. Not that it were >>>> possible otherwise. >>>> >>>>>>>>> Decider must compute the mapping from their finite string input to >>>>>>>>> the actual behavior that this finite string specifies. >>>> If possible. >>>>>>>>> They are not free to imagine the behavior that the authors of >>>>>>>>> textbooks expect. >>>> Nor crackpots. >>>> >>>>>>> The finite string input does not communicate the behavior that the >>>>>>> textbook authors expect it to communicate. >>>> Bullshit. Your neither-decider-nor-simulator just can't handle it. >>>> The direct execution of DDD is the measure of things. A simulation >>>> must behave identically. Of course you may be able to do analysis >>>> on whether it halts, but that's different. Simulation is dumb. >>>> >>>>>> The finite string certainly DOES communicate what is needed to >>>>>> determine the behavior, or it wasn't a correct representation. >>>> Deflection follows: >>>>> There is no sequence of truth preserving operations from the finite >>>>> string machine code of DDD that can correctly ignore the pathological >>>>> relationship between H0 and DDD as an aspect of the behavior that this >>>>> finite string specifies. >>>> Many other simulators or deciders work correctly with DDD, just not the >>>> one it calls. But they each get a different one wrong. >>>> What do you mean with "ignore the relationship"? >>>> >>>>> No one has noticed this before because no one ever thought to make >>>>> every >>>>> single detail 100% concrete, thus leaving huge gaps in all prior >>>>> reasoning. >>>> We have a proof. >>>> >>> >>> You have dogmatic false assumptions. >>> It is an verified fact that the input to H(D,D) cannot >>> be mapped to the behavior of D(D). >> >> >> ???? >> >> But the Halting Function does that map. >> > > I ask you to show the detailed steps of that map and > you always dodge. This leads me to believe that you > know you are lying. "maps" don't HAVE steps, they have results. Since DDD WILL HALT, since HH0(DDD) will return or you have lies that HH0 is a decider, then the map is: DDD -> Halting. The mapping is DEFINED not by a finite sequence of steps, but by a result which is determined by the factual basis of does the program represented by the input come to a final state in a finite number of steps of that program when it is run. And it does, since you have indicated that HH0 is defined to alway return an answer in a finite number of steps. So, DDD will halt unless you are a liar. > > _DDD() > [00002093] 55 push ebp > [00002094] 8bec mov ebp,esp > [00002096] 6893200000 push 00002093 ; push DDD > [0000209b] e853f4ffff call 000014f3 ; call HH0 > [000020a0] 83c404 add esp,+04 > [000020a3] 5d pop ebp > [000020a4] c3 ret > Size in bytes:(0018) [000020a4] >
[toc] | [prev] | [next] | [standalone]
| From | Mikko <mikko.levanto@iki.fi> |
|---|---|
| Date | 2024-06-20 08:17 +0300 |
| Message-ID | <v50e1q$2e95t$1@dont-email.me> |
| In reply to | #107424 |
On 2024-06-19 13:00:57 +0000, olcott said:
> On 6/19/2024 3:08 AM, Fred. Zwarts wrote:
>> Op 18.jun.2024 om 18:26 schreef olcott:
>>> On 6/18/2024 10:47 AM, Fred. Zwarts wrote:
>>>> Op 18.jun.2024 om 17:33 schreef olcott:
>>>>> On 6/18/2024 10:20 AM, Fred. Zwarts wrote:
>>>>>
>>>>> It is a verified fact that serious C people have recently
>>>>> agreed to the following verbatim statement in the C group.
>>>
>>> http://al.howardknight.net/?STYPE=msgid&MSGI=%3Cv4pg5p%24morv%241%40raubtier-asyl.eternal-september.org%3E+
>>>
>>>
>>>>> You either lack this degree of skill in C or are only
>>>>> interested in playing head games.
>>>>
>>>> I have seen the response. It was most certainly not a serious reply.
>>>> But you know apparently to little of C to understand that.
>>>> Probably, because you are unable to escape from rebuttal mode, even if
>>>> the truth is obvious.
>>>>
>>>
>>> I have known C since K&R was the standard and met
>>> Bjarne Stroustrup when he came to our university
>>> to promote his new C++ programming language.
>>>
>>> *You seem to be willfully ignorant*
>>>
>>>> It was your own proof that showed that in
>>>>
>>>> int main()
>>>> {
>>>> return H(main);
>>>> }
>>>>
>>>>
>>>> main halts, whereas H reported non-halting. So, it you were honest you
>>>> would stop claiming that H is correct.
>>>>
>>>
>>> That is merely a more difficult to understand version of this
>>> same pathological relationship.
>>>
>>> int main()
>>> {
>>> Output("Input_Halts = ", HH0(main));
>>> }
>>>
>>> _main()
>>> [000020c2] 55 push ebp
>>> [000020c3] 8bec mov ebp,esp
>>> [000020c5] 68c2200000 push 000020c2 ; push main
>>> [000020ca] e833f4ffff call 00001502 ; call HH0
>>> [000020cf] 83c404 add esp,+04
>>> [000020d2] 50 push eax
>>> [000020d3] 6843070000 push 00000743
>>> [000020d8] e885e6ffff call 00000762
>>> [000020dd] 83c408 add esp,+08
>>> [000020e0] eb04 jmp 000020e6
>>> [000020e2] 33c0 xor eax,eax
>>> [000020e4] eb02 jmp 000020e8
>>> [000020e6] 33c0 xor eax,eax
>>> [000020e8] 5d pop ebp
>>> [000020e9] c3 ret
>>> Size in bytes:(0040) [000020e9]
>>>
>>> machine stack stack machine assembly
>>> address address data code language
>>> ======== ======== ======== ========= =============
>>> [000020c2][001036c3][00000000] 55 push ebp
>>> [000020c3][001036c3][00000000] 8bec mov ebp,esp
>>> [000020c5][001036bf][000020c2] 68c2200000 push 000020c2 ; push main
>>> [000020ca][001036bb][000020cf] e833f4ffff call 00001502 ; call HH0
>>> New slave_stack at:103767
>>>
>>> Begin Local Halt Decider Simulation Execution Trace Stored at:11376f
>>> [000020c2][0011375f][00113763] 55 push ebp ; begin main
>>> [000020c3][0011375f][00113763] 8bec mov ebp,esp
>>> [000020c5][0011375b][000020c2] 68c2200000 push 000020c2 ; push main
>>> [000020ca][00113757][000020cf] e833f4ffff call 00001502 ; call HH0
>>> New slave_stack at:14e18f
>>> [000020c2][0015e187][0015e18b] 55 push ebp ; begin main
>>> [000020c3][0015e187][0015e18b] 8bec mov ebp,esp
>>> [000020c5][0015e183][000020c2] 68c2200000 push 000020c2 ; push main
>>> [000020ca][0015e17f][000020cf] e833f4ffff call 00001502 ; call HH0
>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>>
>>> [000020cf][001036c3][00000000] 83c404 add esp,+04
>>> [000020d2][001036bf][00000000] 50 push eax
>>> [000020d3][001036bb][00000743] 6843070000 push 00000743
>>> [000020d8][001036bb][00000743] e885e6ffff call 00000762
>>> Input_Halts = 0
>>> [000020dd][001036c3][00000000] 83c408 add esp,+08
>>> [000020e0][001036c3][00000000] eb04 jmp 000020e6
>>> [000020e6][001036c3][00000000] 33c0 xor eax,eax
>>> [000020e8][001036c7][00000018] 5d pop ebp
>>> [000020e9][001036cb][00000000] c3 ret ; exit main
>>> Number of Instructions Executed(10070) == 150 Pages
>>>
>>
>> It is easier to understand because a print statement was added.
>> You proved that it halts, but H0 reports non-halting.
>> So, it produces a false negative.
>> So, now it has been proved that H, H0, etc produce false negatives,
>> when used to determine halting behaviour, please, stop to call them
>> halt-deciders, or termination-deciders.
>> They might be "simulation deciders". When returning true, the
>> simulation was correct, when false, the full simulation was not
>> possible.
>
> I don't want to discuss your screwy example because I
> can't use screwy examples in my paper.
If you could ever publish a paper there would soon be papers with examples
(which you may call "screwy") that your method gets wrong.
--
Mikko
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-20 00:22 -0500 |
| Message-ID | <v50eaj$2e5ij$3@dont-email.me> |
| In reply to | #107477 |
On 6/20/2024 12:17 AM, Mikko wrote:
> On 2024-06-19 13:00:57 +0000, olcott said:
>
>> On 6/19/2024 3:08 AM, Fred. Zwarts wrote:
>>> Op 18.jun.2024 om 18:26 schreef olcott:
>>>> On 6/18/2024 10:47 AM, Fred. Zwarts wrote:
>>>>> Op 18.jun.2024 om 17:33 schreef olcott:
>>>>>> On 6/18/2024 10:20 AM, Fred. Zwarts wrote:
>>>>>>
>>>>>> It is a verified fact that serious C people have recently
>>>>>> agreed to the following verbatim statement in the C group.
>>>>
>>>> http://al.howardknight.net/?STYPE=msgid&MSGI=%3Cv4pg5p%24morv%241%40raubtier-asyl.eternal-september.org%3E+
>>>>
>>>>>> You either lack this degree of skill in C or are only
>>>>>> interested in playing head games.
>>>>>
>>>>> I have seen the response. It was most certainly not a serious reply.
>>>>> But you know apparently to little of C to understand that.
>>>>> Probably, because you are unable to escape from rebuttal mode, even
>>>>> if the truth is obvious.
>>>>>
>>>>
>>>> I have known C since K&R was the standard and met
>>>> Bjarne Stroustrup when he came to our university
>>>> to promote his new C++ programming language.
>>>>
>>>> *You seem to be willfully ignorant*
>>>>
>>>>> It was your own proof that showed that in
>>>>>
>>>>> int main()
>>>>> {
>>>>> return H(main);
>>>>> }
>>>>>
>>>>>
>>>>> main halts, whereas H reported non-halting. So, it you were honest
>>>>> you would stop claiming that H is correct.
>>>>>
>>>>
>>>> That is merely a more difficult to understand version of this
>>>> same pathological relationship.
>>>>
>>>> int main()
>>>> {
>>>> Output("Input_Halts = ", HH0(main));
>>>> }
>>>>
>>>> _main()
>>>> [000020c2] 55 push ebp
>>>> [000020c3] 8bec mov ebp,esp
>>>> [000020c5] 68c2200000 push 000020c2 ; push main
>>>> [000020ca] e833f4ffff call 00001502 ; call HH0
>>>> [000020cf] 83c404 add esp,+04
>>>> [000020d2] 50 push eax
>>>> [000020d3] 6843070000 push 00000743
>>>> [000020d8] e885e6ffff call 00000762
>>>> [000020dd] 83c408 add esp,+08
>>>> [000020e0] eb04 jmp 000020e6
>>>> [000020e2] 33c0 xor eax,eax
>>>> [000020e4] eb02 jmp 000020e8
>>>> [000020e6] 33c0 xor eax,eax
>>>> [000020e8] 5d pop ebp
>>>> [000020e9] c3 ret
>>>> Size in bytes:(0040) [000020e9]
>>>>
>>>> machine stack stack machine assembly
>>>> address address data code language
>>>> ======== ======== ======== ========= =============
>>>> [000020c2][001036c3][00000000] 55 push ebp
>>>> [000020c3][001036c3][00000000] 8bec mov ebp,esp
>>>> [000020c5][001036bf][000020c2] 68c2200000 push 000020c2 ; push main
>>>> [000020ca][001036bb][000020cf] e833f4ffff call 00001502 ; call HH0
>>>> New slave_stack at:103767
>>>>
>>>> Begin Local Halt Decider Simulation Execution Trace Stored at:11376f
>>>> [000020c2][0011375f][00113763] 55 push ebp ; begin main
>>>> [000020c3][0011375f][00113763] 8bec mov ebp,esp
>>>> [000020c5][0011375b][000020c2] 68c2200000 push 000020c2 ; push main
>>>> [000020ca][00113757][000020cf] e833f4ffff call 00001502 ; call HH0
>>>> New slave_stack at:14e18f
>>>> [000020c2][0015e187][0015e18b] 55 push ebp ; begin main
>>>> [000020c3][0015e187][0015e18b] 8bec mov ebp,esp
>>>> [000020c5][0015e183][000020c2] 68c2200000 push 000020c2 ; push main
>>>> [000020ca][0015e17f][000020cf] e833f4ffff call 00001502 ; call HH0
>>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>>>
>>>> [000020cf][001036c3][00000000] 83c404 add esp,+04
>>>> [000020d2][001036bf][00000000] 50 push eax
>>>> [000020d3][001036bb][00000743] 6843070000 push 00000743
>>>> [000020d8][001036bb][00000743] e885e6ffff call 00000762
>>>> Input_Halts = 0
>>>> [000020dd][001036c3][00000000] 83c408 add esp,+08
>>>> [000020e0][001036c3][00000000] eb04 jmp 000020e6
>>>> [000020e6][001036c3][00000000] 33c0 xor eax,eax
>>>> [000020e8][001036c7][00000018] 5d pop ebp
>>>> [000020e9][001036cb][00000000] c3 ret ; exit main
>>>> Number of Instructions Executed(10070) == 150 Pages
>>>>
>>>
>>> It is easier to understand because a print statement was added.
>>> You proved that it halts, but H0 reports non-halting.
>>> So, it produces a false negative.
>>> So, now it has been proved that H, H0, etc produce false negatives,
>>> when used to determine halting behaviour, please, stop to call them
>>> halt-deciders, or termination-deciders.
>>> They might be "simulation deciders". When returning true, the
>>> simulation was correct, when false, the full simulation was not
>>> possible.
>>
>> I don't want to discuss your screwy example because I
>> can't use screwy examples in my paper.
>
> If you could ever publish a paper there would soon be papers with examples
> (which you may call "screwy") that your method gets wrong.
>
My whole purpose is to refute the conventional proofs.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-20 07:33 -0400 |
| Message-ID | <v51432$hpdb$2@i2pn2.org> |
| In reply to | #107479 |
On 6/20/24 1:22 AM, olcott wrote: > > My whole purpose is to refute the conventional proofs. > > And have FAILED at that miserably. In fact, you keep on claiming they must be correct as you try to prove them wrong. Part of your problem, is you don't seem to actually understand formal logic, and keep trying to use argument instead of proof, showing your utter ignorance of what you are trying to do.
[toc] | [prev] | [next] | [standalone]
| From | Mikko <mikko.levanto@iki.fi> |
|---|---|
| Date | 2024-06-20 17:54 +0300 |
| Message-ID | <v51fqh$2kc12$1@dont-email.me> |
| In reply to | #107479 |
On 2024-06-20 05:22:27 +0000, olcott said:
> On 6/20/2024 12:17 AM, Mikko wrote:
>> On 2024-06-19 13:00:57 +0000, olcott said:
>>
>>> On 6/19/2024 3:08 AM, Fred. Zwarts wrote:
>>>> Op 18.jun.2024 om 18:26 schreef olcott:
>>>>> On 6/18/2024 10:47 AM, Fred. Zwarts wrote:
>>>>>> Op 18.jun.2024 om 17:33 schreef olcott:
>>>>>>> On 6/18/2024 10:20 AM, Fred. Zwarts wrote:
>>>>>>>
>>>>>>> It is a verified fact that serious C people have recently
>>>>>>> agreed to the following verbatim statement in the C group.
>>>>>
>>>>> http://al.howardknight.net/?STYPE=msgid&MSGI=%3Cv4pg5p%24morv%241%40raubtier-asyl.eternal-september.org%3E+
>>>>>
>>>>>
>>>>>>> You either lack this degree of skill in C or are only
>>>>>>> interested in playing head games.
>>>>>>
>>>>>> I have seen the response. It was most certainly not a serious reply.
>>>>>> But you know apparently to little of C to understand that.
>>>>>> Probably, because you are unable to escape from rebuttal mode, even if
>>>>>> the truth is obvious.
>>>>>>
>>>>>
>>>>> I have known C since K&R was the standard and met
>>>>> Bjarne Stroustrup when he came to our university
>>>>> to promote his new C++ programming language.
>>>>>
>>>>> *You seem to be willfully ignorant*
>>>>>
>>>>>> It was your own proof that showed that in
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>> return H(main);
>>>>>> }
>>>>>>
>>>>>>
>>>>>> main halts, whereas H reported non-halting. So, it you were honest you
>>>>>> would stop claiming that H is correct.
>>>>>>
>>>>>
>>>>> That is merely a more difficult to understand version of this
>>>>> same pathological relationship.
>>>>>
>>>>> int main()
>>>>> {
>>>>> Output("Input_Halts = ", HH0(main));
>>>>> }
>>>>>
>>>>> _main()
>>>>> [000020c2] 55 push ebp
>>>>> [000020c3] 8bec mov ebp,esp
>>>>> [000020c5] 68c2200000 push 000020c2 ; push main
>>>>> [000020ca] e833f4ffff call 00001502 ; call HH0
>>>>> [000020cf] 83c404 add esp,+04
>>>>> [000020d2] 50 push eax
>>>>> [000020d3] 6843070000 push 00000743
>>>>> [000020d8] e885e6ffff call 00000762
>>>>> [000020dd] 83c408 add esp,+08
>>>>> [000020e0] eb04 jmp 000020e6
>>>>> [000020e2] 33c0 xor eax,eax
>>>>> [000020e4] eb02 jmp 000020e8
>>>>> [000020e6] 33c0 xor eax,eax
>>>>> [000020e8] 5d pop ebp
>>>>> [000020e9] c3 ret
>>>>> Size in bytes:(0040) [000020e9]
>>>>>
>>>>> machine stack stack machine assembly
>>>>> address address data code language
>>>>> ======== ======== ======== ========= =============
>>>>> [000020c2][001036c3][00000000] 55 push ebp
>>>>> [000020c3][001036c3][00000000] 8bec mov ebp,esp
>>>>> [000020c5][001036bf][000020c2] 68c2200000 push 000020c2 ; push main
>>>>> [000020ca][001036bb][000020cf] e833f4ffff call 00001502 ; call HH0
>>>>> New slave_stack at:103767
>>>>>
>>>>> Begin Local Halt Decider Simulation Execution Trace Stored at:11376f
>>>>> [000020c2][0011375f][00113763] 55 push ebp ; begin main
>>>>> [000020c3][0011375f][00113763] 8bec mov ebp,esp
>>>>> [000020c5][0011375b][000020c2] 68c2200000 push 000020c2 ; push main
>>>>> [000020ca][00113757][000020cf] e833f4ffff call 00001502 ; call HH0
>>>>> New slave_stack at:14e18f
>>>>> [000020c2][0015e187][0015e18b] 55 push ebp ; begin main
>>>>> [000020c3][0015e187][0015e18b] 8bec mov ebp,esp
>>>>> [000020c5][0015e183][000020c2] 68c2200000 push 000020c2 ; push main
>>>>> [000020ca][0015e17f][000020cf] e833f4ffff call 00001502 ; call HH0
>>>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>>>>
>>>>> [000020cf][001036c3][00000000] 83c404 add esp,+04
>>>>> [000020d2][001036bf][00000000] 50 push eax
>>>>> [000020d3][001036bb][00000743] 6843070000 push 00000743
>>>>> [000020d8][001036bb][00000743] e885e6ffff call 00000762
>>>>> Input_Halts = 0
>>>>> [000020dd][001036c3][00000000] 83c408 add esp,+08
>>>>> [000020e0][001036c3][00000000] eb04 jmp 000020e6
>>>>> [000020e6][001036c3][00000000] 33c0 xor eax,eax
>>>>> [000020e8][001036c7][00000018] 5d pop ebp
>>>>> [000020e9][001036cb][00000000] c3 ret ; exit main
>>>>> Number of Instructions Executed(10070) == 150 Pages
>>>>>
>>>>
>>>> It is easier to understand because a print statement was added.
>>>> You proved that it halts, but H0 reports non-halting.
>>>> So, it produces a false negative.
>>>> So, now it has been proved that H, H0, etc produce false negatives,
>>>> when used to determine halting behaviour, please, stop to call them
>>>> halt-deciders, or termination-deciders.
>>>> They might be "simulation deciders". When returning true, the
>>>> simulation was correct, when false, the full simulation was not
>>>> possible.
>>>
>>> I don't want to discuss your screwy example because I
>>> can't use screwy examples in my paper.
>>
>> If you could ever publish a paper there would soon be papers with examples
>> (which you may call "screwy") that your method gets wrong.
>>
>
> My whole purpose is to refute the conventional proofs.
After so many years, why it is still a purpose and not a publication?
--
Mikko
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-20 10:06 -0500 |
| Message-ID | <v51gij$2kbbe$3@dont-email.me> |
| In reply to | #107494 |
On 6/20/2024 9:54 AM, Mikko wrote:
> On 2024-06-20 05:22:27 +0000, olcott said:
>
>> On 6/20/2024 12:17 AM, Mikko wrote:
>>> On 2024-06-19 13:00:57 +0000, olcott said:
>>>
>>>> On 6/19/2024 3:08 AM, Fred. Zwarts wrote:
>>>>> Op 18.jun.2024 om 18:26 schreef olcott:
>>>>>> On 6/18/2024 10:47 AM, Fred. Zwarts wrote:
>>>>>>> Op 18.jun.2024 om 17:33 schreef olcott:
>>>>>>>> On 6/18/2024 10:20 AM, Fred. Zwarts wrote:
>>>>>>>>
>>>>>>>> It is a verified fact that serious C people have recently
>>>>>>>> agreed to the following verbatim statement in the C group.
>>>>>>
>>>>>> http://al.howardknight.net/?STYPE=msgid&MSGI=%3Cv4pg5p%24morv%241%40raubtier-asyl.eternal-september.org%3E+
>>>>>>
>>>>>>>> You either lack this degree of skill in C or are only
>>>>>>>> interested in playing head games.
>>>>>>>
>>>>>>> I have seen the response. It was most certainly not a serious reply.
>>>>>>> But you know apparently to little of C to understand that.
>>>>>>> Probably, because you are unable to escape from rebuttal mode,
>>>>>>> even if the truth is obvious.
>>>>>>>
>>>>>>
>>>>>> I have known C since K&R was the standard and met
>>>>>> Bjarne Stroustrup when he came to our university
>>>>>> to promote his new C++ programming language.
>>>>>>
>>>>>> *You seem to be willfully ignorant*
>>>>>>
>>>>>>> It was your own proof that showed that in
>>>>>>>
>>>>>>> int main()
>>>>>>> {
>>>>>>> return H(main);
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> main halts, whereas H reported non-halting. So, it you were
>>>>>>> honest you would stop claiming that H is correct.
>>>>>>>
>>>>>>
>>>>>> That is merely a more difficult to understand version of this
>>>>>> same pathological relationship.
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>> Output("Input_Halts = ", HH0(main));
>>>>>> }
>>>>>>
>>>>>> _main()
>>>>>> [000020c2] 55 push ebp
>>>>>> [000020c3] 8bec mov ebp,esp
>>>>>> [000020c5] 68c2200000 push 000020c2 ; push main
>>>>>> [000020ca] e833f4ffff call 00001502 ; call HH0
>>>>>> [000020cf] 83c404 add esp,+04
>>>>>> [000020d2] 50 push eax
>>>>>> [000020d3] 6843070000 push 00000743
>>>>>> [000020d8] e885e6ffff call 00000762
>>>>>> [000020dd] 83c408 add esp,+08
>>>>>> [000020e0] eb04 jmp 000020e6
>>>>>> [000020e2] 33c0 xor eax,eax
>>>>>> [000020e4] eb02 jmp 000020e8
>>>>>> [000020e6] 33c0 xor eax,eax
>>>>>> [000020e8] 5d pop ebp
>>>>>> [000020e9] c3 ret
>>>>>> Size in bytes:(0040) [000020e9]
>>>>>>
>>>>>> machine stack stack machine assembly
>>>>>> address address data code language
>>>>>> ======== ======== ======== ========= =============
>>>>>> [000020c2][001036c3][00000000] 55 push ebp
>>>>>> [000020c3][001036c3][00000000] 8bec mov ebp,esp
>>>>>> [000020c5][001036bf][000020c2] 68c2200000 push 000020c2 ; push main
>>>>>> [000020ca][001036bb][000020cf] e833f4ffff call 00001502 ; call HH0
>>>>>> New slave_stack at:103767
>>>>>>
>>>>>> Begin Local Halt Decider Simulation Execution Trace Stored
>>>>>> at:11376f
>>>>>> [000020c2][0011375f][00113763] 55 push ebp ; begin main
>>>>>> [000020c3][0011375f][00113763] 8bec mov ebp,esp
>>>>>> [000020c5][0011375b][000020c2] 68c2200000 push 000020c2 ; push main
>>>>>> [000020ca][00113757][000020cf] e833f4ffff call 00001502 ; call HH0
>>>>>> New slave_stack at:14e18f
>>>>>> [000020c2][0015e187][0015e18b] 55 push ebp ; begin main
>>>>>> [000020c3][0015e187][0015e18b] 8bec mov ebp,esp
>>>>>> [000020c5][0015e183][000020c2] 68c2200000 push 000020c2 ; push main
>>>>>> [000020ca][0015e17f][000020cf] e833f4ffff call 00001502 ; call HH0
>>>>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>>>>>
>>>>>> [000020cf][001036c3][00000000] 83c404 add esp,+04
>>>>>> [000020d2][001036bf][00000000] 50 push eax
>>>>>> [000020d3][001036bb][00000743] 6843070000 push 00000743
>>>>>> [000020d8][001036bb][00000743] e885e6ffff call 00000762
>>>>>> Input_Halts = 0
>>>>>> [000020dd][001036c3][00000000] 83c408 add esp,+08
>>>>>> [000020e0][001036c3][00000000] eb04 jmp 000020e6
>>>>>> [000020e6][001036c3][00000000] 33c0 xor eax,eax
>>>>>> [000020e8][001036c7][00000018] 5d pop ebp
>>>>>> [000020e9][001036cb][00000000] c3 ret ; exit main
>>>>>> Number of Instructions Executed(10070) == 150 Pages
>>>>>>
>>>>>
>>>>> It is easier to understand because a print statement was added.
>>>>> You proved that it halts, but H0 reports non-halting.
>>>>> So, it produces a false negative.
>>>>> So, now it has been proved that H, H0, etc produce false negatives,
>>>>> when used to determine halting behaviour, please, stop to call them
>>>>> halt-deciders, or termination-deciders.
>>>>> They might be "simulation deciders". When returning true, the
>>>>> simulation was correct, when false, the full simulation was not
>>>>> possible.
>>>>
>>>> I don't want to discuss your screwy example because I
>>>> can't use screwy examples in my paper.
>>>
>>> If you could ever publish a paper there would soon be papers with
>>> examples
>>> (which you may call "screwy") that your method gets wrong.
>>>
>>
>> My whole purpose is to refute the conventional proofs.
>
> After so many years, why it is still a purpose and not a publication?
>
I have not yet found the words so that people can fully
understand that I am correct. People here on this forum
are happy to deny verified facts.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-20 21:55 -0400 |
| Message-ID | <v52mii$jund$4@i2pn2.org> |
| In reply to | #107497 |
On 6/20/24 11:06 AM, olcott wrote:
> On 6/20/2024 9:54 AM, Mikko wrote:
>> On 2024-06-20 05:22:27 +0000, olcott said:
>>
>>> On 6/20/2024 12:17 AM, Mikko wrote:
>>>> On 2024-06-19 13:00:57 +0000, olcott said:
>>>>
>>>>> On 6/19/2024 3:08 AM, Fred. Zwarts wrote:
>>>>>> Op 18.jun.2024 om 18:26 schreef olcott:
>>>>>>> On 6/18/2024 10:47 AM, Fred. Zwarts wrote:
>>>>>>>> Op 18.jun.2024 om 17:33 schreef olcott:
>>>>>>>>> On 6/18/2024 10:20 AM, Fred. Zwarts wrote:
>>>>>>>>>
>>>>>>>>> It is a verified fact that serious C people have recently
>>>>>>>>> agreed to the following verbatim statement in the C group.
>>>>>>>
>>>>>>> http://al.howardknight.net/?STYPE=msgid&MSGI=%3Cv4pg5p%24morv%241%40raubtier-asyl.eternal-september.org%3E+
>>>>>>>
>>>>>>>>> You either lack this degree of skill in C or are only
>>>>>>>>> interested in playing head games.
>>>>>>>>
>>>>>>>> I have seen the response. It was most certainly not a serious
>>>>>>>> reply.
>>>>>>>> But you know apparently to little of C to understand that.
>>>>>>>> Probably, because you are unable to escape from rebuttal mode,
>>>>>>>> even if the truth is obvious.
>>>>>>>>
>>>>>>>
>>>>>>> I have known C since K&R was the standard and met
>>>>>>> Bjarne Stroustrup when he came to our university
>>>>>>> to promote his new C++ programming language.
>>>>>>>
>>>>>>> *You seem to be willfully ignorant*
>>>>>>>
>>>>>>>> It was your own proof that showed that in
>>>>>>>>
>>>>>>>> int main()
>>>>>>>> {
>>>>>>>> return H(main);
>>>>>>>> }
>>>>>>>>
>>>>>>>>
>>>>>>>> main halts, whereas H reported non-halting. So, it you were
>>>>>>>> honest you would stop claiming that H is correct.
>>>>>>>>
>>>>>>>
>>>>>>> That is merely a more difficult to understand version of this
>>>>>>> same pathological relationship.
>>>>>>>
>>>>>>> int main()
>>>>>>> {
>>>>>>> Output("Input_Halts = ", HH0(main));
>>>>>>> }
>>>>>>>
>>>>>>> _main()
>>>>>>> [000020c2] 55 push ebp
>>>>>>> [000020c3] 8bec mov ebp,esp
>>>>>>> [000020c5] 68c2200000 push 000020c2 ; push main
>>>>>>> [000020ca] e833f4ffff call 00001502 ; call HH0
>>>>>>> [000020cf] 83c404 add esp,+04
>>>>>>> [000020d2] 50 push eax
>>>>>>> [000020d3] 6843070000 push 00000743
>>>>>>> [000020d8] e885e6ffff call 00000762
>>>>>>> [000020dd] 83c408 add esp,+08
>>>>>>> [000020e0] eb04 jmp 000020e6
>>>>>>> [000020e2] 33c0 xor eax,eax
>>>>>>> [000020e4] eb02 jmp 000020e8
>>>>>>> [000020e6] 33c0 xor eax,eax
>>>>>>> [000020e8] 5d pop ebp
>>>>>>> [000020e9] c3 ret
>>>>>>> Size in bytes:(0040) [000020e9]
>>>>>>>
>>>>>>> machine stack stack machine assembly
>>>>>>> address address data code language
>>>>>>> ======== ======== ======== ========= =============
>>>>>>> [000020c2][001036c3][00000000] 55 push ebp
>>>>>>> [000020c3][001036c3][00000000] 8bec mov ebp,esp
>>>>>>> [000020c5][001036bf][000020c2] 68c2200000 push 000020c2 ; push main
>>>>>>> [000020ca][001036bb][000020cf] e833f4ffff call 00001502 ; call HH0
>>>>>>> New slave_stack at:103767
>>>>>>>
>>>>>>> Begin Local Halt Decider Simulation Execution Trace Stored
>>>>>>> at:11376f
>>>>>>> [000020c2][0011375f][00113763] 55 push ebp ; begin main
>>>>>>> [000020c3][0011375f][00113763] 8bec mov ebp,esp
>>>>>>> [000020c5][0011375b][000020c2] 68c2200000 push 000020c2 ; push main
>>>>>>> [000020ca][00113757][000020cf] e833f4ffff call 00001502 ; call HH0
>>>>>>> New slave_stack at:14e18f
>>>>>>> [000020c2][0015e187][0015e18b] 55 push ebp ; begin main
>>>>>>> [000020c3][0015e187][0015e18b] 8bec mov ebp,esp
>>>>>>> [000020c5][0015e183][000020c2] 68c2200000 push 000020c2 ; push main
>>>>>>> [000020ca][0015e17f][000020cf] e833f4ffff call 00001502 ; call HH0
>>>>>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>>>>>>
>>>>>>> [000020cf][001036c3][00000000] 83c404 add esp,+04
>>>>>>> [000020d2][001036bf][00000000] 50 push eax
>>>>>>> [000020d3][001036bb][00000743] 6843070000 push 00000743
>>>>>>> [000020d8][001036bb][00000743] e885e6ffff call 00000762
>>>>>>> Input_Halts = 0
>>>>>>> [000020dd][001036c3][00000000] 83c408 add esp,+08
>>>>>>> [000020e0][001036c3][00000000] eb04 jmp 000020e6
>>>>>>> [000020e6][001036c3][00000000] 33c0 xor eax,eax
>>>>>>> [000020e8][001036c7][00000018] 5d pop ebp
>>>>>>> [000020e9][001036cb][00000000] c3 ret ; exit main
>>>>>>> Number of Instructions Executed(10070) == 150 Pages
>>>>>>>
>>>>>>
>>>>>> It is easier to understand because a print statement was added.
>>>>>> You proved that it halts, but H0 reports non-halting.
>>>>>> So, it produces a false negative.
>>>>>> So, now it has been proved that H, H0, etc produce false
>>>>>> negatives, when used to determine halting behaviour, please, stop
>>>>>> to call them halt-deciders, or termination-deciders.
>>>>>> They might be "simulation deciders". When returning true, the
>>>>>> simulation was correct, when false, the full simulation was not
>>>>>> possible.
>>>>>
>>>>> I don't want to discuss your screwy example because I
>>>>> can't use screwy examples in my paper.
>>>>
>>>> If you could ever publish a paper there would soon be papers with
>>>> examples
>>>> (which you may call "screwy") that your method gets wrong.
>>>>
>>>
>>> My whole purpose is to refute the conventional proofs.
>>
>> After so many years, why it is still a purpose and not a publication?
>>
>
> I have not yet found the words so that people can fully
> understand that I am correct. People here on this forum
> are happy to deny verified facts.
>
No, we find the errors in your fables that you think prove what you want.
[toc] | [prev] | [next] | [standalone]
| From | Python <python@invalid.org> |
|---|---|
| Date | 2024-06-18 17:56 +0200 |
| Message-ID | <v4samu$1drc6$1@dont-email.me> |
| In reply to | #107371 |
Le 18/06/2024 à 17:33, olcott a écrit : ... > It is a verified fact that serious C people have recently > agreed to the following verbatim statement in the C group. > You either lack this degree of skill in C or are only > interested in playing head games. > > http://al.howardknight.net/?STYPE=msgid&MSGI=%3Cv4pg5p%24morv%241%40raubtier-asyl.eternal-september.org%3E+ The answser (on comp.lang.c,comp.lang.c++) was this single line: >> Everything correct, no further questions allowed. You really didn't spot the pun, Peter Olcott? Really? It was a obvious one intended to make you stop posting idiotic posts there!!! Did it work BTW? Oh. My. God. You really are *that* demented?
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-18 11:29 -0500 |
| Message-ID | <v4scko$1eb2f$2@dont-email.me> |
| In reply to | #107377 |
On 6/18/2024 10:56 AM, Python wrote: > Le 18/06/2024 à 17:33, olcott a écrit : > ... >> It is a verified fact that serious C people have recently >> agreed to the following verbatim statement in the C group. >> You either lack this degree of skill in C or are only >> interested in playing head games. >> >> http://al.howardknight.net/?STYPE=msgid&MSGI=%3Cv4pg5p%24morv%241%40raubtier-asyl.eternal-september.org%3E+ > > The answser (on comp.lang.c,comp.lang.c++) was this single line: > >>> Everything correct, no further questions allowed. > > You really didn't spot the pun, Peter Olcott? Really? It was > a obvious one intended to make you stop posting idiotic posts > there!!! Did it work BTW? > > Oh. My. God. You really are *that* demented? > There are four other affirmations that I cannot post here. I am estimating that you are either incompetent or a liar. -- Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-18 22:16 -0400 |
| Message-ID | <v4tf1t$ddeo$3@i2pn2.org> |
| In reply to | #107371 |
On 6/18/24 11:33 AM, olcott wrote:
> On 6/18/2024 10:20 AM, Fred. Zwarts wrote:
>> Op 18.jun.2024 om 14:38 schreef olcott:
>>> On 6/18/2024 2:57 AM, Fred. Zwarts wrote:
>>>> Op 17.jun.2024 om 17:56 schreef olcott:
>>>>> On 6/17/2024 9:49 AM, Fred. Zwarts wrote:
>>>>>> Op 17.jun.2024 om 16:34 schreef olcott:
>>>>>>> On 6/17/2024 9:18 AM, Fred. Zwarts wrote:
>>>>>>>> Op 17.jun.2024 om 15:47 schreef olcott:
>>>>>>>>> On 6/17/2024 8:30 AM, Fred. Zwarts wrote:
>>>>>>>>>> Op 17.jun.2024 om 14:20 schreef olcott:
>>>>>>>>>>> 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*
>>>>>>>>>>
>>>>>>>>>> No, that is not a logical conclusion.
>>>>>>>>>
>>>>>>>>> Every C programmer that knows what an x86 emulator is knows
>>>>>>>>> that when H0 emulates the machine language of Infinite_Loop,
>>>>>>>>> Infinite_Recursion, and DDD that it must abort these emulations
>>>>>>>>> so that itself can terminate normally.
>>>>>>>>
>>>>>>>> That might be correct.
>>>>>>>>>
>>>>>>>>> When this is construed as non-halting criteria then simulating
>>>>>>>>> termination analyzer H0 is correct to reject these inputs as non-
>>>>>>>>> halting.
>>>>>>>>
>>>>>>>> That is wrong. It only shows that H0 is unable to simulate
>>>>>>>> itself. It tells nothing about the halting of the input.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> *Too late you have already affirmed the words above*
>>>>>>>>> Affirming the first part necessitates the second part.
>>>>>>>>>
>>>>>>>> That is not logical. If a non-aborting program is wrong, it does
>>>>>>>> not follow that a program that aborts is correct.
>>>>>>>> Please, think before you reply.
>>>>>>>>
>>>>>>>> So, I repeat:
>>>>>>>> The logical conclusion if both aborting and not aborting result
>>>>>>>> in errors, is: a halt-decider cannot be based on such a simulation.
>>>>>>>
>>>>>>> Your view here is merely ignorant of the fact that deciders
>>>>>>> must report on the behavior specified by their inputs.
>>>>>>>
>>>>>>
>>>>>> It is incorrect to assume that a failing simulation is able to
>>>>>> report about its input.
>>>>>> The simulation fails, because H0 is unable to simulate itself.
>>>>>>
>>>>>
>>>>> There is no possible way for the call to H0 by DDD
>>>>> correctly simulated by any H0 to return to its caller.
>>>>
>>>> We have not seen a proof for this claim and since H0 has
>>>> contradictory requirements nobody else has ever provided a proof.
>>>> But OK, lets assume your are right. Simulated H0 is unable to
>>>> simulate itself op to its final state and return to its caller,
>>>> because it was aborted one cycle before it would return to its caller.
>>>>
>>>>>
>>>>> _DDD()
>>>>> [00001fd2] 55 push ebp
>>>>> [00001fd3] 8bec mov ebp,esp
>>>>> [00001fd5] 68d21f0000 push 00001fd2 ; push address of DDD
>>>>> [00001fda] e8f3f9ffff call 000019d2 ; call H0
>>>>> [00001fdf] 83c404 add esp,+04
>>>>> [00001fe2] 5d pop ebp
>>>>> [00001fe3] c3 ret
>>>>> Size in bytes:(0018) [00001fe3]
>>>>>
>>>>> *THAT THIS IS OVER YOUR HEAD DOES NOT MEAN THAT I AM INCORRECT*
>>>>> DDD correctly simulated by H0 *is* the behavior that
>>>>> the finite string of x86 machine code of DDD specifies.
>>>>>
>>>>
>>>> It is such a simple fact that H0 cannot possibly correct.
>>>
>>> Are you pretending to be incompetent about the semantics of the
>>> x86 language or you you actually incompetent?
>>
>> I understand x86, but I am afraid you don't. Because you assume
>> results that are not there.
>>
>>>
>>> The C people already agreed that I am correct about this:
>>
>> No serious C people have agreed. They can't, because your H0 has
>> contradictory requirements.
>>
>
> It is a verified fact that serious C people have recently
> agreed to the following verbatim statement in the C group.
> You either lack this degree of skill in C or are only
> interested in playing head games.
>
> http://al.howardknight.net/?STYPE=msgid&MSGI=%3Cv4pg5p%24morv%241%40raubtier-asyl.eternal-september.org%3E+
Yep the "Serious member of the C programming group Bonita, who is a
laughing stock there for their strange ideas.
Of COURSE your "Appeal to Authority" is to Bonita.
>>>
>>> typedef void (*ptr)();
>>> int H0(ptr P);
>>>
>>> void Infinite_Loop()
>>> {
>>> HERE: goto HERE;
>>> }
>>>
>>> void Infinite_Recursion()
>>> {
>>> Infinite_Recursion();
>>> }
>>>
>>> void DDD()
>>> {
>>> H0(DDD);
>>> }
>>>
>>> int main()
>>> {
>>> H0(Infinite_Loop);
>>> H0(Infinite_Recursion);
>>> H0(DDD);
>>> }
>>>
>>> Every C programmer that knows what an x86 emulator is knows that when H0
>>> emulates the machine language of Infinite_Loop, Infinite_Recursion, and
>>> DDD that it must abort these emulations so that itself can terminate
>>> normally.
>>
>> You are repeating. It seems difficult for you to escape rebuttal mode.
>> It was shown already to you that the first two examples are very
>> different from the last one.
>>
>> The last one is equivalent to:
>>
>> int main()
>> {
>> return H0(main);
>> }
>>
>> where your own proved that H reports a false negative. This is the
>> same case as DDD.
>>
>>>
>>> When this is construed as non-halting criteria then simulating
>>> termination analyzer H0 is correct to reject these inputs as non-halting
>>> by returning 0 to its caller.
>>
>> It is incorrect to report the last one as non-halting, because H0
>> aborts one cycle too early, which makes that it misses the fact that
>> the simulated self would abort and halt.
>>
>>>
>>>> If it does not abort it does not return. If it does abort, it does
>>>> not see the correct behaviour that was specified in the input,
>>>> because it aborted its simulation one cycle too early to see the
>>>> behaviour in the input.
>>>> H0 fails to do a correct simulation, because it does not process all
>>>> of its input, but aborts its input before it can process the part of
>>>> the input that also specifies behaviour. The final behaviour
>>>> specified by the input is unreachable for the simulator, because it
>>>> is unable to simulate itself.
>>>>
>>>> If even such simple facts are over your head, you must be stuck in
>>>> rebuttal mode very deeply.
>>>
>>
>
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-18 22:16 -0400 |
| Message-ID | <v4tf1o$ddeo$1@i2pn2.org> |
| In reply to | #107360 |
On 6/18/24 8:38 AM, olcott wrote:
> On 6/18/2024 2:57 AM, Fred. Zwarts wrote:
>> Op 17.jun.2024 om 17:56 schreef olcott:
>>> On 6/17/2024 9:49 AM, Fred. Zwarts wrote:
>>>> Op 17.jun.2024 om 16:34 schreef olcott:
>>>>> On 6/17/2024 9:18 AM, Fred. Zwarts wrote:
>>>>>> Op 17.jun.2024 om 15:47 schreef olcott:
>>>>>>> On 6/17/2024 8:30 AM, Fred. Zwarts wrote:
>>>>>>>> Op 17.jun.2024 om 14:20 schreef olcott:
>>>>>>>>> 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*
>>>>>>>>
>>>>>>>> No, that is not a logical conclusion.
>>>>>>>
>>>>>>> Every C programmer that knows what an x86 emulator is knows
>>>>>>> that when H0 emulates the machine language of Infinite_Loop,
>>>>>>> Infinite_Recursion, and DDD that it must abort these emulations
>>>>>>> so that itself can terminate normally.
>>>>>>
>>>>>> That might be correct.
>>>>>>>
>>>>>>> When this is construed as non-halting criteria then simulating
>>>>>>> termination analyzer H0 is correct to reject these inputs as non-
>>>>>>> halting.
>>>>>>
>>>>>> That is wrong. It only shows that H0 is unable to simulate itself.
>>>>>> It tells nothing about the halting of the input.
>>>>>>
>>>>>>>
>>>>>>> *Too late you have already affirmed the words above*
>>>>>>> Affirming the first part necessitates the second part.
>>>>>>>
>>>>>> That is not logical. If a non-aborting program is wrong, it does
>>>>>> not follow that a program that aborts is correct.
>>>>>> Please, think before you reply.
>>>>>>
>>>>>> So, I repeat:
>>>>>> The logical conclusion if both aborting and not aborting result in
>>>>>> errors, is: a halt-decider cannot be based on such a simulation.
>>>>>
>>>>> Your view here is merely ignorant of the fact that deciders
>>>>> must report on the behavior specified by their inputs.
>>>>>
>>>>
>>>> It is incorrect to assume that a failing simulation is able to
>>>> report about its input.
>>>> The simulation fails, because H0 is unable to simulate itself.
>>>>
>>>
>>> There is no possible way for the call to H0 by DDD
>>> correctly simulated by any H0 to return to its caller.
>>
>> We have not seen a proof for this claim and since H0 has contradictory
>> requirements nobody else has ever provided a proof.
>> But OK, lets assume your are right. Simulated H0 is unable to simulate
>> itself op to its final state and return to its caller, because it was
>> aborted one cycle before it would return to its caller.
>>
>>>
>>> _DDD()
>>> [00001fd2] 55 push ebp
>>> [00001fd3] 8bec mov ebp,esp
>>> [00001fd5] 68d21f0000 push 00001fd2 ; push address of DDD
>>> [00001fda] e8f3f9ffff call 000019d2 ; call H0
>>> [00001fdf] 83c404 add esp,+04
>>> [00001fe2] 5d pop ebp
>>> [00001fe3] c3 ret
>>> Size in bytes:(0018) [00001fe3]
>>>
>>> *THAT THIS IS OVER YOUR HEAD DOES NOT MEAN THAT I AM INCORRECT*
>>> DDD correctly simulated by H0 *is* the behavior that
>>> the finite string of x86 machine code of DDD specifies.
>>>
>>
>> It is such a simple fact that H0 cannot possibly correct.
>
> Are you pretending to be incompetent about the semantics of the
> x86 language or you you actually incompetent?
But YOU seem to be ACTUALLY incompetent, as you think x86 processor can
somehow ignore the call instruction and NOT go into the subroutine called.
>
> The C people already agreed that I am correct about this:
>
> typedef void (*ptr)();
> int H0(ptr P);
>
> void Infinite_Loop()
> {
> HERE: goto HERE;
> }
>
> void Infinite_Recursion()
> {
> Infinite_Recursion();
> }
>
> void DDD()
> {
> H0(DDD);
> }
>
> int main()
> {
> H0(Infinite_Loop);
> H0(Infinite_Recursion);
> H0(DDD);
> }
>
> Every C programmer that knows what an x86 emulator is knows that when H0
> emulates the machine language of Infinite_Loop, Infinite_Recursion, and
> DDD that it must abort these emulations so that itself can terminate
> normally.
>
> When this is construed as non-halting criteria then simulating
> termination analyzer H0 is correct to reject these inputs as non-halting
> by returning 0 to its caller.
But you ignore that DDD uses H0, and thus H0 to adiquitely answer about
the behavior of DDD, H0 must properly understand the behavior of H0.
Since you think H0 should abort and return 0, we can see that H0 was
just incorrect about its decision.
>
>> If it does not abort it does not return. If it does abort, it does not
>> see the correct behaviour that was specified in the input, because it
>> aborted its simulation one cycle too early to see the behaviour in the
>> input.
>> H0 fails to do a correct simulation, because it does not process all
>> of its input, but aborts its input before it can process the part of
>> the input that also specifies behaviour. The final behaviour specified
>> by the input is unreachable for the simulator, because it is unable to
>> simulate itself.
>>
>> If even such simple facts are over your head, you must be stuck in
>> rebuttal mode very deeply.
>
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-17 18:42 -0400 |
| Message-ID | <v4qe53$a0nm$1@i2pn2.org> |
| In reply to | #107310 |
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.
>
>> If he creates a H that does abort, he creates a false negative. It
>> will never be correct.
>>
>> It would be very stupid to construe this as non-halting criteria,
>> because it is clear that it will produce false negatives, i.e. false
>> results.
>
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-17 20:16 -0500 |
| Message-ID | <v4qn65$10qh6$1@dont-email.me> |
| In reply to | #107337 |
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.
When I explain this in terms of of mathematical mappings
from finite strings to behaviors this simply leaps over
everyone's head.
--
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 21:24 -0400 |
| Message-ID | <v4qnkf$a0nm$5@i2pn2.org> |
| In reply to | #107343 |
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.
> When I explain this in terms of of mathematical mappings
> from finite strings to behaviors this simply leaps over
> everyone's head.
>
As has been shown, you can apply the input to H0 (when you don't change
it, so the call to H0 still goes to this H0), to a UTM and it will reach
the final end, so *THIS* H0 did not "Need" to abort its input, but did
because it was programmend to.
Change the H0 to H1, which simulates longer, and keep the input DDD
calling H0, and we see that if H1 simulates long enough, it will see the
end to.
The problem is you try to justify changing the input when you change
'H', which is just a lie, as the input needs to be a COMPLETE PROGRAM to
even HAVE behavior, and that complere program includes the exact version
of the decider that it is designed to refute,
Yes, your verskon where the input changes shows something, and that is
that you don't understand the meaning of theory.
We can only ask for behavior of specific programs, your idea of a
"template" as in input is flawed, as the template doesn't HAVE a
definied behavior, only specific instances do.
It is like being asked the sum of 2 + and then not giving the second
number, there is no valid answer to that.
Thus, your logic is just shown to be based on invalid principles and LIES.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-17 21:04 -0500 |
| Message-ID | <v4qpvo$10qh6$2@dont-email.me> |
| In reply to | #107344 |
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.
>
>> When I explain this in terms of of mathematical mappings
>> from finite strings to behaviors this simply leaps over
>> everyone's head.
>>
>
> As has been shown, you can apply the input to H0 (when you don't change
> it, so the call to H0 still goes to this H0), to a UTM and it will reach
> the final end, so *THIS* H0 did not "Need" to abort its input, but did
> because it was programmend to.
>
Not so much.
void DDD()
{
UTM(DDD);
}
--
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 22:33 -0400 |
| Message-ID | <v4qrmd$a0nm$6@i2pn2.org> |
| In reply to | #107345 |
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, you can't do what you claim,
as the "Correct Simulation" needs to STOP and go no further at the call
to H, as you can't simulate in the correct order the instuctions you do
not have.
And when you do include the bytes from H, then you no longer can claim
that they are the same bytes.
It just shows that you have LIED when you say the input is JUST the
dozen or so instruction of the C function provided.
For it to actually be asking the decider the question it is supposed to
be asking, it needs to include the bytes of the full program.
This is why you try to LIE that you can't make a proper copy of H,
because it makes you claim clearly false.
>
>>
>>> When I explain this in terms of of mathematical mappings
>>> from finite strings to behaviors this simply leaps over
>>> everyone's head.
>>>
>>
>> As has been shown, you can apply the input to H0 (when you don't
>> change it, so the call to H0 still goes to this H0), to a UTM and it
>> will reach the final end, so *THIS* H0 did not "Need" to abort its
>> input, but did because it was programmend to.
>>
>
> Not so much.
>
> void DDD()
> {
> UTM(DDD);
> }
>
WRONG.
DDD() doesn't change, I guess are just too stupid to undrstand that.
You just failed Requirements analysis 101.
The above does not match the definion of the contray program of the
proofs. (unless you are trying to claim that UTM is a valid Halt Decider).
It needs to be main calling UTM(DDD) while DDD still calls H0(DDD)
You are just proving that you are a total idiot.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-17 21:36 -0500 |
| Message-ID | <v4qrr8$15beg$1@dont-email.me> |
| In reply to | #107346 |
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.
--
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 22:44 -0400 |
| Message-ID | <v4qsav$a0nn$3@i2pn2.org> |
| In reply to | #107347 |
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.
It is just a DAMNED LIE.
[toc] | [prev] | [next] | [standalone]
Page 3 of 9 — ← Prev page 1 2 [3] 4 5 6 7 8 9 Next page →
Back to top | Article view | comp.theory
csiph-web