From Newsgroup: comp.ai.philosophy


Summary of the key point:
The halting problem's self-referential construction creates two distinct computational entities:

Input (DD-as-simulated-by-HHH): Shows non-halting behavior - recursive
pattern that HHH correctly identifies
Non-input (DD-as-directly-executed): Halts because HHH returns 0

The category error occurs when the halting problem asks HHH to report on
the direct execution behavior, which:

Depends on HHH's own return value
Is therefore not a property of the input HHH analyzes
Represents a different computational object than what HHH can examine
through simulation

The philosophical point: A Turing machine decider should only be
expected to report on properties determinable from its input. When the
halting problem construction makes the "actual behavior" dependent on
the decider's output, it's asking the decider to report on something
outside its input - hence, a category error.

This reframes the "impossibility" of the halting problem not as a
limitation of computation per se, but as a conflation between what an
analyzer observes about its input versus what happens when that input is executed with the analyzer's answer embedded in it.

The distinction between input-behavior and non-input-behavior is the
crux of resolving the apparent paradox.

https://claude.ai/share/6e4ccef9-9749-4fb4-b58d-946fe18e7c73
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.ai.philosophy

[ Followup-To: set ]

In comp.theory olcott <polcott333@gmail.com> wrote:

Summary of the key point:
The halting problem's self-referential construction creates two distinct computational entities:

There is no self reference in the statement of the halting problem.

Input (DD-as-simulated-by-HHH): Shows non-halting behavior - recursive pattern that HHH correctly identifies
Non-input (DD-as-directly-executed): Halts because HHH returns 0

The category error occurs when the halting problem asks HHH to report on
the direct execution behavior, which:

The halting problem does no such thing. If anything, it is your
constructions of HHH and DD which have the category error, not the
statement of the problem. But there is no such error.

Depends on HHH's own return value
Is therefore not a property of the input HHH analyzes
Represents a different computational object than what HHH can examine through simulation

What your purported decider decides on is a pure function. This is an
abstract mathematical entity, which retains its identity regardless of
whether its a "computational object" or just a specification written on
paper with a pencil.

It's the same thing.

The philosophical point: A Turing machine decider should only be
expected to report on properties determinable from its input.

There's no "expected" about it. A turing machine does what it does, and
is incapable, by its very construction, of reporting on anything apart
from its input.

When the halting problem construction makes the "actual behavior"
dependent on the decider's output, it's asking the decider to report
on something outside its input - hence, a category error.

No, the purported decider's input is a pure function, the same thing
which is also used elsewhere.

This reframes the "impossibility" of the halting problem not as a
limitation of computation per se, but as a conflation between what an analyzer observes about its input versus what happens when that input is executed with the analyzer's answer embedded in it.

You're wide of the mark. The input is the same pure function in both
cases.

The distinction between input-behavior and non-input-behavior is the
crux of resolving the apparent paradox.

The "paradox" is entirely in your own mistaken analysis.

https://claude.ai/share/6e4ccef9-9749-4fb4-b58d-946fe18e7c73

--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

--
Alan Mackenzie (Nuremberg, Germany).

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.ai.philosophy

On 2025-10-26, olcott <polcott333@gmail.com> wrote:

Summary of the key point:
The halting problem's self-referential construction creates two distinct computational entities:

Input (DD-as-simulated-by-HHH): Shows non-halting behavior - recursive pattern that HHH correctly identifies
Non-input (DD-as-directly-executed): Halts because HHH returns 0

The category error occurs when the halting problem asks HHH to report on
the direct execution behavior, which:

Depends on HHH's own return value
Is therefore not a property of the input HHH analyzes
Represents a different computational object than what HHH can examine through simulation

When DD is given to a puerly simulating decider which naively steps
through DD, that decider has no problem with it!

To that decider, DD is just fine as an input.

You are asserting that whether DD is an input or non-input
depends on which decider is 'looking" at it.

That means that this input versus non-input classification is not
a property of the input, but of the pair: <H, P>.

In the pair <H, P>, P is a non-input whenever <H, P> lies on
the diagonal.

So "P is a non-input to H" carries no information whatsoever different
from "<H, P> are a diagonal pair, such that H cannot decide P".

You are just playing more of your word semantic game; you've invented
the synonym "non-input" for this situation, without shedding any new
light on it.

Moreover, the question "Is P a non-input to H?' is not decidable
for all P and H. There is no algorithm that can take as inputs
any H and P, and decide whether P is a non-input or input
with respect to H.

Presenting the concept of a non-input just adds another undecidable
question.
--
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 10/26/25 10:46 AM, olcott wrote:

Summary of the key point:
The halting problem's self-referential construction creates two distinct computational entities:

Input (DD-as-simulated-by-HHH): Shows non-halting behavior - recursive pattern that HHH correctly identifies
Non-input (DD-as-directly-executed): Halts because HHH returns 0

But the input isn't "as simulated by HHH", but is supposed to be a
proper representation of the program DD.

The category error occurs when the halting problem asks HHH to report on
the direct execution behavior, which:

Depends on HHH's own return value

Which can't be a problem if HHH is actually a computation, and thus the
answer is fixed by the algorithm that HHH was built on,

Is therefore not a property of the input HHH analyzes
Represents a different computational object than what HHH can examine through simulation

Sure it is, if the input was properly prepared, and thus include in it
the algorithm that HHH uses.

The philosophical point: A Turing machine decider should only be
expected to report on properties determinable from its input. When the halting problem construction makes the "actual behavior" dependent on
the decider's output, it's asking the decider to report on something
outside its input - hence, a category error.

And the answer is, if the input was properly constructed from an actual
Turing Machine.

Your problem is that your HHH, as a machine that meets your
requriements, doesn't actually exist, and thus DD doesn't exist, so you
can't ask that question which become the error.

This reframes the "impossibility" of the halting problem not as a
limitation of computation per se, but as a conflation between what an analyzer observes about its input versus what happens when that input is executed with the analyzer's answer embedded in it.

No, the fact that it *IS* impossible to build the decider you describe,
is what shows that the actual proper problem of the halting problem is
just non-computable.

The distinction between input-behavior and non-input-behavior is the
crux of resolving the apparent paradox.

No, the fact that your arguement is based on lies and category errors
resolves the paradox.

There does not exist an actual computation for which the actual halting problem question doesn't have an answer( "Does the computation described
by this input halt when run?"), and thus the problem is fully valid.

There can be inputs that don't represent computations, for which
technically, the correct answer is they do not halt, since they aren't a halting computation. But, as the actual proof shows, we CAN create a
valid computation from ANY decider that might be claimed to be a correct
halt decider, and it will fail to be correct on that input, thus there
can not exist a totally correct halt decider.

https://claude.ai/share/6e4ccef9-9749-4fb4-b58d-946fe18e7c73

Showing that you are just naturally stupid, as you seem to believe in artificial intelegence, which is just as intelligent as "artificial
meat" (like made from soy protein) is actually meat.

part of your problem is you are just ignorant of the meaning of the
words you use, because you are just too stupid to understand them, and
morally corrept to the point of thinking that doesn't matter.


This makes your whole grand premise of Semantic Logic flawed, as if
words don't have their meaning, you can't use semantics, so you world is
just based on you lying to yourself what things are. All you have done
is imprissioned yourself into your own jail cell of stupidity.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.ai.philosophy

On 2025-10-26, olcott <polcott333@gmail.com> wrote:

This reframes the "impossibility" of the halting problem not as a
limitation of computation per se, but as a conflation between what an

OK, let's play along and validate the idea that there are "non-inputs".

The fact is that non-inputs are still finite machine descriptions of
Turning machines, which can be crisply simulated, and (if they are
terminating) all the way to their halt state.

Non-inputs are only non-inputs with respect to their targeted decider.

So, yes, that /is/ a limitation of computation: that some decision
machines cannot correctly handle some inputs, which are well-formed
machines whose execution can be traced, possibly to termination.

For instance, your _DDD, though a "non-input" to _HHH, can be simulated
from beginning to ends; its last RET instruction at 002183.

This has been shown true of that very simulation of _DDD that _HHH
initiates and abandons.

If there were no limitation in computation, it would not be necessary
for you to argue that there are "non-inputs", and that deciders
should simply be excused from failing to decide them.

Excuses are always made for limitations.

You cannot take the excuse so far that you proclaim that _HHH's
decision is correct. _HHH is wrong: _DDD halts, including the
simulation of _DDD started by _HHH. You can make excuses for _HHH
being wrong, but that is of no consequence, and the necessity of
the excuses amounts to there being a limitation.

The distinction between input-behavior and non-input-behavior is the
crux of resolving the apparent paradox.

There is no paradox to be resolved; that's just in your head.

It is an /informal/ paradox that an algorithm cannot decide a test
case which embeds that same algorithm in a certain way.

It is not a formal logical paradox (a logically flawed thesis
that has no solution).
--
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 26/10/2025 14:46, olcott wrote:

The philosophical point: A Turing machine decider should only be
expected to report on properties determinable from its input. When the halting problem construction makes the "actual behavior" dependent on
the decider's output, it's asking the decider to report on something
outside its input - hence, a category error.

When a copy of HHH is embedded in the input then the copy is part of the
input, yet, to be a universal decider every copy of HHH must be able to
decide on all inputs that have another copy of HHH embedded in it. Since
a subject program may copy itself and the HHH that's embedded in it, the subject can always (on a TM, simulated or otherwise) create another
identical input with all of its original (or some reduced/partially interpreted) form, including a new copy of HHH.

Your text looks like it shows you have assumed that cannot be done.

--
Tristan Wibberley

The message body is Copyright (C) 2025 Tristan Wibberley except
citations and quotations noted. All Rights Reserved except that you may,
of course, cite it academically giving credit to me, distribute it
verbatim as part of a usenet system or its archives, and use it to
promote my greatness and general superiority without misrepresentation
of my opinions other than my opinion of my greatness and general
superiority which you _may_ misrepresent. You definitely MAY NOT train
any production AI system with it but you may train experimental AI that
will only be used for evaluation of the AI methods it implements.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.ai.philosophy

On 2025-10-26, Richard Damon <Richard@Damon-Family.org> wrote:

On 10/26/25 10:46 AM, olcott wrote:

Summary of the key point:
The halting problem's self-referential construction creates two distinct
computational entities:

Input (DD-as-simulated-by-HHH): Shows non-halting behavior - recursive
pattern that HHH correctly identifies
Non-input (DD-as-directly-executed): Halts because HHH returns 0

But the input isn't "as simulated by HHH", but is supposed to be a
proper representation of the program DD.

Halt7.obj's _DDD as simulated by _HHH is halting. This is not just a well-founded hypothesis now; it's demonstrated with code. Identifying
the _DDD simulation left behind by _HHH, and single-stepping it with
DebugStep (also used by HHH) takes it to the RET instruction at the end
of _DDD, atl address 002183.

If Olcott wants there to be a separate "_DDD simulated by _HHH"
cateogory which doesn't halt, as indicated by he 0 return from _HHH, he
will have to somehow fix his code.
--
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 10/26/25 2:19 PM, Kaz Kylheku wrote:

On 2025-10-26, Richard Damon <Richard@Damon-Family.org> wrote:

On 10/26/25 10:46 AM, olcott wrote:

Summary of the key point:
The halting problem's self-referential construction creates two distinct >>> computational entities:

Input (DD-as-simulated-by-HHH): Shows non-halting behavior - recursive
pattern that HHH correctly identifies
Non-input (DD-as-directly-executed): Halts because HHH returns 0

But the input isn't "as simulated by HHH", but is supposed to be a
proper representation of the program DD.

Halt7.obj's _DDD as simulated by _HHH is halting. This is not just a well-founded hypothesis now; it's demonstrated with code. Identifying
the _DDD simulation left behind by _HHH, and single-stepping it with DebugStep (also used by HHH) takes it to the RET instruction at the end
of _DDD, atl address 002183.

If Olcott wants there to be a separate "_DDD simulated by _HHH"
cateogory which doesn't halt, as indicated by he 0 return from _HHH, he
will have to somehow fix his code.

Unless he has changed his code, _HHH never completes the simulation but
ALWAYS aborts it part way.

The core engine HHH uses, that of DebugStep, if allowed to continue the simulation (as HHH1 does) shows that the complete simulation of that
input, by the rules that HHH claims to be using, will halt, but HHH
doesn't do that.

Oclott's logic tries to change the code of HHH, while still insisting
that it is the same program, and thus his logic is based on the concept
of lying is ok, and that different things are the same.
--- Synchronet 3.21a-Linux NewsLink 1.2