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

On 10/15/2024 9:12 PM, Richard Damon wrote:

On 10/15/24 6:03 PM, olcott wrote:

On 10/15/2024 4:39 PM, joes wrote:

Am Tue, 15 Oct 2024 14:56:01 -0500 schrieb olcott:

On 10/15/2024 2:29 PM, joes wrote:

Am Tue, 15 Oct 2024 14:18:52 -0500 schrieb olcott:

On 10/15/2024 10:32 AM, joes wrote:

Am Tue, 15 Oct 2024 07:33:47 -0500 schrieb olcott:

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.
*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.

Stipulative definitions can also not be correct. Correctness is
simply out of scope. It can be rejected though. Is your best defense
really "it has no truth value"?

It is the same as verifying that a conclusion logically follows form
its premises when hypothesizing that the premises are true.

What is the same?

>

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.

And not a function that can't be simulated by HHH.

Meaning, DDD is terminating function, because it reaches its return,
even though HHH can't simulate the call to itself (because a simulator
terminates only when its input does, so it can't halt simulating
itself).

In other words you insist on failing to understand that the behavior of
DDD after HHH aborts its emulation is different than the behavior that
requires HHH to abort its emulation.

>

WDYM "after"?

>
The executed DDD begins its trace before HHH(DDD)
is invoked.
>
The emulated DDD begins its trace only after HHH(DDD)
is invoked.
>
This makes it possible for HHH(DDD) to return to DDD
and impossible for any HHH(DDD) to return to any DDD.
>

 Nope, since the emulated HHH in the emulation of DDD will do EXACTLY like the directly executed HHH, and thus that result is what a correct emulation needs to show.
 

The difference in behavior is because DDD of the
relative execution order of DDD and HHH.
(a) The executed DDD is executed before HHH.
(b) DDD is emulated after HHH is executed.
This is what makes the behavior of DDD different
between these two cases.
You seem to be saying that the executed HHH must change
its own order of execution relative to its emulated DDD
such that the emulated DDD begins before its own emulator
starts running.
Is this what you mean?
Can you see that the execution order is different?
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer