Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory,sci.logic,comp.ai.philosophy
Subject: Re: People are still trying to get away with disagreeing with the
 semantics of the x86 language
Date: Sat, 29 Jun 2024 12:45:08 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <v5pdmk$1gd9e$1@i2pn2.org>
References: <v5pbjf$55h$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 29 Jun 2024 16:45:08 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="1586478"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
X-Spam-Checker-Version: SpamAssassin 4.0.0
Content-Language: en-US
In-Reply-To: <v5pbjf$55h$1@dont-email.me>
Bytes: 6978
Lines: 153

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,