On 2025-08-16 14:53, olcott wrote:

On 8/16/2025 3:48 PM, dbush wrote:

On 8/16/2025 4:46 PM, olcott wrote:

It only needs to watch the details of the simulation
of its input by some means.

And because the input includes something besides a machine description
and the input to that machine, it is DISQUALIFIED.

In my simplified case the machine description has no
input. HHH only has to somehow watch the behavior of
the input. That is all that it needs. Thus HHH is a
pure function of its input in this case.

It doesn't matter whether the machine description has an input; what
matters is that to be a pure function it cannot rely on global states.
You have a static local variable and while that may be local in *scope*
it is still a global state.

André

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 16 Aug 2025 16:16:48 -0500, olcott wrote:

On 8/16/2025 4:10 PM, dbush wrote:

On 8/16/2025 5:07 PM, olcott wrote:

On 8/16/2025 3:55 PM, dbush wrote:

On 8/16/2025 4:53 PM, olcott wrote:

On 8/16/2025 3:48 PM, dbush wrote:

On 8/16/2025 4:46 PM, olcott wrote:

It only needs to watch the details of the simulation of its input >>>>>>> by some means.

And because the input includes something besides a machine
description and the input to that machine, it is DISQUALIFIED.

In my simplified case the machine description has no input.

And because HHH takes another input besides that machine description,
it is DISQUALIFIED from being a halt decider / termination analyzer.

Ultimately the actual computation remains a pure function of its
input.

And because the input of HHH includes something other than a machine
description, it is therefore DISQUALIFIED.

That one HHH seems to do this does not entail that this is required by
every HHH.

Ultimately HHH is a pure function of its input no matter how other implementations are defined.

Even if HHH is a pure function of its input it doesn't stop its caller
from doing the opposite of the reported decision thus confirming the
Halting Problem is undecidable.

/Flibble

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-08-16 15:19, olcott wrote:

On 8/16/2025 4:11 PM, André G. Isaak wrote:

On 2025-08-16 14:53, olcott wrote:

On 8/16/2025 3:48 PM, dbush wrote:

On 8/16/2025 4:46 PM, olcott wrote:

It only needs to watch the details of the simulation
of its input by some means.

And because the input includes something besides a machine
description and the input to that machine, it is DISQUALIFIED.

In my simplified case the machine description has no
input. HHH only has to somehow watch the behavior of
the input. That is all that it needs. Thus HHH is a
pure function of its input in this case.

It doesn't matter whether the machine description has an input; what
matters is that to be a pure function it cannot rely on global states.
You have a static local variable and while that may be local in
*scope* it is still a global state.

André

None-the-less HHH is ultimately a pure function
of the its input in that no HHH needs to see more
than the behavior of this input.

Then rewrite your HHH() without the static local variable. If it is
indeed a pure function, this will be possible. If it isn't, then it
won't be. If it needs the static local variable, then that variable is
an *input*.

What you don't seem to grasp is that in a c function such as

int foo(x, y);

x and y are not the input to the function (in the sense of computational theory); they are the formal parameters to the function.

In the case of *pure* functions, the formal parameters and the input
will be the same. In the case of impure functions, the input will
include more than just the formal parameters.

If you rely on any global variable (including static local variables)
then it is not a pure function.

If either x or y is a pointer, then it is not a pure function. (the
input wouldn't be x or y, it would be the thing x or y points to).

André

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-08-16 15:40, olcott wrote:

On 8/16/2025 4:27 PM, André G. Isaak wrote:

What you don't seem to grasp is that in a c function such as

int foo(x, y);

x and y are not the input to the function (in the sense of
computational theory); they are the formal parameters to the function.

For all practical purposes these are the same thing.

No, they are not. The input to a function is the formal parameters plus
and global variables or local static variables, plus anything passed by
pointer that might be altered between calls.

In the case of *pure* functions, the formal parameters and the input
will be the same. In the case of impure functions, the input will
include more than just the formal parameters.

Yes.

If you rely on any global variable (including static local variables)
then it is not a pure function.

If either x or y is a pointer, then it is not a pure function.

Unless it is a pointer to static data.
C never passes actual strings.

But there is no guarantee that something is a pure function if it is
passed a pointer (or anything containing a pointer). It is possible to
write pure functions which involve pointers as long as the data pointed
to is guaranteed not to change between invocations of the function.

André

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-08-16 15:54, olcott wrote:

On 8/16/2025 4:47 PM, André G. Isaak wrote:

On 2025-08-16 15:40, olcott wrote:

On 8/16/2025 4:27 PM, André G. Isaak wrote:

What you don't seem to grasp is that in a c function such as

int foo(x, y);

x and y are not the input to the function (in the sense of
computational theory); they are the formal parameters to the function. >>>>

For all practical purposes these are the same thing.

No, they are not. The input to a function is the formal parameters
plus and global variables or local static variables, plus anything
passed by pointer that might be altered between calls.

In the case of *pure* functions, the formal parameters and the input
will be the same. In the case of impure functions, the input will
include more than just the formal parameters.

Yes.

If you rely on any global variable (including static local
variables) then it is not a pure function.

If either x or y is a pointer, then it is not a pure function.

Unless it is a pointer to static data.
C never passes actual strings.

But there is no guarantee that something is a pure function if it is
passed a pointer (or anything containing a pointer). It is possible to
write pure functions which involve pointers as long as the data
pointed to is guaranteed not to change between invocations of the
function.

André

*You do not have this exactly correctly*

In computer programming, a pure function is a function that has the
following properties:[1][2]

(1) the function return values are identical for identical arguments (no variation with local static variables, non-local variables, mutable
reference arguments or input streams, i.e., referential transparency), and

(2) the function has no side effects (no mutation of non-local
variables, mutable reference arguments or input/output streams).

https://en.wikipedia.org/wiki/Pure_function

Everything I said is entirely consistent with the above so I don't see
why you would claim that it's incorrect.

André

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 16 Aug 2025 17:07:18 -0500, olcott wrote:

On 8/16/2025 5:01 PM, dbush wrote:

On 8/16/2025 5:50 PM, olcott wrote:

On 8/16/2025 4:46 PM, dbush wrote:

On 8/16/2025 5:43 PM, olcott wrote:

On 8/16/2025 4:38 PM, dbush wrote:

On 8/16/2025 5:33 PM, olcott wrote:

On 8/16/2025 4:25 PM, dbush wrote:

On 8/16/2025 5:16 PM, olcott wrote:

On 8/16/2025 4:10 PM, dbush wrote:

On 8/16/2025 5:07 PM, olcott wrote:

On 8/16/2025 3:55 PM, dbush wrote:

On 8/16/2025 4:53 PM, olcott wrote:

On 8/16/2025 3:48 PM, dbush wrote:

On 8/16/2025 4:46 PM, olcott wrote:

It only needs to watch the details of the simulation of >>>>>>>>>>>>>>> its input by some means.

And because the input includes something besides a machine >>>>>>>>>>>>>> description and the input to that machine, it is
DISQUALIFIED.

In my simplified case the machine description has no input. >>>>>>>>>>>> And because HHH takes another input besides that machine >>>>>>>>>>>> description, it is DISQUALIFIED from being a halt decider / >>>>>>>>>>>> termination analyzer.

Ultimately the actual computation remains a pure function of >>>>>>>>>>> its input.

And because the input of HHH includes something other than a >>>>>>>>>> machine description, it is therefore DISQUALIFIED.

That one HHH seems to do this does not entail that this is
required by every HHH.

Ultimately HHH is a pure function of its input

And if its input includes something other than a machine
description it is DISQUALIFIED.

HHH inherently needs nothing more than the actual behavior of its >>>>>>> input.

And if its input includes something other than a machine
description (which it does) it is DISQUALIFIED.

Like always you deny the verified facts.

And the verified fact is that HHH takes somthing other than a machine
description as input and is therefore DISQUALIFIED from being a halt
decider / termination analyzer.

I already told you too many times that the design of HHH is a pure
function of its inputs

And one of those inputs

No dipshit the only input to the DESIGN of HHH is the machine
description.

Eh? The design of HHH is static and must take any input as a parameter otherwise it doesn't meet the requirements of a halt decider. You are
confused.

/Flibble

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-08-16 17:01, olcott wrote:

On 8/16/2025 5:55 PM, dbush wrote:

A call to HHH with a blank execution trace will behave differently
than a call to HHH with a non-blank execution trace.  That makes it an
input

HHH would create and keep this execution trace
in local memory. It already starts out blank.

But it's not in local memory. It's declared as static, which means it is
a *global* variable. It just happens to have local scope.

Any global variable that your HHH() accesses counts as *an input* to
that function. And this is an input that is not part of the definition
of a halt decider which must take *only* the machine description and
input string as inputs.

You keep insisting that people need to be experts in C to understand
you, but the reality is that people need to understand computational
theory. C is just a tool being used here. And you clearly don't
understand computational theory very well, as evidenced by the fact that
you keep trying to map concepts from computational theory onto concepts
from C where no such direct mapping exists. In the above case you keep confusing the formal parameters of a C function with the inputs of a computations; the two are not the same thing.

André

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/16/25 4:53 PM, olcott wrote:

On 8/16/2025 3:48 PM, dbush wrote:

On 8/16/2025 4:46 PM, olcott wrote:

It only needs to watch the details of the simulation
of its input by some means.

And because the input includes something besides a machine description
and the input to that machine, it is DISQUALIFIED.

In my simplified case the machine description has no
input. HHH only has to somehow watch the behavior of
the input. That is all that it needs. Thus HHH is a
pure function of its input in this case.

But it stops watching before it has seen enough to make the right decision.

That was its error.

The problem is the "pathological" program can put that key information
after the point that the decider stops looking, or if it doesn't stop
looking, it runs forever.

Both make the decider wrong, and its design has to do one or the other.

This is what makes the decision problem uncomputable, as we can make,
for a given decider, an input that it will get wrong.

Thus, there is no decider that gets the answer right for all inputs.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/16/25 5:07 PM, olcott wrote:

On 8/16/2025 3:55 PM, dbush wrote:

On 8/16/2025 4:53 PM, olcott wrote:

On 8/16/2025 3:48 PM, dbush wrote:

On 8/16/2025 4:46 PM, olcott wrote:

It only needs to watch the details of the simulation
of its input by some means.

And because the input includes something besides a machine
description and the input to that machine, it is DISQUALIFIED.

In my simplified case the machine description has no
input.

And because HHH takes another input besides that machine description,
it is DISQUALIFIED from being a halt decider / termination analyzer.

Ultimately the actual computation remains a pure
function of its input.

No, it isn't, as it sends information via a back channel to another
instance of the function.

Pure functions can not take or give information via back channels.

Some HHH(DD) simulates its input until it sees the
*recursive simulation non-halting behavior pattern*
Nothing besides this input is ever actually required.

But the pattern is sees isn't non-halting, as it will be part of a
halting program.

All you are doing is demonstrating that you logic thinks that lies are
ok and wrong answer can just be declared to be right.

So you have no grounds or ability to disprove the climate deniers, as
you "logic" is based on worse techniques then they use.

And of course you can't make a truth predicate, as the truth of a
statement has been made undefined, as false statements can be made true
just by some decree, and thus you system is just BROKEN.

Sorry, all you are doing it proving you are just a bad liar.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/16/25 5:16 PM, olcott wrote:

On 8/16/2025 4:10 PM, dbush wrote:

On 8/16/2025 5:07 PM, olcott wrote:

On 8/16/2025 3:55 PM, dbush wrote:

On 8/16/2025 4:53 PM, olcott wrote:

On 8/16/2025 3:48 PM, dbush wrote:

On 8/16/2025 4:46 PM, olcott wrote:

It only needs to watch the details of the simulation
of its input by some means.

And because the input includes something besides a machine
description and the input to that machine, it is DISQUALIFIED.

In my simplified case the machine description has no
input.

And because HHH takes another input besides that machine
description, it is DISQUALIFIED from being a halt decider /
termination analyzer.

Ultimately the actual computation remains a pure
function of its input.

And because the input of HHH includes something other than a machine
description, it is therefore DISQUALIFIED.

That one HHH seems to do this does not entail
that this is required by every HHH.

Ultimately HHH is a pure function of its input
no matter how other implementations are defined.

Then show us one that is.

This is one of your fundamental problems, you think you can just define something to have a set of properties, and such a thing exists.

That is the world of the insane.

Also remember, to be a "pure function of its input" it can only look at
its input, and thus it can't get the code of HHH from the "shared memory space", that is just the not-allowed global memory. You will need to
include that code in the "input" so HHH can look at it.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/16/25 5:26 PM, olcott wrote:

On 8/16/2025 4:20 PM, Mr Flibble wrote:

On Sat, 16 Aug 2025 16:16:48 -0500, olcott wrote:

On 8/16/2025 4:10 PM, dbush wrote:

On 8/16/2025 5:07 PM, olcott wrote:

On 8/16/2025 3:55 PM, dbush wrote:

On 8/16/2025 4:53 PM, olcott wrote:

On 8/16/2025 3:48 PM, dbush wrote:

On 8/16/2025 4:46 PM, olcott wrote:

It only needs to watch the details of the simulation of its input >>>>>>>>> by some means.

And because the input includes something besides a machine
description and the input to that machine, it is DISQUALIFIED.

In my simplified case the machine description has no input.

And because HHH takes another input besides that machine description, >>>>>> it is DISQUALIFIED from being a halt decider / termination analyzer. >>>>>

Ultimately the actual computation remains a pure function of its
input.

And because the input of HHH includes something other than a machine
description, it is therefore DISQUALIFIED.

That one HHH seems to do this does not entail that this is required by
every HHH.

Ultimately HHH is a pure function of its input no matter how other
implementations are defined.

Even if HHH is a pure function of its input it doesn't stop its caller
from doing the opposite of the reported decision thus confirming the
Halting Problem is undecidable.

/Flibble

Then we would be back to the original point.
Everyone knowing the theory of computation
and Turing machines sufficiently well would
already know that Turing machine deciders
never compute the mapping from their caller.

But need to for their input, even if it matches its caller.

You are just showing that you are admitting defeat by going back to
proven wrong statements.

Sorry, your claims follow the classical pattern of a pathological liar,
you are stuck not able to get to something more basic as that will make
the lies to obvious, and the statements you are trying to use aren't the
actual foundational statements of the system.

Your only excuess for them is that they "seem obvious" to you, but they actually fail to meet the requirements and definitions. This is the
pathology of a pathological liar.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/16/25 5:33 PM, olcott wrote:

On 8/16/2025 4:25 PM, dbush wrote:

On 8/16/2025 5:16 PM, olcott wrote:

On 8/16/2025 4:10 PM, dbush wrote:

On 8/16/2025 5:07 PM, olcott wrote:

On 8/16/2025 3:55 PM, dbush wrote:

On 8/16/2025 4:53 PM, olcott wrote:

On 8/16/2025 3:48 PM, dbush wrote:

On 8/16/2025 4:46 PM, olcott wrote:

It only needs to watch the details of the simulation
of its input by some means.

And because the input includes something besides a machine
description and the input to that machine, it is DISQUALIFIED.

In my simplified case the machine description has no
input.

And because HHH takes another input besides that machine
description, it is DISQUALIFIED from being a halt decider /
termination analyzer.

Ultimately the actual computation remains a pure
function of its input.

And because the input of HHH includes something other than a machine
description, it is therefore DISQUALIFIED.

That one HHH seems to do this does not entail
that this is required by every HHH.

Ultimately HHH is a pure function of its input

And if its input includes something other than a machine description
it is DISQUALIFIED.

HHH inherently needs nothing more than the actual
behavior of its input.

I designed HHH so that it detects a repeating
state and has no idea that DD is calling itself.

Sure it does, it is getting back channel information from the other
instance of itself.

Your "pattern" can't be defined without that information, as it depends
on a comparison between two diffeent contexts. EIther the outer context
know the inner is a version of itself, due to non-turing-completeness,
or it gets the data via an illegal back-channel.

That is one reason that back channel isn't allowed.

All you are doing is proving you don't understand what you are talking
about, but just making up lies that you are beleiving in.

This make you just a pathological liar.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/16/25 5:43 PM, olcott wrote:

On 8/16/2025 4:38 PM, dbush wrote:

On 8/16/2025 5:33 PM, olcott wrote:

On 8/16/2025 4:25 PM, dbush wrote:

On 8/16/2025 5:16 PM, olcott wrote:

On 8/16/2025 4:10 PM, dbush wrote:

On 8/16/2025 5:07 PM, olcott wrote:

On 8/16/2025 3:55 PM, dbush wrote:

On 8/16/2025 4:53 PM, olcott wrote:

On 8/16/2025 3:48 PM, dbush wrote:

On 8/16/2025 4:46 PM, olcott wrote:

It only needs to watch the details of the simulation
of its input by some means.

And because the input includes something besides a machine >>>>>>>>>> description and the input to that machine, it is DISQUALIFIED. >>>>>>>>>

In my simplified case the machine description has no
input.

And because HHH takes another input besides that machine
description, it is DISQUALIFIED from being a halt decider /
termination analyzer.

Ultimately the actual computation remains a pure
function of its input.

And because the input of HHH includes something other than a
machine description, it is therefore DISQUALIFIED.

That one HHH seems to do this does not entail
that this is required by every HHH.

Ultimately HHH is a pure function of its input

And if its input includes something other than a machine description
it is DISQUALIFIED.

HHH inherently needs nothing more than the actual
behavior of its input.

And if its input includes something other than a machine description
(which it does) it is DISQUALIFIED.

Like always you deny the verified facts.
The inherent design of HHH only needs to see the
behavior of its input.

No, YOU deny the verified facts, because you refuse to look at them.

Your "facts: have been disproven, and your only defense for them is to
repeat them, which is no defense, but an admission that you are just
lying that they are facts.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/16/25 5:50 PM, olcott wrote:

On 8/16/2025 4:46 PM, dbush wrote:

On 8/16/2025 5:43 PM, olcott wrote:

On 8/16/2025 4:38 PM, dbush wrote:

On 8/16/2025 5:33 PM, olcott wrote:

On 8/16/2025 4:25 PM, dbush wrote:

On 8/16/2025 5:16 PM, olcott wrote:

On 8/16/2025 4:10 PM, dbush wrote:

On 8/16/2025 5:07 PM, olcott wrote:

On 8/16/2025 3:55 PM, dbush wrote:

On 8/16/2025 4:53 PM, olcott wrote:

On 8/16/2025 3:48 PM, dbush wrote:

On 8/16/2025 4:46 PM, olcott wrote:

It only needs to watch the details of the simulation >>>>>>>>>>>>> of its input by some means.

And because the input includes something besides a machine >>>>>>>>>>>> description and the input to that machine, it is DISQUALIFIED. >>>>>>>>>>>

In my simplified case the machine description has no
input.

And because HHH takes another input besides that machine
description, it is DISQUALIFIED from being a halt decider / >>>>>>>>>> termination analyzer.

Ultimately the actual computation remains a pure
function of its input.

And because the input of HHH includes something other than a
machine description, it is therefore DISQUALIFIED.

That one HHH seems to do this does not entail
that this is required by every HHH.

Ultimately HHH is a pure function of its input

And if its input includes something other than a machine
description it is DISQUALIFIED.

HHH inherently needs nothing more than the actual
behavior of its input.

And if its input includes something other than a machine description
(which it does) it is DISQUALIFIED.

Like always you deny the verified facts.

And the verified fact is that HHH takes somthing other than a machine
description as input and is therefore DISQUALIFIED from being a halt
decider / termination analyzer.

I already told you too many times that the
design of HHH is a pure function of its
inputs and you change the subject away from
the design of HHH to something else because
you are inherently a liar.

And then show that it isn't

After all, HHH looks at memory that isn't part of its input, when it
traces into the code of the HHH that DD calls.

Sorry, you are just showing youa re just a POOR pathological liar that
can't even keep his lies convincing, and proving that you are just
ignorant of the topic you are studing, and happy to stay that way, as
you make no effort to learn the correct meaning of the words.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/16/25 6:07 PM, olcott wrote:

On 8/16/2025 5:01 PM, dbush wrote:

On 8/16/2025 5:50 PM, olcott wrote:

On 8/16/2025 4:46 PM, dbush wrote:

On 8/16/2025 5:43 PM, olcott wrote:

On 8/16/2025 4:38 PM, dbush wrote:

On 8/16/2025 5:33 PM, olcott wrote:

On 8/16/2025 4:25 PM, dbush wrote:

On 8/16/2025 5:16 PM, olcott wrote:

On 8/16/2025 4:10 PM, dbush wrote:

On 8/16/2025 5:07 PM, olcott wrote:

On 8/16/2025 3:55 PM, dbush wrote:

On 8/16/2025 4:53 PM, olcott wrote:

On 8/16/2025 3:48 PM, dbush wrote:

On 8/16/2025 4:46 PM, olcott wrote:

It only needs to watch the details of the simulation >>>>>>>>>>>>>>> of its input by some means.

And because the input includes something besides a machine >>>>>>>>>>>>>> description and the input to that machine, it is
DISQUALIFIED.

In my simplified case the machine description has no >>>>>>>>>>>>> input.

And because HHH takes another input besides that machine >>>>>>>>>>>> description, it is DISQUALIFIED from being a halt decider / >>>>>>>>>>>> termination analyzer.

Ultimately the actual computation remains a pure
function of its input.

And because the input of HHH includes something other than a >>>>>>>>>> machine description, it is therefore DISQUALIFIED.

That one HHH seems to do this does not entail
that this is required by every HHH.

Ultimately HHH is a pure function of its input

And if its input includes something other than a machine
description it is DISQUALIFIED.

HHH inherently needs nothing more than the actual
behavior of its input.

And if its input includes something other than a machine
description (which it does) it is DISQUALIFIED.

Like always you deny the verified facts.

And the verified fact is that HHH takes somthing other than a
machine description as input and is therefore DISQUALIFIED from
being a halt decider / termination analyzer.

I already told you too many times that the
design of HHH is a pure function of its
inputs

And one of those inputs

No dipshit the only input to the DESIGN of HHH
is the machine description.

And not the full one by your claims, which makes you the liar for
claiming it is the machine description.

If you include the code of HHH as required, your later step fails as it
is clear that there isn't just a singular DD in your system, but a
different input for each of your HHHs, so you can't use ones simulaiton
to prove the behavior of another, and shows that your criteria is just nonsense.

is something other than a machine description, therefore HHH is
DISQUALIFIED from being a halt decider / termination analyzer

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 17/08/2025 03:36, olcott wrote:

On 8/16/2025 7:39 PM, André G. Isaak wrote:

<snip>

You keep insisting that people need to be experts in C to
understand you, but the reality is that people need to
understand computational theory.

Not to understand that DD correctly simulated by HHH
cannot possibly reach its "return" instruction final
halt state.

You say that like it matters.
It doesn't.

What matters is that, to qualify as a decider, HHH must return.
And the moment it does, you're screwed.

It is your failure to understand this simple truth that is the
cause of all your problems.

<snip>

Thus when HHH is a computable function that reports
on the behavior of DD correctly simulated by HHH
then the halting problem proofs *ARE REFUTED*

Well, clearly not. If anything, it shows that a UTM halting
decider that works by "correct simulation" is not possible.

If people are going to keep lying about the behavior
of DD correctly simulated by HHH they will also be
dishonest when HHH is a pure function of its inputs.

"correctly simulated" begs the question.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 17/08/2025 05:26, olcott wrote:

On 8/16/2025 10:57 PM, Richard Heathfield wrote:

On 17/08/2025 03:36, olcott wrote:

On 8/16/2025 7:39 PM, André G. Isaak wrote:

<snip>

You keep insisting that people need to be experts in C to
understand you, but the reality is that people need to
understand computational theory.

Not to understand that DD correctly simulated by HHH
cannot possibly reach its "return" instruction final
halt state.

You say that like it matters.
It doesn't.

What matters is that, to qualify as a decider, HHH must return.
And the moment it does, you're screwed.

It is not that I am screwed it is that computer science is changed.

If you say so.

The simulation is correct the return value is correct.

If you say so.

All four chat bot now agree.

That matters a lot.

Thus when HHH is a computable function that reports
on the behavior of DD correctly simulated by HHH
then the halting problem proofs *ARE REFUTED*

Well, clearly not. If anything, it shows that a UTM halting
decider that works by "correct simulation" is not possible.

That is where you are wrong. Correct
simulation is proven beyond all doubt.

I'm sure you're right. The fact that it claims DD doesn't
terminate when it actually does terminate is just one of those
things we have to pretend we didn't notice.

It'll be fine. Duct tape should do it.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Sat, 16 Aug 2025 16:40:46 -0500 schrieb olcott:

On 8/16/2025 4:27 PM, André G. Isaak wrote:

On 2025-08-16 15:19, olcott wrote:

On 8/16/2025 4:11 PM, André G. Isaak wrote:

On 2025-08-16 14:53, olcott wrote:

On 8/16/2025 3:48 PM, dbush wrote:

On 8/16/2025 4:46 PM, olcott wrote:

It only needs to watch the details of the simulation of its input >>>>>>> by some means.

And because the input includes something besides a machine
description and the input to that machine, it is DISQUALIFIED.

In my simplified case the machine description has no input. HHH only >>>>> has to somehow watch the behavior of the input. That is all that it
needs. Thus HHH is a pure function of its input in this case.

It doesn't matter whether the machine description has an input; what
matters is that to be a pure function it cannot rely on global
states. You have a static local variable and while that may be local
in *scope* it is still a global state.

None-the-less HHH is ultimately a pure function of the its input in
that no HHH needs to see more than the behavior of this input.

Then rewrite your HHH() without the static local variable. If it is
indeed a pure function, this will be possible. If it isn't, then it
won't be. If it needs the static local variable, then that variable is
an *input*.
What you don't seem to grasp is that in a c function such as
int foo(x, y);
x and y are not the input to the function (in the sense of
computational theory); they are the formal parameters to the function.

In the case of *pure* functions, the formal parameters and the input
will be the same. In the case of impure functions, the input will
include more than just the formal parameters.

Yes.

If you rely on any global variable (including static local variables)
then it is not a pure function.
If either x or y is a pointer, then it is not a pure function.

Unless it is a pointer to static data.

Static doesn’t mean immutable.

(the input wouldn't be x or y, it would be the thing x or y points to).

With everyone gaslighting me it is not worth the effort. I could make
HHH a pure function of its input and everyone here would just lie about
it.

No need to lie. You can’t make HHH a pure function without breaking it.

--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/16/25 10:36 PM, olcott wrote:

On 8/16/2025 7:39 PM, André G. Isaak wrote:

On 2025-08-16 17:01, olcott wrote:

On 8/16/2025 5:55 PM, dbush wrote:

A call to HHH with a blank execution trace will behave differently
than a call to HHH with a non-blank execution trace.  That makes it
an input

HHH would create and keep this execution trace
in local memory. It already starts out blank.

But it's not in local memory. It's declared as static, which means it
is a *global* variable. It just happens to have local scope.

Yes one HHH in the universe is like that.
Since HHH only needs to see the behavior
of DD (its input) the DESIGN of HHH *is*
a pure function of its input.

In other words, you are just admitting to LYING again by changing the
meaning of a Pure function.

When are you going to stop lying to yourself and trying to pass that
onto the world.

All you are doing is proving how utterly morally corrupt you are, and so
stupid that you don't think it is obvious to everyone else. Irt seems
you are also mentally defective and unable to learn the meaning of words
or have a caring about them.

Since the only HHH you have actually shown doesn't meet your
requirements, HHH doesn't meet your requirements, and you are admitting
that you are just a stupid liar that makes up that things exist.

Any global variable that your HHH() accesses counts as *an input* to
that function. And this is an input that is not part of the definition
of a halt decider which must take *only* the machine description and
input string as inputs.

I was waiting for people to quit lying about the
behavior of DD correctly simulated by HHH before
I handled these details.

But since that claim isn't a sensible statement, but only a statement
about a hypothetical machine that doesn't meet the other requirements
for HHH, it is meaningless.

NO HHH that gives the non-halting answer correctly simulates its input,
and that input has never been shown to be non-halting, but only halting.

Your "logic" system is built on lies.

You keep insisting that people need to be experts in C to understand
you, but the reality is that people need to understand computational
theory.

Not to understand that DD correctly simulated by HHH
cannot possibly reach its "return" instruction final
halt state.

And no HHH that coorrectly simulates its input will ever give an answer,
and the DD that you are thinking about here is a diffferent DD then is
given to your HHH that gives an answer.

Your "logic" is built on the lie that you can call different things to
be the the same thing.

This is just one of the definitions of insanity.

C is just a tool being used here. And you clearly don't understand
computational theory very well, as evidenced by the fact that you keep
trying to map concepts from computational theory onto concepts from C
where no such direct mapping exists.

DD *is* the halting problem counter-example input.
DD correctly simulated by HHH *DOES NOT HALT*
according to the theory of computation where
halting is reaching a final halt state.

No it isn't, not the way you treat it.

The Halting Problem input is a full program, and thus includes the code
of the decider as part of itself, and as part of the input.

The Decider it calls is a single machine, chosen from the set of (Correct/Possible) Halt Deciders.

You talk about HHH as being an infinite set of machines all at once,
which is non-sense, as you can't call an infinite set of machines in a
single machine.

In the above case you keep confusing the formal parameters of a C
function with the inputs of a computations; the two are not the same
thing.

André

Yes inputs was always the wrong term it has always
been arguments as shown below.

SImilar terms for different contexts

Computable functions are the basic objects of study
in computability theory. Informally, a function is
computable if there is an algorithm that computes
the value of the function for every value of its
argument. https://en.wikipedia.org/wiki/Computable_function

And you do know that DD isn't a "Computable Function" because it isn't
actually a "Function", as that term is a term-of-art here with a special meaing: https://en.wikipedia.org/wiki/Function_(mathematics)

The "Function" in "Computable Function" is just a mapping of Domain to
Range, and is computable because there exists a finite algrothim that
computes it.

The Function has arguments.
The Algorithm has inputs, that represent those arguments.

Thus when HHH is a computable function that reports
on the behavior of DD correctly simulated by HHH
then the halting problem proofs *ARE REFUTED*

No, it isn't, and can't be, it is supposed to be the algorithm that
computes the functions defined as the mapping of algorithms and if they
reach a final state when run.

If people are going to keep lying about the behavior
of DD correctly simulated by HHH they will also be
dishonest when HHH is a pure function of its inputs.

Since it is you that is lying about that behavior, it is you that needs
to stop.

From the problem description which you have been claiming to have been
working on for 22 years CLEARLY says that the property/behavior of the
input that is being asked about it the halting behavior of the program
that input represents, as that is the argument of the halting function
it is trying to compute.

All you are doing is proving you don't understand what semantics are, or
what most of the words you use mean, and that you just don't care about
them.

Sorry, all you are doing it proving you are just an ignorant
pathological liar.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/17/25 12:26 AM, olcott wrote:

On 8/16/2025 10:57 PM, Richard Heathfield wrote:

On 17/08/2025 03:36, olcott wrote:

On 8/16/2025 7:39 PM, André G. Isaak wrote:

<snip>

You keep insisting that people need to be experts in C to understand
you, but the reality is that people need to understand computational
theory.

Not to understand that DD correctly simulated by HHH
cannot possibly reach its "return" instruction final
halt state.

You say that like it matters.
It doesn't.

What matters is that, to qualify as a decider, HHH must return. And
the moment it does, you're screwed.

It is not that I am screwed it is that computer science is changed.
The simulation is correct the return value is correct.
All four chat bot now agree.

No, you are screwed, and you did it to yourself by trying to change the
meaing of the words because you made yourself to ignorant to know what
they mean, and refuse to learn, making yourself just an ignorant
pathological liar.

It is your failure to understand this simple truth that is the cause
of all your problems.

<snip>

Thus when HHH is a computable function that reports
on the behavior of DD correctly simulated by HHH
then the halting problem proofs *ARE REFUTED*

Well, clearly not. If anything, it shows that a UTM halting decider
that works by "correct simulation" is not possible.

That is where you are wrong. Correct
simulation is proven beyond all doubt.

Where?

You claim it, but when shown where it is wrong you ignore that.

The "correct simulation" of the input halts, as HHH(DD) returns 0.

The "correct simulation of DD by HHH" is a lie, as your HHH doesn't do
one, and your hypothetical HHH doesn't take the same input, because you
lie about what your input is supposed to be.

Sorry, all you have done is proved that you lie, and don't care about it.

If people are going to keep lying about the behavior
of DD correctly simulated by HHH they will also be
dishonest when HHH is a pure function of its inputs.

"correctly simulated" begs the question.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 17 Aug 2025 08:15:26 -0500, olcott wrote:

On 8/17/2025 1:48 AM, Chris M. Thomasson wrote:

On 8/16/2025 9:26 PM, olcott wrote:
[...]

It is not that I am screwed it is that computer science is changed.
The simulation is correct the return value is correct.
All four chat bot now agree.[...]

Oh, REALLY? Do you lash them when they disagree? Yikes! Thhhhwack!

ChatGPT 5.0 figured out how to say my words much more precisely. Itself
and Gemini previously guessed what the answer should be.

ChatGPT 5.0 wrote a <Rubric> that forced itself and Gemini to think it
all the way through.

Now all five LLM systems figured out the *recursive simulation
non-halting behavior pattern*
and that HHH(DD)==0 is correct all on their own without prompting.

If HHH(DD) reports non-halting as you suggest then DD() will do the
opposite (halt) thus confirming that the Halting Problem is undecidable.

/Flibble

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/17/25 9:23 AM, olcott wrote:

On 8/17/2025 1:19 AM, joes wrote:

Am Sat, 16 Aug 2025 16:40:46 -0500 schrieb olcott:

On 8/16/2025 4:27 PM, André G. Isaak wrote:

On 2025-08-16 15:19, olcott wrote:

On 8/16/2025 4:11 PM, André G. Isaak wrote:

On 2025-08-16 14:53, olcott wrote:

On 8/16/2025 3:48 PM, dbush wrote:

On 8/16/2025 4:46 PM, olcott wrote:

It only needs to watch the details of the simulation of its input >>>>>>>>> by some means.

And because the input includes something besides a machine
description and the input to that machine, it is DISQUALIFIED.

In my simplified case the machine description has no input. HHH only >>>>>>> has to somehow watch the behavior of the input. That is all that it >>>>>>> needs. Thus HHH is a pure function of its input in this case.

It doesn't matter whether the machine description has an input; what >>>>>> matters is that to be a pure function it cannot rely on global
states. You have a static local variable and while that may be local >>>>>> in *scope* it is still a global state.

None-the-less HHH is ultimately a pure function of the its input in
that no HHH needs to see more than the behavior of this input.

Then rewrite your HHH() without the static local variable. If it is
indeed a pure function, this will be possible. If it isn't, then it
won't be. If it needs the static local variable, then that variable is >>>> an *input*.
What you don't seem to grasp is that in a c function such as
int foo(x, y);
x and y are not the input to the function (in the sense of
computational theory); they are the formal parameters to the function.

In the case of *pure* functions, the formal parameters and the input
will be the same. In the case of impure functions, the input will
include more than just the formal parameters.

Yes.

If you rely on any global variable (including static local variables)
then it is not a pure function.
If either x or y is a pointer, then it is not a pure function.

Unless it is a pointer to static data.

Static doesn’t mean immutable.

I meant data that never changes.

So, you admit to using the wrong definitions in the context.

That is one of your big problems, you don't understand that the meaning
of words depend on the context it is used in, and using the wrong
definition is an error, and repeating it after the error is pointed out
becomes a lie (as a reasonable person would understand the error)

This is what makes you the pathological liar you are, because you just
refuse to learn the actual contextual meaning of the words you use, as
you think you have the "right" to lie with another meaning.

(the input wouldn't be x or y, it would be the thing x or y points to). >>>>

With everyone gaslighting me it is not worth the effort. I could make
HHH a pure function of its input and everyone here would just lie about
it.

No need to lie. You can’t make HHH a pure function without breaking it.

Whether or not HHH is a pure function for other
things HHH is a pure function when DD is
correctly simulated by HHH and this DD cannot
possibly reach its own final halt state.

If people didn't flat out lie about it then
everyone would see that this much by itself
is much more progress than anyone else ever
made on the halting problem.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)