Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.theory > #108003 > unrolled thread
| Started by | olcott <polcott333@gmail.com> |
|---|---|
| First post | 2024-06-29 11:09 -0500 |
| Last post | 2024-07-01 08:31 -0500 |
| Articles | 20 on this page of 129 — 5 participants |
Back to article view | Back to comp.theory
People are still trying to get away with disagreeing with the semantics of the x86 language olcott <polcott333@gmail.com> - 2024-06-29 11:09 -0500
Re: People are still trying to get away with disagreeing with the semantics of the x86 language Richard Damon <richard@damon-family.org> - 2024-06-29 12:45 -0400
Re: People are still trying to get away with disagreeing with the semantics of the x86 language olcott <polcott333@gmail.com> - 2024-06-29 12:17 -0500
Re: People are still trying to get away with disagreeing with the semantics of the x86 language Richard Damon <richard@damon-family.org> - 2024-06-29 13:59 -0400
Re: People are still trying to get away with disagreeing with the semantics of the x86 language olcott <polcott333@gmail.com> - 2024-06-29 13:06 -0500
Re: People are still trying to get away with disagreeing with the semantics of the x86 language Richard Damon <richard@damon-family.org> - 2024-06-29 14:38 -0400
Re: People are still trying to get away with disagreeing with the semantics of the x86 language olcott <polcott333@gmail.com> - 2024-06-29 13:47 -0500
Re: People are still trying to get away with disagreeing with the semantics of the x86 language Richard Damon <richard@damon-family.org> - 2024-06-29 15:08 -0400
Re: People are still trying to get away with disagreeing with the semantics of the x86 language olcott <polcott333@gmail.com> - 2024-06-29 14:25 -0500
Re: People are still trying to get away with disagreeing with the semantics of the x86 language Richard Damon <richard@damon-family.org> - 2024-06-29 16:10 -0400
Re: People are still trying to get away with disagreeing with the semantics of the x86 language olcott <polcott333@gmail.com> - 2024-06-29 15:17 -0500
Re: People are still trying to get away with disagreeing with the semantics of the x86 language Richard Damon <richard@damon-family.org> - 2024-06-29 16:25 -0400
Re: People are still trying to get away with disagreeing with the semantics of the x86 language olcott <polcott333@gmail.com> - 2024-06-29 15:33 -0500
Re: People are still trying to get away with disagreeing with the semantics of the x86 language Richard Damon <richard@damon-family.org> - 2024-06-29 17:19 -0400
Re: People are still trying to get away with disagreeing with the semantics of the x86 language olcott <polcott333@gmail.com> - 2024-06-29 17:54 -0500
Re: People are still trying to get away with disagreeing with the semantics of the x86 language Richard Damon <richard@damon-family.org> - 2024-06-29 19:46 -0400
Re: People are still trying to get away with disagreeing with the semantics of the x86 language olcott <polcott333@gmail.com> - 2024-06-29 21:46 -0500
Re: People are still trying to get away with disagreeing with the semantics of the x86 language Mikko <mikko.levanto@iki.fi> - 2024-06-30 12:02 +0300
Re: People are still trying to get away with disagreeing with the semantics of the x86 language Richard Damon <richard@damon-family.org> - 2024-06-30 08:34 -0400
Re: People are still trying to get away with disagreeing with the semantics of the x86 language olcott <polcott333@gmail.com> - 2024-06-30 09:07 -0500
Re: People are still trying to get away with disagreeing with the semantics of the x86 language Richard Damon <richard@damon-family.org> - 2024-06-30 15:31 -0400
Re: People are still trying to get away with disagreeing with the semantics of the x86 language olcott <polcott333@gmail.com> - 2024-06-30 16:37 -0500
Re: People are still trying to get away with disagreeing with the semantics of the x86 language Richard Damon <richard@damon-family.org> - 2024-06-30 17:55 -0400
Re: People are still trying to get away with disagreeing with the semantics of the x86 language Mikko <mikko.levanto@iki.fi> - 2024-06-30 11:50 +0300
Re: People are still trying to get away with disagreeing with the semantics of the x86 language Mikko <mikko.levanto@iki.fi> - 2024-06-30 11:42 +0300
Re: People are still trying to get away with disagreeing with the semantics of the x86 language olcott <polcott333@gmail.com> - 2024-06-30 12:18 -0500
Re: People are still trying to get away with disagreeing with the semantics of the x86 language Richard Damon <richard@damon-family.org> - 2024-06-30 15:31 -0400
Re: People are still trying to get away with disagreeing with the semantics of the x86 language olcott <polcott333@gmail.com> - 2024-06-30 16:41 -0500
Re: People are still trying to get away with disagreeing with the semantics of the x86 language Richard Damon <richard@damon-family.org> - 2024-06-30 17:54 -0400
Re: People are still trying to get away with disagreeing with the semantics of the x86 language Richard Damon <richard@damon-family.org> - 2024-06-30 17:55 -0400
Re: People are still trying to get away with disagreeing with the semantics of the x86 language olcott <polcott333@gmail.com> - 2024-06-30 16:48 -0500
Re: People are still trying to get away with disagreeing with the semantics of the x86 language Richard Damon <richard@damon-family.org> - 2024-06-30 17:57 -0400
Re: People are still trying to get away with disagreeing with the semantics of the x86 language olcott <polcott333@gmail.com> - 2024-06-30 17:41 -0500
Re: People are still trying to get away with disagreeing with the semantics of the x86 language Richard Damon <richard@damon-family.org> - 2024-06-30 19:14 -0400
Re: People are still trying to get away with disagreeing with the semantics of the x86 language olcott <polcott333@gmail.com> - 2024-06-30 18:18 -0500
Re: People are still trying to get away with disagreeing with the semantics of the x86 language Richard Damon <richard@damon-family.org> - 2024-06-30 19:53 -0400
Re: People are still trying to get away with disagreeing with the semantics of the x86 language olcott <polcott333@gmail.com> - 2024-06-30 19:00 -0500
Re: People are still trying to get away with disagreeing with the semantics of the x86 language Richard Damon <richard@damon-family.org> - 2024-06-30 20:13 -0400
Re: People are still trying to get away with disagreeing with the semantics of the x86 language olcott <polcott333@gmail.com> - 2024-06-30 19:27 -0500
Re: People are still trying to get away with disagreeing with the semantics of the x86 language Richard Damon <richard@damon-family.org> - 2024-06-30 20:44 -0400
Re: People are still trying to get away with disagreeing with the semantics of the x86 language olcott <polcott333@gmail.com> - 2024-06-30 20:03 -0500
Re: People are still trying to get away with disagreeing with the semantics of the x86 language Richard Damon <richard@damon-family.org> - 2024-06-30 21:24 -0400
Re: People are still trying to get away with disagreeing with the semantics of the x86 language olcott <polcott333@gmail.com> - 2024-06-30 20:38 -0500
Re: People are still trying to get away with disagreeing with the semantics of the x86 language Richard Damon <richard@damon-family.org> - 2024-06-30 22:16 -0400
Re: People are still trying to get away with disagreeing with the semantics of the x86 language olcott <polcott333@gmail.com> - 2024-06-30 21:27 -0500
Re: People are still trying to get away with disagreeing with the semantics of the x86 language Richard Damon <richard@damon-family.org> - 2024-07-01 07:08 -0400
Re: People are still trying to get away with disagreeing with the semantics of the x86 language olcott <polcott333@gmail.com> - 2024-07-01 07:49 -0500
Re: olcott is still disagreeing with the semantics of simulation joes <noreply@example.org> - 2024-07-01 15:57 +0000
Re: olcott is still disagreeing with the semantics of simulation olcott <polcott333@gmail.com> - 2024-07-01 11:03 -0500
Re: olcott is still disagreeing with the semantics of simulation Richard Damon <richard@damon-family.org> - 2024-07-01 20:38 -0400
Re: olcott is still disagreeing with the semantics of simulation olcott <polcott333@gmail.com> - 2024-07-01 20:41 -0500
Re: olcott is still disagreeing with the semantics of simulation Richard Damon <richard@damon-family.org> - 2024-07-01 21:54 -0400
Re: olcott is still disagreeing with the semantics of simulation olcott <polcott333@gmail.com> - 2024-07-01 21:18 -0500
Re: olcott is still disagreeing with the semantics of simulation Richard Damon <richard@damon-family.org> - 2024-07-01 22:38 -0400
Re: People are still trying to get away with disagreeing with the semantics of the x86 language Richard Damon <richard@damon-family.org> - 2024-07-01 20:38 -0400
Re: People are still trying to get away with disagreeing with the semantics of the x86 language olcott <polcott333@gmail.com> - 2024-07-01 20:32 -0500
Re: People are still trying to get away with disagreeing with the semantics of the x86 language Richard Damon <richard@damon-family.org> - 2024-07-01 21:58 -0400
Re: People are still trying to get away with disagreeing with the semantics of the x86 language joes <noreply@example.org> - 2024-07-03 14:25 +0000
Re: People are still trying to get away with disagreeing with the semantics of the x86 language Richard Damon <richard@damon-family.org> - 2024-07-01 20:38 -0400
Re: People are still trying to get away with disagreeing with the semantics of the x86 language olcott <polcott333@gmail.com> - 2024-07-01 20:42 -0500
Re: People are still trying to get away with disagreeing with the semantics of the x86 language Richard Damon <richard@damon-family.org> - 2024-07-01 22:00 -0400
Re: People are still trying to get away with disagreeing with the semantics of the x86 language olcott <polcott333@gmail.com> - 2024-07-01 21:21 -0500
Re: People are still trying to get away with disagreeing with the semantics of the x86 language Richard Damon <richard@damon-family.org> - 2024-07-01 22:40 -0400
Re: People are still trying to get away with disagreeing with the semantics of the x86 language joes <noreply@example.org> - 2024-07-03 14:23 +0000
Re: People are still trying to get away with disagreeing with the semantics of the x86 language Mikko <mikko.levanto@iki.fi> - 2024-07-02 09:13 +0300
Re: People are still trying to get away with disagreeing with the semantics of the x86 language olcott <polcott333@gmail.com> - 2024-06-30 22:25 -0500
Re: People are still trying to get away with disagreeing with the semantics of the x86 language Richard Damon <richard@damon-family.org> - 2024-07-01 07:08 -0400
Re: People are still trying to get away with disagreeing with the semantics of the x86 language olcott <polcott333@gmail.com> - 2024-07-01 07:53 -0500
Re: People are still trying to get away with disagreeing with the semantics of the x86 language Richard Damon <richard@damon-family.org> - 2024-07-01 20:38 -0400
Re: People are still trying to get away with disagreeing with the semantics of the x86 language joes <noreply@example.org> - 2024-07-04 11:05 +0000
Re: People are still trying to get away with disagreeing with the semantics of the x86 language olcott <polcott333@gmail.com> - 2024-07-04 07:51 -0500
Re: People are still trying to get away with disagreeing with the semantics of the x86 language Richard Damon <richard@damon-family.org> - 2024-07-04 11:25 -0400
Re: People are still trying to get away with disagreeing with the semantics of the x86 language --- repeat until acknowledged olcott <polcott333@gmail.com> - 2024-06-30 17:00 -0500
Re: People are still trying to get away with disagreeing with the semantics of the x86 language --- repeat until acknowledged Richard Damon <richard@damon-family.org> - 2024-06-30 18:04 -0400
Re: People are still trying to get away with disagreeing with the semantics of the x86 language --- repeat until acknowledged olcott <polcott333@gmail.com> - 2024-06-30 17:48 -0500
Re: People are still trying to get away with disagreeing with the semantics of the x86 language --- repeat until acknowledged Richard Damon <richard@damon-family.org> - 2024-06-30 19:13 -0400
Re: People are still trying to get away with disagreeing with the semantics of the x86 language Mikko <mikko.levanto@iki.fi> - 2024-07-01 09:05 +0300
Re: People are still trying to get away with disagreeing with the semantics of the x86 language olcott <polcott333@gmail.com> - 2024-07-01 07:44 -0500
Re: People are still trying to get away with disagreeing with the semantics of the x86 language joes <noreply@example.org> - 2024-07-01 16:01 +0000
Re: People are still trying to get away with disagreeing with the semantics of the x86 language olcott <polcott333@gmail.com> - 2024-07-01 11:12 -0500
Re: People are still trying to get away with disagreeing with the semantics of the x86 language Richard Damon <richard@damon-family.org> - 2024-07-01 20:38 -0400
Re: People are still trying to get away with disagreeing with the semantics of the x86 language Mikko <mikko.levanto@iki.fi> - 2024-07-02 09:59 +0300
Re: People are still trying to get away with disagreeing with the semantics of the x86 language olcott <polcott333@gmail.com> - 2024-07-02 13:43 -0500
Re: People are still trying to get away with disagreeing with the semantics of the x86 language "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-07-02 21:22 +0200
Re: People are still trying to get away with disagreeing with the semantics of the x86 language olcott <polcott333@gmail.com> - 2024-07-02 14:48 -0500
Re: People are still trying to get away with disagreeing with the semantics of the x86 language "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-07-03 10:26 +0200
Re: People are still trying to get away with disagreeing with the semantics of the x86 language olcott <polcott333@gmail.com> - 2024-07-03 08:21 -0500
Re: People are still trying to get away with disagreeing with the semantics of the x86 language joes <noreply@example.org> - 2024-07-03 14:39 +0000
Re: People are still trying to get away with disagreeing with the semantics of the x86 language olcott <polcott333@gmail.com> - 2024-07-03 09:45 -0500
Re: People are still trying to get away with disagreeing with the semantics of the x86 language joes <noreply@example.org> - 2024-07-04 10:15 +0000
Re: People are still trying to get away with disagreeing with the semantics of the x86 language olcott <polcott333@gmail.com> - 2024-07-04 07:46 -0500
Re: People are still trying to get away with disagreeing with the semantics of the x86 language joes <noreply@example.org> - 2024-07-04 13:26 +0000
Re: People are still trying to get away with disagreeing with the semantics of the x86 language olcott <polcott333@gmail.com> - 2024-07-04 08:41 -0500
Re: People are still trying to get away with disagreeing with the semantics of the x86 language joes <noreply@example.org> - 2024-07-04 15:06 +0000
Re: People are still trying to get away with disagreeing with the semantics of the x86 language olcott <polcott333@gmail.com> - 2024-07-04 11:03 -0500
Re: People are still trying to get away with disagreeing with the semantics of the x86 language joes <noreply@example.org> - 2024-07-04 16:26 +0000
Re: People are still trying to get away with disagreeing with the semantics of the x86 language olcott <polcott333@gmail.com> - 2024-07-04 11:31 -0500
Re: People are still trying to get away with disagreeing with the semantics of the x86 language joes <noreply@example.org> - 2024-07-04 16:35 +0000
Re: People are still trying to get away with disagreeing with the semantics of the x86 language Richard Damon <richard@damon-family.org> - 2024-07-04 12:52 -0400
Re: People are still trying to get away with disagreeing with the semantics of the x86 language Richard Damon <richard@damon-family.org> - 2024-07-04 11:25 -0400
Re: People are still trying to get away with disagreeing with the semantics of the x86 language Richard Damon <richard@damon-family.org> - 2024-07-04 11:25 -0400
Re: People are still trying to get away with disagreeing with the semantics of the x86 language "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-07-03 17:59 +0200
Re: People are still trying to get away with disagreeing with the semantics of the x86 language olcott <polcott333@gmail.com> - 2024-07-03 11:03 -0500
Re: People are still trying to get away with disagreeing with the semantics of the x86 language "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-07-03 19:51 +0200
Re: People are still trying to get away with disagreeing with the semantics of the x86 language olcott <polcott333@gmail.com> - 2024-07-03 12:58 -0500
Re: People are still trying to get away with disagreeing with the semantics of the x86 language "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-07-03 20:25 +0200
Re: People are still trying to get away with disagreeing with the semantics of the x86 language olcott <polcott333@gmail.com> - 2024-07-03 13:37 -0500
Re: People are still trying to get away with disagreeing with the semantics of the x86 language "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-07-03 20:46 +0200
Re: People are still trying to get away with disagreeing with the semantics of the x86 language olcott <polcott333@gmail.com> - 2024-07-03 13:59 -0500
Re: People are still trying to get away with disagreeing with the semantics of the x86 language "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-07-03 21:15 +0200
Re: People are still trying to get away with disagreeing with the semantics of the x86 language olcott <polcott333@gmail.com> - 2024-07-03 14:23 -0500
Re: People are still trying to get away with disagreeing with the semantics of the x86 language "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-07-03 21:31 +0200
DDD correctly emulated by any pure function HHH that can possibly exist DOES NOT HALT olcott <polcott333@gmail.com> - 2024-07-03 15:08 -0500
Re: DDD correctly emulated by any pure function HHH that can possibly exist DOES NOT HALT "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-07-03 22:59 +0200
Re: DDD correctly emulated by any pure function HHH that can possibly exist DOES NOT HALT olcott <polcott333@gmail.com> - 2024-07-03 16:04 -0500
Re: DDD correctly emulated by any pure function HHH that can possibly exist DOES NOT HALT "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-07-04 09:35 +0200
Re: People are still trying to get away with disagreeing with the semantics of the x86 language joes <noreply@example.org> - 2024-07-04 10:23 +0000
Re: People are still trying to get away with disagreeing with the semantics of the x86 language Richard Damon <richard@damon-family.org> - 2024-07-02 18:44 -0400
Re: People are still trying to get away with disagreeing with the semantics of the x86 language Mikko <mikko.levanto@iki.fi> - 2024-07-03 09:41 +0300
Re: People are still trying to get away with disagreeing with the semantics of the x86 language olcott <polcott333@gmail.com> - 2024-07-03 08:17 -0500
Re: People are still trying to get away with disagreeing with the semantics of the x86 language Mikko <mikko.levanto@iki.fi> - 2024-07-04 08:57 +0300
Re: People are still trying to get away with disagreeing with the semantics of the x86 language "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-07-01 10:32 +0200
Re: People are still trying to get away with disagreeing with the semantics of the x86 language olcott <polcott333@gmail.com> - 2024-07-01 07:46 -0500
Re: People are still trying to get away with disagreeing with the semantics of the x86 language "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-07-01 16:37 +0200
Re: People are still trying to get away with disagreeing with the semantics of the x86 language olcott <polcott333@gmail.com> - 2024-07-01 09:50 -0500
Re: People are still trying to get away with disagreeing with the semantics of the x86 language olcott <polcott333@gmail.com> - 2024-07-01 10:20 -0500
Re: People are still trying to get away with disagreeing with the semantics of the x86 language "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-07-01 20:22 +0200
Re: People are still trying to get away with disagreeing with the semantics of the x86 language "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-07-01 10:46 +0200
Re: People are still trying to get away with disagreeing with the semantics of the x86 language olcott <polcott333@gmail.com> - 2024-07-01 08:31 -0500
Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-30 15:31 -0400 |
| Message-ID | <v5sbpp$1kfbr$1@i2pn2.org> |
| In reply to | #108036 |
On 6/30/24 10:07 AM, olcott wrote: > On 6/30/2024 7:34 AM, Richard Damon wrote: >> On 6/29/24 10:46 PM, olcott wrote: >>> On 6/29/2024 6:46 PM, Richard Damon wrote: >>>> On 6/29/24 6:54 PM, olcott wrote: >>>>> On 6/29/2024 4:19 PM, Richard Damon wrote: >>>>>> On 6/29/24 4:33 PM, olcott wrote: >>>>>>> On 6/29/2024 3:25 PM, Richard Damon wrote: >>>>>>>> On 6/29/24 4:17 PM, olcott wrote: >>>>>>>>> On 6/29/2024 3:10 PM, Richard Damon wrote: >>>>>>>>>> On 6/29/24 3:25 PM, olcott wrote: >>>>>>>>>>> On 6/29/2024 2:08 PM, Richard Damon wrote: >>>>>>>>>>>> On 6/29/24 2:47 PM, olcott wrote: >>>>>>>>>>>>> On 6/29/2024 1:38 PM, Richard Damon wrote: >>>>>>>>>>>>>> On 6/29/24 2:06 PM, olcott wrote: >>>>>>>>>>> >>>>>>>>>>> <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> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> But that only applies if H determines a CORRECT SIMULATION per >>>>>>>>>> HIS definition does not halt >>>>>>>>>> . >>>>>>>>>> That means the DIRECT EXECUTION of the program represented by >>>>>>>>>> the input does not halt, since that is the DEFINITION of the >>>>>>>>>> results of a correct simuation. >>>>>>>>>> >>>>>>>>>> That also requires that the simulation does not stop until it >>>>>>>>>> reaches a final state. You H neither does that nor correctly >>>>>>>>>> determines that (since it does halt) thus you can never use >>>>>>>>>> the second paragraph to be allowed to abort, even though you >>>>>>>>>> do anyway, which is why you get the wrong answer. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *N steps of correct simulation are specified* >>>>>>>>>>>>>>> H correctly simulates its input D until H >>>>>>>>>>>>>>> H correctly simulates its input D until H >>>>>>>>>>>>>>> H correctly simulates its input D until H >>>>>>>>>>>>>>> H correctly simulates its input D until H >>>>>>>>>>>>>> >>>>>>>>>>>>>> Which does not determine the ACTUAL behavor >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> _DDD() >>>>>>>>>>>>> [00002172] 55 push ebp ; housekeeping >>>>>>>>>>>>> [00002173] 8bec mov ebp,esp ; housekeeping >>>>>>>>>>>>> [00002175] 6872210000 push 00002172 ; push DDD >>>>>>>>>>>>> [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD) >>>>>>>>>>>>> [0000217f] 83c404 add esp,+04 >>>>>>>>>>>>> [00002182] 5d pop ebp >>>>>>>>>>>>> [00002183] c3 ret >>>>>>>>>>>>> Size in bytes:(0018) [00002183] >>>>>>>>>>>>> >>>>>>>>>>>>> That you already know that it does prove that DDD correctly >>>>>>>>>>>>> emulated by HHH would never stop running unless aborted >>>>>>>>>>>>> or out-of-memory error >>>>>>>>>>>>> >>>>>>>>>>>>> *proves that you are trying to get away with a bald-faced lie* >>>>>>>>>>>>> I really hope that you repent before it is too late. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Nope, just shows your stupidity, as the above code has NO >>>>>>>>>>>> defined behavior as it accesses code that is not defined by it. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> *Its behavior is completely defined by* >>>>>>>>>>> (a) The finite string x86 machine code that includes >>>>>>>>>>> the recursive emulation call from DDD to HHH(DDD). >>>>>>>>>> >>>>>>>>>> But by the semantics of the x86 langugage, the call to HHH >>>>>>>>>> does NOT do a "recursive simulation" since that is not a term >>>>>>>>>> in that language. >>>>>>>>>> >>>>>>>>>> The Call to HHH just cause the >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> (b) The semantics of the x86 language. >>>>>>>>>>> >>>>>>>>>>> (c) That HHH is an x86 emulator that correctly emulates >>>>>>>>>>> N steps of DDD. >>>>>>>>>> >>>>>>>>>> Which isn't an ACTUALY correct emulation, but only a PARTIAL >>>>>>>>>> correct emulation (since correct emulation implies EVERY >>>>>>>>>> instruction but a terminal one is followed by the next >>>>>>>>>> instruction). >>>>>>>>>> >>>>>>>>>> The key fact is that PARTIAL emulation doesn't reveal the >>>>>>>>>> future of the behavior past the point of the emulation. >>>>>>>>> >>>>>>>>> In other words you are trying to get away with claiming >>>>>>>>> that professor Sipser made a stupid mistake: >>>>>>>>> >>>>>>>>> H correctly simulates its input D until H correctly determines >>>>>>>>> that its simulated D would never stop running unless aborted >>>>>>>> >>>>>>>> Nope, he just laid a trap that you fell into. >>>>>>>> >>>>>>> >>>>>>> He could not have possibly laid any trap you dumb bunny. >>>>>>> All of the words were my own verbatim words. It took me >>>>>>> two years to compose those exact words. >>>>>>> >>>>>> >>>>>> Right, and he could have seen the errors in your apparent >>>>>> misunderstanding of the words and accepted them, knowing that they >>>>>> were actually meaningless. >>>>>> >>>>>>>> The ONLY simulation that Professor Sipser accepts as correct, is >>>>>>>> one that shows EXACTLY the behavior of the machine being simulated. >>>>>>>> >>>>>>> >>>>>>> So you are stupid enough to believe that professor Sipser >>>>>>> is stupid enough to to try and get away with disagreeing >>>>>>> with the semantics of the x86 language? >>>>>> >>>>>> The question said NOTHING of the x86 language, so it doesn't matter. >>>>>> >>>>> >>>>> Liar Liar pants on fire !!! >>>>> Liar Liar pants on fire !!! >>>>> Liar Liar pants on fire !!! >>>>> Liar Liar pants on fire !!! >>>>> Liar Liar pants on fire !!! >>>> >>>> But the question to Professor Sipser was, as you quoted: >>>> >>>> <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> >>>> >>>> >>>> Which said NOTHING about the x86 language, >>>> >>>> So, who is the liar now? >>>> >>>>> >>>>> _DDD() >>>>> [00002172] 55 push ebp ; housekeeping >>>>> [00002173] 8bec mov ebp,esp ; housekeeping >>>>> [00002175] 6872210000 push 00002172 ; push DDD >>>>> [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD) >>>>> [0000217f] 83c404 add esp,+04 >>>>> [00002182] 5d pop ebp >>>>> [00002183] c3 ret >>>>> Size in bytes:(0018) [00002183] >>>>> >>>>> The call from DDD to HHH(DDD) when N steps of DDD are correctly >>>>> emulated by any pure function x86 emulator HHH cannot possibly >>>>> return. >>>>> >>>> >>>> Which wasn't what we were talking about with Professor Sipser, who >>>> never saw any of that. >>>> >>>> I guess you just have a major brain malfunction and can't keep your >>>> lies straight. >>>> >>>> This just proves your unreliability when it comes to statements >>> >>> Partial halt deciders constructed for the x86 language >>> are isomorphic to this termination analyzer build for >>> the C programming language. >> >> Which still has nothing to do with you LYING about your question to >> Professor Sipser. >> >> And x86 is not fully isomorphic to the C programming language. >> >> The x86 language is probably easier to simulate but harder to decide >> on, because it can create more complicated interactions. >> >> Note, there isn't a trivial translation between x86 and C (or LLVM). C >> to LLVM to x86 is algorithmically doable, but with a lot of options at >> each step. And when doing the reverse, you normally don't get anything >> like the original code you started with. >> >> And then we get to the fact that "Halt Deciding" and "Termination >> Analying" are DIFFERENT problems, Halt Deciding being if a particular >> Program/Input will halt when it is run, while Termination Analysers >> answer if there is ANY input that might make a given machine not Halt. >> A much different problem (which you clearly don't understand). >> >>> >>> *AProVE: Non-Termination Witnesses for C Programs* >>> To prove (non-)termination of a C program, AProVE uses the >>> Clang compiler [7] to translate it to the intermediate >>> representation of the LLVM framework [15]. Then AProVE >>> symbolically executes the LLVM program and uses abstraction >>> to obtain a finite symbolic execution graph (SEG) containing >>> all possible program runs. >>> https://link.springer.com/content/pdf/10.1007/978-3-030-99527-0_21.pdf >> >> Which isn't based on "Pure Emulation" like your deciders are. There is >> a lot of pre-work done to determine what parts might need to be >> emulated. Note, since "Termination Analyzers" don't have an input to >> the program, the "emulation" they do needs to be different, but >> looking at the mapping of possible states to possible states. >> >>> >>> Even a Turing machine based partial halt decider is >>> locked in to the Turing Machine description language. >>> Is this really over your head? >>> >> >> But there isn't a single Turing Machine Description Language that all >> UTMs use. >> >> Also, the Theory isn't about "Partial" Halt Deciders, as those are >> numerous, but about Correct Halt Decider (implied Complete, i.e. >> handles ALL inputs), so switching to partial decider is just a >> deceitful dodge. >> >> It is still true that the xemantics of the x86 language define the >> behavior of a set of bytes, as the behavior when you ACTUALLY RUN >> THEM, and nothing else. >> > > That stupid idea forces "interpreting" the call to HHH(DDD) > from DDD simulated by HHH to disagree with the x86 language > and return when the x86 language says this is impossible. Why do you say that? By the x86 language, HHH is just a series of instructions to do something. And without the bytes specified, we don't know what they do. There is no way to try to specify AT THE x86 instruction level, that HHH is an "emulator" as that isn't a concept at the x86 instruction level. Also, it is a LIE to say HHH is a "x86 Emulator", as that term, unadorned, means it is an UNCONDITIONAL emulator (like a UTM) which is isn't since you define that it has the power to decide that its input is non-halting (and might do it incorrectly) and thus its emulation at each step is conditional on that logic. > > _DDD() > [00002172] 55 push ebp ; housekeeping > [00002173] 8bec mov ebp,esp ; housekeeping > [00002175] 6872210000 push 00002172 ; push DDD > [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD) > [0000217f] 83c404 add esp,+04 > [00002182] 5d pop ebp > [00002183] c3 ret > Size in bytes:(0018) [00002183] > >> And that means, you need the code for the COMPLETE program (or >> sub-program) to talk about behavior, which includes the code for >> everything that one piece of code calls, so for your D family of >> inputs, the H family of deciders that it has been paired with. >
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-30 16:37 -0500 |
| Message-ID | <v5sj6q$mpem$1@dont-email.me> |
| In reply to | #108040 |
On 6/30/2024 2:31 PM, Richard Damon wrote: > On 6/30/24 10:07 AM, olcott wrote: >> On 6/30/2024 7:34 AM, Richard Damon wrote: >>> On 6/29/24 10:46 PM, olcott wrote: >>>> On 6/29/2024 6:46 PM, Richard Damon wrote: >>>>> On 6/29/24 6:54 PM, olcott wrote: >>>>>> On 6/29/2024 4:19 PM, Richard Damon wrote: >>>>>>> On 6/29/24 4:33 PM, olcott wrote: >>>>>>>> On 6/29/2024 3:25 PM, Richard Damon wrote: >>>>>>>>> On 6/29/24 4:17 PM, olcott wrote: >>>>>>>>>> On 6/29/2024 3:10 PM, Richard Damon wrote: >>>>>>>>>>> On 6/29/24 3:25 PM, olcott wrote: >>>>>>>>>>>> On 6/29/2024 2:08 PM, Richard Damon wrote: >>>>>>>>>>>>> On 6/29/24 2:47 PM, olcott wrote: >>>>>>>>>>>>>> On 6/29/2024 1:38 PM, Richard Damon wrote: >>>>>>>>>>>>>>> On 6/29/24 2:06 PM, olcott wrote: >>>>>>>>>>>> >>>>>>>>>>>> <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> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> But that only applies if H determines a CORRECT SIMULATION >>>>>>>>>>> per HIS definition does not halt >>>>>>>>>>> . >>>>>>>>>>> That means the DIRECT EXECUTION of the program represented by >>>>>>>>>>> the input does not halt, since that is the DEFINITION of the >>>>>>>>>>> results of a correct simuation. >>>>>>>>>>> >>>>>>>>>>> That also requires that the simulation does not stop until it >>>>>>>>>>> reaches a final state. You H neither does that nor correctly >>>>>>>>>>> determines that (since it does halt) thus you can never use >>>>>>>>>>> the second paragraph to be allowed to abort, even though you >>>>>>>>>>> do anyway, which is why you get the wrong answer. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> *N steps of correct simulation are specified* >>>>>>>>>>>>>>>> H correctly simulates its input D until H >>>>>>>>>>>>>>>> H correctly simulates its input D until H >>>>>>>>>>>>>>>> H correctly simulates its input D until H >>>>>>>>>>>>>>>> H correctly simulates its input D until H >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Which does not determine the ACTUAL behavor >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> _DDD() >>>>>>>>>>>>>> [00002172] 55 push ebp ; housekeeping >>>>>>>>>>>>>> [00002173] 8bec mov ebp,esp ; housekeeping >>>>>>>>>>>>>> [00002175] 6872210000 push 00002172 ; push DDD >>>>>>>>>>>>>> [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD) >>>>>>>>>>>>>> [0000217f] 83c404 add esp,+04 >>>>>>>>>>>>>> [00002182] 5d pop ebp >>>>>>>>>>>>>> [00002183] c3 ret >>>>>>>>>>>>>> Size in bytes:(0018) [00002183] >>>>>>>>>>>>>> >>>>>>>>>>>>>> That you already know that it does prove that DDD correctly >>>>>>>>>>>>>> emulated by HHH would never stop running unless aborted >>>>>>>>>>>>>> or out-of-memory error >>>>>>>>>>>>>> >>>>>>>>>>>>>> *proves that you are trying to get away with a bald-faced >>>>>>>>>>>>>> lie* >>>>>>>>>>>>>> I really hope that you repent before it is too late. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Nope, just shows your stupidity, as the above code has NO >>>>>>>>>>>>> defined behavior as it accesses code that is not defined by >>>>>>>>>>>>> it. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> *Its behavior is completely defined by* >>>>>>>>>>>> (a) The finite string x86 machine code that includes >>>>>>>>>>>> the recursive emulation call from DDD to HHH(DDD). >>>>>>>>>>> >>>>>>>>>>> But by the semantics of the x86 langugage, the call to HHH >>>>>>>>>>> does NOT do a "recursive simulation" since that is not a term >>>>>>>>>>> in that language. >>>>>>>>>>> >>>>>>>>>>> The Call to HHH just cause the >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> (b) The semantics of the x86 language. >>>>>>>>>>>> >>>>>>>>>>>> (c) That HHH is an x86 emulator that correctly emulates >>>>>>>>>>>> N steps of DDD. >>>>>>>>>>> >>>>>>>>>>> Which isn't an ACTUALY correct emulation, but only a PARTIAL >>>>>>>>>>> correct emulation (since correct emulation implies EVERY >>>>>>>>>>> instruction but a terminal one is followed by the next >>>>>>>>>>> instruction). >>>>>>>>>>> >>>>>>>>>>> The key fact is that PARTIAL emulation doesn't reveal the >>>>>>>>>>> future of the behavior past the point of the emulation. >>>>>>>>>> >>>>>>>>>> In other words you are trying to get away with claiming >>>>>>>>>> that professor Sipser made a stupid mistake: >>>>>>>>>> >>>>>>>>>> H correctly simulates its input D until H correctly determines >>>>>>>>>> that its simulated D would never stop running unless aborted >>>>>>>>> >>>>>>>>> Nope, he just laid a trap that you fell into. >>>>>>>>> >>>>>>>> >>>>>>>> He could not have possibly laid any trap you dumb bunny. >>>>>>>> All of the words were my own verbatim words. It took me >>>>>>>> two years to compose those exact words. >>>>>>>> >>>>>>> >>>>>>> Right, and he could have seen the errors in your apparent >>>>>>> misunderstanding of the words and accepted them, knowing that >>>>>>> they were actually meaningless. >>>>>>> >>>>>>>>> The ONLY simulation that Professor Sipser accepts as correct, >>>>>>>>> is one that shows EXACTLY the behavior of the machine being >>>>>>>>> simulated. >>>>>>>>> >>>>>>>> >>>>>>>> So you are stupid enough to believe that professor Sipser >>>>>>>> is stupid enough to to try and get away with disagreeing >>>>>>>> with the semantics of the x86 language? >>>>>>> >>>>>>> The question said NOTHING of the x86 language, so it doesn't matter. >>>>>>> >>>>>> >>>>>> Liar Liar pants on fire !!! >>>>>> Liar Liar pants on fire !!! >>>>>> Liar Liar pants on fire !!! >>>>>> Liar Liar pants on fire !!! >>>>>> Liar Liar pants on fire !!! >>>>> >>>>> But the question to Professor Sipser was, as you quoted: >>>>> >>>>> <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> >>>>> >>>>> >>>>> Which said NOTHING about the x86 language, >>>>> >>>>> So, who is the liar now? >>>>> >>>>>> >>>>>> _DDD() >>>>>> [00002172] 55 push ebp ; housekeeping >>>>>> [00002173] 8bec mov ebp,esp ; housekeeping >>>>>> [00002175] 6872210000 push 00002172 ; push DDD >>>>>> [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD) >>>>>> [0000217f] 83c404 add esp,+04 >>>>>> [00002182] 5d pop ebp >>>>>> [00002183] c3 ret >>>>>> Size in bytes:(0018) [00002183] >>>>>> >>>>>> The call from DDD to HHH(DDD) when N steps of DDD are correctly >>>>>> emulated by any pure function x86 emulator HHH cannot possibly >>>>>> return. >>>>>> >>>>> >>>>> Which wasn't what we were talking about with Professor Sipser, who >>>>> never saw any of that. >>>>> >>>>> I guess you just have a major brain malfunction and can't keep your >>>>> lies straight. >>>>> >>>>> This just proves your unreliability when it comes to statements >>>> >>>> Partial halt deciders constructed for the x86 language >>>> are isomorphic to this termination analyzer build for >>>> the C programming language. >>> >>> Which still has nothing to do with you LYING about your question to >>> Professor Sipser. >>> >>> And x86 is not fully isomorphic to the C programming language. >>> >>> The x86 language is probably easier to simulate but harder to decide >>> on, because it can create more complicated interactions. >>> >>> Note, there isn't a trivial translation between x86 and C (or LLVM). >>> C to LLVM to x86 is algorithmically doable, but with a lot of options >>> at each step. And when doing the reverse, you normally don't get >>> anything like the original code you started with. >>> >>> And then we get to the fact that "Halt Deciding" and "Termination >>> Analying" are DIFFERENT problems, Halt Deciding being if a particular >>> Program/Input will halt when it is run, while Termination Analysers >>> answer if there is ANY input that might make a given machine not >>> Halt. A much different problem (which you clearly don't understand). >>> >>>> >>>> *AProVE: Non-Termination Witnesses for C Programs* >>>> To prove (non-)termination of a C program, AProVE uses the >>>> Clang compiler [7] to translate it to the intermediate >>>> representation of the LLVM framework [15]. Then AProVE >>>> symbolically executes the LLVM program and uses abstraction >>>> to obtain a finite symbolic execution graph (SEG) containing >>>> all possible program runs. >>>> https://link.springer.com/content/pdf/10.1007/978-3-030-99527-0_21.pdf >>> >>> Which isn't based on "Pure Emulation" like your deciders are. There >>> is a lot of pre-work done to determine what parts might need to be >>> emulated. Note, since "Termination Analyzers" don't have an input to >>> the program, the "emulation" they do needs to be different, but >>> looking at the mapping of possible states to possible states. >>> >>>> >>>> Even a Turing machine based partial halt decider is >>>> locked in to the Turing Machine description language. >>>> Is this really over your head? >>>> >>> >>> But there isn't a single Turing Machine Description Language that all >>> UTMs use. >>> >>> Also, the Theory isn't about "Partial" Halt Deciders, as those are >>> numerous, but about Correct Halt Decider (implied Complete, i.e. >>> handles ALL inputs), so switching to partial decider is just a >>> deceitful dodge. >>> >>> It is still true that the xemantics of the x86 language define the >>> behavior of a set of bytes, as the behavior when you ACTUALLY RUN >>> THEM, and nothing else. >>> >> >> That stupid idea forces "interpreting" the call to HHH(DDD) >> from DDD simulated by HHH to disagree with the x86 language >> and return when the x86 language says this is impossible. > > Why do you say that? > > By the x86 language, HHH is just a series of instructions to do something. > Then what you are saying here are just words that are about something or other and no more specific than that. > And without the bytes specified, we don't know what they do. > > There is no way to try to specify AT THE x86 instruction level, that HHH > is an "emulator" as that isn't a concept at the x86 instruction level. > > Also, it is a LIE to say HHH is a "x86 Emulator", as that term, > unadorned, means it is an UNCONDITIONAL emulator (like a UTM) which is > isn't since you define that it has the power to decide that its input is > non-halting (and might do it incorrectly) and thus its emulation at each > step is conditional on that logic. > >> >> _DDD() >> [00002172] 55 push ebp ; housekeeping >> [00002173] 8bec mov ebp,esp ; housekeeping >> [00002175] 6872210000 push 00002172 ; push DDD >> [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD) >> [0000217f] 83c404 add esp,+04 >> [00002182] 5d pop ebp >> [00002183] c3 ret >> Size in bytes:(0018) [00002183] >> >>> And that means, you need the code for the COMPLETE program (or >>> sub-program) to talk about behavior, which includes the code for >>> everything that one piece of code calls, so for your D family of >>> inputs, the H family of deciders that it has been paired with. >> > -- 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-30 17:55 -0400 |
| Message-ID | <v5sk80$1kfbr$6@i2pn2.org> |
| In reply to | #108044 |
On 6/30/24 5:37 PM, olcott wrote: > On 6/30/2024 2:31 PM, Richard Damon wrote: >> On 6/30/24 10:07 AM, olcott wrote: >>> On 6/30/2024 7:34 AM, Richard Damon wrote: >>>> On 6/29/24 10:46 PM, olcott wrote: >>>>> On 6/29/2024 6:46 PM, Richard Damon wrote: >>>>>> On 6/29/24 6:54 PM, olcott wrote: >>>>>>> On 6/29/2024 4:19 PM, Richard Damon wrote: >>>>>>>> On 6/29/24 4:33 PM, olcott wrote: >>>>>>>>> On 6/29/2024 3:25 PM, Richard Damon wrote: >>>>>>>>>> On 6/29/24 4:17 PM, olcott wrote: >>>>>>>>>>> On 6/29/2024 3:10 PM, Richard Damon wrote: >>>>>>>>>>>> On 6/29/24 3:25 PM, olcott wrote: >>>>>>>>>>>>> On 6/29/2024 2:08 PM, Richard Damon wrote: >>>>>>>>>>>>>> On 6/29/24 2:47 PM, olcott wrote: >>>>>>>>>>>>>>> On 6/29/2024 1:38 PM, Richard Damon wrote: >>>>>>>>>>>>>>>> On 6/29/24 2:06 PM, olcott wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> <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> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> But that only applies if H determines a CORRECT SIMULATION >>>>>>>>>>>> per HIS definition does not halt >>>>>>>>>>>> . >>>>>>>>>>>> That means the DIRECT EXECUTION of the program represented >>>>>>>>>>>> by the input does not halt, since that is the DEFINITION of >>>>>>>>>>>> the results of a correct simuation. >>>>>>>>>>>> >>>>>>>>>>>> That also requires that the simulation does not stop until >>>>>>>>>>>> it reaches a final state. You H neither does that nor >>>>>>>>>>>> correctly determines that (since it does halt) thus you can >>>>>>>>>>>> never use the second paragraph to be allowed to abort, even >>>>>>>>>>>> though you do anyway, which is why you get the wrong answer. >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> *N steps of correct simulation are specified* >>>>>>>>>>>>>>>>> H correctly simulates its input D until H >>>>>>>>>>>>>>>>> H correctly simulates its input D until H >>>>>>>>>>>>>>>>> H correctly simulates its input D until H >>>>>>>>>>>>>>>>> H correctly simulates its input D until H >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Which does not determine the ACTUAL behavor >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> _DDD() >>>>>>>>>>>>>>> [00002172] 55 push ebp ; housekeeping >>>>>>>>>>>>>>> [00002173] 8bec mov ebp,esp ; housekeeping >>>>>>>>>>>>>>> [00002175] 6872210000 push 00002172 ; push DDD >>>>>>>>>>>>>>> [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD) >>>>>>>>>>>>>>> [0000217f] 83c404 add esp,+04 >>>>>>>>>>>>>>> [00002182] 5d pop ebp >>>>>>>>>>>>>>> [00002183] c3 ret >>>>>>>>>>>>>>> Size in bytes:(0018) [00002183] >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> That you already know that it does prove that DDD correctly >>>>>>>>>>>>>>> emulated by HHH would never stop running unless aborted >>>>>>>>>>>>>>> or out-of-memory error >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *proves that you are trying to get away with a bald-faced >>>>>>>>>>>>>>> lie* >>>>>>>>>>>>>>> I really hope that you repent before it is too late. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Nope, just shows your stupidity, as the above code has NO >>>>>>>>>>>>>> defined behavior as it accesses code that is not defined >>>>>>>>>>>>>> by it. >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> *Its behavior is completely defined by* >>>>>>>>>>>>> (a) The finite string x86 machine code that includes >>>>>>>>>>>>> the recursive emulation call from DDD to HHH(DDD). >>>>>>>>>>>> >>>>>>>>>>>> But by the semantics of the x86 langugage, the call to HHH >>>>>>>>>>>> does NOT do a "recursive simulation" since that is not a >>>>>>>>>>>> term in that language. >>>>>>>>>>>> >>>>>>>>>>>> The Call to HHH just cause the >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> (b) The semantics of the x86 language. >>>>>>>>>>>>> >>>>>>>>>>>>> (c) That HHH is an x86 emulator that correctly emulates >>>>>>>>>>>>> N steps of DDD. >>>>>>>>>>>> >>>>>>>>>>>> Which isn't an ACTUALY correct emulation, but only a PARTIAL >>>>>>>>>>>> correct emulation (since correct emulation implies EVERY >>>>>>>>>>>> instruction but a terminal one is followed by the next >>>>>>>>>>>> instruction). >>>>>>>>>>>> >>>>>>>>>>>> The key fact is that PARTIAL emulation doesn't reveal the >>>>>>>>>>>> future of the behavior past the point of the emulation. >>>>>>>>>>> >>>>>>>>>>> In other words you are trying to get away with claiming >>>>>>>>>>> that professor Sipser made a stupid mistake: >>>>>>>>>>> >>>>>>>>>>> H correctly simulates its input D until H correctly determines >>>>>>>>>>> that its simulated D would never stop running unless aborted >>>>>>>>>> >>>>>>>>>> Nope, he just laid a trap that you fell into. >>>>>>>>>> >>>>>>>>> >>>>>>>>> He could not have possibly laid any trap you dumb bunny. >>>>>>>>> All of the words were my own verbatim words. It took me >>>>>>>>> two years to compose those exact words. >>>>>>>>> >>>>>>>> >>>>>>>> Right, and he could have seen the errors in your apparent >>>>>>>> misunderstanding of the words and accepted them, knowing that >>>>>>>> they were actually meaningless. >>>>>>>> >>>>>>>>>> The ONLY simulation that Professor Sipser accepts as correct, >>>>>>>>>> is one that shows EXACTLY the behavior of the machine being >>>>>>>>>> simulated. >>>>>>>>>> >>>>>>>>> >>>>>>>>> So you are stupid enough to believe that professor Sipser >>>>>>>>> is stupid enough to to try and get away with disagreeing >>>>>>>>> with the semantics of the x86 language? >>>>>>>> >>>>>>>> The question said NOTHING of the x86 language, so it doesn't >>>>>>>> matter. >>>>>>>> >>>>>>> >>>>>>> Liar Liar pants on fire !!! >>>>>>> Liar Liar pants on fire !!! >>>>>>> Liar Liar pants on fire !!! >>>>>>> Liar Liar pants on fire !!! >>>>>>> Liar Liar pants on fire !!! >>>>>> >>>>>> But the question to Professor Sipser was, as you quoted: >>>>>> >>>>>> <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> >>>>>> >>>>>> >>>>>> Which said NOTHING about the x86 language, >>>>>> >>>>>> So, who is the liar now? >>>>>> >>>>>>> >>>>>>> _DDD() >>>>>>> [00002172] 55 push ebp ; housekeeping >>>>>>> [00002173] 8bec mov ebp,esp ; housekeeping >>>>>>> [00002175] 6872210000 push 00002172 ; push DDD >>>>>>> [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD) >>>>>>> [0000217f] 83c404 add esp,+04 >>>>>>> [00002182] 5d pop ebp >>>>>>> [00002183] c3 ret >>>>>>> Size in bytes:(0018) [00002183] >>>>>>> >>>>>>> The call from DDD to HHH(DDD) when N steps of DDD are correctly >>>>>>> emulated by any pure function x86 emulator HHH cannot possibly >>>>>>> return. >>>>>>> >>>>>> >>>>>> Which wasn't what we were talking about with Professor Sipser, who >>>>>> never saw any of that. >>>>>> >>>>>> I guess you just have a major brain malfunction and can't keep >>>>>> your lies straight. >>>>>> >>>>>> This just proves your unreliability when it comes to statements >>>>> >>>>> Partial halt deciders constructed for the x86 language >>>>> are isomorphic to this termination analyzer build for >>>>> the C programming language. >>>> >>>> Which still has nothing to do with you LYING about your question to >>>> Professor Sipser. >>>> >>>> And x86 is not fully isomorphic to the C programming language. >>>> >>>> The x86 language is probably easier to simulate but harder to decide >>>> on, because it can create more complicated interactions. >>>> >>>> Note, there isn't a trivial translation between x86 and C (or LLVM). >>>> C to LLVM to x86 is algorithmically doable, but with a lot of >>>> options at each step. And when doing the reverse, you normally don't >>>> get anything like the original code you started with. >>>> >>>> And then we get to the fact that "Halt Deciding" and "Termination >>>> Analying" are DIFFERENT problems, Halt Deciding being if a >>>> particular Program/Input will halt when it is run, while Termination >>>> Analysers answer if there is ANY input that might make a given >>>> machine not Halt. A much different problem (which you clearly don't >>>> understand). >>>> >>>>> >>>>> *AProVE: Non-Termination Witnesses for C Programs* >>>>> To prove (non-)termination of a C program, AProVE uses the >>>>> Clang compiler [7] to translate it to the intermediate >>>>> representation of the LLVM framework [15]. Then AProVE >>>>> symbolically executes the LLVM program and uses abstraction >>>>> to obtain a finite symbolic execution graph (SEG) containing >>>>> all possible program runs. >>>>> https://link.springer.com/content/pdf/10.1007/978-3-030-99527-0_21.pdf >>>> >>>> Which isn't based on "Pure Emulation" like your deciders are. There >>>> is a lot of pre-work done to determine what parts might need to be >>>> emulated. Note, since "Termination Analyzers" don't have an input to >>>> the program, the "emulation" they do needs to be different, but >>>> looking at the mapping of possible states to possible states. >>>> >>>>> >>>>> Even a Turing machine based partial halt decider is >>>>> locked in to the Turing Machine description language. >>>>> Is this really over your head? >>>>> >>>> >>>> But there isn't a single Turing Machine Description Language that >>>> all UTMs use. >>>> >>>> Also, the Theory isn't about "Partial" Halt Deciders, as those are >>>> numerous, but about Correct Halt Decider (implied Complete, i.e. >>>> handles ALL inputs), so switching to partial decider is just a >>>> deceitful dodge. >>>> >>>> It is still true that the xemantics of the x86 language define the >>>> behavior of a set of bytes, as the behavior when you ACTUALLY RUN >>>> THEM, and nothing else. >>>> >>> >>> That stupid idea forces "interpreting" the call to HHH(DDD) >>> from DDD simulated by HHH to disagree with the x86 language >>> and return when the x86 language says this is impossible. >> >> Why do you say that? >> >> By the x86 language, HHH is just a series of instructions to do >> something. >> > > Then what you are saying here are just words that are > about something or other and no more specific than that. No, since you have defined that meaning is based on the x86 instructions set, and its correct emulation, then the ONLY thing a "call HHH" instruction can mean, is that the next steps of the behavior will be the emulation of the instructions of HHH. There is no "option" to define that HHH is an emulator and that the call to HHH just starts an emulation, because that isn't behavior defined in the x86 instruction set. Also, HHH is no "a x86 emulator" but a CONDITIONAL x86 emulator, and that fact is important. For one thing, it means that you can not, even under an "equivalency" of emulation replace the emulation of the emulator with the machie it is emulating as you are doing, as that is only valid for an UNCONDITIONAL emulation, which isn't what HHH does. > >> And without the bytes specified, we don't know what they do. >> >> There is no way to try to specify AT THE x86 instruction level, that >> HHH is an "emulator" as that isn't a concept at the x86 instruction >> level. >> >> Also, it is a LIE to say HHH is a "x86 Emulator", as that term, >> unadorned, means it is an UNCONDITIONAL emulator (like a UTM) which is >> isn't since you define that it has the power to decide that its input >> is non-halting (and might do it incorrectly) and thus its emulation at >> each step is conditional on that logic. >> >>> >>> _DDD() >>> [00002172] 55 push ebp ; housekeeping >>> [00002173] 8bec mov ebp,esp ; housekeeping >>> [00002175] 6872210000 push 00002172 ; push DDD >>> [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD) >>> [0000217f] 83c404 add esp,+04 >>> [00002182] 5d pop ebp >>> [00002183] c3 ret >>> Size in bytes:(0018) [00002183] >>> >>>> And that means, you need the code for the COMPLETE program (or >>>> sub-program) to talk about behavior, which includes the code for >>>> everything that one piece of code calls, so for your D family of >>>> inputs, the H family of deciders that it has been paired with. >>> >> >
[toc] | [prev] | [next] | [standalone]
| From | Mikko <mikko.levanto@iki.fi> |
|---|---|
| Date | 2024-06-30 11:50 +0300 |
| Message-ID | <v5r696$enkl$1@dont-email.me> |
| In reply to | #108005 |
On 2024-06-29 17:17:29 +0000, olcott said:
> On 6/29/2024 11:45 AM, Richard Damon wrote:
>> On 6/29/24 12:09 PM, olcott wrote:
>>> People are still trying to get away with disagreeing with
>>> the semantics of the x86 language. That is isomorphic to
>>> trying to get away with disagreeing with arithmetic.
>>
>> Nope, we are not disagreeing with the semantics of the x86 language, we
>> are disagreeing with your misunderstanding of how it works.
>>
>>>
>>> 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.
>>
>> No the x86 language "knows" NOTHING about H0 being a x86 emulator. It
>> is just a function that maybe happens to be a partial x86 emulator, but
>> that is NOT a fundamental result of it being H0.
>>
>>>
>>> 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 construed as non-halting BECAUSE it has been shown that your H0
>> *WILL* terminate its PARTIAL emulation of the code it is emulating and
>> returning.
>>
>>>
>>> Simulating termination analyzers must report on the behavior
>>> that their finite string input specifies thus H0 must report
>>> that DDD correctly emulated by H0 remains stuck in recursive
>>> simulation.
>>
>> Right, so H0 is REQUIRED to return, and thus if the termination
>> analyser knows that H0 is a termination analyzer it knows that the call
>> to H0 MUST return, and thus DDD must be a terminating program.
>>
>> An H0 that doesn't know this, and can't figure out that H0 will return,
>> but just keeps emulating H0 emulating its input will just fail to meet
>> its own requirement to return.
>>
>>>
>>> <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>
>>
>> Right, and the only definition Professor Sipser uses for "Correct
>> Simulation" is a simulation that EXACTLY REPRODUCES the behavior of the
>> directly executed program represented by the input. Your H doesn't do
>> that, nor correctly predicts the behavior of such a simulation of the
>> input (since that behavior is to halt) so it can never proper avail
>> itself of the second paragraph, so does so erroneously getting the
>> wrong answer.
>>
>>>
>>> People are trying to get away with disagreeing with the semantics
>>> of the x86 language by disagreeing that
>>>
>>> The call from DDD to HHH(DDD) when N steps of DDD are correctly
>>> emulated by any pure function x86 emulator HHH cannot possibly
>>> return.
>>
>> Except that the "N Steps of DDD correctly emulated" is NOT the
>> definition of the "behavior" of the input DDD.
>>
>> "inputs" Do not have "behavoir", that is a property of a program, so
>> the input only "represents" that program, in this case the program DDD.
>>
>
> *According to the professor Sipser approved criteria YES IT IS*
It is not a good idea to speculate about other peoples opinions.
Better to stick to the topic specified by OP.
> The call from DDD to HHH(DDD) when N steps of DDD are correctly
> emulated by any pure function x86 emulator HHH 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 HHH(DDD)
> [0000217f] 83c404 add esp,+04
> [00002182] 5d pop ebp
> [00002183] c3 ret
> Size in bytes:(0018) [00002183]
--
Mikko
[toc] | [prev] | [next] | [standalone]
| From | Mikko <mikko.levanto@iki.fi> |
|---|---|
| Date | 2024-06-30 11:42 +0300 |
| Message-ID | <v5r5q9$ekvf$1@dont-email.me> |
| In reply to | #108003 |
On 2024-06-29 16:09:19 +0000, olcott said:
> People are still trying to get away with disagreeing with
> the semantics of the x86 language. That is isomorphic to
> trying to get away with disagreeing with arithmetic.
>
> 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.
>
> Simulating termination analyzers must report on the behavior
> that their finite string input specifies thus H0 must report
> that DDD correctly emulated by H0 remains stuck in recursive
> simulation.
>
> <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>
>
> People are trying to get away with disagreeing with the semantics
> of the x86 language by disagreeing that
>
> The call from DDD to HHH(DDD) when N steps of DDD are correctly
> emulated by any pure function x86 emulator HHH 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 HHH(DDD)
> [0000217f] 83c404 add esp,+04
> [00002182] 5d pop ebp
> [00002183] c3 ret
> Size in bytes:(0018) [00002183]
>
>
> *A 100% complete and total rewrite of the prior paper*
> https://www.researchgate.net/publication/381636432_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_P
>
Nothing above is or points to any evdence about the alleged disagreement.
--
Mikko
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-30 12:18 -0500 |
| Message-ID | <v5s40h$jvgt$1@dont-email.me> |
| In reply to | #108026 |
On 6/30/2024 3:42 AM, Mikko wrote:
> On 2024-06-29 16:09:19 +0000, olcott said:
>
>> People are still trying to get away with disagreeing with
>> the semantics of the x86 language. That is isomorphic to
>> trying to get away with disagreeing with arithmetic.
>>
>> 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.
>>
>> Simulating termination analyzers must report on the behavior
>> that their finite string input specifies thus H0 must report
>> that DDD correctly emulated by H0 remains stuck in recursive
>> simulation.
>>
>> <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>
>>
>> People are trying to get away with disagreeing with the semantics
>> of the x86 language by disagreeing that
>>
>> The call from DDD to HHH(DDD) when N steps of DDD are correctly
>> emulated by any pure function x86 emulator HHH 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 HHH(DDD)
>> [0000217f] 83c404 add esp,+04
>> [00002182] 5d pop ebp
>> [00002183] c3 ret
>> Size in bytes:(0018) [00002183]
>>
>>
>> *A 100% complete and total rewrite of the prior paper*
>> https://www.researchgate.net/publication/381636432_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_P
>
> Nothing above is or points to any evdence about the alleged disagreement.
>
Of course not. I only said the actual truth.
Richard just said that he affirms that when DDD correctly
simulated by HHH calls HHH(DDD) that this call returns even
though the semantics of the x86 language disagrees.
On 6/30/2024 7:34 AM, Richard Damon wrote:
> It is still true that the xemantics of the x86
> language define the behavior of a set of bytes,
> as the behavior when you ACTUALLY RUN THEM,
> and nothing else.
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
Richard thinks that he can get away with disagreeing with this
verified fact:
The call from DDD to HHH(DDD) when N steps of DDD are correctly
emulated by any pure function x86 emulator HHH 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 | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-30 15:31 -0400 |
| Message-ID | <v5sbpt$1kfbr$2@i2pn2.org> |
| In reply to | #108037 |
On 6/30/24 1:18 PM, olcott wrote:
> On 6/30/2024 3:42 AM, Mikko wrote:
>> On 2024-06-29 16:09:19 +0000, olcott said:
>>
>>> People are still trying to get away with disagreeing with
>>> the semantics of the x86 language. That is isomorphic to
>>> trying to get away with disagreeing with arithmetic.
>>>
>>> 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.
>>>
>>> Simulating termination analyzers must report on the behavior
>>> that their finite string input specifies thus H0 must report
>>> that DDD correctly emulated by H0 remains stuck in recursive
>>> simulation.
>>>
>>> <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>
>>>
>>> People are trying to get away with disagreeing with the semantics
>>> of the x86 language by disagreeing that
>>>
>>> The call from DDD to HHH(DDD) when N steps of DDD are correctly
>>> emulated by any pure function x86 emulator HHH 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 HHH(DDD)
>>> [0000217f] 83c404 add esp,+04
>>> [00002182] 5d pop ebp
>>> [00002183] c3 ret
>>> Size in bytes:(0018) [00002183]
>>>
>>>
>>> *A 100% complete and total rewrite of the prior paper*
>>> https://www.researchgate.net/publication/381636432_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_P
>>
>> Nothing above is or points to any evdence about the alleged disagreement.
>>
>
> Of course not. I only said the actual truth.
>
> Richard just said that he affirms that when DDD correctly
> simulated by HHH calls HHH(DDD) that this call returns even
> though the semantics of the x86 language disagrees.
What in the sematics of the x86 language, which INCLUDES that ever
instruction WILL be followed by the next instruction, says that the HHH
that is calld by DDD won't eventually return.
Since you assert that HHH(DDD) called by main returns, then by your
requreement that HHH be a "pure function" ALL copies of it will do the
same thing.
Yes, the EMULATION of HHH by HHH, but that can not be the "behavior of
the input" as that "behavior" depends on more than just the input.
>
> On 6/30/2024 7:34 AM, Richard Damon wrote:
> > It is still true that the xemantics of the x86
> > language define the behavior of a set of bytes,
> > as the behavior when you ACTUALLY RUN THEM,
> > and nothing else.
>
> _DDD()
> [00002172] 55 push ebp ; housekeeping
> [00002173] 8bec mov ebp,esp ; housekeeping
> [00002175] 6872210000 push 00002172 ; push DDD
> [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
> [0000217f] 83c404 add esp,+04
> [00002182] 5d pop ebp
> [00002183] c3 ret
> Size in bytes:(0018) [00002183]
>
> Richard thinks that he can get away with disagreeing with this
> verified fact:
>
> The call from DDD to HHH(DDD) when N steps of DDD are correctly
> emulated by any pure function x86 emulator HHH cannot possibly
> return.
>
But the "BEHAVIOR OF THE INPUT", which is ONLY a function of the input
doesn't stop looking at the x86 instructions just because HHH stop
emulating them.
You are just stuck with an INCONSISTANT definition of behavior which
just isn't allowed. The Behavior of the input, per the x86 semantic
interpretation, is the behavior of the program the input represents,
which included that particular HHH as part of it, and that will return.\
You are just stuck with the lies you have told yourself.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-30 16:41 -0500 |
| Message-ID | <v5sjdl$mpem$2@dont-email.me> |
| In reply to | #108041 |
On 6/30/2024 2:31 PM, Richard Damon wrote:
> On 6/30/24 1:18 PM, olcott wrote:
>> On 6/30/2024 3:42 AM, Mikko wrote:
>>> On 2024-06-29 16:09:19 +0000, olcott said:
>>>
>>>> People are still trying to get away with disagreeing with
>>>> the semantics of the x86 language. That is isomorphic to
>>>> trying to get away with disagreeing with arithmetic.
>>>>
>>>> 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.
>>>>
>>>> Simulating termination analyzers must report on the behavior
>>>> that their finite string input specifies thus H0 must report
>>>> that DDD correctly emulated by H0 remains stuck in recursive
>>>> simulation.
>>>>
>>>> <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>
>>>>
>>>> People are trying to get away with disagreeing with the semantics
>>>> of the x86 language by disagreeing that
>>>>
>>>> The call from DDD to HHH(DDD) when N steps of DDD are correctly
>>>> emulated by any pure function x86 emulator HHH 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 HHH(DDD)
>>>> [0000217f] 83c404 add esp,+04
>>>> [00002182] 5d pop ebp
>>>> [00002183] c3 ret
>>>> Size in bytes:(0018) [00002183]
>>>>
>>>>
>>>> *A 100% complete and total rewrite of the prior paper*
>>>> https://www.researchgate.net/publication/381636432_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_P
>>>
>>> Nothing above is or points to any evdence about the alleged
>>> disagreement.
>>>
>>
>> Of course not. I only said the actual truth.
>>
>> Richard just said that he affirms that when DDD correctly
>> simulated by HHH calls HHH(DDD) that this call returns even
>> though the semantics of the x86 language disagrees.
>
> What in the sematics of the x86 language, which INCLUDES that ever
> instruction WILL be followed by the next instruction, says that the HHH
> that is calld by DDD won't eventually return.
>
So finally you quit lying.
--
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-30 17:54 -0400 |
| Message-ID | <v5sk7i$1kfbr$4@i2pn2.org> |
| In reply to | #108045 |
On 6/30/24 5:41 PM, olcott wrote:
> On 6/30/2024 2:31 PM, Richard Damon wrote:
>> On 6/30/24 1:18 PM, olcott wrote:
>>> On 6/30/2024 3:42 AM, Mikko wrote:
>>>> On 2024-06-29 16:09:19 +0000, olcott said:
>>>>
>>>>> People are still trying to get away with disagreeing with
>>>>> the semantics of the x86 language. That is isomorphic to
>>>>> trying to get away with disagreeing with arithmetic.
>>>>>
>>>>> 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.
>>>>>
>>>>> Simulating termination analyzers must report on the behavior
>>>>> that their finite string input specifies thus H0 must report
>>>>> that DDD correctly emulated by H0 remains stuck in recursive
>>>>> simulation.
>>>>>
>>>>> <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>
>>>>>
>>>>> People are trying to get away with disagreeing with the semantics
>>>>> of the x86 language by disagreeing that
>>>>>
>>>>> The call from DDD to HHH(DDD) when N steps of DDD are correctly
>>>>> emulated by any pure function x86 emulator HHH 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 HHH(DDD)
>>>>> [0000217f] 83c404 add esp,+04
>>>>> [00002182] 5d pop ebp
>>>>> [00002183] c3 ret
>>>>> Size in bytes:(0018) [00002183]
>>>>>
>>>>>
>>>>> *A 100% complete and total rewrite of the prior paper*
>>>>> https://www.researchgate.net/publication/381636432_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_P
>>>>
>>>> Nothing above is or points to any evdence about the alleged
>>>> disagreement.
>>>>
>>>
>>> Of course not. I only said the actual truth.
>>>
>>> Richard just said that he affirms that when DDD correctly
>>> simulated by HHH calls HHH(DDD) that this call returns even
>>> though the semantics of the x86 language disagrees.
>>
>> What in the sematics of the x86 language, which INCLUDES that ever
>> instruction WILL be followed by the next instruction, says that the
>> HHH that is calld by DDD won't eventually return.
>>
>
> So finally you quit lying.
>
I didn't say it didn't, I asked the question WHAT SAYS IT DOESNT.
I guess you don't understand questions.
Failure to provide your proof just adds another confirmed lie to your list.
THIS IS JUST ANOTHER EXAMPLE OF YOU LYING BY MISINTERPRETING WHAT PEOPLE
ARE SAYING.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-30 17:55 -0400 |
| Message-ID | <v5sk7n$1kfbr$5@i2pn2.org> |
| In reply to | #108045 |
On 6/30/24 5:41 PM, olcott wrote:
> On 6/30/2024 2:31 PM, Richard Damon wrote:
>> On 6/30/24 1:18 PM, olcott wrote:
>>> On 6/30/2024 3:42 AM, Mikko wrote:
>>>> On 2024-06-29 16:09:19 +0000, olcott said:
>>>>
>>>>> People are still trying to get away with disagreeing with
>>>>> the semantics of the x86 language. That is isomorphic to
>>>>> trying to get away with disagreeing with arithmetic.
>>>>>
>>>>> 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.
>>>>>
>>>>> Simulating termination analyzers must report on the behavior
>>>>> that their finite string input specifies thus H0 must report
>>>>> that DDD correctly emulated by H0 remains stuck in recursive
>>>>> simulation.
>>>>>
>>>>> <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>
>>>>>
>>>>> People are trying to get away with disagreeing with the semantics
>>>>> of the x86 language by disagreeing that
>>>>>
>>>>> The call from DDD to HHH(DDD) when N steps of DDD are correctly
>>>>> emulated by any pure function x86 emulator HHH 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 HHH(DDD)
>>>>> [0000217f] 83c404 add esp,+04
>>>>> [00002182] 5d pop ebp
>>>>> [00002183] c3 ret
>>>>> Size in bytes:(0018) [00002183]
>>>>>
>>>>>
>>>>> *A 100% complete and total rewrite of the prior paper*
>>>>> https://www.researchgate.net/publication/381636432_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_P
>>>>
>>>> Nothing above is or points to any evdence about the alleged
>>>> disagreement.
>>>>
>>>
>>> Of course not. I only said the actual truth.
>>>
>>> Richard just said that he affirms that when DDD correctly
>>> simulated by HHH calls HHH(DDD) that this call returns even
>>> though the semantics of the x86 language disagrees.
>>
>> What in the sematics of the x86 language, which INCLUDES that ever
>> instruction WILL be followed by the next instruction, says that the
>> HHH that is calld by DDD won't eventually return.
>>
>
> So finally you quit lying.
>
Right, if HHH is ACTUAL a correct
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-30 16:48 -0500 |
| Message-ID | <v5sjsa$msl0$1@dont-email.me> |
| In reply to | #108041 |
On 6/30/2024 2:31 PM, Richard Damon wrote:
> On 6/30/24 1:18 PM, olcott wrote:
>> On 6/30/2024 3:42 AM, Mikko wrote:
>>> On 2024-06-29 16:09:19 +0000, olcott said:
>>>
>>>> People are still trying to get away with disagreeing with
>>>> the semantics of the x86 language. That is isomorphic to
>>>> trying to get away with disagreeing with arithmetic.
>>>>
>>>> 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.
>>>>
>>>> Simulating termination analyzers must report on the behavior
>>>> that their finite string input specifies thus H0 must report
>>>> that DDD correctly emulated by H0 remains stuck in recursive
>>>> simulation.
>>>>
>>>> <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>
>>>>
>>>> People are trying to get away with disagreeing with the semantics
>>>> of the x86 language by disagreeing that
>>>>
>>>> The call from DDD to HHH(DDD) when N steps of DDD are correctly
>>>> emulated by any pure function x86 emulator HHH 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 HHH(DDD)
>>>> [0000217f] 83c404 add esp,+04
>>>> [00002182] 5d pop ebp
>>>> [00002183] c3 ret
>>>> Size in bytes:(0018) [00002183]
>>>>
>>>>
>>>> *A 100% complete and total rewrite of the prior paper*
>>>> https://www.researchgate.net/publication/381636432_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_P
>>>
>>> Nothing above is or points to any evdence about the alleged
>>> disagreement.
>>>
>>
>> Of course not. I only said the actual truth.
>>
>> Richard just said that he affirms that when DDD correctly
>> simulated by HHH calls HHH(DDD) that this call returns even
>> though the semantics of the x86 language disagrees.
>
> What in the sematics of the x86 language, which INCLUDES that ever
> instruction WILL be followed by the next instruction, says that the HHH
> that is calld by DDD won't eventually return.
>
> Since you assert that HHH(DDD) called by main returns, then by your
> requreement that HHH be a "pure function" ALL copies of it will do the
> same thing.
>
> Yes, the EMULATION of HHH by HHH, but that can not be the "behavior of
> the input" as that "behavior" depends on more than just the input.
>
Therefore DDD correctly simulated by HHH DOES NOT HALT.
Thus HHH correctly reports that DDD DOES NOT HALT.
--
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-30 17:57 -0400 |
| Message-ID | <v5skc9$1kfbr$7@i2pn2.org> |
| In reply to | #108046 |
On 6/30/24 5:48 PM, olcott wrote:
> On 6/30/2024 2:31 PM, Richard Damon wrote:
>> On 6/30/24 1:18 PM, olcott wrote:
>>> On 6/30/2024 3:42 AM, Mikko wrote:
>>>> On 2024-06-29 16:09:19 +0000, olcott said:
>>>>
>>>>> People are still trying to get away with disagreeing with
>>>>> the semantics of the x86 language. That is isomorphic to
>>>>> trying to get away with disagreeing with arithmetic.
>>>>>
>>>>> 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.
>>>>>
>>>>> Simulating termination analyzers must report on the behavior
>>>>> that their finite string input specifies thus H0 must report
>>>>> that DDD correctly emulated by H0 remains stuck in recursive
>>>>> simulation.
>>>>>
>>>>> <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>
>>>>>
>>>>> People are trying to get away with disagreeing with the semantics
>>>>> of the x86 language by disagreeing that
>>>>>
>>>>> The call from DDD to HHH(DDD) when N steps of DDD are correctly
>>>>> emulated by any pure function x86 emulator HHH 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 HHH(DDD)
>>>>> [0000217f] 83c404 add esp,+04
>>>>> [00002182] 5d pop ebp
>>>>> [00002183] c3 ret
>>>>> Size in bytes:(0018) [00002183]
>>>>>
>>>>>
>>>>> *A 100% complete and total rewrite of the prior paper*
>>>>> https://www.researchgate.net/publication/381636432_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_P
>>>>
>>>> Nothing above is or points to any evdence about the alleged
>>>> disagreement.
>>>>
>>>
>>> Of course not. I only said the actual truth.
>>>
>>> Richard just said that he affirms that when DDD correctly
>>> simulated by HHH calls HHH(DDD) that this call returns even
>>> though the semantics of the x86 language disagrees.
>>
>> What in the sematics of the x86 language, which INCLUDES that ever
>> instruction WILL be followed by the next instruction, says that the
>> HHH that is calld by DDD won't eventually return.
>>
>> Since you assert that HHH(DDD) called by main returns, then by your
>> requreement that HHH be a "pure function" ALL copies of it will do the
>> same thing.
>>
>> Yes, the EMULATION of HHH by HHH, but that can not be the "behavior of
>> the input" as that "behavior" depends on more than just the input.
>>
>
> Therefore DDD correctly simulated by HHH DOES NOT HALT.
> Thus HHH correctly reports that DDD DOES NOT HALT.
>
And then it doesn't correct emulate the input, and thus is a LIAR.
if HHH does abort and return, then DDD, and the HHH that it calls, also
returns but AFTER HHH aborts its emulation of it.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-30 17:41 -0500 |
| Message-ID | <v5smuk$n7a2$1@dont-email.me> |
| In reply to | #108050 |
On 6/30/2024 4:57 PM, Richard Damon wrote:
> On 6/30/24 5:48 PM, olcott wrote:
>> On 6/30/2024 2:31 PM, Richard Damon wrote:
>>> On 6/30/24 1:18 PM, olcott wrote:
>>>> On 6/30/2024 3:42 AM, Mikko wrote:
>>>>> On 2024-06-29 16:09:19 +0000, olcott said:
>>>>>
>>>>>> People are still trying to get away with disagreeing with
>>>>>> the semantics of the x86 language. That is isomorphic to
>>>>>> trying to get away with disagreeing with arithmetic.
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> Simulating termination analyzers must report on the behavior
>>>>>> that their finite string input specifies thus H0 must report
>>>>>> that DDD correctly emulated by H0 remains stuck in recursive
>>>>>> simulation.
>>>>>>
>>>>>> <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>
>>>>>>
>>>>>> People are trying to get away with disagreeing with the semantics
>>>>>> of the x86 language by disagreeing that
>>>>>>
>>>>>> The call from DDD to HHH(DDD) when N steps of DDD are correctly
>>>>>> emulated by any pure function x86 emulator HHH 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 HHH(DDD)
>>>>>> [0000217f] 83c404 add esp,+04
>>>>>> [00002182] 5d pop ebp
>>>>>> [00002183] c3 ret
>>>>>> Size in bytes:(0018) [00002183]
>>>>>>
>>>>>>
>>>>>> *A 100% complete and total rewrite of the prior paper*
>>>>>> https://www.researchgate.net/publication/381636432_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_P
>>>>>
>>>>> Nothing above is or points to any evdence about the alleged
>>>>> disagreement.
>>>>>
>>>>
>>>> Of course not. I only said the actual truth.
>>>>
>>>> Richard just said that he affirms that when DDD correctly
>>>> simulated by HHH calls HHH(DDD) that this call returns even
>>>> though the semantics of the x86 language disagrees.
>>>
>>> What in the sematics of the x86 language, which INCLUDES that ever
>>> instruction WILL be followed by the next instruction, says that the
>>> HHH that is calld by DDD won't eventually return.
>>>
>>> Since you assert that HHH(DDD) called by main returns, then by your
>>> requreement that HHH be a "pure function" ALL copies of it will do
>>> the same thing.
>>>
>>> Yes, the EMULATION of HHH by HHH, but that can not be the "behavior
>>> of the input" as that "behavior" depends on more than just the input.
>>>
>>
>> Therefore DDD correctly simulated by HHH DOES NOT HALT.
>> Thus HHH correctly reports that DDD DOES NOT HALT.
>>
>
> And then it doesn't correct emulate the input, and thus is a LIAR.
>
You already know that you are the liar here and are
lying about not knowing this.
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
The call from DDD to HHH(DDD) when N steps of DDD are
correctly emulated by any pure function x86 emulator
HHH at machine address 0000217a 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 | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-30 19:14 -0400 |
| Message-ID | <v5sorr$1kfbr$10@i2pn2.org> |
| In reply to | #108053 |
On 6/30/24 6:41 PM, olcott wrote:
> On 6/30/2024 4:57 PM, Richard Damon wrote:
>> On 6/30/24 5:48 PM, olcott wrote:
>>> On 6/30/2024 2:31 PM, Richard Damon wrote:
>>>> On 6/30/24 1:18 PM, olcott wrote:
>>>>> On 6/30/2024 3:42 AM, Mikko wrote:
>>>>>> On 2024-06-29 16:09:19 +0000, olcott said:
>>>>>>
>>>>>>> People are still trying to get away with disagreeing with
>>>>>>> the semantics of the x86 language. That is isomorphic to
>>>>>>> trying to get away with disagreeing with arithmetic.
>>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>> Simulating termination analyzers must report on the behavior
>>>>>>> that their finite string input specifies thus H0 must report
>>>>>>> that DDD correctly emulated by H0 remains stuck in recursive
>>>>>>> simulation.
>>>>>>>
>>>>>>> <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>
>>>>>>>
>>>>>>> People are trying to get away with disagreeing with the semantics
>>>>>>> of the x86 language by disagreeing that
>>>>>>>
>>>>>>> The call from DDD to HHH(DDD) when N steps of DDD are correctly
>>>>>>> emulated by any pure function x86 emulator HHH 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 HHH(DDD)
>>>>>>> [0000217f] 83c404 add esp,+04
>>>>>>> [00002182] 5d pop ebp
>>>>>>> [00002183] c3 ret
>>>>>>> Size in bytes:(0018) [00002183]
>>>>>>>
>>>>>>>
>>>>>>> *A 100% complete and total rewrite of the prior paper*
>>>>>>> https://www.researchgate.net/publication/381636432_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_P
>>>>>>
>>>>>> Nothing above is or points to any evdence about the alleged
>>>>>> disagreement.
>>>>>>
>>>>>
>>>>> Of course not. I only said the actual truth.
>>>>>
>>>>> Richard just said that he affirms that when DDD correctly
>>>>> simulated by HHH calls HHH(DDD) that this call returns even
>>>>> though the semantics of the x86 language disagrees.
>>>>
>>>> What in the sematics of the x86 language, which INCLUDES that ever
>>>> instruction WILL be followed by the next instruction, says that the
>>>> HHH that is calld by DDD won't eventually return.
>>>>
>>>> Since you assert that HHH(DDD) called by main returns, then by your
>>>> requreement that HHH be a "pure function" ALL copies of it will do
>>>> the same thing.
>>>>
>>>> Yes, the EMULATION of HHH by HHH, but that can not be the "behavior
>>>> of the input" as that "behavior" depends on more than just the input.
>>>>
>>>
>>> Therefore DDD correctly simulated by HHH DOES NOT HALT.
>>> Thus HHH correctly reports that DDD DOES NOT HALT.
>>>
>>
>> And then it doesn't correct emulate the input, and thus is a LIAR.
>>
>
> You already know that you are the liar here and are
> lying about not knowing this.
>
> _DDD()
> [00002172] 55 push ebp ; housekeeping
> [00002173] 8bec mov ebp,esp ; housekeeping
> [00002175] 6872210000 push 00002172 ; push DDD
> [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
> [0000217f] 83c404 add esp,+04
> [00002182] 5d pop ebp
> [00002183] c3 ret
> Size in bytes:(0018) [00002183]
>
> The call from DDD to HHH(DDD) when N steps of DDD are
> correctly emulated by any pure function x86 emulator
> HHH at machine address 0000217a cannot possibly return.
>
The problem is that the N steps emulated by HHH are not, and CAN NOT be
the "behavior of the input", but only the complete emulation of the input.
The problem with just the N steps, is that NOTHING about the input
specifies that number N, so it isn't part of the input, and the
"behavior of the input" must be determined by just the input (and what
it represents).
Thus, your "argument" is based on invalid definitions, showing your
utter stupidity.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-30 18:18 -0500 |
| Message-ID | <v5sp4v$nnko$1@dont-email.me> |
| In reply to | #108056 |
On 6/30/2024 6:14 PM, Richard Damon wrote:
> On 6/30/24 6:41 PM, olcott wrote:
>> On 6/30/2024 4:57 PM, Richard Damon wrote:
>>> On 6/30/24 5:48 PM, olcott wrote:
>>>> On 6/30/2024 2:31 PM, Richard Damon wrote:
>>>>> On 6/30/24 1:18 PM, olcott wrote:
>>>>>> On 6/30/2024 3:42 AM, Mikko wrote:
>>>>>>> On 2024-06-29 16:09:19 +0000, olcott said:
>>>>>>>
>>>>>>>> People are still trying to get away with disagreeing with
>>>>>>>> the semantics of the x86 language. That is isomorphic to
>>>>>>>> trying to get away with disagreeing with arithmetic.
>>>>>>>>
>>>>>>>> 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.
>>>>>>>>
>>>>>>>> Simulating termination analyzers must report on the behavior
>>>>>>>> that their finite string input specifies thus H0 must report
>>>>>>>> that DDD correctly emulated by H0 remains stuck in recursive
>>>>>>>> simulation.
>>>>>>>>
>>>>>>>> <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>
>>>>>>>>
>>>>>>>> People are trying to get away with disagreeing with the semantics
>>>>>>>> of the x86 language by disagreeing that
>>>>>>>>
>>>>>>>> The call from DDD to HHH(DDD) when N steps of DDD are correctly
>>>>>>>> emulated by any pure function x86 emulator HHH 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 HHH(DDD)
>>>>>>>> [0000217f] 83c404 add esp,+04
>>>>>>>> [00002182] 5d pop ebp
>>>>>>>> [00002183] c3 ret
>>>>>>>> Size in bytes:(0018) [00002183]
>>>>>>>>
>>>>>>>>
>>>>>>>> *A 100% complete and total rewrite of the prior paper*
>>>>>>>> https://www.researchgate.net/publication/381636432_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_P
>>>>>>>
>>>>>>> Nothing above is or points to any evdence about the alleged
>>>>>>> disagreement.
>>>>>>>
>>>>>>
>>>>>> Of course not. I only said the actual truth.
>>>>>>
>>>>>> Richard just said that he affirms that when DDD correctly
>>>>>> simulated by HHH calls HHH(DDD) that this call returns even
>>>>>> though the semantics of the x86 language disagrees.
>>>>>
>>>>> What in the sematics of the x86 language, which INCLUDES that ever
>>>>> instruction WILL be followed by the next instruction, says that the
>>>>> HHH that is calld by DDD won't eventually return.
>>>>>
>>>>> Since you assert that HHH(DDD) called by main returns, then by your
>>>>> requreement that HHH be a "pure function" ALL copies of it will do
>>>>> the same thing.
>>>>>
>>>>> Yes, the EMULATION of HHH by HHH, but that can not be the "behavior
>>>>> of the input" as that "behavior" depends on more than just the input.
>>>>>
>>>>
>>>> Therefore DDD correctly simulated by HHH DOES NOT HALT.
>>>> Thus HHH correctly reports that DDD DOES NOT HALT.
>>>>
>>>
>>> And then it doesn't correct emulate the input, and thus is a LIAR.
>>>
>>
>> You already know that you are the liar here and are
>> lying about not knowing this.
>>
>> _DDD()
>> [00002172] 55 push ebp ; housekeeping
>> [00002173] 8bec mov ebp,esp ; housekeeping
>> [00002175] 6872210000 push 00002172 ; push DDD
>> [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
>> [0000217f] 83c404 add esp,+04
>> [00002182] 5d pop ebp
>> [00002183] c3 ret
>> Size in bytes:(0018) [00002183]
>>
>> The call from DDD to HHH(DDD) when N steps of DDD are
>> correctly emulated by any pure function x86 emulator
>> HHH at machine address 0000217a cannot possibly return.
>>
>
> The problem is that the N steps emulated by HHH are not, and CAN NOT be
> the "behavior of the input",
They need not be the FULL behavior of the input.
H correctly simulates its input D until
H correctly simulates its input D until
H correctly simulates its input D until
H correctly simulates its input D until
H correctly simulates its input D until
H correctly simulates its input D until
H correctly simulates its input D until
H correctly simulates its input D until
H correctly simulates its input D until
H correctly simulates its input D until
H correctly simulates its input D until
H correctly simulates its input D until
H correctly simulates its input D until
H correctly simulates its input D until
H correctly simulates its input D until
H correctly simulates its input D until
H correctly simulates its input D until
H correctly simulates its input D until
H correctly simulates its input D until
H correctly simulates its input D until
H correctly simulates its input D until
H correctly simulates its input D until
H correctly simulates its input D until
H correctly simulates its input D until
H correctly simulates its input D until
H correctly simulates its input D until
H correctly simulates its input D until
H correctly determines that its simulated D would never
stop running unless aborted
--
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-30 19:53 -0400 |
| Message-ID | <v5sr4t$1kfbq$1@i2pn2.org> |
| In reply to | #108057 |
On 6/30/24 7:18 PM, olcott wrote:
> On 6/30/2024 6:14 PM, Richard Damon wrote:
>> On 6/30/24 6:41 PM, olcott wrote:
>>> On 6/30/2024 4:57 PM, Richard Damon wrote:
>>>> On 6/30/24 5:48 PM, olcott wrote:
>>>>> On 6/30/2024 2:31 PM, Richard Damon wrote:
>>>>>> On 6/30/24 1:18 PM, olcott wrote:
>>>>>>> On 6/30/2024 3:42 AM, Mikko wrote:
>>>>>>>> On 2024-06-29 16:09:19 +0000, olcott said:
>>>>>>>>
>>>>>>>>> People are still trying to get away with disagreeing with
>>>>>>>>> the semantics of the x86 language. That is isomorphic to
>>>>>>>>> trying to get away with disagreeing with arithmetic.
>>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>> Simulating termination analyzers must report on the behavior
>>>>>>>>> that their finite string input specifies thus H0 must report
>>>>>>>>> that DDD correctly emulated by H0 remains stuck in recursive
>>>>>>>>> simulation.
>>>>>>>>>
>>>>>>>>> <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>
>>>>>>>>>
>>>>>>>>> People are trying to get away with disagreeing with the semantics
>>>>>>>>> of the x86 language by disagreeing that
>>>>>>>>>
>>>>>>>>> The call from DDD to HHH(DDD) when N steps of DDD are correctly
>>>>>>>>> emulated by any pure function x86 emulator HHH 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 HHH(DDD)
>>>>>>>>> [0000217f] 83c404 add esp,+04
>>>>>>>>> [00002182] 5d pop ebp
>>>>>>>>> [00002183] c3 ret
>>>>>>>>> Size in bytes:(0018) [00002183]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> *A 100% complete and total rewrite of the prior paper*
>>>>>>>>> https://www.researchgate.net/publication/381636432_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_P
>>>>>>>>
>>>>>>>> Nothing above is or points to any evdence about the alleged
>>>>>>>> disagreement.
>>>>>>>>
>>>>>>>
>>>>>>> Of course not. I only said the actual truth.
>>>>>>>
>>>>>>> Richard just said that he affirms that when DDD correctly
>>>>>>> simulated by HHH calls HHH(DDD) that this call returns even
>>>>>>> though the semantics of the x86 language disagrees.
>>>>>>
>>>>>> What in the sematics of the x86 language, which INCLUDES that ever
>>>>>> instruction WILL be followed by the next instruction, says that
>>>>>> the HHH that is calld by DDD won't eventually return.
>>>>>>
>>>>>> Since you assert that HHH(DDD) called by main returns, then by
>>>>>> your requreement that HHH be a "pure function" ALL copies of it
>>>>>> will do the same thing.
>>>>>>
>>>>>> Yes, the EMULATION of HHH by HHH, but that can not be the
>>>>>> "behavior of the input" as that "behavior" depends on more than
>>>>>> just the input.
>>>>>>
>>>>>
>>>>> Therefore DDD correctly simulated by HHH DOES NOT HALT.
>>>>> Thus HHH correctly reports that DDD DOES NOT HALT.
>>>>>
>>>>
>>>> And then it doesn't correct emulate the input, and thus is a LIAR.
>>>>
>>>
>>> You already know that you are the liar here and are
>>> lying about not knowing this.
>>>
>>> _DDD()
>>> [00002172] 55 push ebp ; housekeeping
>>> [00002173] 8bec mov ebp,esp ; housekeeping
>>> [00002175] 6872210000 push 00002172 ; push DDD
>>> [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
>>> [0000217f] 83c404 add esp,+04
>>> [00002182] 5d pop ebp
>>> [00002183] c3 ret
>>> Size in bytes:(0018) [00002183]
>>>
>>> The call from DDD to HHH(DDD) when N steps of DDD are
>>> correctly emulated by any pure function x86 emulator
>>> HHH at machine address 0000217a cannot possibly return.
>>>
>>
>> The problem is that the N steps emulated by HHH are not, and CAN NOT
>> be the "behavior of the input",
> They need not be the FULL behavior of the input.
>
> H correctly simulates its input D until
> H correctly simulates its input D until
> H correctly simulates its input D until
> H correctly simulates its input D until
> H correctly simulates its input D until
> H correctly simulates its input D until
> H correctly simulates its input D until
> H correctly simulates its input D until
> H correctly simulates its input D until
> H correctly simulates its input D until
> H correctly simulates its input D until
> H correctly simulates its input D until
> H correctly simulates its input D until
> H correctly simulates its input D until
> H correctly simulates its input D until
> H correctly simulates its input D until
> H correctly simulates its input D until
> H correctly simulates its input D until
> H correctly simulates its input D until
> H correctly simulates its input D until
> H correctly simulates its input D until
> H correctly simulates its input D until
> H correctly simulates its input D until
> H correctly simulates its input D until
> H correctly simulates its input D until
> H correctly simulates its input D until
> H correctly simulates its input D until
And that can NOT be the "Behavior of the Input" as it depends on more
that just the input.
Your question is just like asking what is two plus ____?
>
> H correctly determines that its simulated D would never
> stop running unless aborted
But you mean, that H dertermined that IT can not simulate its input to
the point that it stops running.
Also, "Unless aborted" is an illogical statment, as it is a FACT that
THIS H aborted its emulation. Remember, your input D, MUST INCLUDE its
copy of the decider H that it calls, or H CAN NOT CORRECTLY SIMULATE
this input, and thus hus your claim is just based on a lie as premise.
Part of the problem is that BY DEFINITION, "Behavior" is that of a
PROGRAM, so what it does when directly run or completely simulated.
Thus it is NOT true the a correctly (and thus completely) simulated D
would never stop running, so your conclusion is a LIE.
t best you need to rephase your claim, that H can not simulate its input
to the final return.
You FORGET (or never learned or just choose to ignore) that partial
simulation just show partial behavior and do not indicate (by
themselves) behavior past the point the simulation was stopped, and the
NO CLAIM about what happened after can be validly made.
Youj are just proving your utter ignorance of the field that you are
claiming making "revolutionary discoveries" abouyt, which are just the
results of your stupid ignorance.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-30 19:00 -0500 |
| Message-ID | <v5srjn$o1o0$1@dont-email.me> |
| In reply to | #108058 |
On 6/30/2024 6:53 PM, Richard Damon wrote:
> On 6/30/24 7:18 PM, olcott wrote:
>> On 6/30/2024 6:14 PM, Richard Damon wrote:
>>> On 6/30/24 6:41 PM, olcott wrote:
>>>> On 6/30/2024 4:57 PM, Richard Damon wrote:
>>>>> On 6/30/24 5:48 PM, olcott wrote:
>>>>>> On 6/30/2024 2:31 PM, Richard Damon wrote:
>>>>>>> On 6/30/24 1:18 PM, olcott wrote:
>>>>>>>> On 6/30/2024 3:42 AM, Mikko wrote:
>>>>>>>>> On 2024-06-29 16:09:19 +0000, olcott said:
>>>>>>>>>
>>>>>>>>>> People are still trying to get away with disagreeing with
>>>>>>>>>> the semantics of the x86 language. That is isomorphic to
>>>>>>>>>> trying to get away with disagreeing with arithmetic.
>>>>>>>>>>
>>>>>>>>>> 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.
>>>>>>>>>>
>>>>>>>>>> Simulating termination analyzers must report on the behavior
>>>>>>>>>> that their finite string input specifies thus H0 must report
>>>>>>>>>> that DDD correctly emulated by H0 remains stuck in recursive
>>>>>>>>>> simulation.
>>>>>>>>>>
>>>>>>>>>> <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>
>>>>>>>>>>
>>>>>>>>>> People are trying to get away with disagreeing with the semantics
>>>>>>>>>> of the x86 language by disagreeing that
>>>>>>>>>>
>>>>>>>>>> The call from DDD to HHH(DDD) when N steps of DDD are correctly
>>>>>>>>>> emulated by any pure function x86 emulator HHH 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 HHH(DDD)
>>>>>>>>>> [0000217f] 83c404 add esp,+04
>>>>>>>>>> [00002182] 5d pop ebp
>>>>>>>>>> [00002183] c3 ret
>>>>>>>>>> Size in bytes:(0018) [00002183]
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> *A 100% complete and total rewrite of the prior paper*
>>>>>>>>>> https://www.researchgate.net/publication/381636432_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_P
>>>>>>>>>
>>>>>>>>> Nothing above is or points to any evdence about the alleged
>>>>>>>>> disagreement.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Of course not. I only said the actual truth.
>>>>>>>>
>>>>>>>> Richard just said that he affirms that when DDD correctly
>>>>>>>> simulated by HHH calls HHH(DDD) that this call returns even
>>>>>>>> though the semantics of the x86 language disagrees.
>>>>>>>
>>>>>>> What in the sematics of the x86 language, which INCLUDES that
>>>>>>> ever instruction WILL be followed by the next instruction, says
>>>>>>> that the HHH that is calld by DDD won't eventually return.
>>>>>>>
>>>>>>> Since you assert that HHH(DDD) called by main returns, then by
>>>>>>> your requreement that HHH be a "pure function" ALL copies of it
>>>>>>> will do the same thing.
>>>>>>>
>>>>>>> Yes, the EMULATION of HHH by HHH, but that can not be the
>>>>>>> "behavior of the input" as that "behavior" depends on more than
>>>>>>> just the input.
>>>>>>>
>>>>>>
>>>>>> Therefore DDD correctly simulated by HHH DOES NOT HALT.
>>>>>> Thus HHH correctly reports that DDD DOES NOT HALT.
>>>>>>
>>>>>
>>>>> And then it doesn't correct emulate the input, and thus is a LIAR.
>>>>>
>>>>
>>>> You already know that you are the liar here and are
>>>> lying about not knowing this.
>>>>
>>>> _DDD()
>>>> [00002172] 55 push ebp ; housekeeping
>>>> [00002173] 8bec mov ebp,esp ; housekeeping
>>>> [00002175] 6872210000 push 00002172 ; push DDD
>>>> [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
>>>> [0000217f] 83c404 add esp,+04
>>>> [00002182] 5d pop ebp
>>>> [00002183] c3 ret
>>>> Size in bytes:(0018) [00002183]
>>>>
>>>> The call from DDD to HHH(DDD) when N steps of DDD are
>>>> correctly emulated by any pure function x86 emulator
>>>> HHH at machine address 0000217a cannot possibly return.
>>>>
>>>
>>> The problem is that the N steps emulated by HHH are not, and CAN NOT
>>> be the "behavior of the input",
>> They need not be the FULL behavior of the input.
>>
>> H correctly simulates its input D until
>> H correctly simulates its input D until
>> H correctly simulates its input D until
>
> And that can NOT be the "Behavior of the Input" as it depends on more
> that just the input.
>
DDD correctly emulated by HHH calls
an emulated HHH that emulates its own DDD
THIS SEQUENCE CANNOT POSSIBLY RETURN WHY PERSISTENTLY LIE ABOUT IT?
THIS SEQUENCE CANNOT POSSIBLY RETURN WHY PERSISTENTLY LIE ABOUT IT?
THIS SEQUENCE CANNOT POSSIBLY RETURN WHY PERSISTENTLY LIE ABOUT IT?
THIS SEQUENCE CANNOT POSSIBLY RETURN WHY PERSISTENTLY LIE ABOUT IT?
THIS SEQUENCE CANNOT POSSIBLY RETURN WHY PERSISTENTLY LIE ABOUT IT?
--
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-30 20:13 -0400 |
| Message-ID | <v5ssaq$1kfbq$2@i2pn2.org> |
| In reply to | #108059 |
On 6/30/24 8:00 PM, olcott wrote:
> On 6/30/2024 6:53 PM, Richard Damon wrote:
>> On 6/30/24 7:18 PM, olcott wrote:
>>> On 6/30/2024 6:14 PM, Richard Damon wrote:
>>>> On 6/30/24 6:41 PM, olcott wrote:
>>>>> On 6/30/2024 4:57 PM, Richard Damon wrote:
>>>>>> On 6/30/24 5:48 PM, olcott wrote:
>>>>>>> On 6/30/2024 2:31 PM, Richard Damon wrote:
>>>>>>>> On 6/30/24 1:18 PM, olcott wrote:
>>>>>>>>> On 6/30/2024 3:42 AM, Mikko wrote:
>>>>>>>>>> On 2024-06-29 16:09:19 +0000, olcott said:
>>>>>>>>>>
>>>>>>>>>>> People are still trying to get away with disagreeing with
>>>>>>>>>>> the semantics of the x86 language. That is isomorphic to
>>>>>>>>>>> trying to get away with disagreeing with arithmetic.
>>>>>>>>>>>
>>>>>>>>>>> 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.
>>>>>>>>>>>
>>>>>>>>>>> Simulating termination analyzers must report on the behavior
>>>>>>>>>>> that their finite string input specifies thus H0 must report
>>>>>>>>>>> that DDD correctly emulated by H0 remains stuck in recursive
>>>>>>>>>>> simulation.
>>>>>>>>>>>
>>>>>>>>>>> <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>
>>>>>>>>>>>
>>>>>>>>>>> People are trying to get away with disagreeing with the
>>>>>>>>>>> semantics
>>>>>>>>>>> of the x86 language by disagreeing that
>>>>>>>>>>>
>>>>>>>>>>> The call from DDD to HHH(DDD) when N steps of DDD are correctly
>>>>>>>>>>> emulated by any pure function x86 emulator HHH 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 HHH(DDD)
>>>>>>>>>>> [0000217f] 83c404 add esp,+04
>>>>>>>>>>> [00002182] 5d pop ebp
>>>>>>>>>>> [00002183] c3 ret
>>>>>>>>>>> Size in bytes:(0018) [00002183]
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> *A 100% complete and total rewrite of the prior paper*
>>>>>>>>>>> https://www.researchgate.net/publication/381636432_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_P
>>>>>>>>>>
>>>>>>>>>> Nothing above is or points to any evdence about the alleged
>>>>>>>>>> disagreement.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Of course not. I only said the actual truth.
>>>>>>>>>
>>>>>>>>> Richard just said that he affirms that when DDD correctly
>>>>>>>>> simulated by HHH calls HHH(DDD) that this call returns even
>>>>>>>>> though the semantics of the x86 language disagrees.
>>>>>>>>
>>>>>>>> What in the sematics of the x86 language, which INCLUDES that
>>>>>>>> ever instruction WILL be followed by the next instruction, says
>>>>>>>> that the HHH that is calld by DDD won't eventually return.
>>>>>>>>
>>>>>>>> Since you assert that HHH(DDD) called by main returns, then by
>>>>>>>> your requreement that HHH be a "pure function" ALL copies of it
>>>>>>>> will do the same thing.
>>>>>>>>
>>>>>>>> Yes, the EMULATION of HHH by HHH, but that can not be the
>>>>>>>> "behavior of the input" as that "behavior" depends on more than
>>>>>>>> just the input.
>>>>>>>>
>>>>>>>
>>>>>>> Therefore DDD correctly simulated by HHH DOES NOT HALT.
>>>>>>> Thus HHH correctly reports that DDD DOES NOT HALT.
>>>>>>>
>>>>>>
>>>>>> And then it doesn't correct emulate the input, and thus is a LIAR.
>>>>>>
>>>>>
>>>>> You already know that you are the liar here and are
>>>>> lying about not knowing this.
>>>>>
>>>>> _DDD()
>>>>> [00002172] 55 push ebp ; housekeeping
>>>>> [00002173] 8bec mov ebp,esp ; housekeeping
>>>>> [00002175] 6872210000 push 00002172 ; push DDD
>>>>> [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
>>>>> [0000217f] 83c404 add esp,+04
>>>>> [00002182] 5d pop ebp
>>>>> [00002183] c3 ret
>>>>> Size in bytes:(0018) [00002183]
>>>>>
>>>>> The call from DDD to HHH(DDD) when N steps of DDD are
>>>>> correctly emulated by any pure function x86 emulator
>>>>> HHH at machine address 0000217a cannot possibly return.
>>>>>
>>>>
>>>> The problem is that the N steps emulated by HHH are not, and CAN NOT
>>>> be the "behavior of the input",
>>> They need not be the FULL behavior of the input.
>>>
>>> H correctly simulates its input D until
>>> H correctly simulates its input D until
>>> H correctly simulates its input D until
>>
>> And that can NOT be the "Behavior of the Input" as it depends on more
>> that just the input.
>>
>
> DDD correctly emulated by HHH calls
> an emulated HHH that emulates its own DDD
>
> THIS SEQUENCE CANNOT POSSIBLY RETURN WHY PERSISTENTLY LIE ABOUT IT?
> THIS SEQUENCE CANNOT POSSIBLY RETURN WHY PERSISTENTLY LIE ABOUT IT?
> THIS SEQUENCE CANNOT POSSIBLY RETURN WHY PERSISTENTLY LIE ABOUT IT?
> THIS SEQUENCE CANNOT POSSIBLY RETURN WHY PERSISTENTLY LIE ABOUT IT?
> THIS SEQUENCE CANNOT POSSIBLY RETURN WHY PERSISTENTLY LIE ABOUT IT?
>
But it does, just after H gives up its simulation.
You have even show that with a simulation.
H(D,D) simulated D(D) for a bit, then gives up and returns 0.
D(D) calls H(D,D) and it then gets that same return (after H has given
up on it) and then returns itself.
You don't seem to understand that "Behavior" is not dependent on it
being observed by the simulation.
This is because your idea of "Truth" is just incorrect.
It is IMPOSSIBLE to define a partial behavior of the input that depends
on the decider, as that is NOT POSSIBLY a behavior of the INPUT (alone),
and that is what a decider MUST be asked about, and the mapping it is
computing only sees what that input represents.
H can only say that, as far as it simulated, H(D,D) never returned to D.
It can NOT say that H(D,D) will NEVER return to D, as that is just
FALSE, since H(D,D) has been claimed, and verified to return.
THis happens with H/D, H0/DD and HHH/DDD and all your variations. As
long as the function that the input calls does return from its call from
main, that function will also return to the program the input represents
(at least as long as you keep the "pure function" requirement, which you
need to be even close to Turing Equivalenet).
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-30 19:27 -0500 |
| Message-ID | <v5st66$o7ss$1@dont-email.me> |
| In reply to | #108060 |
On 6/30/2024 7:13 PM, Richard Damon wrote: > On 6/30/24 8:00 PM, olcott wrote: >> >> THIS SEQUENCE CANNOT POSSIBLY RETURN WHY PERSISTENTLY LIE ABOUT IT? >> THIS SEQUENCE CANNOT POSSIBLY RETURN WHY PERSISTENTLY LIE ABOUT IT? >> THIS SEQUENCE CANNOT POSSIBLY RETURN WHY PERSISTENTLY LIE ABOUT IT? >> THIS SEQUENCE CANNOT POSSIBLY RETURN WHY PERSISTENTLY LIE ABOUT IT? >> THIS SEQUENCE CANNOT POSSIBLY RETURN WHY PERSISTENTLY LIE ABOUT IT? >> > > But it does, just after H gives up its simulation. > > You have even show that with a simulation. > Liar Liar Pants on Fire !!! Liar Liar Pants on Fire !!! Liar Liar Pants on Fire !!! DDD correctly emulated by HHH calls an emulated HHH(DDD) that emulates its own DDD that calls an emulated HHH(DDD) that is either aborted at some point never returning or hits out-of-memory error never returning -- 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-30 20:44 -0400 |
| Message-ID | <v5su4q$1kfbr$11@i2pn2.org> |
| In reply to | #108061 |
On 6/30/24 8:27 PM, olcott wrote:
> On 6/30/2024 7:13 PM, Richard Damon wrote:
>> On 6/30/24 8:00 PM, olcott wrote:
>>>
>>> THIS SEQUENCE CANNOT POSSIBLY RETURN WHY PERSISTENTLY LIE ABOUT IT?
>>> THIS SEQUENCE CANNOT POSSIBLY RETURN WHY PERSISTENTLY LIE ABOUT IT?
>>> THIS SEQUENCE CANNOT POSSIBLY RETURN WHY PERSISTENTLY LIE ABOUT IT?
>>> THIS SEQUENCE CANNOT POSSIBLY RETURN WHY PERSISTENTLY LIE ABOUT IT?
>>> THIS SEQUENCE CANNOT POSSIBLY RETURN WHY PERSISTENTLY LIE ABOUT IT?
>>>
>>
>> But it does, just after H gives up its simulation.
>>
>> You have even show that with a simulation.
>>
>
> Liar Liar Pants on Fire !!!
> Liar Liar Pants on Fire !!!
> Liar Liar Pants on Fire !!!
Are you forgetting this message:
On 4/27/21 12:55 AM, olcott wrote:
Message-ID: <Teudndbu59GVBBr9nZ2dnUU7-V2dnZ2d@giganews.com>
> void H_Hat(u32 P)
> {
> u32 Input_Halts = Halts(P, P);
> if (Input_Halts)
> HERE: goto HERE;
> }
>
>
> int main()
> {
> H_Hat((u32)H_Hat);
> }
>
>
> _H_Hat()
> [00000b98](01) 55 push ebp
> [00000b99](02) 8bec mov ebp,esp
>
[00000b9b](01) 51 push ecx
> [00000b9c](03) 8b4508 mov eax,[ebp+08]
> [00000b9f](01) 50 push eax
> [00000ba0](03) 8b4d08 mov ecx,[ebp+08]
> [00000ba3](01) 51 push ecx
> [00000ba4](05) e88ffdffff call 00000938
> [00000ba9](03) 83c408 add esp,+08
> [00000bac](03) 8945fc mov [ebp-04],eax
> [00000baf](04) 837dfc00 cmp dword [ebp-04],+00
> [00000bb3](02) 7402 jz 00000bb7
> [00000bb5](02) ebfe jmp 00000bb5
> [00000bb7](02) 8be5 mov esp,ebp
> [00000bb9](01) 5d pop ebp
> [00000bba](01) c3 ret
> Size in bytes:(0035) [00000bba]
>
> _main()
> [00000bc8](01) 55 push ebp
> [00000bc9](02) 8bec mov ebp,esp
> [00000bcb](05) 68980b0000 push 00000b98
> [00000bd0](05) e8c3ffffff call 00000b98
> [00000bd5](03) 83c404 add esp,+04
> [00000bd8](02) 33c0 xor eax,eax
> [00000bda](01) 5d pop ebp
> [00000bdb](01) c3 ret
> Size in bytes:(0020) [00000bdb]
>
> ===============================
> ...[00000bc8][001015d4][00000000](01) 55 push ebp
> ...[00000bc9][001015d4][00000000](02) 8bec mov ebp,esp
> ...[00000bcb][001015d0][00000b98](05) 68980b0000 push 00000b98
> ...[00000bd0][001015cc][00000bd5](05) e8c3ffffff call 00000b98
> ...[00000b98][001015c8][001015d4](01) 55 push ebp
> ...[00000b99][001015c8][001015d4](02) 8bec mov ebp,esp
> ...[00000b9b][001015c4][00000000](01) 51 push ecx
> ...[00000b9c][001015c4][00000000](03) 8b4508 mov eax,[ebp+08]
> ...[00000b9f][001015c0][00000b98](01) 50 push eax
> ...[00000ba0][001015c0][00000b98](03) 8b4d08 mov ecx,[ebp+08]
> ...[00000ba3][001015bc][00000b98](01) 51 push ecx
> ...[00000ba4][001015b8][00000ba9](05) e88ffdffff call 00000938
> Begin Local Halt Decider Simulation at Machine Address:b98
> ...[00000b98][00211674][00211678](01) 55 push ebp
> ...[00000b99][00211674][00211678](02) 8bec mov ebp,esp
> ...[00000b9b][00211670][00201644](01) 51 push ecx
> ...[00000b9c][00211670][00201644](03) 8b4508 mov eax,[ebp+08]
> ...[00000b9f][0021166c][00000b98](01) 50 push eax
> ...[00000ba0][0021166c][00000b98](03) 8b4d08 mov ecx,[ebp+08]
> ...[00000ba3][00211668][00000b98](01) 51 push ecx
> ...[00000ba4][00211664][00000ba9](05) e88ffdffff call 00000938
> ...[00000b98][0025c09c][0025c0a0](01) 55 push ebp
> ...[00000b99][0025c09c][0025c0a0](02) 8bec mov ebp,esp
> ...[00000b9b][0025c098][0024c06c](01) 51 push ecx
> ...[00000b9c][0025c098][0024c06c](03) 8b4508 mov eax,[ebp+08]
> ...[00000b9f][0025c094][00000b98](01) 50 push eax
> ...[00000ba0][0025c094][00000b98](03) 8b4d08 mov ecx,[ebp+08]
> ...[00000ba3][0025c090][00000b98](01) 51 push ecx
> ...[00000ba4][0025c08c][00000ba9](05) e88ffdffff call 00000938
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
Above decision was from the call the Halts inside H_Hat, deciding that
H_Hat(H_Hat) seems to be non-halting, it then returns that answer and is
processed below:
> ...[00000ba9][001015c4][00000000](03) 83c408 add esp,+08
> ...[00000bac][001015c4][00000000](03) 8945fc mov [ebp-04],eax
> ...[00000baf][001015c4][00000000](04) 837dfc00 cmp dword [ebp-04],+00
> ...[00000bb3][001015c4][00000000](02) 7402 jz 00000bb7
> ...[00000bb7][001015c8][001015d4](02) 8be5 mov esp,ebp
> ...[00000bb9][001015cc][00000bd5](01) 5d pop ebp
> ...[00000bba][001015d0][00000b98](01) c3 ret
> ...[00000bd5][001015d4][00000000](03) 83c404 add esp,+04
> ...[00000bd8][001015d4][00000000](02) 33c0 xor eax,eax
> ...[00000bda][001015d8][00100000](01) 5d pop ebp
> ...[00000bdb][001015dc][00000098](01) c3 ret
SEE IT HALTED!
> Number_of_User_Instructions(39)
> Number of Instructions Executed(26567)
>
> DDD correctly emulated by HHH calls an emulated HHH(DDD)
> that emulates its own DDD that calls an emulated HHH(DDD)
> that is either aborted at some point never returning or
> hits out-of-memory error never returning
>
>
>
But HHH doesn't "Correctly Emulation" DDD by the definition that
provides the full behavior.
Since *THE* HHH DOES abort its emulation of *THIS* DDD, then THIS DDD
will return, just after this HHH has given up its emulation.
You LIE by confusing THIS HHH with another machine you try to also call
HHH, looking at a DIFFERENT input you deceptively try to also call DDD
that is different because it has been paired with that other HHH.
None of that other behavior matters for THIS DDD.
You are just proving you don't understand the meaning of the words you
are using, but you MAKE UP fake defintions out of your IGNORANCE and lie
that they are the right definitions.
Sorry, it looks like you are fated for a Hot time in the future.
[toc] | [prev] | [next] | [standalone]
Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
Back to top | Article view | comp.theory
csiph-web