From Newsgroup: comp.ai.philosophy

On 2025-11-17, olcott <polcott333@gmail.com> wrote:

On 11/15/2025 8:48 PM, Kaz Kylheku wrote:

On 2025-11-16, olcott <polcott333@gmail.com> wrote:

HHH cannot possibly report on the behavior
of its caller because HHH has no way of
knowing what function is calling it.

This means that when the halting problem
requires HHH to report on the behavior of
its caller: DD() that its is requiring
something outside the scope of computation.

That's dumber than the Witch scene in Monty Python and The Holy Grail.

*I will be utterly relentless about this*
*I will be utterly relentless about this*
*I will be utterly relentless about this*
*I will be utterly relentless about this*

Yes and now if you could just translate that
mere baseless rhetoric into actual reasoning
with a sound basis.

Not to denigrate you but I think that this
would be totally out of your depth as it
would be for most everyone.

I am certainly not smarter than Turing, but you think you are.

I do not believe that HHH is required to report on the behavior
of its caller. There is no such thing.

In the computing environment you have devised, the top activation of HHH
has a caller, which is the (one and only) activation of main. That
observation is not interesting or relevant, and, more importantly,
/must/ not be relevant.

Pure functions do not have a context. Given an expression f(x, y),
it denotes eactly the same calculation no matter where it is placed,
provided that the placement does not override the meaning of the
symbol f (that is to say, there isn't a lexically enclosing
shadowing redefinition of f).

This property is called "referential transparency" in CS.

The test case D can incorporate any one of an infinite number
of possible representations of the /algorithm/ on which H is based.

It uses that algorithm, but does not call H.

The circumstances of the halting problem are not limited to the narrow conception that is embodied in just your C programming experiment.

It is about algorithms, not specific functions in a programming
language, which are all in the same image, such that D
calls the same address H that is the procedure deciding it.

You've not acknowledged your mistakes, such as:

- continuing to use impure functions (e.g. mutating global
execution trace buffer; distinguishing "Root == 1" H
functions from "Root == 0").

- treating unequal addresses as necessarily unequal functions.

- conflating the instruction events from multiple simulations
into a single execution trace buffer.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.ai.philosophy

On 2025-11-19, Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> wrote:

On 19/11/2025 17:48, Kaz Kylheku wrote:

Recursive functions and Turing machines are equivalent. The halting
problem is about recursive functions too.

There exists an equivalent ...

In any case, topics in the halting problem cannot be properly explored
using impure procedures --- not in such a way that we assume that those
procedures directly correspond to recursive functions.

No. The Halting Theorem has no problems demonstrable with leaky
simulation (emulation) sandboxes.

That is correct, but what you cannot say is that specific stateful
procedures in that leaky simulation correspond to pure recursive
functions in the theory of computation. (And, therefore, to
individual Turing Machines.)

You can build a model of your leaky sandbox in whch you identify
what the Turing Machines or functions are.

(Once you do that, it would probably make sense for your claims about
halting to revolve around that.)

Topics can be explored with leaky sandboxes, topics such as "How can
leaky sandboxes and their effects be characterised?" and "What are the relationships between various recursive functions and various Turing
Machines and their generalisations?"

Olcott's leaky Halt7.obj/x86utm_exe sandbox /cannot/ be
characterized in such a way we refer to the stateful C procedure
HHH as a recursive primitive function.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.ai.philosophy

On 2025-11-19, olcott <polcott333@gmail.com> wrote:

ChatGPT agrees yet in this case I cannot independently
verify that it is correct.

Why, how intellectually modest of you.

Can you describe what it is that you are not able to do, exactly?

What does it mean when you "verify" something correct?

I imagine it is something like, you search your mind for a baseless
belief backed by handwaving arguments whch matches the poposition
in question. If you find such a belief, then the proposition is
verified correct. If you find an opposite belief, then the proposition
is incorrect. Otherwise it remains unverified.

Close?
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21a-Linux NewsLink 1.2