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: Tue, 15 Oct 2024 22:11:52 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <9f364b73fd521b2700b2dd0a0e7300a2e7a9710b@i2pn2.org>
References: <ve39pb$24k00$1@dont-email.me> <veb557$3lbkf$2@dont-email.me>
 <2e6d8fc76e4e70decca1df44f49b338e61cc557e@i2pn2.org>
 <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 16 Oct 2024 02:11:52 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="2226561"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
In-Reply-To: <velnfc$1n3gb$1@dont-email.me>
Content-Language: en-US
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 6206
Lines: 114

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.

> 
> < It also
>> says that a conterargument may use a different stipulative definition
>> for the same term.
>>
> 
> When evaluating the the deductive validity of my reasoning
> changing the premises is the strawman deception.
> https://iep.utm.edu/val-snd/

And changing the criteria of terminating is a strawman deception on YOUR 
part.

> 
> When evaluating the external truth of my stipulated definition
> premises and thus the soundness of my reasoning

Which is INVALID, as it isn't compatible with the system, so can NEVER 
be true.

> 
> one cannot change the subject away from the termination analysis
> of C functions to the halt deciders of the theory of computation
> this too is the strawman deception.

Right, which look at the FULL behavior of the function, and EVERYTHING 
the call, which means includes

> 
> To the best of my knowledge all of my stipulative definitions
> are consistent with the terms-of-the-art of the fields of the
> termination analysis of C functions and x86 emulation.
> 

Nope, as "Termination" is a property of PROGRAM not just C functions, 
unless they can also meet the requirements of being a Computer Science 
Program, which means they are condidered to contain ALL the code they use.

DDD is not such a function unless you include as part of its definition 
the full definition of the behavior of the HHH that it is calling (and 
thus HHH can not assume it might behave diffferent then what the HHH 
that is actually being asked does).

Thus, you can neither redefine the criteria for HHH and still call it 
termination, or say that the input is restricted to just the code of the 
C function DDD.

Sorry, you are just WRONG, and your refuse to undertstand this makes you 
STUPID.