From Newsgroup: comp.ai.philosophy

On 10/2/2026 9:32 AM, Python wrote:

Le 02/10/2026 à 16:15, olcott a écrit :

On 10/2/2026 8:58 AM, Python wrote:

Le 02/10/2026 à 15:56, olcott a écrit :

On 10/2/2026 8:32 AM, Python wrote:

Le 02/10/2026 à 15:24, olcott a écrit :

On 10/2/2026 7:59 AM, Python wrote:

Le 02/10/2026 à 14:28, olcott a écrit :

On 10/1/2026 10:05 PM, dart200 wrote:

On 10/1/26 5:28 PM, Chris M. Thomasson wrote:

On 10/1/2026 3:54 PM, dart200 wrote:
[...]

Are you saying that the halting problem is not solvable? If >>>>>>>>>> so, so what?

it is solvable for an enumerable set of machines that includes >>>>>>>>> all possible output sequences, it is not solvable for all
possible machines

The key mistake of the halting theorem is that
it requires a halt decider to report on the behavior
of the direct execution of DD() from main()

https://github.com/plolcott/x86utm/blob/master/README.md
This is outside of the Church-Turing scope when this scope
is understood to only allow finite string transformation
rules to be applied to finite string inputs to derive any
any all outputs.

The only correct finite string transformation rules that
HHH is allowed to apply to its finite string input DD are
specified by the operational semantics of the C programming
language.

There are no correct finite string transformation rules that
HHH can possibly apply to its input finite string that derive
the behavior of DD directly executed in main().

Peter, this distinction between "the operational semantics of C" >>>>>>> and "the behavior of DD directly executed from main()" does not >>>>>>> exist.

Counter-factual you just did not pay close enough
attention and merely leaped to a false conclusion.

Peter, saying "counter-factual" is not a counterargument.

It has taken me many thousands of hours very carefully
compose the few words that I just said. Carefully
study them for a few hours until you fully understand
every subtle nuance of every single detail before you
reply.

Peter, the number of hours you spent composing a statement has no
bearing on whether it is true.

That is true, None-the-less I will no longer
tolerate people that glance at a couple of
my words before artificially contriving a
rebuttal that conclusively proves that they
did not bother to pay complete attention
to every detail of what I said.

Peter, then demonstrate that.

This was a very excellent reply:

Quote the specific words of yours that I failed to pay attention to, and explain what they mean that my response failed to address.

You wrote:

   "The only correct finite string transformation rules that
    HHH is allowed to apply to its finite string input DD are
    specified by the operational semantics of the C programming
    language."

I explicitly agreed with that premise.

You then wrote:

   "There are no correct finite string transformation rules that
    HHH can possibly apply to its input finite string that derive
    the behavior of DD directly executed in main()."

That is the conclusion I challenged.

My objection is very specific: the behavior of DD when executed from
main() is itself generated by successive applications of the operational semantics of C.

So there is no "artificially contrived rebuttal" here.

If I have misunderstood what you mean by "derive the behavior of DD
directly executed in main()", define that phrase precisely and show
where my interpretation differs from yours.

That would resolve the issue immediately.

--
Copyright 2026 Olcott

My 28 year goal has been to make
"true on the basis of meaning expressed in language"
reliably computable for the entire body of general knowledge.
The complete structure of this system is now defined.

The entire body of knowledge expressed in language is
comprised of two types of relations between finite strings:
(a) *Axioms* Expressions of language that are stipulated to be true.

My system bridges the analytic/synthetic distinction by
expressly encoding all empirical "atomic facts" in a formal
language such as CycL of the Cyc project.

(b) *Inference Rules* Expressions of language that are semantically
entailed syntactically from (a) and/or (b).
--- Synchronet 3.22a-Linux NewsLink 1.2