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

On 10/16/24 1:42 PM, olcott wrote:

On 10/16/2024 12:24 PM, joes wrote:

Am Wed, 16 Oct 2024 12:13:12 -0500 schrieb olcott:

On 10/16/2024 3:05 AM, Mikko wrote:

On 2024-10-16 03:52:00 +0000, olcott said:

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.

There is no known way to construct one that isn't. No computer can
execute a function that is not Turing computable.

In other words you think that functions that rely on global data such
that they are not a pure function of their inputs are A OK?

Says the one with an if(Root).
Apart from that, purity has nothing to do with computability.
>

 Quite a few experts agree that the purity of a function
ensures its computability. It was like pulling teeth to
get this out of them. It was like the computer science
experts desperately wanted to remain totally ignorant
of mapping computer science to software engineering.
 

Yes, purity will ensure that a function is a computation (not computability, you don't seem to understand the difference).
Being a computation doesn't mean the function is correct.
You HHH and family are NOT "pure functions" and do so in a way that makes them NOT EQUivALENT to a Turing Machine.
Your HHH / DDD is also not a properly split decider / input pair due to your intermingling of address space, as shown by your thought that the repesentation of DDD doesn't need to include the code for HHH because it is there.
That means the representation of DDD that you use is NOT a correct representaion of the program, which is what you base your equivocation logic on.