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 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7 Next page →
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-30 20:03 -0500 |
| Message-ID | <v5sv8o$ogo5$1@dont-email.me> |
| In reply to | #108062 |
On 6/30/2024 7:44 PM, Richard Damon wrote:
> 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.
Your despicable lying strawman deception may work on fools
I am no fool.
I had to dumb this down because even the smartest
people here were overwhelmed:
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.
_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]
--
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 21:24 -0400 |
| Message-ID | <v5t0h8$1kfbr$12@i2pn2.org> |
| In reply to | #108063 |
On 6/30/24 9:03 PM, olcott wrote:
> On 6/30/2024 7:44 PM, Richard Damon wrote:
>> 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.
>
> Your despicable lying strawman deception may work on fools
> I am no fool.
>
> I had to dumb this down because even the smartest
> people here were overwhelmed:
>
> 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.
But that is NOT the "behavior of the input", and CAN NOT BE SO DEFINED.
"N Steps", where that N is determined by the decider, make the criteria
NOT VALID, as it isn't a criteria based on the input alone.
All you can claim is that HHH can not simulate the input to the return
statement, NOT that the "behavior of the input" is to not return.
Your claim is like the claim that "If cats were dogs, then we can show
that cat bark".
You are just demonstrating your utter ignorance of the basic principles
of the field.
There is not "Mathematical Mapping" of the INPUT ALONE that your
deciders can be trying to compute, so your criteria is just INVALID.
Your inability to see that just means that you are just to stupid or too
ignorant to know what you are talking about.
>
> _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]
>
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-30 20:38 -0500 |
| Message-ID | <v5t1af$omq9$1@dont-email.me> |
| In reply to | #108064 |
On 6/30/2024 8:24 PM, Richard Damon wrote: > On 6/30/24 9:03 PM, olcott wrote: >> On 6/30/2024 7:44 PM, Richard Damon wrote: >> >> I had to dumb this down because even the smartest >> people here were overwhelmed: >> >> 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. > > But that is NOT the "behavior of the input", and CAN NOT BE SO DEFINED. > I don't understand why you so stupidly lie about 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] DDD is correctly emulated by HHH which calls an emulated HHH(DDD) to repeat the process until 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 22:16 -0400 |
| Message-ID | <v5t3h4$1kfbr$13@i2pn2.org> |
| In reply to | #108065 |
On 6/30/24 9:38 PM, olcott wrote: > On 6/30/2024 8:24 PM, Richard Damon wrote: >> On 6/30/24 9:03 PM, olcott wrote: >> On 6/30/2024 7:44 PM, Richard >> Damon wrote: >>> >>> I had to dumb this down because even the smartest >>> people here were overwhelmed: >>> >>> 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. >> >> But that is NOT the "behavior of the input", and CAN NOT BE SO DEFINED. >> > > I don't understand why you so stupidly lie about 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] > > DDD is correctly emulated by HHH which calls an > emulated HHH(DDD) to repeat the process until aborted. > And, since the HHH that DDD calls will abort is emulation, it WILL return to DDD and it will return also. You seem to be confused by the fact that the outer HHH stopped looking at the behavior of its input when it aborted its simulation. HHH aborting its emulation DOES NOT STOP THE BEHAVIOR OF THE MACHINE IT WAS EMULATING. Also, "DDD" isn't just the bytes you list above, or your problem isn't properly defined, as then HHH can not correct emulate its input past the call instructions, which is a ERROR you keep on repeating. THe input to HHH must include ALL of the code of DDD and everything it calls, or it isn't a proper input, and you are just shown to have been lying for years about that.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-30 21:27 -0500 |
| Message-ID | <v5t470$t0hj$1@dont-email.me> |
| In reply to | #108066 |
On 6/30/2024 9:16 PM, Richard Damon wrote: > On 6/30/24 9:38 PM, olcott wrote: >> On 6/30/2024 8:24 PM, Richard Damon wrote: >>> On 6/30/24 9:03 PM, olcott wrote: >> On 6/30/2024 7:44 PM, Richard >>> Damon wrote: >>>> >>>> I had to dumb this down because even the smartest >>>> people here were overwhelmed: >>>> >>>> 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. >>> >>> But that is NOT the "behavior of the input", and CAN NOT BE SO DEFINED. >>> >> >> I don't understand why you so stupidly lie about 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] >> >> DDD is correctly emulated by HHH which calls an >> emulated HHH(DDD) to repeat the process until aborted. >> > > And, since the HHH that DDD calls will abort is emulation, it WILL > return to DDD and it will return also. > How can stopping the emulation the first four instructions of DDD possibly do anything besides stop? -- 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-07-01 07:08 -0400 |
| Message-ID | <v5u2o5$1mj7k$1@i2pn2.org> |
| In reply to | #108067 |
On 6/30/24 10:27 PM, olcott wrote: > On 6/30/2024 9:16 PM, Richard Damon wrote: >> On 6/30/24 9:38 PM, olcott wrote: >>> On 6/30/2024 8:24 PM, Richard Damon wrote: >>>> On 6/30/24 9:03 PM, olcott wrote: >> On 6/30/2024 7:44 PM, Richard >>>> Damon wrote: >>>>> >>>>> I had to dumb this down because even the smartest >>>>> people here were overwhelmed: >>>>> >>>>> 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. >>>> >>>> But that is NOT the "behavior of the input", and CAN NOT BE SO DEFINED. >>>> >>> >>> I don't understand why you so stupidly lie about 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] >>> >>> DDD is correctly emulated by HHH which calls an >>> emulated HHH(DDD) to repeat the process until aborted. >>> >> >> And, since the HHH that DDD calls will abort is emulation, it WILL >> return to DDD and it will return also. >> > > How can stopping the emulation the first four > instructions of DDD possibly do anything besides stop? > The emulation stops, and the emulating behavor of HHH stops, but not the behavior of the input. You don't seem to understand that fact, perhaps because you confuse Truth with Knowledge. Emulation doesn't create or define the behavior of the input, that existed at the moment the program prepresented by the input was created. Emulation REVEALS that behvior to the emulator. The only behavior it creates is that of the emulator, not the emulated. You seem to not understand that property of programs, perhaps because you don't understand determinism, which requires a good understanding of what Truth is.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-07-01 07:49 -0500 |
| Message-ID | <v5u8li$12udb$3@dont-email.me> |
| In reply to | #108074 |
On 7/1/2024 6:08 AM, Richard Damon wrote: > On 6/30/24 10:27 PM, olcott wrote: >> On 6/30/2024 9:16 PM, Richard Damon wrote: >>> On 6/30/24 9:38 PM, olcott wrote: >>>> On 6/30/2024 8:24 PM, Richard Damon wrote: >>>>> On 6/30/24 9:03 PM, olcott wrote: >> On 6/30/2024 7:44 PM, Richard >>>>> Damon wrote: >>>>>> >>>>>> I had to dumb this down because even the smartest >>>>>> people here were overwhelmed: >>>>>> >>>>>> 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. >>>>> >>>>> But that is NOT the "behavior of the input", and CAN NOT BE SO >>>>> DEFINED. >>>>> >>>> >>>> I don't understand why you so stupidly lie about 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] >>>> >>>> DDD is correctly emulated by HHH which calls an >>>> emulated HHH(DDD) to repeat the process until aborted. >>>> >>> >>> And, since the HHH that DDD calls will abort is emulation, it WILL >>> return to DDD and it will return also. >>> >> >> How can stopping the emulation the first four >> instructions of DDD possibly do anything besides stop? >> > > The emulation stops, and the emulating behavor of HHH stops, but not the > behavior of the input. When DDD is no longer being emulated all of its behavior stops. DDD is the input. -- Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | joes <noreply@example.org> |
|---|---|
| Date | 2024-07-01 15:57 +0000 |
| Subject | Re: olcott is still disagreeing with the semantics of simulation |
| Message-ID | <v5ujm6$1na1q$3@i2pn2.org> |
| In reply to | #108078 |
Am Mon, 01 Jul 2024 07:49:54 -0500 schrieb olcott: > On 7/1/2024 6:08 AM, Richard Damon wrote: >> On 6/30/24 10:27 PM, olcott wrote: >>> On 6/30/2024 9:16 PM, Richard Damon wrote: >>>> On 6/30/24 9:38 PM, olcott wrote: >>>>> On 6/30/2024 8:24 PM, Richard Damon wrote: >>>>>> On 6/30/24 9:03 PM, olcott wrote: >> On 6/30/2024 7:44 PM, Richard >>>>>> Damon wrote: >>>>>>> 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. >>>>>> But that is NOT the "behavior of the input", and CAN NOT BE SO >>>>>> DEFINED. >>>>> DDD is emulated by HHH which calls an emulated HHH(DDD) to >>>>> repeat the process until aborted. >>>> And, since the HHH that DDD calls will abort is emulation, it WILL >>>> return to DDD and it will return also. Right. >> The emulation stops, and the emulating behavor of HHH stops, but not >> the behavior of the input. > When DDD is no longer being emulated all of its behavior stops. DDD is > the input. Again: emulating does not change what the input does of its own. Aborting an emulation is premature, as the input does not contain an abort. -- Am Fri, 28 Jun 2024 16:52:17 -0500 schrieb olcott: Objectively I am a genius.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-07-01 11:03 -0500 |
| Subject | Re: olcott is still disagreeing with the semantics of simulation |
| Message-ID | <v5ujvn$1550s$1@dont-email.me> |
| In reply to | #108093 |
On 7/1/2024 10:57 AM, joes wrote:
> Am Mon, 01 Jul 2024 07:49:54 -0500 schrieb olcott:
>> On 7/1/2024 6:08 AM, Richard Damon wrote:
>>> On 6/30/24 10:27 PM, olcott wrote:
>>>> On 6/30/2024 9:16 PM, Richard Damon wrote:
>>>>> On 6/30/24 9:38 PM, olcott wrote:
>>>>>> On 6/30/2024 8:24 PM, Richard Damon wrote:
>>>>>>> On 6/30/24 9:03 PM, olcott wrote: >> On 6/30/2024 7:44 PM, Richard
>>>>>>> Damon wrote:
>
>>>>>>>> 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.
>>>>>>> But that is NOT the "behavior of the input", and CAN NOT BE SO
>>>>>>> DEFINED.
>
>>>>>> DDD is emulated by HHH which calls an emulated HHH(DDD) to
>>>>>> repeat the process until aborted.
>>>>> And, since the HHH that DDD calls will abort is emulation, it WILL
>>>>> return to DDD and it will return also.
> Right.
>
>>> The emulation stops, and the emulating behavor of HHH stops, but not
>>> the behavior of the input.
>> When DDD is no longer being emulated all of its behavior stops. DDD is
>> the input.
> Again: emulating does not change what the input does of its own. Aborting
> an emulation is premature, as the input does not contain an abort.
>
*The title of this post is a lie*
*The title of this post is a lie*
*The title of this post is a lie*
void Infinite_Loop()
{
HERE: goto HERE;
}
void Infinite_Recursion()
{
Infinite_Recursion();
}
void DDD()
{
HHH(DDD);
}
int main()
{
HHH(Infinite_Loop);
HHH(Infinite_Recursion);
HHH(DDD);
}
*Each one of these cases meets this criteria*
<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>
--
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-07-01 20:38 -0400 |
| Subject | Re: olcott is still disagreeing with the semantics of simulation |
| Message-ID | <v5vi6d$1oanb$5@i2pn2.org> |
| In reply to | #108095 |
On 7/1/24 12:03 PM, olcott wrote:
> On 7/1/2024 10:57 AM, joes wrote:
>> Am Mon, 01 Jul 2024 07:49:54 -0500 schrieb olcott:
>>> On 7/1/2024 6:08 AM, Richard Damon wrote:
>>>> On 6/30/24 10:27 PM, olcott wrote:
>>>>> On 6/30/2024 9:16 PM, Richard Damon wrote:
>>>>>> On 6/30/24 9:38 PM, olcott wrote:
>>>>>>> On 6/30/2024 8:24 PM, Richard Damon wrote:
>>>>>>>> On 6/30/24 9:03 PM, olcott wrote: >> On 6/30/2024 7:44 PM, Richard
>>>>>>>> Damon wrote:
>>
>>>>>>>>> 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.
>>>>>>>> But that is NOT the "behavior of the input", and CAN NOT BE SO
>>>>>>>> DEFINED.
>>
>>>>>>> DDD is emulated by HHH which calls an emulated HHH(DDD) to
>>>>>>> repeat the process until aborted.
>>>>>> And, since the HHH that DDD calls will abort is emulation, it WILL
>>>>>> return to DDD and it will return also.
>> Right.
>>
>>>> The emulation stops, and the emulating behavor of HHH stops, but not
>>>> the behavior of the input.
>>> When DDD is no longer being emulated all of its behavior stops. DDD is
>>> the input.
>> Again: emulating does not change what the input does of its own. Aborting
>> an emulation is premature, as the input does not contain an abort.
>>
>
> *The title of this post is a lie*
> *The title of this post is a lie*
> *The title of this post is a lie*
Nope, it is the TRUTH.
OLCOTT is the one lying.
>
> void Infinite_Loop()
> {
> HERE: goto HERE;
> }
>
> void Infinite_Recursion()
> {
> Infinite_Recursion();
> }
>
> void DDD()
> {
> HHH(DDD);
> }
>
> int main()
> {
> HHH(Infinite_Loop);
> HHH(Infinite_Recursion);
> HHH(DDD);
> }
>
> *Each one of these cases meets this criteria*
>
> <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 since the definition of a "Correct Simulation" that Professor
Sipser would use (as with most of the world) is one that recreates the
full behavior of the program represented by the input, which means it
NEVER stops until it reaches an end state, and your H doesn't do that,
or correctly predicts what such a simulation of the input would do, you
can't use the second paragraph, so when it aborts, it can get the answer
wrong, which it does.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-07-01 20:41 -0500 |
| Subject | Re: olcott is still disagreeing with the semantics of simulation |
| Message-ID | <v5vlro$1b0k9$5@dont-email.me> |
| In reply to | #108106 |
On 7/1/2024 7:38 PM, Richard Damon wrote:
> On 7/1/24 12:03 PM, olcott wrote:
>> On 7/1/2024 10:57 AM, joes wrote:
>>> Am Mon, 01 Jul 2024 07:49:54 -0500 schrieb olcott:
>>>> On 7/1/2024 6:08 AM, Richard Damon wrote:
>>>>> On 6/30/24 10:27 PM, olcott wrote:
>>>>>> On 6/30/2024 9:16 PM, Richard Damon wrote:
>>>>>>> On 6/30/24 9:38 PM, olcott wrote:
>>>>>>>> On 6/30/2024 8:24 PM, Richard Damon wrote:
>>>>>>>>> On 6/30/24 9:03 PM, olcott wrote: >> On 6/30/2024 7:44 PM, Richard
>>>>>>>>> Damon wrote:
>>>
>>>>>>>>>> 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.
>>>>>>>>> But that is NOT the "behavior of the input", and CAN NOT BE SO
>>>>>>>>> DEFINED.
>>>
>>>>>>>> DDD is emulated by HHH which calls an emulated HHH(DDD) to
>>>>>>>> repeat the process until aborted.
>>>>>>> And, since the HHH that DDD calls will abort is emulation, it WILL
>>>>>>> return to DDD and it will return also.
>>> Right.
>>>
>>>>> The emulation stops, and the emulating behavor of HHH stops, but not
>>>>> the behavior of the input.
>>>> When DDD is no longer being emulated all of its behavior stops. DDD is
>>>> the input.
>>> Again: emulating does not change what the input does of its own.
>>> Aborting
>>> an emulation is premature, as the input does not contain an abort.
>>>
>>
>> *The title of this post is a lie*
>> *The title of this post is a lie*
>> *The title of this post is a lie*
>
> Nope, it is the TRUTH.
>
> OLCOTT is the one lying.
>
>>
>> void Infinite_Loop()
>> {
>> HERE: goto HERE;
>> }
>>
>> void Infinite_Recursion()
>> {
>> Infinite_Recursion();
>> }
>>
>> void DDD()
>> {
>> HHH(DDD);
>> }
>>
>> int main()
>> {
>> HHH(Infinite_Loop);
>> HHH(Infinite_Recursion);
>> HHH(DDD);
>> }
>>
>> *Each one of these cases meets this criteria*
>>
>> <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 since the definition of a "Correct Simulation" that Professor
> Sipser would use (as with most of the world) is one that recreates the
> full behavior of the program represented by the input,
No Professor Sipser would agree to 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]
DDD is correctly emulated by HHH which calls an
emulated HHH(DDD) to repeat the process until 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-07-01 21:54 -0400 |
| Subject | Re: olcott is still disagreeing with the semantics of simulation |
| Message-ID | <v5vmkh$1oana$1@i2pn2.org> |
| In reply to | #108114 |
On 7/1/24 9:41 PM, olcott wrote:
> On 7/1/2024 7:38 PM, Richard Damon wrote:
>> On 7/1/24 12:03 PM, olcott wrote:
>>> On 7/1/2024 10:57 AM, joes wrote:
>>>> Am Mon, 01 Jul 2024 07:49:54 -0500 schrieb olcott:
>>>>> On 7/1/2024 6:08 AM, Richard Damon wrote:
>>>>>> On 6/30/24 10:27 PM, olcott wrote:
>>>>>>> On 6/30/2024 9:16 PM, Richard Damon wrote:
>>>>>>>> On 6/30/24 9:38 PM, olcott wrote:
>>>>>>>>> On 6/30/2024 8:24 PM, Richard Damon wrote:
>>>>>>>>>> On 6/30/24 9:03 PM, olcott wrote: >> On 6/30/2024 7:44 PM,
>>>>>>>>>> Richard
>>>>>>>>>> Damon wrote:
>>>>
>>>>>>>>>>> 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.
>>>>>>>>>> But that is NOT the "behavior of the input", and CAN NOT BE SO
>>>>>>>>>> DEFINED.
>>>>
>>>>>>>>> DDD is emulated by HHH which calls an emulated HHH(DDD) to
>>>>>>>>> repeat the process until aborted.
>>>>>>>> And, since the HHH that DDD calls will abort is emulation, it WILL
>>>>>>>> return to DDD and it will return also.
>>>> Right.
>>>>
>>>>>> The emulation stops, and the emulating behavor of HHH stops, but not
>>>>>> the behavior of the input.
>>>>> When DDD is no longer being emulated all of its behavior stops. DDD is
>>>>> the input.
>>>> Again: emulating does not change what the input does of its own.
>>>> Aborting
>>>> an emulation is premature, as the input does not contain an abort.
>>>>
>>>
>>> *The title of this post is a lie*
>>> *The title of this post is a lie*
>>> *The title of this post is a lie*
>>
>> Nope, it is the TRUTH.
>>
>> OLCOTT is the one lying.
>>
>>>
>>> void Infinite_Loop()
>>> {
>>> HERE: goto HERE;
>>> }
>>>
>>> void Infinite_Recursion()
>>> {
>>> Infinite_Recursion();
>>> }
>>>
>>> void DDD()
>>> {
>>> HHH(DDD);
>>> }
>>>
>>> int main()
>>> {
>>> HHH(Infinite_Loop);
>>> HHH(Infinite_Recursion);
>>> HHH(DDD);
>>> }
>>>
>>> *Each one of these cases meets this criteria*
>>>
>>> <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 since the definition of a "Correct Simulation" that
>> Professor Sipser would use (as with most of the world) is one that
>> recreates the full behavior of the program represented by the input,
>
> No Professor Sipser would agree to 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]
>
> DDD is correctly emulated by HHH which calls an
> emulated HHH(DDD) to repeat the process until aborted.
>
>
Why do you say that?
He would problem just laugh at you and point out that the input is
incorrect because is isn't actually the representation of a program,
since it references something that isn't part of it.
You are just so stupid you think you know what people much smarter than
you would think.
I don't care what you IQ test scored, It seems you might now fail a
simple cognitive reasoning test, since you show you can't put simple
facts together without adding ideas you make up out of your own lies.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-07-01 21:18 -0500 |
| Subject | Re: olcott is still disagreeing with the semantics of simulation |
| Message-ID | <v5vo12$1f17p$2@dont-email.me> |
| In reply to | #108117 |
On 7/1/2024 8:54 PM, Richard Damon wrote:
> On 7/1/24 9:41 PM, olcott wrote:
>> On 7/1/2024 7:38 PM, Richard Damon wrote:
>>> On 7/1/24 12:03 PM, olcott wrote:
>>>> On 7/1/2024 10:57 AM, joes wrote:
>>>>> Am Mon, 01 Jul 2024 07:49:54 -0500 schrieb olcott:
>>>>>> On 7/1/2024 6:08 AM, Richard Damon wrote:
>>>>>>> On 6/30/24 10:27 PM, olcott wrote:
>>>>>>>> On 6/30/2024 9:16 PM, Richard Damon wrote:
>>>>>>>>> On 6/30/24 9:38 PM, olcott wrote:
>>>>>>>>>> On 6/30/2024 8:24 PM, Richard Damon wrote:
>>>>>>>>>>> On 6/30/24 9:03 PM, olcott wrote: >> On 6/30/2024 7:44 PM,
>>>>>>>>>>> Richard
>>>>>>>>>>> Damon wrote:
>>>>>
>>>>>>>>>>>> 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.
>>>>>>>>>>> But that is NOT the "behavior of the input", and CAN NOT BE SO
>>>>>>>>>>> DEFINED.
>>>>>
>>>>>>>>>> DDD is emulated by HHH which calls an emulated HHH(DDD) to
>>>>>>>>>> repeat the process until aborted.
>>>>>>>>> And, since the HHH that DDD calls will abort is emulation, it WILL
>>>>>>>>> return to DDD and it will return also.
>>>>> Right.
>>>>>
>>>>>>> The emulation stops, and the emulating behavor of HHH stops, but not
>>>>>>> the behavior of the input.
>>>>>> When DDD is no longer being emulated all of its behavior stops.
>>>>>> DDD is
>>>>>> the input.
>>>>> Again: emulating does not change what the input does of its own.
>>>>> Aborting
>>>>> an emulation is premature, as the input does not contain an abort.
>>>>>
>>>>
>>>> *The title of this post is a lie*
>>>> *The title of this post is a lie*
>>>> *The title of this post is a lie*
>>>
>>> Nope, it is the TRUTH.
>>>
>>> OLCOTT is the one lying.
>>>
>>>>
>>>> void Infinite_Loop()
>>>> {
>>>> HERE: goto HERE;
>>>> }
>>>>
>>>> void Infinite_Recursion()
>>>> {
>>>> Infinite_Recursion();
>>>> }
>>>>
>>>> void DDD()
>>>> {
>>>> HHH(DDD);
>>>> }
>>>>
>>>> int main()
>>>> {
>>>> HHH(Infinite_Loop);
>>>> HHH(Infinite_Recursion);
>>>> HHH(DDD);
>>>> }
>>>>
>>>> *Each one of these cases meets this criteria*
>>>>
>>>> <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 since the definition of a "Correct Simulation" that
>>> Professor Sipser would use (as with most of the world) is one that
>>> recreates the full behavior of the program represented by the input,
>>
>> No Professor Sipser would agree to 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]
>>
>> DDD is correctly emulated by HHH which calls an
>> emulated HHH(DDD) to repeat the process until aborted.
>>
>>
>
> Why do you say that?
>
Because he already knows the truth of it.
Now that I am getting closer to death I may contact him again.
I have to perfect my new paper before doing this.
*Termination Analyzer H is Not Fooled by Pathological Input P*
https://www.researchgate.net/publication/381636432_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_P
--
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-07-01 22:38 -0400 |
| Subject | Re: olcott is still disagreeing with the semantics of simulation |
| Message-ID | <v5vp75$1oana$6@i2pn2.org> |
| In reply to | #108122 |
On 7/1/24 10:18 PM, olcott wrote:
> On 7/1/2024 8:54 PM, Richard Damon wrote:
>> On 7/1/24 9:41 PM, olcott wrote:
>>> On 7/1/2024 7:38 PM, Richard Damon wrote:
>>>> On 7/1/24 12:03 PM, olcott wrote:
>>>>> On 7/1/2024 10:57 AM, joes wrote:
>>>>>> Am Mon, 01 Jul 2024 07:49:54 -0500 schrieb olcott:
>>>>>>> On 7/1/2024 6:08 AM, Richard Damon wrote:
>>>>>>>> On 6/30/24 10:27 PM, olcott wrote:
>>>>>>>>> On 6/30/2024 9:16 PM, Richard Damon wrote:
>>>>>>>>>> On 6/30/24 9:38 PM, olcott wrote:
>>>>>>>>>>> On 6/30/2024 8:24 PM, Richard Damon wrote:
>>>>>>>>>>>> On 6/30/24 9:03 PM, olcott wrote: >> On 6/30/2024 7:44 PM,
>>>>>>>>>>>> Richard
>>>>>>>>>>>> Damon wrote:
>>>>>>
>>>>>>>>>>>>> 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.
>>>>>>>>>>>> But that is NOT the "behavior of the input", and CAN NOT BE SO
>>>>>>>>>>>> DEFINED.
>>>>>>
>>>>>>>>>>> DDD is emulated by HHH which calls an emulated HHH(DDD) to
>>>>>>>>>>> repeat the process until aborted.
>>>>>>>>>> And, since the HHH that DDD calls will abort is emulation, it
>>>>>>>>>> WILL
>>>>>>>>>> return to DDD and it will return also.
>>>>>> Right.
>>>>>>
>>>>>>>> The emulation stops, and the emulating behavor of HHH stops, but
>>>>>>>> not
>>>>>>>> the behavior of the input.
>>>>>>> When DDD is no longer being emulated all of its behavior stops.
>>>>>>> DDD is
>>>>>>> the input.
>>>>>> Again: emulating does not change what the input does of its own.
>>>>>> Aborting
>>>>>> an emulation is premature, as the input does not contain an abort.
>>>>>>
>>>>>
>>>>> *The title of this post is a lie*
>>>>> *The title of this post is a lie*
>>>>> *The title of this post is a lie*
>>>>
>>>> Nope, it is the TRUTH.
>>>>
>>>> OLCOTT is the one lying.
>>>>
>>>>>
>>>>> void Infinite_Loop()
>>>>> {
>>>>> HERE: goto HERE;
>>>>> }
>>>>>
>>>>> void Infinite_Recursion()
>>>>> {
>>>>> Infinite_Recursion();
>>>>> }
>>>>>
>>>>> void DDD()
>>>>> {
>>>>> HHH(DDD);
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>> HHH(Infinite_Loop);
>>>>> HHH(Infinite_Recursion);
>>>>> HHH(DDD);
>>>>> }
>>>>>
>>>>> *Each one of these cases meets this criteria*
>>>>>
>>>>> <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 since the definition of a "Correct Simulation" that
>>>> Professor Sipser would use (as with most of the world) is one that
>>>> recreates the full behavior of the program represented by the input,
>>>
>>> No Professor Sipser would agree to 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]
>>>
>>> DDD is correctly emulated by HHH which calls an
>>> emulated HHH(DDD) to repeat the process until aborted.
>>>
>>>
>>
>> Why do you say that?
>>
>
> Because he already knows the truth of it.
> Now that I am getting closer to death I may contact him again.
> I have to perfect my new paper before doing this.
>
> *Termination Analyzer H is Not Fooled by Pathological Input P*
> https://www.researchgate.net/publication/381636432_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_P
>
In other words, your logic presumes that it knows better than the person
who spoke what he means.,
Just shows you are a DAMNED LIAR.
You may be unplesantly surprized at his answer, or maybe he will just
lay a bigger trap for you and let you just totally embarass yourself
with your paper.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-07-01 20:38 -0400 |
| Message-ID | <v5vi5p$1oanb$1@i2pn2.org> |
| In reply to | #108078 |
On 7/1/24 8:49 AM, olcott wrote: > On 7/1/2024 6:08 AM, Richard Damon wrote: >> On 6/30/24 10:27 PM, olcott wrote: >>> On 6/30/2024 9:16 PM, Richard Damon wrote: >>>> On 6/30/24 9:38 PM, olcott wrote: >>>>> On 6/30/2024 8:24 PM, Richard Damon wrote: >>>>>> On 6/30/24 9:03 PM, olcott wrote: >> On 6/30/2024 7:44 PM, Richard >>>>>> Damon wrote: >>>>>>> >>>>>>> I had to dumb this down because even the smartest >>>>>>> people here were overwhelmed: >>>>>>> >>>>>>> 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. >>>>>> >>>>>> But that is NOT the "behavior of the input", and CAN NOT BE SO >>>>>> DEFINED. >>>>>> >>>>> >>>>> I don't understand why you so stupidly lie about 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] >>>>> >>>>> DDD is correctly emulated by HHH which calls an >>>>> emulated HHH(DDD) to repeat the process until aborted. >>>>> >>>> >>>> And, since the HHH that DDD calls will abort is emulation, it WILL >>>> return to DDD and it will return also. >>>> >>> >>> How can stopping the emulation the first four >>> instructions of DDD possibly do anything besides stop? >>> >> >> The emulation stops, and the emulating behavor of HHH stops, but not >> the behavior of the input. > > When DDD is no longer being emulated all of its behavior > stops. DDD is the input. > Nope, the emulation of DDD may stop, but the BEHAIVOR of THE INPUT, which isn't dependent on the emulator looking at it, continues, since it MUST due the semantics of the x86 instruction set. You just are stuck in your world of fantasy, and have lost contact with REALITY.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-07-01 20:32 -0500 |
| Message-ID | <v5vlb2$1b0k9$2@dont-email.me> |
| In reply to | #108102 |
On 7/1/2024 7:38 PM, Richard Damon wrote: > On 7/1/24 8:49 AM, olcott wrote: >> On 7/1/2024 6:08 AM, Richard Damon wrote: >>> On 6/30/24 10:27 PM, olcott wrote: >>>> On 6/30/2024 9:16 PM, Richard Damon wrote: >>>>> On 6/30/24 9:38 PM, olcott wrote: >>>>>> On 6/30/2024 8:24 PM, Richard Damon wrote: >>>>>>> On 6/30/24 9:03 PM, olcott wrote: >> On 6/30/2024 7:44 PM, >>>>>>> Richard Damon wrote: >>>>>>>> >>>>>>>> I had to dumb this down because even the smartest >>>>>>>> people here were overwhelmed: >>>>>>>> >>>>>>>> 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. >>>>>>> >>>>>>> But that is NOT the "behavior of the input", and CAN NOT BE SO >>>>>>> DEFINED. >>>>>>> >>>>>> >>>>>> I don't understand why you so stupidly lie about 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] >>>>>> >>>>>> DDD is correctly emulated by HHH which calls an >>>>>> emulated HHH(DDD) to repeat the process until aborted. >>>>>> >>>>> >>>>> And, since the HHH that DDD calls will abort is emulation, it WILL >>>>> return to DDD and it will return also. >>>>> >>>> >>>> How can stopping the emulation the first four >>>> instructions of DDD possibly do anything besides stop? >>>> >>> >>> The emulation stops, and the emulating behavor of HHH stops, but not >>> the behavior of the input. >> >> When DDD is no longer being emulated all of its behavior >> stops. DDD is the input. >> > > Nope, the emulation of DDD may stop, but the BEHAIVOR of THE INPUT, > which isn't dependent on the emulator looking at it, That is a stupid lie. In input is a static string when not emulated and only becomes a dynamic process when emulated. *Anyone with anything like a BSCS would know that* -- 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-07-01 21:58 -0400 |
| Message-ID | <v5vmsa$1oana$2@i2pn2.org> |
| In reply to | #108111 |
On 7/1/24 9:32 PM, olcott wrote: > On 7/1/2024 7:38 PM, Richard Damon wrote: >> On 7/1/24 8:49 AM, olcott wrote: >>> On 7/1/2024 6:08 AM, Richard Damon wrote: >>>> On 6/30/24 10:27 PM, olcott wrote: >>>>> On 6/30/2024 9:16 PM, Richard Damon wrote: >>>>>> On 6/30/24 9:38 PM, olcott wrote: >>>>>>> On 6/30/2024 8:24 PM, Richard Damon wrote: >>>>>>>> On 6/30/24 9:03 PM, olcott wrote: >> On 6/30/2024 7:44 PM, >>>>>>>> Richard Damon wrote: >>>>>>>>> >>>>>>>>> I had to dumb this down because even the smartest >>>>>>>>> people here were overwhelmed: >>>>>>>>> >>>>>>>>> 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. >>>>>>>> >>>>>>>> But that is NOT the "behavior of the input", and CAN NOT BE SO >>>>>>>> DEFINED. >>>>>>>> >>>>>>> >>>>>>> I don't understand why you so stupidly lie about 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] >>>>>>> >>>>>>> DDD is correctly emulated by HHH which calls an >>>>>>> emulated HHH(DDD) to repeat the process until aborted. >>>>>>> >>>>>> >>>>>> And, since the HHH that DDD calls will abort is emulation, it WILL >>>>>> return to DDD and it will return also. >>>>>> >>>>> >>>>> How can stopping the emulation the first four >>>>> instructions of DDD possibly do anything besides stop? >>>>> >>>> >>>> The emulation stops, and the emulating behavor of HHH stops, but not >>>> the behavior of the input. >>> >>> When DDD is no longer being emulated all of its behavior >>> stops. DDD is the input. >>> >> >> Nope, the emulation of DDD may stop, but the BEHAIVOR of THE INPUT, >> which isn't dependent on the emulator looking at it, > > That is a stupid lie. In input is a static string when not > emulated and only becomes a dynamic process when emulated. > *Anyone with anything like a BSCS would know that* > Nope, that CAN'T be the definition of the "behvior of the Input" but of the behavior of the "input processed by this machine". "Behavior" is a term used on MACHINES (so in the above case, the machine is the DECIDER, not the input). When you talk about the "behavior of the input" that needs to represent the behavior of the machine the input represents. You just don't seem to understand the basics of the field, because you your enforce ignorance.
[toc] | [prev] | [next] | [standalone]
| From | joes <noreply@example.org> |
|---|---|
| Date | 2024-07-03 14:25 +0000 |
| Message-ID | <3aed9291dd746be1c3d8760a16b0f5ddb279313f@i2pn2.org> |
| In reply to | #108111 |
Am Mon, 01 Jul 2024 20:32:18 -0500 schrieb olcott: > On 7/1/2024 7:38 PM, Richard Damon wrote: >> On 7/1/24 8:49 AM, olcott wrote: >>> On 7/1/2024 6:08 AM, Richard Damon wrote: >>>> On 6/30/24 10:27 PM, olcott wrote: >>>>> On 6/30/2024 9:16 PM, Richard Damon wrote: >>>>>> On 6/30/24 9:38 PM, olcott wrote: >>>>>>> On 6/30/2024 8:24 PM, Richard Damon wrote: >>>>>>>> On 6/30/24 9:03 PM, olcott wrote: >> On 6/30/2024 7:44 PM, >>>>>>>> Richard Damon wrote: >>>>>> And, since the HHH that DDD calls will abort is emulation, it WILL >>>>>> return to DDD and it will return also. >>>>>> >>>>> How can stopping the emulation the first four instructions of DDD >>>>> possibly do anything besides stop? >>>>> >>>> The emulation stops, and the emulating behavor of HHH stops, but not >>>> the behavior of the input. >>> >>> When DDD is no longer being emulated all of its behavior stops. DDD is >>> the input. >>> >> Nope, the emulation of DDD may stop, but the BEHAIVOR of THE INPUT, >> which isn't dependent on the emulator looking at it, > > That is a stupid lie. In input is a static string when not emulated and > only becomes a dynamic process when emulated. Defined that way, there is no notion of the input halting or not AT ALL. If you abort, you are not simulating the input, because it doesn’t contain an abort. -- Am Fri, 28 Jun 2024 16:52:17 -0500 schrieb olcott: Objectively I am a genius.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-07-01 20:38 -0400 |
| Message-ID | <v5vi6t$1oanb$8@i2pn2.org> |
| In reply to | #108078 |
On 7/1/24 8:49 AM, olcott wrote: > On 7/1/2024 6:08 AM, Richard Damon wrote: >> On 6/30/24 10:27 PM, olcott wrote: >>> On 6/30/2024 9:16 PM, Richard Damon wrote: >>>> On 6/30/24 9:38 PM, olcott wrote: >>>>> On 6/30/2024 8:24 PM, Richard Damon wrote: >>>>>> On 6/30/24 9:03 PM, olcott wrote: >> On 6/30/2024 7:44 PM, Richard >>>>>> Damon wrote: >>>>>>> >>>>>>> I had to dumb this down because even the smartest >>>>>>> people here were overwhelmed: >>>>>>> >>>>>>> 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. >>>>>> >>>>>> But that is NOT the "behavior of the input", and CAN NOT BE SO >>>>>> DEFINED. >>>>>> >>>>> >>>>> I don't understand why you so stupidly lie about 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] >>>>> >>>>> DDD is correctly emulated by HHH which calls an >>>>> emulated HHH(DDD) to repeat the process until aborted. >>>>> >>>> >>>> And, since the HHH that DDD calls will abort is emulation, it WILL >>>> return to DDD and it will return also. >>>> >>> >>> How can stopping the emulation the first four >>> instructions of DDD possibly do anything besides stop? >>> >> >> The emulation stops, and the emulating behavor of HHH stops, but not >> the behavior of the input. > > When DDD is no longer being emulated all of its behavior > stops. DDD is the input. > Nope. YOU don't understand the meaning of the terms, perhaps because you don't understand what REALITY is. The "Behavior of the Input" comes from the input alone, and doesn't depend on the emulator doing anything. The emulation only REVEALS the behavior to the decider, not create it.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-07-01 20:42 -0500 |
| Message-ID | <v5vlv2$1b0k9$6@dont-email.me> |
| In reply to | #108109 |
On 7/1/2024 7:38 PM, Richard Damon wrote: > On 7/1/24 8:49 AM, olcott wrote: >> On 7/1/2024 6:08 AM, Richard Damon wrote: >>> On 6/30/24 10:27 PM, olcott wrote: >>>> On 6/30/2024 9:16 PM, Richard Damon wrote: >>>>> On 6/30/24 9:38 PM, olcott wrote: >>>>>> On 6/30/2024 8:24 PM, Richard Damon wrote: >>>>>>> On 6/30/24 9:03 PM, olcott wrote: >> On 6/30/2024 7:44 PM, >>>>>>> Richard Damon wrote: >>>>>>>> >>>>>>>> I had to dumb this down because even the smartest >>>>>>>> people here were overwhelmed: >>>>>>>> >>>>>>>> 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. >>>>>>> >>>>>>> But that is NOT the "behavior of the input", and CAN NOT BE SO >>>>>>> DEFINED. >>>>>>> >>>>>> >>>>>> I don't understand why you so stupidly lie about 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] >>>>>> >>>>>> DDD is correctly emulated by HHH which calls an >>>>>> emulated HHH(DDD) to repeat the process until aborted. >>>>>> >>>>> >>>>> And, since the HHH that DDD calls will abort is emulation, it WILL >>>>> return to DDD and it will return also. >>>>> >>>> >>>> How can stopping the emulation the first four >>>> instructions of DDD possibly do anything besides stop? >>>> >>> >>> The emulation stops, and the emulating behavor of HHH stops, but not >>> the behavior of the input. >> >> When DDD is no longer being emulated all of its behavior >> stops. DDD is the input. >> > > Nope. YOU don't understand the meaning of the terms, perhaps because you > don't understand what REALITY is. > > The "Behavior of the Input" comes from the input alone, and doesn't > depend on the emulator doing anything. > Static strings do not become dynamic processes unless and until they are simulated. > The emulation only REVEALS the behavior to the decider, not create 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]
Page 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7 Next page →
Back to top | Article view | comp.theory
csiph-web