Path: ...!weretis.net!feeder9.news.weretis.net!news.nk.ca!rocksolid2!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 13:59:04 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <v5pi18$1gd9e$2@i2pn2.org>
References: <v5pbjf$55h$1@dont-email.me> <v5pdmk$1gd9e$1@i2pn2.org>
 <v5pfj9$adt$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 17:59:04 -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: <v5pfj9$adt$1@dont-email.me>
Bytes: 7239
Lines: 157

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.