Re: The actual truth is that ... industry standard stipulative definitions

Liste des GroupesRevenir à theory 
Sujet : Re: The actual truth is that ... industry standard stipulative definitions
De : richard (at) *nospam* damon-family.org (Richard Damon)
Groupes : comp.theory
Date : 16. Oct 2024, 03:12:02
Autres entêtes
Organisation : i2pn2 (i2pn.org)
Message-ID : <f154c55c56747517580dd06249a39a48a4eeee1d@i2pn2.org>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
User-Agent : Mozilla Thunderbird
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.
But since it CAN be incorrect, that doesn't hold.
Stiplutive definition can not redefine terms of a Formal Logic and have the argument stay in that Formal Logic system.  PERIOD, by the definition of a Formal Logic System.
You can only make your claim if you acknoldge that you are not staying in the field of Computation Theory, and thus can't even rely on any facts IN computation theory as they may not hold with your changed definition.
Thus, a premise that includes a stiplitive definition that is in contradiction to the Formal Logic System the statement is claimed to be in is just INVALID, as it is not allowed.
It isn't that the statement is FALSE, but the statement is DEFINITIONALLY excluded from the system.

 
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.
Only to your stupid claims.

 
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.
But only if the stipulation is ALLOWED TO OCCUR in the system.
All you are doing is proving that you don't understand the rules of Formal Logic.

 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.
Right. and DDD does that. Since the BEHAVIOR of a function is DEFINED to be what it does when it is directly executed.

 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.
Which isn't accurate, because to be compatible with your above definition of behavior, to be complete, it must not ABORT.
While some fields allow for just partial emulation, those fields also limit what those emulation indicate, and they do not claim to indicate non-termination.
Sorry, you are just using your mis-learned by rote non-education come out.

 A *correct_x86_emulation* of non-terminating inputs includes at
least N steps of *correct_x86_emulation*.
No, in includes an UNBOUNDED number of steps of correct x86 emulations.
Only N steps would be "Not yet terminating"
This error is a result of your previous incorrect definition.

 DDD *correctly_emulated_by* HHH refers to a *correct_x86_emulation*.
This also adds that HHH is emulating itself emulating DDD at least once.
Nope, because you used a wrong definition to try to pull an equivocation.
Yes, some field say "correct emulation" determine behavior
Some fields allow a "corect emulation" to be a partial emulation.
No field allows both, so you are just equivocating on the meaning of "correct emulation"

 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 no HHH that returns an answer did a correct emulation by the definition that shows behavior, and thus your statement is just invalid.

 Each of the directly executed HHH emulator/analyzers that returns
0 correctly reports the above *non_terminating _behavior* of its input.
Nope, proven 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/
So, since your arguement is based on trying to change the meaning of the definition of the terms you are using, you are just admitting that you arguement is just a strawman.

 When evaluating the external truth of my stipulated definition
premises and thus the soundness of my reasoning
But your stipulated definition was VOID on its utterance, as it violated the definitions of the formal system. That means the following statements can not use it either, or they are voided from the logic system.

 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.
But the Theory of Termination Analysis of C functions defines that the C functions it works on include ALL the behavior of any function that function calls.
Thus, to ignore that requirement makes your arguement a strawman.

 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.

Date Sujet#  Auteur
9 Jul 25 o 

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal