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 1 of 7 [1] 2 3 4 5 6 7 Next page →
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-29 11:09 -0500 |
| Subject | People are still trying to get away with disagreeing with the semantics of the x86 language |
| Message-ID | <v5pbjf$55h$1@dont-email.me> |
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
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-29 12:45 -0400 |
| Message-ID | <v5pdmk$1gd9e$1@i2pn2.org> |
| In reply to | #108003 |
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.
Programs are also a COMPLETE specification of the steps the program will
execute when run, so you below code is NOT a complete representation of
the program DDD, so has include implicitly the definition of the
SPECIFIC HHH that it has been pair with. One aspect of this implicit
pairing is that this input inlcudes that EXACT HHH as part of its
definition (and thus is NOT a "template" so when you argue about giving
it to some other machine HHH, either you are giving that HHH a DIFFERENT
input, or that other HHH is giving this DDD paired with the original HHH.
The Behavior of this input, given your claim that HHH will "correctly"
determine it to be non-halting and return that answer, is thus the
behavior of the program DDD, including the code of THAT HHH that will
return to it and return, and thus your HHH is just wrong about the
non-terminating behavior of the input.
Looking at your arguement, we need to look at what you are claiming to
do, and fully define it. Are you trying to make DDD just a template
(which doesn't by itself have behavior), or has DDD been bound to the
decider you are claiming.
In the first case, we can't make any logical determination about THIS
input from the behavior of other deciders looking at OTHER inputs.
In the second case, when the other decider simulates THIS input longer,
it will see that it DOES halt (since THIS HHH returns) so your argument
that "No HHH" can emulate thins
>
> _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
>
Since it is clear that you are making the same mistakes in that paper as
you made here, they don't need repeating.
You are just showing you don't understand any of the basics of the field
you are trying to talk about.
You have programs that are not programs and trying to redefine what
"Halting" means, which just proves you are a liar,
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-29 12:17 -0500 |
| Message-ID | <v5pfj9$adt$1@dont-email.me> |
| In reply to | #108004 |
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*
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]
--
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-29 13:59 -0400 |
| Message-ID | <v5pi18$1gd9e$2@i2pn2.org> |
| In reply to | #108005 |
On 6/29/24 1:17 PM, olcott wrote:
> 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*
>
Nope. Where dp you see that in what he says? Remember, you need to
interpret the words by what he means them to say.
His ONLY definition of "Correct Simulation" is a simulation that exactly
recreates the behavior of the program described by the input, and that
in one that does not stop its simulation. So, NOT your "N Step"
So, you are just stuck in your lies, by trying to change the meaning of
the words that others are argeeing to.
> 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.
Maybe you can say that HHH can not emulate the input to the return, but
that is a different claim.
The behavior for only N steps (N determined by the decider) is NOT a
valid definition of the behavior of the input, as it isn't a property of
the just the input. It is a SUBJECTIVE measure, not an OBJECTIVE measure.
>
> _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]
>
Which, as I have pointed out, CAN'T be the sole definition of the input,
as it does not represent a "program, thus showing you argument is built
on deception.
Your "input", must implicitly include the one and only HHH that THIS
input has been paired to.
Either your problem is just invalid as DDD isn't a program at all,
or you are talking about a large (infinite) set of inputs, and you can't
actually talk about any of them individually, and thus there is no *THE*
behavior of *THE* input, as you don't have just a single program you are
talking about,
or, your argument breaks as all your other deciders get this exact input
calling this exact HHH which shows that it will return when you look at
it with another version of HHH, looking that that original input calling
that original HHH and it sees that the original HHH will return and thus
DDD will return.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-29 13:06 -0500 |
| Message-ID | <v5pifq$1hae$1@dont-email.me> |
| In reply to | #108006 |
On 6/29/2024 12:59 PM, Richard Damon wrote:
> On 6/29/24 1:17 PM, olcott wrote:
>> 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*
>>
>
> Nope. Where dp you see that in what he says? Remember, you need to
> interpret the words by what he means them to say.
>
> His ONLY definition of "Correct Simulation" is a simulation that exactly
> recreates the behavior of the program described by the input, and that
> in one that does not stop its simulation. So, NOT your "N Step"
>
*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
Professor Sipser certainly would not be stupid enough to
disagree with the semantics of the x86 programming language.
You are like the thief caught in the act of stealing money
from a cash register and with the stolen money still in your
hand denying that you have any stolen money in your hand.
--
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-29 14:38 -0400 |
| Message-ID | <v5pkal$1gd9e$3@i2pn2.org> |
| In reply to | #108007 |
On 6/29/24 2:06 PM, olcott wrote:
> On 6/29/2024 12:59 PM, Richard Damon wrote:
>> On 6/29/24 1:17 PM, olcott wrote:
>>> 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*
>>>
>>
>> Nope. Where dp you see that in what he says? Remember, you need to
>> interpret the words by what he means them to say.
>>
>> His ONLY definition of "Correct Simulation" is a simulation that
>> exactly recreates the behavior of the program described by the input,
>> and that in one that does not stop its simulation. So, NOT your "N Step"
>>
>
> *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
>
> Professor Sipser certainly would not be stupid enough to
> disagree with the semantics of the x86 programming language.
Of course not, and the semantics of the x86 programming language say
that the behavior of a piecee of code (which must be fully defined,
unlike your example) is exactly what it does when run.
"Correct Emulation" of code doesn't arbitrarily stop the emulation,
except to generate only a PARTIAL dec
>
> You are like the thief caught in the act of stealing money
> from a cash register and with the stolen money still in your
> hand denying that you have any stolen money in your hand.
>
Really, where is my lie?
YOU are the one that has been caught "red handed" with you numerous lies
that you avoid answering about.
Where is ANY of the authorativive references for ANY of your claims?
MISSING, because you lie about them.
How does your emulator correctly emulate the call instruction when you
don't provide the code it calls?
Where does the x86 language say that ANY instruction begins an
"emulation" of the code provided to the instruction. (Especially when
such emulation has an implicit conditionality to it that you try to ignore).
You are just proving that you whole argument is based on your own lies.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-29 13:47 -0500 |
| Message-ID | <v5pkss$1nkd$1@dont-email.me> |
| In reply to | #108008 |
On 6/29/2024 1:38 PM, Richard Damon wrote:
> On 6/29/24 2:06 PM, olcott wrote:
>> On 6/29/2024 12:59 PM, Richard Damon wrote:
>>> On 6/29/24 1:17 PM, olcott wrote:
>>>> 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*
>>>>
>>>
>>> Nope. Where dp you see that in what he says? Remember, you need to
>>> interpret the words by what he means them to say.
>>>
>>> His ONLY definition of "Correct Simulation" is a simulation that
>>> exactly recreates the behavior of the program described by the input,
>>> and that in one that does not stop its simulation. So, NOT your "N Step"
>>>
>>
>> *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.
--
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-29 15:08 -0400 |
| Message-ID | <v5pm48$1gd9e$4@i2pn2.org> |
| In reply to | #108009 |
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:
>>> On 6/29/2024 12:59 PM, Richard Damon wrote:
>>>> On 6/29/24 1:17 PM, olcott wrote:
>>>>> 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*
>>>>>
>>>>
>>>> Nope. Where dp you see that in what he says? Remember, you need to
>>>> interpret the words by what he means them to say.
>>>>
>>>> His ONLY definition of "Correct Simulation" is a simulation that
>>>> exactly recreates the behavior of the program described by the
>>>> input, and that in one that does not stop its simulation. So, NOT
>>>> your "N Step"
>>>>
>>>
>>> *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.
When you include that code, your claim is non-sense, as the definition
of HHH becomes FIXED AND DEFINED and your terminology meaningless.
"unless" implies choices, which no longer exist, as HHH has been
specifed so it does or it doesn't.
If HHH DOES abort its simulation and returns, then DDD DOES return.
"DDD correctly emulated by HHH", when that emulation is allowed to be
partial, is NOT a valid property for the input, as it is not a property
of JUST the input. So, the ONLY possible meanings are that you are
defining HHH to NEVER abort, at which poiht the "unless" is meaningless
as something defined to never abort can't abort, or that you are just
using wrong definitons of terms.
Sorry, but you "logic" is just filled with illogic and is just based on
deception and lies.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-29 14:25 -0500 |
| Message-ID | <v5pn47$27nl$1@dont-email.me> |
| In reply to | #108010 |
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>
>>>>
>>>> *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).
(b) The semantics of the x86 language.
(c) That HHH is an x86 emulator that correctly emulates
N steps of DDD.
*I am not infallible so I may have left out a detail*
*These facts are deduced from the above facts*
(1) 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.
(2) (1) means that DDD correctly simulated by HHH would
never stop running unless aborted.
I don't understand why you risk your salvation
by trying to get away with such a bald-faced lie.
Those the believe salvation cannot be lost may
correct in the God sees their future behavior thus
never granting them salvation in the first place.
--
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-29 16:10 -0400 |
| Message-ID | <v5ppnb$1gd9e$5@i2pn2.org> |
| In reply to | #108011 |
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. But the "Behavior" of the program represtented by the input, does. Remember, "Behavior" is an attribute of programs, not "inputs", inputs only point to the behavior of the program they represent. Programs do not "stop" just because some emulation of them ceased. > > *I am not infallible so I may have left out a detail* Like FACTS. > > *These facts are deduced from the above facts* > (1) 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. > No, the CALL DOES return (if HHH is a decider), that return is just not emulated by HHH, which being just a PARTIAL emulation doesn't reveal the behavior after it aborts its emulation. > (2) (1) means that DDD correctly simulated by HHH would > never stop running unless aborted. Nope, It means that either you have an HHH that never stops its emulation, and thus fail to be the decider you claim, or that it does and doesn't do > > I don't understand why you risk your salvation > by trying to get away with such a bald-faced lie. But it isn't a lie. It is the truth. You just don't seem to understand that knowing just part of what is correct isn't knowing ALL of what is correct. > > Those the believe salvation cannot be lost may > correct in the God sees their future behavior thus > never granting them salvation in the first place. > That is one theory. Doesn't seem it really matters to you, since it is clear you were never came close to salvation, as you don't accept God's word as his word, but have decided you get to pick and choose from it.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-29 15:17 -0500 |
| Message-ID | <v5pq4l$31tt$1@dont-email.me> |
| In reply to | #108014 |
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 -- 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-29 16:25 -0400 |
| Message-ID | <v5pqji$1gd9d$2@i2pn2.org> |
| In reply to | #108016 |
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. The ONLY simulation that Professor Sipser accepts as correct, is one that shows EXACTLY the behavior of the machine being simulated. Thus, for H to determine that its simulated D would never stop running unless aborted, that means that the UTM simulation of this input would never stop running. That is the only "simulated D" that has meaning in the subject. The "its" refers to the simulation of this machines input. Since that doesn't happen, your H can not correct determine that it would. So, you H can not use the clause to have permission to abort. Now, if you had saind until H correctly determines that its simulaiton of D would never stop running unless aborted you might have had a leg to stand on, except that just has a meaningless "unless" as this H either does or does not abort, and can not do the other thing.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-29 15:33 -0500 |
| Message-ID | <v5pr33$31tt$2@dont-email.me> |
| In reply to | #108017 |
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. > 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? *I don't buy it. You are not that stupid you are a liar* -- Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-29 17:19 -0400 |
| Message-ID | <v5ptp3$1hdtc$1@i2pn2.org> |
| In reply to | #108018 |
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. Since you said "Halt Decider" he would be correct to asume you were talking about Turing Machines. And, in Turing Machines, the only thing talked about as far as "Simulation" would be the UTM, and that ONLY does fully correct and complete simulations, so barring very clear mention otherwise, that is what is assumed. I guess you are just admitting you fell for the trap. > > *I don't buy it. You are not that stupid you are a liar* > But YOU seem to be that stupid, or self-enforced ignorant. You just don't know what is actually true.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-29 17:54 -0500 |
| Message-ID | <v5q3an$4rvs$1@dont-email.me> |
| In reply to | #108019 |
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 !!! _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. -- 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-29 19:46 -0400 |
| Message-ID | <v5q6c2$1hdtc$2@i2pn2.org> |
| In reply to | #108020 |
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
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-29 21:46 -0500 |
| Message-ID | <v5qgu4$aulp$1@dont-email.me> |
| In reply to | #108021 |
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. *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 Even a Turing machine based partial halt decider is locked in to the Turing Machine description language. Is this really over your head? -- Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Mikko <mikko.levanto@iki.fi> |
|---|---|
| Date | 2024-06-30 12:02 +0300 |
| Message-ID | <v5r6vl$erg6$1@dont-email.me> |
| In reply to | #108022 |
On 2024-06-30 02:46:27 +0000, olcott said: > 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. No, they are not. The input to a partial halt decider takes the that has two parts: a description of a Turing machine (or, more generally, an algorithm) and a description of an input to that Turing machine (or algorithm). The input to a temination alanlyzer is different: only the first part is there but not the second part. In particular, the input to AProVE mentioned below does not include any input to the analyzed program. > *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 > > Even a Turing machine based partial halt decider is > locked in to the Turing Machine description language. What does "locked" mean in that context? > Is this really over your head? -- Mikko
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-30 08:34 -0400 |
| Message-ID | <v5rjcm$1jcrr$1@i2pn2.org> |
| In reply to | #108022 |
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. 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 09:07 -0500 |
| Message-ID | <v5roq5$hnqf$1@dont-email.me> |
| In reply to | #108033 |
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. _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]
Page 1 of 7 [1] 2 3 4 5 6 7 Next page →
Back to top | Article view | comp.theory
csiph-web