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

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

On 10/15/24 8:39 AM, olcott wrote:

On 10/15/2024 4:58 AM, joes wrote:

Am Mon, 14 Oct 2024 20:12:37 -0500 schrieb olcott:

On 10/14/2024 6:50 PM, Richard Damon wrote:

On 10/14/24 12:05 PM, olcott wrote:

On 10/14/2024 6:21 AM, Richard Damon wrote:

On 10/14/24 5:53 AM, olcott wrote:

On 10/14/2024 3:21 AM, Mikko wrote:

On 2024-10-13 12:49:01 +0000, Richard Damon said:

On 10/12/24 8:11 PM, olcott wrote:

>

Trying to change to a different analytical framework than the one that
I am stipulating is the strawman deception. *Essentially an
intentional fallacy of equivocation error*

But, you claim to be working on that Halting Problem,

I quit claiming this many messages ago and you didn't bother to notice.

Can you please give the date and time? Did you also explicitly disclaim
it or just silently leave it out?
>

>
Even people of low intelligence that are not trying to
be as disagreeable as possible would be able to notice
that a specified C function is not a Turing machine.

 But it needs to be computationally equivalent to one to ask about Termination.
 

Not at all.
https://en.wikipedia.org/wiki/Pure_function
A termination analyzer need not be a Turing computable function.
*According to the industry standard definitions that I stipulated*
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.
Each of the directly executed HHH emulator/analyzers that returns
0 correctly reports the above *non_terminating _behavior* of its input.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer