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
Subject: Re: The actual truth is that ... industry standard stipulative
 definitions
Date: Wed, 16 Oct 2024 07:44:36 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <8ed7dfad199cfcadac4e1b1be67f7e91a6ff13f5@i2pn2.org>
References: <ve39pb$24k00$1@dont-email.me> <vebchp$3m87o$1@dont-email.me>
 <1071eb58637e27c9b2b99052ddb14701a147d23a@i2pn2.org>
 <vebeu2$3mp5v$1@dont-email.me>
 <58fef4e221da8d8bc3c274b9ee4d6b7b5dd82990@i2pn2.org>
 <vebmta$3nqde$1@dont-email.me>
 <99541b6e95dc30204bf49057f8f4c4496fbcc3db@i2pn2.org>
 <vedb3s$3g3a$1@dont-email.me> <vedibm$4891$2@dont-email.me>
 <72315c1456c399b2121b3fffe90b933be73e39b6@i2pn2.org>
 <vee6s1$7l0f$1@dont-email.me>
 <1180775691cf24be4a082676bc531877147202e3@i2pn2.org>
 <veec23$8jnq$1@dont-email.me>
 <c81fcbf97a35bd428495b0e70f3b54e545e8ae59@i2pn2.org>
 <vef37r$bknp$2@dont-email.me>
 <7e79306e9771378b032e6832548eeef7429888c4@i2pn2.org>
 <veikaf$14fb3$1@dont-email.me> <veipmb$15764$2@dont-email.me>
 <c56fcfcf793d65bebd7d17db4fccafd1b8dea072@i2pn2.org>
 <vejfg0$1879f$3@dont-email.me> <velajq$1l69v$1@dont-email.me>
 <velnfc$1n3gb$1@dont-email.me>
 <9f364b73fd521b2700b2dd0a0e7300a2e7a9710b@i2pn2.org>
 <ven87e$2230b$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 16 Oct 2024 11:44:36 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="2284055"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
X-Spam-Checker-Version: SpamAssassin 4.0.0
In-Reply-To: <ven87e$2230b$2@dont-email.me>
Content-Language: en-US
Bytes: 5444
Lines: 89

On 10/15/24 10:25 PM, olcott wrote:
> On 10/15/2024 9:11 PM, Richard Damon wrote:
>> On 10/15/24 8:33 AM, olcott wrote:
>>> On 10/15/2024 3:54 AM, Mikko wrote:
>>>> On 2024-10-14 16:05:20 +0000, olcott said:
>>>>
>>>>> A stipulative definition is a type of definition in which
>>>>> a new or currently existing term is given a new specific
>>>>> meaning for the purposes of argument or discussion in a
>>>>> given context. https://en.wikipedia.org/wiki/Stipulative_definition
>>>>>
>>>>> *Disagreeing with a stipulative definition is incorrect*
>>>>
>>>> The Wikipedia page does not say that. It only says that a stipulative
>>>> definition itself cannot be correct.
>>>
>>> If X cannot be incorrect then disagreeing that X is correct
>>> is incorrect.
>>>
>>>> It says nothing about disagreement.
>>>> In particular, one may diagree with the usefulness of a stipulative
>>>> definition.
>>>>
>>>
>>> It seems that my reviewers on this forum make being disagreeable
>>> a top priority.
>>>
>>>> The article also says that the scope of a stipulative definition is
>>>> restricted to an argument or discussion in given context. 
>>>
>>> Once a stipulated definition is provided by its author it continues
>>> to apply to every use of this term when properly qualified.
>>>
>>> A *non_terminating_C_function* is C a function that cannot possibly
>>> reach its own "return" instruction  (final state) thus never terminates.
>>> A *non_terminating_x86_function* is the same idea applied to x86
>>> functions having "ret" instructions. *non_terminating _behavior* refers
>>> to the above definitions.
>>>
>>> It is stipulated that *correct_x86_emulation* means that a finite
>>> string of x86 instructions is emulated according to the semantics
>>> of the x86 language beginning with the first bytes of this string.
>>>
>>> A *correct_x86_emulation* of non-terminating inputs includes at
>>> least N steps of *correct_x86_emulation*.
>>>
>>> DDD *correctly_emulated_by* HHH refers to a *correct_x86_emulation*.
>>> This also adds that HHH is emulating itself emulating DDD at least once.
>>>
>>> void DDD()
>>> {
>>>    HHH(DDD);
>>>    return;
>>> }
>>>
>>> When HHH is an x86 emulation based termination analyzer then
>>> each DDD *correctly_emulated_by* any HHH that it calls never returns.
>>
>> But, to do so, HHH can't abort is eulation, so doesn't answer, and 
>> thius isn't the HHH that you claim to correctly ans
>>
>>>
>>> Each of the directly executed HHH emulator/analyzers that returns
>>> 0 correctly reports the above *non_terminating _behavior* of its input.
>>
>> But, since the input isn't "non-terminating" per the definiton of the 
>> field, you are just WRONG.
>>
> 
> WRONG FIELD YOU FREAKING JACKASS !!!
> 

Really? That is the field of everything you have quoted for your argument!

Analysys of "leafs", of code that calls nothing that isn't part of the 
code under analysys, and Termination as the FINAL behavior of the code.

Try to show me something that is accepted in the field that defines 
non-terminating in the way you want to claim it.

That it can be appied to a non-leaf function (without includig the whole 
branch to make it a leaf-branch), or

That a partial emulation not reaching a final state is proof, by itself, 
that the function is non-terminating.

Go ahead, knock yourself out, and try to find it,

You are just proving that YOU aren't in the field, and are just totally 
ignorant of what you claim to be talking about.