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 6 of 9 — ← Prev page 1 2 3 4 5 [6] 7 8 9 Next page →
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-23 08:13 -0500 |
| Subject | Re: Simulating termination analyzers by dummies --- criteria is met |
| Message-ID | <v59726$bko6$2@dont-email.me> |
| In reply to | #107663 |
On 6/23/2024 2:57 AM, Mikko wrote:
> On 2024-06-22 14:11:28 +0000, olcott said:
>
>> On 6/22/2024 8:27 AM, Richard Damon wrote:
>>> On 6/22/24 9:04 AM, olcott wrote:
>>>>
>>>> I am the sole inventor of the simulating halt decider.
>>>>
>>>> Ben Bacarisse contacted professor Sipser to verify that he
>>>> really did says this. The details are in this forum about
>>>> the same date.
>>>>
>>>> https://www.amazon.com/Introduction-Theory-Computation-Michael-Sipser/dp/113318779X/
>>>>
>>>> <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>>> If simulating halt decider H correctly simulates its input D
>>>> until H correctly determines that its simulated D would never
>>>> stop running unless aborted then
>>>>
>>>> H can abort its simulation of D and correctly report that D
>>>> specifies a non-halting sequence of configurations.
>>>> </MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>>
>>> And, as I remember, he also verified that he disagrees with your
>>> definition of correct simulation.
>>>
>>>>
>>>> *Ben also verified that the criteria have been met*
>>>> On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
>>>> > I don't think that is the shell game. PO really /has/ an H
>>>> > (it's trivial to do for this one case) that correctly determines
>>>> > that P(P) *would* never stop running *unless* aborted.
>>>
>>> Right, Ben was willing to do what I am not that you can prove that,
>>> by your definition, H can show that it "must" abort its simulation or
>>> the input will run forever.
>>>
>>> But, just like me, he also agrees that this is NOT the defintion of
>>> Halting, so H is just shown to be a correct (partial) POOP decider
>>> but ot a Halt Decider, not even for that one input.
>>>
>>
>> On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
>> > I don't think that is the shell game. PO really /has/ an H
>> > (it's trivial to do for this one case) that correctly determines
>> > that P(P) *would* never stop running *unless* aborted.
>> >
>> > He knows and accepts that P(P) actually does stop. The
>> > wrong answer is justified by what would happen if H
>> > (and hence a different P) where not what they actually are.
>> >
>> *Ben agrees that the criteria is met for the input*
>>
>> Computable functions are the formalized analogue of the
>> intuitive notion of algorithms, in the sense that a function
>> is computable if there exists an algorithm that can do the
>> job of the function, i.e. *given an input of the function*
>> *domain it can return the corresponding output*
>> https://en.wikipedia.org/wiki/Computable_function
>>
>> *Ben disagrees that the criteria is met for the non-input*
>> Yet no one here can stay focused on the fact that non-inputs
>> *DO NOT COUNT*
>
> In particular, you can't. You have insisted that your "decider"
> or "anlyzer" (or whatever word you happen to use) H or HH (or
> hwatever name you happen to use) must return false because a
> non-input (where instead of the actually called function another
> function that does not halt is called) does not halt.
>
You said it backwards. When I say that I am not guilty and did
not rob the liquor store you cannot paraphrase this as he admitted
that he robbed the liquor store.
H performs a sequence of finite string transformations on
its finite input of x86 machine code. These transformations
include that D calls H(D,D) while being simulated by H. In
such a case the call from D to H(D,D) cannot possibly return.
>> void DDD()
>> {
>> HHH0(DDD);
>> }
>>
>> int main()
>> {
>> Output("Input_Halts = ", HHH0(DDD));
>> Output("Input_Halts = ", HHH1(DDD));
>> }
>>
>> It is a verified fact that the behavior that finite string DDD
>> presents to HH0 is that when DDD correctly simulated by HH0
>> calls HH0(DDD) that this call DOES NOT RETURN.
>>
>> It is a verified fact that the behavior that finite string DDD
>> presents to HH1 is that when DDD correctly simulated by HH1
>> calls HH0(DDD) that this call DOES RETURN.
>
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Mikko <mikko.levanto@iki.fi> |
|---|---|
| Date | 2024-06-24 10:22 +0300 |
| Subject | Re: Simulating termination analyzers by dummies --- criteria is met |
| Message-ID | <v5b6rj$qq4o$1@dont-email.me> |
| In reply to | #107671 |
On 2024-06-23 13:13:42 +0000, olcott said: > On 6/23/2024 2:57 AM, Mikko wrote: >> On 2024-06-22 14:11:28 +0000, olcott said: >> >>> On 6/22/2024 8:27 AM, Richard Damon wrote: >>>> On 6/22/24 9:04 AM, olcott wrote: > >>>>> >>>>> I am the sole inventor of the simulating halt decider. >>>>> >>>>> Ben Bacarisse contacted professor Sipser to verify that he >>>>> really did says this. The details are in this forum about >>>>> the same date. >>>>> >>>>> https://www.amazon.com/Introduction-Theory-Computation-Michael-Sipser/dp/113318779X/ >>>>> >>>>> >>>>> <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>> If simulating halt decider H correctly simulates its input D >>>>> until H correctly determines that its simulated D would never >>>>> stop running unless aborted then >>>>> >>>>> H can abort its simulation of D and correctly report that D >>>>> specifies a non-halting sequence of configurations. >>>>> </MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>> >>>> And, as I remember, he also verified that he disagrees with your >>>> definition of correct simulation. >>>> >>>>> >>>>> *Ben also verified that the criteria have been met* >>>>> On 10/14/2022 7:44 PM, Ben Bacarisse wrote: >>>>> > I don't think that is the shell game. PO really /has/ an H >>>>> > (it's trivial to do for this one case) that correctly determines >>>>> > that P(P) *would* never stop running *unless* aborted. >>>> >>>> Right, Ben was willing to do what I am not that you can prove that, by >>>> your definition, H can show that it "must" abort its simulation or the >>>> input will run forever. >>>> >>>> But, just like me, he also agrees that this is NOT the defintion of >>>> Halting, so H is just shown to be a correct (partial) POOP decider but >>>> ot a Halt Decider, not even for that one input. >>>> >>> >>> On 10/14/2022 7:44 PM, Ben Bacarisse wrote: >>> > I don't think that is the shell game. PO really /has/ an H >>> > (it's trivial to do for this one case) that correctly determines >>> > that P(P) *would* never stop running *unless* aborted. >>> > >>> > He knows and accepts that P(P) actually does stop. The >>> > wrong answer is justified by what would happen if H >>> > (and hence a different P) where not what they actually are. >>> > >>> *Ben agrees that the criteria is met for the input* >>> >>> Computable functions are the formalized analogue of the >>> intuitive notion of algorithms, in the sense that a function >>> is computable if there exists an algorithm that can do the >>> job of the function, i.e. *given an input of the function* >>> *domain it can return the corresponding output* >>> https://en.wikipedia.org/wiki/Computable_function >>> >>> *Ben disagrees that the criteria is met for the non-input* >>> Yet no one here can stay focused on the fact that non-inputs >>> *DO NOT COUNT* >> >> In particular, you can't. You have insisted that your "decider" >> or "anlyzer" (or whatever word you happen to use) H or HH (or >> hwatever name you happen to use) must return false because a >> non-input (where instead of the actually called function another >> function that does not halt is called) does not halt. >> > > You said it backwards. When I say that I am not guilty and did > not rob the liquor store you cannot paraphrase this as he admitted > that he robbed the liquor store. The important qestion is not whether you admit but what the police finds out. > H performs a sequence of finite string transformations on > its finite input of x86 machine code. These transformations > include that D calls H(D,D) while being simulated by H. In > such a case the call from D to H(D,D) cannot possibly return. Which is all we need to know about H in ordet to determine that it is not a decider. -- Mikko
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-24 08:46 -0500 |
| Subject | Re: Simulating termination analyzers by dummies --- criteria is met |
| Message-ID | <v5btcg$v0vb$3@dont-email.me> |
| In reply to | #107714 |
On 6/24/2024 2:22 AM, Mikko wrote:
> On 2024-06-23 13:13:42 +0000, olcott said:
>
>> On 6/23/2024 2:57 AM, Mikko wrote:
>>> On 2024-06-22 14:11:28 +0000, olcott said:
>>>
>>>> On 6/22/2024 8:27 AM, Richard Damon wrote:
>>>>> On 6/22/24 9:04 AM, olcott wrote:
>>
>>>>>>
>>>>>> I am the sole inventor of the simulating halt decider.
>>>>>>
>>>>>> Ben Bacarisse contacted professor Sipser to verify that he
>>>>>> really did says this. The details are in this forum about
>>>>>> the same date.
>>>>>>
>>>>>> https://www.amazon.com/Introduction-Theory-Computation-Michael-Sipser/dp/113318779X/
>>>>>>
>>>>>> <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>>>>> If simulating halt decider H correctly simulates its input D
>>>>>> until H correctly determines that its simulated D would never
>>>>>> stop running unless aborted then
>>>>>>
>>>>>> H can abort its simulation of D and correctly report that D
>>>>>> specifies a non-halting sequence of configurations.
>>>>>> </MIT Professor Sipser agreed to ONLY these verbatim words
>>>>>> 10/13/2022>
>>>>>
>>>>> And, as I remember, he also verified that he disagrees with your
>>>>> definition of correct simulation.
>>>>>
>>>>>>
>>>>>> *Ben also verified that the criteria have been met*
>>>>>> On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
>>>>>> > I don't think that is the shell game. PO really /has/ an H
>>>>>> > (it's trivial to do for this one case) that correctly determines
>>>>>> > that P(P) *would* never stop running *unless* aborted.
>>>>>
>>>>> Right, Ben was willing to do what I am not that you can prove that,
>>>>> by your definition, H can show that it "must" abort its simulation
>>>>> or the input will run forever.
>>>>>
>>>>> But, just like me, he also agrees that this is NOT the defintion of
>>>>> Halting, so H is just shown to be a correct (partial) POOP decider
>>>>> but ot a Halt Decider, not even for that one input.
>>>>>
>>>>
>>>> On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
>>>> > I don't think that is the shell game. PO really /has/ an H
>>>> > (it's trivial to do for this one case) that correctly determines
>>>> > that P(P) *would* never stop running *unless* aborted.
>>>> >
>>>> > He knows and accepts that P(P) actually does stop. The
>>>> > wrong answer is justified by what would happen if H
>>>> > (and hence a different P) where not what they actually are.
>>>> >
>>>> *Ben agrees that the criteria is met for the input*
>>>>
>>>> Computable functions are the formalized analogue of the
>>>> intuitive notion of algorithms, in the sense that a function
>>>> is computable if there exists an algorithm that can do the
>>>> job of the function, i.e. *given an input of the function*
>>>> *domain it can return the corresponding output*
>>>> https://en.wikipedia.org/wiki/Computable_function
>>>>
>>>> *Ben disagrees that the criteria is met for the non-input*
>>>> Yet no one here can stay focused on the fact that non-inputs
>>>> *DO NOT COUNT*
>>>
>>> In particular, you can't. You have insisted that your "decider"
>>> or "anlyzer" (or whatever word you happen to use) H or HH (or
>>> hwatever name you happen to use) must return false because a
>>> non-input (where instead of the actually called function another
>>> function that does not halt is called) does not halt.
>>>
>>
>> You said it backwards. When I say that I am not guilty and did
>> not rob the liquor store you cannot paraphrase this as he admitted
>> that he robbed the liquor store.
>
> The important qestion is not whether you admit but what the police
> finds out.
>
>> H performs a sequence of finite string transformations on
>> its finite input of x86 machine code. These transformations
>> include that D calls H(D,D) while being simulated by H. In
>> such a case the call from D to H(D,D) cannot possibly return.
>
> Which is all we need to know about H in ordet to determine that
> it is not a decider.
>
void DDD()
{
H0(DDD);
}
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call H0(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
The call from DDD to H0(DDD) when DDD is correctly emulated
by H0 cannot possibly return.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | joes <noreply@example.com> |
|---|---|
| Date | 2024-06-24 19:52 +0000 |
| Subject | Re: Simulating termination analyzers by dummies --- criteria is met |
| Message-ID | <v5cip4$10816$3@i2pn2.org> |
| In reply to | #107722 |
Am Mon, 24 Jun 2024 08:46:56 -0500 schrieb olcott:
> On 6/24/2024 2:22 AM, Mikko wrote:
>> On 2024-06-23 13:13:42 +0000, olcott said:
>>> On 6/23/2024 2:57 AM, Mikko wrote:
>>>> On 2024-06-22 14:11:28 +0000, olcott said:
>>>>> On 6/22/2024 8:27 AM, Richard Damon wrote:
>>>>>> On 6/22/24 9:04 AM, olcott wrote:
>>>> In particular, you can't. You have insisted that your "decider" or
>>>> "anlyzer" (or whatever word you happen to use) H or HH (or hwatever
>>>> name you happen to use) must return false because a non-input (where
>>>> instead of the actually called function another function that does
>>>> not halt is called) does not halt.
>> Which is all we need to know about H in ordet to determine that it is
>> not a decider.
>>
> void DDD()
> {
> H0(DDD);
> }
> The call from DDD to H0(DDD) when DDD is correctly emulated by H0 cannot
> possibly return.
Why not? H0 is a decider AND simulator, so it can simulate itself
terminating.
--
Man kann mit dunklen Zahlen nicht rechnen. Für die eigentliche Mathematik
sind sie vollkommen nutzlos. --Wolfgang Mückenheim
[toc] | [prev] | [next] | [standalone]
| From | Alan Mackenzie <acm@muc.de> |
|---|---|
| Date | 2024-06-24 20:27 +0000 |
| Subject | Re: Simulating termination analyzers by dummies --- criteria is met |
| Message-ID | <v5cksb$1mtc$1@news.muc.de> |
| In reply to | #107730 |
joes <noreply@example.com> wrote: [ .... ] > -- > Man kann mit dunklen Zahlen nicht rechnen. Für die eigentliche Mathematik > sind sie vollkommen nutzlos. --Wolfgang Mückenheim Or, in English, "You can't do arithmetic with dark numbers. For actual mathematics, they're completely useless.". Wolfgang Mückenheim is a crank in sci.math and de.sci.mathematik, one of the few remaining ones after Google shut down their Usenet servers in February. He insists on the existence of something he calls "dark numbers" and gives crank-like justifications for them, which do not hold up under more robust questioning. -- Alan Mackenzie (Nuremberg, Germany).
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-24 16:10 -0500 |
| Subject | Re: Simulating termination analyzers by dummies --- criteria is met |
| Message-ID | <v5cnb8$149dc$2@dont-email.me> |
| In reply to | #107732 |
On 6/24/2024 3:27 PM, Alan Mackenzie wrote: > joes <noreply@example.com> wrote: > > [ .... ] > >> -- >> Man kann mit dunklen Zahlen nicht rechnen. Für die eigentliche Mathematik >> sind sie vollkommen nutzlos. --Wolfgang Mückenheim > > Or, in English, "You can't do arithmetic with dark numbers. For actual > mathematics, they're completely useless.". > > Wolfgang Mückenheim is a crank in sci.math and de.sci.mathematik, one of > the few remaining ones after Google shut down their Usenet servers in > February. He insists on the existence of something he calls "dark > numbers" and gives crank-like justifications for them, which do not hold > up under more robust questioning. > In my case people have been disagreeing with the semantics of the x86 programming language for three years when they have insisted that D correctly simulated by H must have the same behavior as the directly executed D(D). *The following is a dumbed down version that is much more* *difficult to rebut without looking foolish* When we stipulate that the only measure of a correct emulation is the semantics of the x86 programming language then we see that when DDD is correctly emulated by H0 that its call to H0(DDD) cannot possibly return. _DDD() [00002172] 55 push ebp ; housekeeping [00002173] 8bec mov ebp,esp ; housekeeping [00002175] 6872210000 push 00002172 ; push DDD [0000217a] e853f4ffff call 000015d2 ; call H0(DDD) [0000217f] 83c404 add esp,+04 [00002182] 5d pop ebp [00002183] c3 ret Size in bytes:(0018) [00002183] When we define H1 as identical to H0 except that DDD does not call H1 then we see that when DDD is correctly emulated by H1 that its call to H0(DDD) does return. This is the same behavior as the directly executed DDD(). -- Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-24 19:48 -0400 |
| Subject | Re: Simulating termination analyzers by dummies --- criteria is met |
| Message-ID | <v5d0l2$10m6o$7@i2pn2.org> |
| In reply to | #107734 |
On 6/24/24 5:10 PM, olcott wrote: > On 6/24/2024 3:27 PM, Alan Mackenzie wrote: >> joes <noreply@example.com> wrote: >> >> [ .... ] >> >>> -- >>> Man kann mit dunklen Zahlen nicht rechnen. Für die eigentliche >>> Mathematik >>> sind sie vollkommen nutzlos. --Wolfgang Mückenheim >> >> Or, in English, "You can't do arithmetic with dark numbers. For actual >> mathematics, they're completely useless.". >> >> Wolfgang Mückenheim is a crank in sci.math and de.sci.mathematik, one of >> the few remaining ones after Google shut down their Usenet servers in >> February. He insists on the existence of something he calls "dark >> numbers" and gives crank-like justifications for them, which do not hold >> up under more robust questioning. >> > > In my case people have been disagreeing with the semantics of > the x86 programming language for three years when they have > insisted that D correctly simulated by H must have the same > behavior as the directly executed D(D). No, we fully understand its semantics. Not sure you do, as you can't produce a trace by the decider that correctly goes past the decider by the requirements to follow those semantics. > > *The following is a dumbed down version that is much more* > *difficult to rebut without looking foolish* > > When we stipulate that the only measure of a correct emulation > is the semantics of the x86 programming language then we see that > when DDD is correctly emulated by H0 that its call to H0(DDD) > cannot possibly return. > > _DDD() > [00002172] 55 push ebp ; housekeeping > [00002173] 8bec mov ebp,esp ; housekeeping > [00002175] 6872210000 push 00002172 ; push DDD > [0000217a] e853f4ffff call 000015d2 ; call H0(DDD) > [0000217f] 83c404 add esp,+04 > [00002182] 5d pop ebp > [00002183] c3 ret > Size in bytes:(0018) [00002183] > > When we define H1 as identical to H0 except that DDD does not > call H1 then we see that when DDD is correctly emulated by H1 > that its call to H0(DDD) does return. This is the same behavior > as the directly executed DDD(). > And the emulation by H0 and H1 will be IDETICAL to the point where H0 stops its emulation. This is a fundamental fact. If you disagree, please show what instruction, CORRECTLY EMULATED per the definition of the x86 instruction set, that is the point of divergance. Your failure, for years to show this just indicate that you know you claim is false, but need to hang onto it to try to fabricate a lie for your false proof.
[toc] | [prev] | [next] | [standalone]
| From | joes <noreply@example.com> |
|---|---|
| Date | 2024-06-25 08:48 +0000 |
| Subject | Re: Simulating termination analyzers by dummies --- criteria is met |
| Message-ID | <v5e098$11urb$1@i2pn2.org> |
| In reply to | #107734 |
Am Mon, 24 Jun 2024 16:10:00 -0500 schrieb olcott: > In my case people have been disagreeing with the semantics of the x86 > programming language for three years when they have insisted that D > correctly simulated by H must have the same behavior as the directly > executed D(D). What are the rules on how much a simulator can diverge from the actual behaviour of its input? > When we stipulate that the only measure of a correct emulation is the > semantics of the x86 programming language then we see that when DDD is > correctly emulated by H0 that its call to H0(DDD) cannot possibly > return. With that I agree. It follows that H0 does not simulate correctly. > When we define H1 as identical to H0 except that DDD does not call H1 > then we see that when DDD is correctly emulated by H1 that its call to > H0(DDD) does return. This is the same behavior as the directly executed > DDD(). That is the actual behaviour. If a simulator does something different, it is wrong. A simulation does not change behaviour. -- Man kann mit dunklen Zahlen nicht rechnen. Für die eigentliche Mathematik sind sie vollkommen nutzlos. --Wolfgang Mückenheim
[toc] | [prev] | [next] | [standalone]
| From | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2024-06-25 14:14 +0200 |
| Subject | Re: Simulating termination analyzers by dummies --- criteria is met |
| Message-ID | <v5ecbt$1hs89$2@dont-email.me> |
| In reply to | #107734 |
Op 24.jun.2024 om 23:10 schreef olcott: > On 6/24/2024 3:27 PM, Alan Mackenzie wrote: >> joes <noreply@example.com> wrote: >> >> [ .... ] >> >>> -- >>> Man kann mit dunklen Zahlen nicht rechnen. Für die eigentliche >>> Mathematik >>> sind sie vollkommen nutzlos. --Wolfgang Mückenheim >> >> Or, in English, "You can't do arithmetic with dark numbers. For actual >> mathematics, they're completely useless.". >> >> Wolfgang Mückenheim is a crank in sci.math and de.sci.mathematik, one of >> the few remaining ones after Google shut down their Usenet servers in >> February. He insists on the existence of something he calls "dark >> numbers" and gives crank-like justifications for them, which do not hold >> up under more robust questioning. >> > > In my case people have been disagreeing with the semantics of > the x86 programming language for three years when they have > insisted that D correctly simulated by H must have the same > behavior as the directly executed D(D). > > *The following is a dumbed down version that is much more* > *difficult to rebut without looking foolish* > > When we stipulate that the only measure of a correct emulation > is the semantics of the x86 programming language then we see that > when DDD is correctly emulated by H0 that its call to H0(DDD) > cannot possibly return. > > _DDD() > [00002172] 55 push ebp ; housekeeping > [00002173] 8bec mov ebp,esp ; housekeeping > [00002175] 6872210000 push 00002172 ; push DDD > [0000217a] e853f4ffff call 000015d2 ; call H0(DDD) > [0000217f] 83c404 add esp,+04 > [00002182] 5d pop ebp > [00002183] c3 ret > Size in bytes:(0018) [00002183] > > When we define H1 as identical to H0 except that DDD does not > call H1 then we see that when DDD is correctly emulated by H1 > that its call to H0(DDD) does return. This is the same behavior > as the directly executed DDD(). And that is the correct behaviour that H0 should simulate as well, but what it cannot do, showing that H0's simulation is incorrect. You are faking that the disagreement is about the X86 programming language, but the only point of disagreement is that you think that aborting belongs to that language, but others think is does not.
[toc] | [prev] | [next] | [standalone]
| From | Mikko <mikko.levanto@iki.fi> |
|---|---|
| Date | 2024-06-25 12:27 +0300 |
| Subject | Re: Simulating termination analyzers by dummies --- criteria is met |
| Message-ID | <v5e2ha$1g7on$1@dont-email.me> |
| In reply to | #107732 |
On 2024-06-24 20:27:55 +0000, Alan Mackenzie said: > joes <noreply@example.com> wrote: > > [ .... ] > >> -- >> Man kann mit dunklen Zahlen nicht rechnen. Für die eigentliche >> Mathematik> sind sie vollkommen nutzlos. --Wolfgang Mückenheim > > Or, in English, "You can't do arithmetic with dark numbers. For actual > mathematics, they're completely useless.". > > Wolfgang Mückenheim is a crank in sci.math and de.sci.mathematik, one of > the few remaining ones after Google shut down their Usenet servers in > February. He insists on the existence of something he calls "dark > numbers" and gives crank-like justifications for them, which do not hold > up under more robust questioning. From the first order Peano axioms it is not possible to prove that there are no non-standard numbers. It is possible to construct (for example in ZF) a model of the first order Peano arithmetic that has a proper subset that is another model of the same Peano artichmetic. And it is possible to do arithmetic with those numbers. Whether useful, I don't know. -- Mikko
[toc] | [prev] | [next] | [standalone]
| From | Alan Mackenzie <acm@muc.de> |
|---|---|
| Date | 2024-06-25 14:06 +0000 |
| Subject | Re: Simulating termination analyzers by dummies --- criteria is met |
| Message-ID | <v5eis8$24l4$2@news.muc.de> |
| In reply to | #107778 |
Mikko <mikko.levanto@iki.fi> wrote: > On 2024-06-24 20:27:55 +0000, Alan Mackenzie said: >> joes <noreply@example.com> wrote: >> [ .... ] >>> -- >>> Man kann mit dunklen Zahlen nicht rechnen. Für die eigentliche >>> Mathematik> sind sie vollkommen nutzlos. --Wolfgang Mückenheim >> Or, in English, "You can't do arithmetic with dark numbers. For actual >> mathematics, they're completely useless.". >> Wolfgang Mückenheim is a crank in sci.math and de.sci.mathematik, one of >> the few remaining ones after Google shut down their Usenet servers in >> February. He insists on the existence of something he calls "dark >> numbers" and gives crank-like justifications for them, which do not hold >> up under more robust questioning. > From the first order Peano axioms it is not possible to prove that there > are no non-standard numbers. It is possible to construct (for example in > ZF) a model of the first order Peano arithmetic that has a proper subset > that is another model of the same Peano artichmetic. And it is possible > to do arithmetic with those numbers. Whether useful, I don't know. Yes. All that is over Wolfgang Mückenheim's head. He doesn't have a degree in maths, but I believe he has a Phd in physics. His intuitions in set theory are those of a rebellious teenager, and he refuses to accept many established mathematical results. The threads he gets involved in in sci.math feel similar to the threads in comp.theory involving Peter Olcott. Such people completely miss the fascination of surreal numbers, Robinson integers, and the rest. Other posters just wish they could get the cranks to learn new (for them) things. Personally, I never learnt much about mathematical logic and the foundations in my maths degree, but I could catch up if I could be bothered, and I'm broadly aware of what I've missed. That distinguishes me from the cranks. > -- > Mikko -- Alan Mackenzie (Nuremberg, Germany).
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-24 16:12 -0500 |
| Subject | Re: Simulating termination analyzers by dummies --- criteria is met |
| Message-ID | <v5cngn$149dc$3@dont-email.me> |
| In reply to | #107730 |
On 6/24/2024 2:52 PM, joes wrote:
> Am Mon, 24 Jun 2024 08:46:56 -0500 schrieb olcott:
>> On 6/24/2024 2:22 AM, Mikko wrote:
>>> On 2024-06-23 13:13:42 +0000, olcott said:
>>>> On 6/23/2024 2:57 AM, Mikko wrote:
>>>>> On 2024-06-22 14:11:28 +0000, olcott said:
>>>>>> On 6/22/2024 8:27 AM, Richard Damon wrote:
>>>>>>> On 6/22/24 9:04 AM, olcott wrote:
>
>>>>> In particular, you can't. You have insisted that your "decider" or
>>>>> "anlyzer" (or whatever word you happen to use) H or HH (or hwatever
>>>>> name you happen to use) must return false because a non-input (where
>>>>> instead of the actually called function another function that does
>>>>> not halt is called) does not halt.
>
>>> Which is all we need to know about H in ordet to determine that it is
>>> not a decider.
>>>
>> void DDD()
>> {
>> H0(DDD);
>> }
>> The call from DDD to H0(DDD) when DDD is correctly emulated by H0 cannot
>> possibly return.
> Why not? H0 is a decider AND simulator, so it can simulate itself
> terminating.
>
That is a stupid thing to say.
When H0 is called in recursive emulation the semantics of the x86
language do not allow H0 to simply ignore this and still terminate.
--
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-24 19:53 -0400 |
| Subject | Re: Simulating termination analyzers by dummies --- criteria is met |
| Message-ID | <v5d0ul$10m6p$4@i2pn2.org> |
| In reply to | #107735 |
On 6/24/24 5:12 PM, olcott wrote:
> On 6/24/2024 2:52 PM, joes wrote:
>> Am Mon, 24 Jun 2024 08:46:56 -0500 schrieb olcott:
>>> On 6/24/2024 2:22 AM, Mikko wrote:
>>>> On 2024-06-23 13:13:42 +0000, olcott said:
>>>>> On 6/23/2024 2:57 AM, Mikko wrote:
>>>>>> On 2024-06-22 14:11:28 +0000, olcott said:
>>>>>>> On 6/22/2024 8:27 AM, Richard Damon wrote:
>>>>>>>> On 6/22/24 9:04 AM, olcott wrote:
>>
>>>>>> In particular, you can't. You have insisted that your "decider" or
>>>>>> "anlyzer" (or whatever word you happen to use) H or HH (or hwatever
>>>>>> name you happen to use) must return false because a non-input (where
>>>>>> instead of the actually called function another function that does
>>>>>> not halt is called) does not halt.
>>
>>>> Which is all we need to know about H in ordet to determine that it is
>>>> not a decider.
>>>>
>>> void DDD()
>>> {
>>> H0(DDD);
>>> }
>>> The call from DDD to H0(DDD) when DDD is correctly emulated by H0 cannot
>>> possibly return.
>
>> Why not? H0 is a decider AND simulator, so it can simulate itself
>> terminating.
>>
> That is a stupid thing to say.
> When H0 is called in recursive emulation the semantics of the x86
> language do not allow H0 to simply ignore this and still terminate.
>
THe semantic of the x86 language do not talk at ALL about "recursion" or
"emulation" as no instruction in the set needs to directly deal with
such things. Yes, you can build recursion emulation out of the
instrucitons, but that is a DERIVED property, not an innate one.
You just don't seem to understand such FACTS, perhaps because you don't
really understand the things you are trying to talk about.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-24 19:44 -0400 |
| Subject | Re: Simulating termination analyzers by dummies --- criteria is met |
| Message-ID | <v5d0ct$10m6o$6@i2pn2.org> |
| In reply to | #107722 |
On 6/24/24 9:46 AM, olcott wrote:
> On 6/24/2024 2:22 AM, Mikko wrote:
>> On 2024-06-23 13:13:42 +0000, olcott said:
>>
>>> On 6/23/2024 2:57 AM, Mikko wrote:
>>>> On 2024-06-22 14:11:28 +0000, olcott said:
>>>>
>>>>> On 6/22/2024 8:27 AM, Richard Damon wrote:
>>>>>> On 6/22/24 9:04 AM, olcott wrote:
>>>
>>>>>>>
>>>>>>> I am the sole inventor of the simulating halt decider.
>>>>>>>
>>>>>>> Ben Bacarisse contacted professor Sipser to verify that he
>>>>>>> really did says this. The details are in this forum about
>>>>>>> the same date.
>>>>>>>
>>>>>>> https://www.amazon.com/Introduction-Theory-Computation-Michael-Sipser/dp/113318779X/
>>>>>>>
>>>>>>> <MIT Professor Sipser agreed to ONLY these verbatim words
>>>>>>> 10/13/2022>
>>>>>>> If simulating halt decider H correctly simulates its input D
>>>>>>> until H correctly determines that its simulated D would never
>>>>>>> stop running unless aborted then
>>>>>>>
>>>>>>> H can abort its simulation of D and correctly report that D
>>>>>>> specifies a non-halting sequence of configurations.
>>>>>>> </MIT Professor Sipser agreed to ONLY these verbatim words
>>>>>>> 10/13/2022>
>>>>>>
>>>>>> And, as I remember, he also verified that he disagrees with your
>>>>>> definition of correct simulation.
>>>>>>
>>>>>>>
>>>>>>> *Ben also verified that the criteria have been met*
>>>>>>> On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
>>>>>>> > I don't think that is the shell game. PO really /has/ an H
>>>>>>> > (it's trivial to do for this one case) that correctly determines
>>>>>>> > that P(P) *would* never stop running *unless* aborted.
>>>>>>
>>>>>> Right, Ben was willing to do what I am not that you can prove
>>>>>> that, by your definition, H can show that it "must" abort its
>>>>>> simulation or the input will run forever.
>>>>>>
>>>>>> But, just like me, he also agrees that this is NOT the defintion
>>>>>> of Halting, so H is just shown to be a correct (partial) POOP
>>>>>> decider but ot a Halt Decider, not even for that one input.
>>>>>>
>>>>>
>>>>> On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
>>>>> > I don't think that is the shell game. PO really /has/ an H
>>>>> > (it's trivial to do for this one case) that correctly determines
>>>>> > that P(P) *would* never stop running *unless* aborted.
>>>>> >
>>>>> > He knows and accepts that P(P) actually does stop. The
>>>>> > wrong answer is justified by what would happen if H
>>>>> > (and hence a different P) where not what they actually are.
>>>>> >
>>>>> *Ben agrees that the criteria is met for the input*
>>>>>
>>>>> Computable functions are the formalized analogue of the
>>>>> intuitive notion of algorithms, in the sense that a function
>>>>> is computable if there exists an algorithm that can do the
>>>>> job of the function, i.e. *given an input of the function*
>>>>> *domain it can return the corresponding output*
>>>>> https://en.wikipedia.org/wiki/Computable_function
>>>>>
>>>>> *Ben disagrees that the criteria is met for the non-input*
>>>>> Yet no one here can stay focused on the fact that non-inputs
>>>>> *DO NOT COUNT*
>>>>
>>>> In particular, you can't. You have insisted that your "decider"
>>>> or "anlyzer" (or whatever word you happen to use) H or HH (or
>>>> hwatever name you happen to use) must return false because a
>>>> non-input (where instead of the actually called function another
>>>> function that does not halt is called) does not halt.
>>>>
>>>
>>> You said it backwards. When I say that I am not guilty and did
>>> not rob the liquor store you cannot paraphrase this as he admitted
>>> that he robbed the liquor store.
>>
>> The important qestion is not whether you admit but what the police
>> finds out.
>>
>>> H performs a sequence of finite string transformations on
>>> its finite input of x86 machine code. These transformations
>>> include that D calls H(D,D) while being simulated by H. In
>>> such a case the call from D to H(D,D) cannot possibly return.
>>
>> Which is all we need to know about H in ordet to determine that
>> it is not a decider.
>>
>
> void DDD()
> {
> H0(DDD);
> }
>
> _DDD()
> [00002172] 55 push ebp ; housekeeping
> [00002173] 8bec mov ebp,esp ; housekeeping
> [00002175] 6872210000 push 00002172 ; push DDD
> [0000217a] e853f4ffff call 000015d2 ; call H0(DDD)
> [0000217f] 83c404 add esp,+04
> [00002182] 5d pop ebp
> [00002183] c3 ret
> Size in bytes:(0018) [00002183]
>
> The call from DDD to H0(DDD) when DDD is correctly emulated
> by H0 cannot possibly return.
>
>
So?
Can you PROVE it?
And why do we care, since it isn't what Halting is defined to be.
DDD does halt if H0 gives an answer.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-18 22:16 -0400 |
| Subject | Re: Simulating termination analyzers by dummies --- What does halting mean? |
| Message-ID | <v4tf26$ddeo$6@i2pn2.org> |
| In reply to | #107393 |
On 6/18/24 1:25 PM, olcott wrote:
> On 6/18/2024 12:06 PM, joes wrote:
>
> void DDD()
> {
> H0(DDD);
> }
>
> DDD correctly simulated by any H0 cannot possibly halt.
>
>> DDD halts iff H0 halts.
>
> Halting is a technical term-of-the-art that corresponds
> to terminates normally. Because Turing machines are
> abstract mathematical objects there has been no notion
> of abnormal termination for a Turing machine.
No "normally" as Turing Machine have no "abnormal terminatiom"
You just don't understand what they are.
>
> We can derive a notion of abnormal termination for Turing
> machines from the standard terms-of-the-art.
How?
>
> Some TM's loop and thus never stop running, this is classical
> non-halting behavior. UTM's simulate Turing machine descriptions.
> This is the same thing as an interpreter interpreting the
> source-code of a program.
>
> A UTM can be adapted so that it only simulates a fixed number
> of iterations of an input that loops. When this UTM stops
> simulating this Turing machine description we cannot correctly
> say that this looping input halted.
>
And then are no longer UTMs, and YES, if a machine based on such am
modifed UTM (so it is no long a UTM) when the UTM stops simulating, we
can not say the input halted, nor can we say it didn't halt.
The not-a-UTM just came to a no-answer state.
The answer will be provided by useing an ACTUAL UTM that keeps on going,
or the direct execution of the machine,
You are just stuck in your idea that Lies are sometimes ok.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-18 21:30 -0500 |
| Subject | Re: Simulating termination analyzers by dummies --- What does halting mean? |
| Message-ID | <v4tfsj$1oosn$1@dont-email.me> |
| In reply to | #107408 |
On 6/18/2024 9:16 PM, Richard Damon wrote:
> On 6/18/24 1:25 PM, olcott wrote:
>> On 6/18/2024 12:06 PM, joes wrote:
>>
>> void DDD()
>> {
>> H0(DDD);
>> }
>>
>> DDD correctly simulated by any H0 cannot possibly halt.
>>
>>> DDD halts iff H0 halts.
>>
>> Halting is a technical term-of-the-art that corresponds
>> to terminates normally. Because Turing machines are
>> abstract mathematical objects there has been no notion
>> of abnormal termination for a Turing machine.
>
> No "normally" as Turing Machine have no "abnormal terminatiom"
>
> You just don't understand what they are.
>
>>
>> We can derive a notion of abnormal termination for Turing
>> machines from the standard terms-of-the-art.
>
> How?
>
>>
>> Some TM's loop and thus never stop running, this is classical
>> non-halting behavior. UTM's simulate Turing machine descriptions.
>> This is the same thing as an interpreter interpreting the
>> source-code of a program.
>>
>> A UTM can be adapted so that it only simulates a fixed number
>> of iterations of an input that loops. When this UTM stops
>> simulating this Turing machine description we cannot correctly
>> say that this looping input halted.
>>
>
> And then are no longer UTMs, and YES, if a machine based on such am
> modifed UTM (so it is no long a UTM) when the UTM stops simulating, we
> can not say the input halted, nor can we say it didn't halt.
>
When such a UTM has been adapted to only simulate
the first ten states of its input TMD, then every
simulated TMD with more than ten states did not
terminate normally.
> The not-a-UTM just came to a no-answer state.
>
I have to go one-step-at-a-time with everyone or
they get overwhelmed and leap to the conclusion
that I am wrong.
> The answer will be provided by useing an ACTUAL UTM that keeps on going,
> or the direct execution of the machine,
>
> You are just stuck in your idea that Lies are sometimes ok.
You are stuck on the idea that repeating states cannot
be recognized in a finite number of steps.
void Infinite_Loop()
{
HERE: goto HERE;
}
void Infinite_Recursion()
{
Infinite_Recursion();
}
void DDD()
{
H0(DDD);
}
Every C programmer that knows what an x86 emulator is knows
that when H0 emulates the machine language of Infinite_Loop,
Infinite_Recursion, and DDD that it must abort these emulations
so that itself can terminate normally.
This was recently confirmed in the C group.
--
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:41 -0400 |
| Subject | Re: Simulating termination analyzers by dummies --- What does halting mean? |
| Message-ID | <v4tgg7$ddeo$8@i2pn2.org> |
| In reply to | #107409 |
On 6/18/24 10:30 PM, olcott wrote:
> On 6/18/2024 9:16 PM, Richard Damon wrote:
>> On 6/18/24 1:25 PM, olcott wrote:
>>> On 6/18/2024 12:06 PM, joes wrote:
>>>
>>> void DDD()
>>> {
>>> H0(DDD);
>>> }
>>>
>>> DDD correctly simulated by any H0 cannot possibly halt.
>>>
>>>> DDD halts iff H0 halts.
>>>
>>> Halting is a technical term-of-the-art that corresponds
>>> to terminates normally. Because Turing machines are
>>> abstract mathematical objects there has been no notion
>>> of abnormal termination for a Turing machine.
>>
>> No "normally" as Turing Machine have no "abnormal terminatiom"
>>
>> You just don't understand what they are.
>>
>>>
>>> We can derive a notion of abnormal termination for Turing
>>> machines from the standard terms-of-the-art.
>>
>> How?
>>
>>>
>>> Some TM's loop and thus never stop running, this is classical
>>> non-halting behavior. UTM's simulate Turing machine descriptions.
>>> This is the same thing as an interpreter interpreting the
>>> source-code of a program.
>>>
>>> A UTM can be adapted so that it only simulates a fixed number
>>> of iterations of an input that loops. When this UTM stops
>>> simulating this Turing machine description we cannot correctly
>>> say that this looping input halted.
>>>
>>
>> And then are no longer UTMs, and YES, if a machine based on such am
>> modifed UTM (so it is no long a UTM) when the UTM stops simulating, we
>> can not say the input halted, nor can we say it didn't halt.
>>
>
> When such a UTM has been adapted to only simulate
> the first ten states of its input TMD, then every
> simulated TMD with more than ten states did not
> terminate normally.
Then it is no longer a UTM.
And its simulation say NOTHING about the machine not terminating,
normally nor not.
Terminating is a property of the actual machine, and not a sumulation of it.
You could say the SIMULATION didn't terminate normally, but you can't
say the machine didn't or even the Turing Machine Description, as you
could give that exact same TMD to a real UTM and find out the actual
behaviof or the input.
You just have lost track of the defintions of what is REALITY (the
actual behavior of the machine) and what is just imagination.
>
>> The not-a-UTM just came to a no-answer state.
>>
>
> I have to go one-step-at-a-time with everyone or
> they get overwhelmed and leap to the conclusion
> that I am wrong.
Nope, you just forget about what is defined to be real.
>
>> The answer will be provided by useing an ACTUAL UTM that keeps on
>> going, or the direct execution of the machine,
>>
>> You are just stuck in your idea that Lies are sometimes ok.
>
> You are stuck on the idea that repeating states cannot
> be recognized in a finite number of steps.
No, ACTUAL REPEATING states can be recognised, but I guess you are too
stupid to understand my description of it.
>
> void Infinite_Loop()
> {
> HERE: goto HERE;
> }
>
> void Infinite_Recursion()
> {
> Infinite_Recursion();
> }
>
> void DDD()
> {
> H0(DDD);
> }
>
> Every C programmer that knows what an x86 emulator is knows
> that when H0 emulates the machine language of Infinite_Loop,
> Infinite_Recursion, and DDD that it must abort these emulations
> so that itself can terminate normally.
Which doesn't mean the program DDD needs to be abort to have it halt.
That is just a figment of your imagination that doesn't understand the
difference between truth and lies.
>
> This was recently confirmed in the C group.
>
Yes, by Bonita, whose confirmation is, if anything a mark against the
statement.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-18 21:51 -0500 |
| Subject | Re: Simulating termination analyzers by dummies --- What does halting mean? |
| Message-ID | <v4th4c$1oosn$2@dont-email.me> |
| In reply to | #107410 |
On 6/18/2024 9:41 PM, Richard Damon wrote:
> On 6/18/24 10:30 PM, olcott wrote:
>> On 6/18/2024 9:16 PM, Richard Damon wrote:
>>> On 6/18/24 1:25 PM, olcott wrote:
>>>> On 6/18/2024 12:06 PM, joes wrote:
>>>>
>>>> void DDD()
>>>> {
>>>> H0(DDD);
>>>> }
>>>>
>>>> DDD correctly simulated by any H0 cannot possibly halt.
>>>>
>>>>> DDD halts iff H0 halts.
>>>>
>>>> Halting is a technical term-of-the-art that corresponds
>>>> to terminates normally. Because Turing machines are
>>>> abstract mathematical objects there has been no notion
>>>> of abnormal termination for a Turing machine.
>>>
>>> No "normally" as Turing Machine have no "abnormal terminatiom"
>>>
>>> You just don't understand what they are.
>>>
>>>>
>>>> We can derive a notion of abnormal termination for Turing
>>>> machines from the standard terms-of-the-art.
>>>
>>> How?
>>>
>>>>
>>>> Some TM's loop and thus never stop running, this is classical
>>>> non-halting behavior. UTM's simulate Turing machine descriptions.
>>>> This is the same thing as an interpreter interpreting the
>>>> source-code of a program.
>>>>
>>>> A UTM can be adapted so that it only simulates a fixed number
>>>> of iterations of an input that loops. When this UTM stops
>>>> simulating this Turing machine description we cannot correctly
>>>> say that this looping input halted.
>>>>
>>>
>>> And then are no longer UTMs, and YES, if a machine based on such am
>>> modifed UTM (so it is no long a UTM) when the UTM stops simulating,
>>> we can not say the input halted, nor can we say it didn't halt.
>>>
>>
>> When such a UTM has been adapted to only simulate
>> the first ten states of its input TMD, then every
>> simulated TMD with more than ten states did not
>> terminate normally.
>
> Then it is no longer a UTM.
>
> And its simulation say NOTHING about the machine not terminating,
> normally nor not.
>
> Terminating is a property of the actual machine, and not a sumulation of
> it.
>
Thus according to your faulty reasoning when the source-code
of a C program is simulated by interpreter this is mere nonsense
gibberish having nothing to do what the behavior that this
source-code specifies.
> You could say the SIMULATION didn't terminate normally, but you can't
> say the machine didn't or even the Turing Machine Description, as you
> could give that exact same TMD to a real UTM and find out the actual
> behaviof or the input.
>
Sure you can otherwise interpreters of source-code would be
a bogus concept.
> You just have lost track of the defintions of what is REALITY (the
> actual behavior of the machine) and what is just imagination.
>
Not I but you.
>>
>>> The not-a-UTM just came to a no-answer state.
>>>
>>
>> I have to go one-step-at-a-time with everyone or
>> they get overwhelmed and leap to the conclusion
>> that I am wrong.
>
> Nope, you just forget about what is defined to be real.
>
>>
>>> The answer will be provided by useing an ACTUAL UTM that keeps on
>>> going, or the direct execution of the machine,
>>>
>>> You are just stuck in your idea that Lies are sometimes ok.
>>
>> You are stuck on the idea that repeating states cannot
>> be recognized in a finite number of steps.
>
> No, ACTUAL REPEATING states can be recognised, but I guess you are too
> stupid to understand my description of it.
>
>>
>> void Infinite_Loop()
>> {
>> HERE: goto HERE;
>> }
>>
>> void Infinite_Recursion()
>> {
>> Infinite_Recursion();
>> }
>>
>> void DDD()
>> {
>> H0(DDD);
>> }
>>
>> Every C programmer that knows what an x86 emulator is knows
>> that when H0 emulates the machine language of Infinite_Loop,
>> Infinite_Recursion, and DDD that it must abort these emulations
>> so that itself can terminate normally.
>
> Which doesn't mean the program DDD needs to be abort to have it halt.
>
The verified that that it does need to be aborted contradicts
your nonsense to the contrary.
> That is just a figment of your imagination that doesn't understand the
> difference between truth and lies.
>
>>
>> This was recently confirmed in the C group.
>>
>
> Yes, by Bonita, whose confirmation is, if anything a mark against the
> statement.
Are you sure that you are not a liar?
I have had numerous experts in C confirm this.
Bonita confirmed this: "Everything correct"
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | joes <noreply@example.com> |
|---|---|
| Date | 2024-06-19 09:08 +0000 |
| Subject | Re: Simulating termination analyzers by dummies --- What does halting mean? |
| Message-ID | <v4u76n$ec9m$3@i2pn2.org> |
| In reply to | #107411 |
Am Tue, 18 Jun 2024 21:51:56 -0500 schrieb olcott: > On 6/18/2024 9:41 PM, Richard Damon wrote: >> On 6/18/24 10:30 PM, olcott wrote: >>> On 6/18/2024 9:16 PM, Richard Damon wrote: >>>> On 6/18/24 1:25 PM, olcott wrote: >>>>> On 6/18/2024 12:06 PM, joes wrote: >>> When such a UTM has been adapted to only simulate the first ten states >>> of its input TMD, then every simulated TMD with more than ten states >>> did not terminate normally. >> Terminating is a property of the actual machine, and not a simulation >> of it. This. > Thus according to your faulty reasoning when the source-code of a C > program is simulated by interpreter this is mere nonsense gibberish > having nothing to do what the behavior that this source-code specifies. YOUR partial decider makes everything halt, even that which doesn't. So yes, it can't simulate infinite loops. >> You could say the SIMULATION didn't terminate normally, but you can't >> say the machine didn't or even the Turing Machine Description, as you >> could give that exact same TMD to a real UTM and find out the actual >> behaviof or the input. > Sure you can otherwise interpreters of source-code would be a bogus > concept. When I write an infinite loop, I want it to be interpreted as an infinite loop. Your H0 is bogus. >> You just have lost track of the defintions of what is REALITY (the >> actual behavior of the machine) and what is just imagination. > Not I but you. The map is not the territory. The simulation is not the machine. >>> Every C programmer that knows what an x86 emulator is knows that when >>> H0 emulates the machine language of Infinite_Loop, Infinite_Recursion, >>> and DDD that it must abort these emulations so that itself can >>> terminate normally. >> Which doesn't mean the program DDD needs to be abort to have it halt. > The verified that that it does need to be aborted contradicts your > nonsense to the contrary. [The verification that it ... ?] If H0 halts, so does DDD (which only calls it). -- joes
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-19 08:31 -0500 |
| Subject | Re: Simulating termination analyzers by dummies --- What does halting mean? |
| Message-ID | <v4umjc$1vpm0$6@dont-email.me> |
| In reply to | #107419 |
On 6/19/2024 4:08 AM, joes wrote:
> Am Tue, 18 Jun 2024 21:51:56 -0500 schrieb olcott:
>> On 6/18/2024 9:41 PM, Richard Damon wrote:
>>> On 6/18/24 10:30 PM, olcott wrote:
>>>> On 6/18/2024 9:16 PM, Richard Damon wrote:
>>>>> On 6/18/24 1:25 PM, olcott wrote:
>>>>>> On 6/18/2024 12:06 PM, joes wrote:
>
>>>> When such a UTM has been adapted to only simulate the first ten states
>>>> of its input TMD, then every simulated TMD with more than ten states
>>>> did not terminate normally.
>
>>> Terminating is a property of the actual machine, and not a simulation
>>> of it.
> This.
>> Thus according to your faulty reasoning when the source-code of a C
>> program is simulated by interpreter this is mere nonsense gibberish
>> having nothing to do what the behavior that this source-code specifies.
> YOUR partial decider makes everything halt, even that which doesn't.
> So yes, it can't simulate infinite loops.
>
My partial decider makes everything stop running this is not
at all the same as halting. Novices get very confused about this.
>>> You could say the SIMULATION didn't terminate normally, but you can't
>>> say the machine didn't or even the Turing Machine Description, as you
>>> could give that exact same TMD to a real UTM and find out the actual
>>> behaviof or the input.
>> Sure you can otherwise interpreters of source-code would be a bogus
>> concept.
> When I write an infinite loop, I want it to be interpreted as an
> infinite loop. Your H0 is bogus.
>
void Infinite_Loop()
{
HERE: goto HERE;
}
int main()
{
Output("Input_Halts = ", H0(Infinite_Loop));
}
_Infinite_Loop()
[00002092] 55 push ebp
[00002093] 8bec mov ebp,esp
[00002095] ebfe jmp 00002095
[00002097] 5d pop ebp
[00002098] c3 ret
Size in bytes:(0007) [00002098]
H0: Begin Simulation Execution Trace Stored at:11376f
Address_of_H0:1aa2
[00002092][0011375f][00113763] 55 push ebp
[00002093][0011375f][00113763] 8bec mov ebp,esp
[00002095][0011375f][00113763] ebfe jmp 00002095
[00002095][0011375f][00113763] ebfe jmp 00002095
H0: Infinite Loop Detected Simulation Stopped
>>> You just have lost track of the defintions of what is REALITY (the
>>> actual behavior of the machine) and what is just imagination.
>> Not I but you.
> The map is not the territory. The simulation is not the machine.
>
(a) If the correct simulation of the x86 machine language of
the function does not prove the actual behavior that this
finite string specifies then source-code interpreters
are a bogus concept.
(b) source-code interpreters are NOT a bogus concept.
>>>> Every C programmer that knows what an x86 emulator is knows that when
>>>> H0 emulates the machine language of Infinite_Loop, Infinite_Recursion,
>>>> and DDD that it must abort these emulations so that itself can
>>>> terminate normally.
>>> Which doesn't mean the program DDD needs to be abort to have it halt.
>> The verified that that it does need to be aborted contradicts your
>> nonsense to the contrary.
> [The verification that it ... ?]
> If H0 halts, so does DDD (which only calls it).
>
My partial decider makes everything stop running this is not
at all the same as halting. Novices get very confused about this.
--
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 6 of 9 — ← Prev page 1 2 3 4 5 [6] 7 8 9 Next page →
Back to top | Article view | comp.theory
csiph-web