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 1 of 9 [1] 2 3 4 5 6 7 8 9 Next page →
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-16 22:33 -0500 |
| Subject | Simulating termination analyzers for dummies |
| Message-ID | <v4oaqu$f9p5$1@dont-email.me> |
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.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [next] | [standalone]
| From | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2024-06-17 10:31 +0200 |
| Message-ID | <v4os9e$i70m$1@dont-email.me> |
| In reply to | #107301 |
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. 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 07:20 -0500 |
| Message-ID | <v4p9mb$lavj$1@dont-email.me> |
| In reply to | #107309 |
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.
> 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.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2024-06-17 15:30 +0200 |
| Message-ID | <v4pdph$l7lf$1@dont-email.me> |
| In reply to | #107310 |
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. The logical conclusion if both
aborting and not aborting result in errors, is: a halt-decider cannot be
based on such a simulation.
> When every input that must be aborted is construed as non-halting
> then the input to H0(DDD) is correctly construed as non-halting.
I you had read further, your would have seen that it is incorrect to
construe such a criterium. It results in false negatives. Because H is
unable to simulate itself it is not a correct criterium for non-halting
of the program.
A false negative indicates already that a wrong criterium is used.
>
>> 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.
>
The criterium whether a program halts or not is the direct execution.
Of course it is possible to define other criteria: The length of its
description is even or odd, or the description is smaller or larger then
1k, or its simulation is unable to process it up to the end. But all of
these are incorrect and will result in false negatives.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-17 08:47 -0500 |
| Message-ID | <v4pepj$ln46$15@dont-email.me> |
| In reply to | #107322 |
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.
When this is construed as non-halting criteria then simulating
termination analyzer H0 is correct to reject these inputs as non-
halting.
*Too late you have already affirmed the words above*
Affirming the first part necessitates the second part.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2024-06-17 16:18 +0200 |
| Message-ID | <v4pgk3$l7le$2@dont-email.me> |
| In reply to | #107326 |
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.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-17 09:34 -0500 |
| Message-ID | <v4phhl$mub6$2@dont-email.me> |
| In reply to | #107328 |
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 against the facts when DDD correctly
simulated by H0 calls a simulated H0(DDD) that this call will
return to the correctly simulated 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 | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2024-06-17 16:49 +0200 |
| Message-ID | <v4piea$l7le$5@dont-email.me> |
| In reply to | #107331 |
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.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-17 10:56 -0500 |
| Message-ID | <v4pmb8$nmvq$1@dont-email.me> |
| In reply to | #107334 |
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.
_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.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2024-06-18 09:57 +0200 |
| Message-ID | <v4rekj$180pg$1@dont-email.me> |
| In reply to | #107336 |
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. 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 | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-18 07:38 -0500 |
| Message-ID | <v4rv45$1blnm$1@dont-email.me> |
| In reply to | #107354 |
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?
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.
> 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.
--
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 | Python <python@invalid.org> |
|---|---|
| Date | 2024-06-18 14:42 +0200 |
| Message-ID | <v4rvb2$19r3f$5@dont-email.me> |
| In reply to | #107360 |
Le 18/06/2024 à 14:38, olcott a écrit :
> On 6/18/2024 2:57 AM, Fred. Zwarts wrote:
...
>> 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?
>
> The C people already agreed that I am correct about this:
Definitely NOT. Given that the following code is not an assertion
(and does not even compile, as usual with Peter Olcott productions).
> 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);
> }
Have you checked weather forecast in Hell as you are likely
to end up there soon?
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-18 08:34 -0500 |
| Message-ID | <v4s2cc$1boeu$7@dont-email.me> |
| In reply to | #107361 |
On 6/18/2024 7:42 AM, Python wrote:
> Le 18/06/2024 à 14:38, olcott a écrit :
>> On 6/18/2024 2:57 AM, Fred. Zwarts wrote:
> ...
>>> 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?
>>
>> The C people already agreed that I am correct about this:
>
> Definitely NOT. Given that the following code is not an assertion
> (and does not even compile, as usual with Peter Olcott productions).
>
>> 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);
>> }
>
> Have you checked weather forecast in Hell as you are likely
> to end up there soon?
I arranged for weekly meetings on repentance with those
delegated with the authority to discuss this with me.
I only have three months left before I will be on medicine that
tends to greatly reduce the levels of several kinds of very
important blood cells. My POD24 diagnosis means that my cancer
came back too soon to try chemotherapy again.
I went though chemo better than average, I only felt really
sick for three days. I had to spend three days in the hospital
three different times because I had a very slight fever of 100.4F
and very low neutrophil counts, AKA Neutropenia. One of these
three times I could not eat or sleep at all for three days.
Validation of POD24 as a robust early clinical end point of
poor survival in FL from 5225 patients on 13 clinical trials
https://pubmed.ncbi.nlm.nih.gov/34614146/
--
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 | <v4tf1r$ddeo$2@i2pn2.org> |
| In reply to | #107368 |
On 6/18/24 9:34 AM, olcott wrote:
> On 6/18/2024 7:42 AM, Python wrote:
>> Le 18/06/2024 à 14:38, olcott a écrit :
>>> On 6/18/2024 2:57 AM, Fred. Zwarts wrote:
>> ...
>>>> 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?
>>>
>>> The C people already agreed that I am correct about this:
>>
>> Definitely NOT. Given that the following code is not an assertion
>> (and does not even compile, as usual with Peter Olcott productions).
>>
>>> 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);
>>> }
>>
>> Have you checked weather forecast in Hell as you are likely
>> to end up there soon?
> I arranged for weekly meetings on repentance with those
> delegated with the authority to discuss this with me.
Really? With who did you arange this with?
My guess it was actually with your lying father.
> I only have three months left before I will be on medicine that
> tends to greatly reduce the levels of several kinds of very
> important blood cells. My POD24 diagnosis means that my cancer
> came back too soon to try chemotherapy again.
So, you need to get off you dead-end logic, and look at the real truth.
>
> I went though chemo better than average, I only felt really
> sick for three days. I had to spend three days in the hospital
> three different times because I had a very slight fever of 100.4F
> and very low neutrophil counts, AKA Neutropenia. One of these
> three times I could not eat or sleep at all for three days.
>
> Validation of POD24 as a robust early clinical end point of
> poor survival in FL from 5225 patients on 13 clinical trials
> https://pubmed.ncbi.nlm.nih.gov/34614146/
>
[toc] | [prev] | [next] | [standalone]
| From | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2024-06-18 17:20 +0200 |
| Message-ID | <v4s8k7$1dcrb$1@dont-email.me> |
| In reply to | #107360 |
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.
>
> 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 | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-18 10:33 -0500 |
| Message-ID | <v4s9cj$1dk9i$1@dont-email.me> |
| In reply to | #107369 |
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+
>>
>> 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.
>>
>
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2024-06-18 17:47 +0200 |
| Message-ID | <v4sa6j$1dcrb$3@dont-email.me> |
| In reply to | #107371 |
Op 18.jun.2024 om 17:33 schreef olcott:
> 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.
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.
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.
>
> http://al.howardknight.net/?STYPE=msgid&MSGI=%3Cv4pg5p%24morv%241%40raubtier-asyl.eternal-september.org%3E+
>>>
>>> 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 | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-18 11:26 -0500 |
| Message-ID | <v4scfo$1eb2f$1@dont-email.me> |
| In reply to | #107375 |
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
--
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 | Python <python@invalid.org> |
|---|---|
| Date | 2024-06-18 18:28 +0200 |
| Message-ID | <v4scjf$1drc6$3@dont-email.me> |
| In reply to | #107381 |
Le 18/06/2024 à 18:26, olcott a écrit : > On 6/18/2024 10:47 AM, Fred. Zwarts wrote: >> Op 18.jun.2024 om 17:33 schreef olcott: ... >> 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. This does not prevent you to be an idiot and completely off track when it comes to C or C++ programming languages.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-18 11:34 -0500 |
| Message-ID | <v4scvi$1eb2f$4@dont-email.me> |
| In reply to | #107383 |
On 6/18/2024 11:28 AM, Python wrote: > Le 18/06/2024 à 18:26, olcott a écrit : >> On 6/18/2024 10:47 AM, Fred. Zwarts wrote: >>> Op 18.jun.2024 om 17:33 schreef olcott: > ... >>> 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. > > This does not prevent you to be an idiot and completely > off track when it comes to C or C++ programming languages. > That no one can provide reasoning showing that this is incorrect because it is correct proves my point. http://al.howardknight.net/?STYPE=msgid&MSGI=%3Cv4pg5p%24morv%241%40raubtier-asyl.eternal-september.org%3E+ -- Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
Page 1 of 9 [1] 2 3 4 5 6 7 8 9 Next page →
Back to top | Article view | comp.theory
csiph-web